I'm web programmer and i'm not familiar with networking , i have this next question i have searched many articles on the internet but it was not helpful and i found difficulties with understanding subnetting .. i preach it anyone who can help me to solve this question :)
The question is :
You have been allocated a class B network address: 165.10.0.0/16
Departments Number of employees
D1 800
D2 200
D3 50
D4 1600
D5 210
D6 60
D7 60
D8 36
D9 210
How to distribute this addresses over the departments with FLSM Method ?
• Max host in D4 which is 1600 and will take it to calculate subnet
• Address Size : 2^11-2=2046
• Subnet Mask : 255.255.248.0
• To calculate new subnet mask: 256 - 248 = 8
• 8 between networks and each one has 2046 addresses.
Dep Number of Employees Address Size Subnet Address
Subnet Mask Start - End IP Broadcast Address
D4 1600 2046 165.10.0.0/21 255.255.248.0 165.10.0.1 - 165.10.0.254 165.10.0.255
D1 800 2046 165.10.8.0/21
255.255.248.0 165.10.8.1 - 165.10.8.254 165.10.8.255
D5 210 2046 165.10.16.0/21
255.255.248.0 165.10.16.1 - 165.10.16.254 165.10.16.255
D9 210 2046 165.10.24.0/21
255.255.248.0 165.10.24.1 - 165.10.24.254 165.10.24.255
D2 200 2046 165.10.32.0/21
255.255.248.0 165.10.32.1 - 165.10.32.254 165.10.32.255
D6 60 2046 165.10.40.0/21
255.255.248.0 165.10.40.1 - 165.10.40.254 165.10.40.255
D7 60 2046 165.10.48.0/21
255.255.248.0 165.10.48.1 - 165.10.48.254 165.10.48.255
D3 50 2046 165.10.56.0/21
255.255.248.0 165.10.56.1 - 165.10.56.254 165.10.56.255
D8 36 2046 165.10.64.0/21
255.255.248.0 165.10.64.1 - 165.10.64.254 165.10.64.255
sorry for unstyled formatted text i couldn't paste my table here ..
Host bits will be 11... Means each n/w will have 2^11 hosts
N/w bits will be 21... Means there will be (16-11) ie 5.. ie 2^5 n/w ie 32 n/w
SM = 255.255.248.0
Related
Block - 130.0.0.0/25 .
Want to create 8 subnet.
Binary Form of Block will be
1000 0010.0000 0000.0000 0000.0000 0000/25
Subnet mask would be
1111 1111.1111 1111.1111 1111.1000 0000
How will I make 8 subnetwork out of this?
You can handle 2 ^ 7 = 128 IP's (binary form: 000 0000 - 111 1111). Each subnetwork will have 128 / 8 = 16 IP's. So the subnetworks will look as follows.
130.0.0.0 - 130.0.0.15
130.0.0.16 - 130.0.0.31
130.0.0.32 - 130.0.0.47
130.0.0.48 - 130.0.0.63
130.0.0.64 - 130.0.0.79
130.0.0.80 - 130.0.0.95
130.0.0.96 - 130.0.0.111
130.0.0.112 - 130.0.0.127
In this question why we subtract 2 from 2^3 while calculating number of subnets. While in CCNA books 2 is not subtracted?
172.16.0.0 /19
Subnets 2^3 -2 = 6
Hosts 2^13 -2 = 8190
Block Size 256-224 = 32
When you want to Subnet the Class B 172.16.0.0 to a / 19 subnet, you add 3 bits to the default Class B netmask (which is /16)
The number of subnet available is 2^3 = 8 Subnets.
Concerning the number of Hosts you can have per subnet, it is 2^13-2
The number 13 comes from 32 (number of bit in a netmask) - (number of bits affected to the MASK part 19)
You substract 2 for each subnet because the first host and the last host are reserved for Network and Broadcast address.
If i don't answer your question, please give more information about what you need.
This is for your subnet mask
Address: 172.16.0.0 10101100.00010000.000 00000.00000000
Netmask: 255.255.224.0 = 19 11111111.11111111.111 00000.00000000
Wildcard: 0.0.31.255 00000000.00000000.000 11111.11111111
=>
Network: 172.16.0.0/19 10101100.00010000.000 00000.00000000 (Class B)
Broadcast: 172.16.31.255 10101100.00010000.000 11111.11111111
HostMin: 172.16.0.1 10101100.00010000.000 00000.00000001
HostMax: 172.16.31.254 10101100.00010000.000 11111.11111110
Hosts/Net: 8190 (Private Internet)
Trying to deconstruct this TCPdump BPF style filter, and need some help:
'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'
Its taken from here
Steps that have taken to better understand what is going on:
1. Lets convert the 0x47455420 to ascii
===> GET
===> tcp[((tcp[12:1] & 0xf0) >> 2):4] = GET
2. Examine the inner tcp filter: (tcp[12:1] & 0xf0)
===> the 0xf0 == 0000 0000 1111 0000 ===> I suppose it is save to discard the upper zeros so I can write 1111 0000
===> tcp[12:1] == 08 (start filtering from byte 13 (0 based indexing, so you could also say start with the byte that has index 12) for 1 byte, so only 13th byte);
===> 08 == 0000 1000
===> 0000 1000 & 1111 0000 == 0000 (bitwise and = if both are 1 then end result is one)
This is where I got confused. The explanation in the hyperlink I provided above is saying
multiply it by four ( (tcp[12:1] & 0xf0)>>2 ) which should give the tcp header length
Impossible if it is zero. Please:
help me find the mistake in my calculations (maybe I'm mixing TCP and IP headers?);
provide some guidance whether my logic is correct.
This is the packet:
19:10:30.091065 IP (tos 0x0, ttl 63, id 40127, offset 0, flags [DF], proto TCP (6), length 2786)
10.240.35.81.47856 > 172.17.13.201.8080: Flags [P.], cksum 0xf2ef (incorrect -> 0xb8f8), seq 2263020471:2263023205, ack 4187927811, win 28, options [nop,nop,TS val 1906863883 ecr 214445688], length 2734
0x0000: 1a17 8e8a a3a0 026d 627d 049c 0800 4500 .......mb}....E.
0,1 2,3 ... ... ... ... 12,13 ... <=== byte indexes
1,2 3,4 ... ... ... ... 13,14 ... <=== counting how many bytes
0x0010: 0ae2 9cbf 4000 3f06 ac3b 0af0 2351 ac11 ....#.?..;..#Q.. <=== 0x0010 number correctly identifies that the first two diggits are the 16th byte
16,17 ... ...
0x0020: 0dc9 baf0 1f90 86e2 f3b7 f99e b503 8018 ................
0x0030: 001c f2ef 0000 0101 080a 71a8 6f0b 0cc8 ..........q.o...
0x0040: 2e78 4745 5420 2f69 636f 6e73 2f75 6e6b .xGET./icons/unk
0x0050: 6e6f 776e 2e67 6966 2048 5454 502f 312e nown.gif.HTTP/1.
0x0060: 310d 0a68 6f73 743a 2070 6870 2d6d 696e 1..host:.php-min
tcp[12:1] is the byte at an offset of 12 bytes from the beginning of the TCP header; the 12 is not the offset from the beginning of the packet, it's the offset from the beginning of the TCP header (it's tcp[12:1], not ether[12:1] or something such as that). The "1" is the number of bytes being referred to.
According to RFC 793, which is the specification for TCP, the byte at an offset of 12 bytes from the beginning of the TCP header contains the data offset in the upper 4 bits and the lower 4 bits are reserved bits. The data offset is "The number of 32 bit words in the TCP Header", which "indicates where the data begins".
The data in the packet is being displayed as a sequence of byte pairs. It's a bit easier to understand if presented as a sequence of individual bytes, so:
0x0000: 1a 17 8e 8a a3 a0 02 6d 62 7d 04 9c 08 00 45 00
eth dest eth src etype IP hdr
The first 6 bytes of the packet are the Ethernet destination address.
The next 6 bytes of the packet are the Ethernet source address.
The 2 bytes after that are the Ethernet type value; it's big-endian, so its value is 0x0800, which is the Ethernet type value for IPv4.
The next 2 bytes are the first 2 bytes of the IPv4 header. According to RFC 791, which is the specification for IPv4, the first byte of the IPv4 header contains the IP version in the upper 4 bits and the header length in the lower 4 bits. That byte has a value of 0x45, so the IP version is 4 (as it should be, for IPv4) and the header length is 5. The header length "is the length of the internet header in 32 bit words", so that's 5 32-bit words, or 20 bytes.
So, for now, let's skip the IPv4 header and go to the TCP header:
0x0020: 0d c9 ba f0 1f 90 86 e2 f3 b7 f9 9e b5 03 80 18
TCP header 12 13
So byte 12 of the TCP header is 0x80. 0x80 & 0xf0 is 0x80, and 0x80 >> 2 is 0x20, which is 32; this is consistent with the upper 4 bits of that byte being the data offset, in 32-bit words, as 8*4 = 32.
tcp[((tcp[12:1] & 0xf0) >> 2):4] is thus, for this packet, tcp[32:4], i.e. the 4 bytes at an offset of 32 from the beginning of the TCP header.
32 bytes from the beginning of the TCP header is:
0x0040: 2e78 4745 5420 2f69 636f 6e73 2f75 6e6b
^
there, and that's the "GET" header of the HTTP request, beginning at the beginning of the TCP segment data. Te 4 bytes in question are "GET ".
So the 12 in tcp[12:1] is not the offset from the beginning of the packet, it's the offset from the beginning of the TCP header (it's tcp[12:1], not ether[12:1] or something such as that).
And, in answer to the questions about the bytes of the packet and what they are:
0x0000: 1a 17 8e 8a a3 a0: Ethernet destination
02 6d 62 7d 04 9c: Ethernet source
08 00: Ethernet type/length field - 0x0800 = IPv4
So the first 14 (0x000e) bytes of the packet are the Ethernet header.
In this packet, the Ethernet type/length field is 0x0800, so the Ethernet payload, following the Ethernet header, is an IPv4 packet, beginning with an IPv4 header:
45: IPv4 version/header length
00: IPv4 Type of Service/Differentiated Service
0x0010: 0a e2: IPv4 total length
9c bf: IPv4 identification
40 00: IPv4 flags/fragment offset
3f: IPv4 time-to-live
06: IPv4 (next) protocol - 6 = TCP
ac 3b: IPv4 header checksum
0a f0 23 51: IPv4 source address
ac 11: first 2 bytes of IPv4 destination address
0x0020: 0d c9: second 2 bytes of IPv4 destination address
The IPv4 header length is 5, so the IPv4 header is 20 bytes. That's the minimum IPv4 header length; it can't be smaller, but it can be larger, if there are IPv4 options after the fixed-length part of the header. There aren't any, in this case.
As the protocol field has the value 6, the IPv4 payload is a TCP packet:
ba f0: TCP source port (47856)
1f 90: TCP destination port (8080)
86 e2 f3 b7: TCP sequence number
f9 9e b5 03: TCP acknowledgment number
80: TCP data offset + reserved bits
18: reserved bits + TCP flags
0x0030: 00 1c: TCP window
f2 ef: TCP checksum
00 00: TCP urgent pointer
That's the 20-byte fixed-length portion of the TCP header; however, the TCP header length is 32 bytes, so there are an additional 12 bytes of TCP options in the header:
01: TCP No-Operation option
01: TCP No-Operation option
08 0a 71 a8 6f 0b 0c c8: first 8 bytes of TCP Timestamp option
0x0040: 2e 78: last 2 bytes of TCP Timestamp option
A TCP header's length must be a multiple of 32 bits, i.e. a multiple of 4 bytes; TCP options might not be a multiple of 4 in length - the TCP Timestamp option is 10 bytes long - so the No-Operation option is used for padding.
So those 32 bytes were the TCP header; what follows is the TCP payload. Apparently, this is on an HTTP connection (the packet is being sent to port 8080, which is an alternate HTTP port), and this is the beginning of an HTTP GET request:
47 45 54 20 2f 69 63 6f 6e 73 2f 75 6e 6b
0x0050: 6e 6f 77 6e 2e 67 69 66 20 48 54 54 50 2f 31 2e
0x0060: 31 0d 0a 68 6f 73 74 3a 20 70 68 70 2d 6d 69 6e
So:
as this was captured either on an Ethernet or on a Wi-Fi network when not in monitor mode (or on some other type of network that either uses Ethernet headers or on which the adapter or driver supplies "fake Ethernet" headers, as with Wi-Fi), the packet will start with an Ethernet header;
as the Ethernet type value is 0x0800, it's followed by an IPv4 header;
as the IPv4 protocol value is 6, it's followed by a TCP header;
as one of the TCP port numbers is a port number typically used by HTTP (8080), it's probably followed by HTTP data of some sort (this isn't guaranteed, however - TCP port numbers are more like hints).
For ARP over the same network, you'll again have an Ethernet header (the ffff ffff is the Ethernet broadcast address, so the packet is being broadcast, as ARP requests usually are), with an Ethernet type of 0x0806, which is the Ethernet type value for ARP.
For ICMP over the same network, you'll again have an Ethernet header, and you'll also have an IPv4 header, so the Ethernet type will be 0x0800. The value in the protocol field in the IPv4 header will be 1, for ICMP.
I'm trying to discover devices, from a coordinator, in my network.
So I sent an ND command to the coordinator and I'm correctly receiving response from other Xbee.
The next step will be to store the information I've received in a web application, in oder to send commands and data.
However, what I'm still missing is some parts in the frame respose. So far I've mapped the frame like this:
1 7E start frame
===== =================== MESSAGE LENGHT
2-3 0x00 0x19 -> 25
===== =================== PACKET TYPE
4 88 -> response to a remote AT command
5 02 frame ID
===== =================== AT COMMAND
6-7 0x4E 0x44 "ND"
8 00 status byte (00 -> OK)
===== =================== MY - Remote Address
9-10 0x17 0x85
===== =================== SH - SERIAL NUMBER HIGH
11-14 0x00 0x13 0xA2 0x00
===== =================== SL - SERIAL NUMBER LOW
15-18 0x40 0xB4 0x50 0x23
===== =================== SIGNAL
19 20
= ======== NI - Node Identifier
20 00
21 FF
22 FE
23 01
24 00
25 C1
26 05
27 10
28 1E
===== ===== CHECKSUM (25th bytes from MESSAGE LENGHT)
29 19
So, where I can find in this response the address of the device ?
My guess is in the NI part of the message but, I haven't find any example/information of how the data are organised.
Could someone point me in the right direction?
As someone told me in the dig.com forum
NI<CR> (Variable length)
PARENT_NETWORK ADDRESS (2 Bytes)<CR>
DEVICE_TYPE (1 Byte: 0=Coord, 1=Router, 2=End Device)
STATUS (1 Byte: Reserved)
PROFILE_ID (2 Bytes)
MANUFACTURER_ID (2 Bytes
So, loking to my frame response:
00 --- Node Identifier variable, (here 1 byte = 00 because no value is set up).
FFFE --- parent network address (2 bytes)
01 --- device type
00 --- status
C105 --- profile id
101E --- manufacturing id
This, afaik, means that in this last part of the frame, no information about address of the device are given. Only information are the SL and SH.
The 16-bit network address is what you've labeled "MY" (0x1785), and the 64-bit MAC address is the combination of SH/SL (00 13 A2 00 40 B4 50 23).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
This question exists because it has
historical significance, but it is not
considered a good, on-topic question
for this site, so please do not use it
as evidence that you can ask similar
questions here.
More info: https://stackoverflow.com/faq
I am having a weird TCP issue that makes no sense at all. I am tearing my hair out.
When downloading a file from Amazon S3 (and only Amazon S3- every other site works fine) some percentage of the time the connections dies. This only happens from our servers in Seattle with a web server behind a NAT router. Connecting directly from the router works fine. From our servers here in Victoria everything works fine, and we can't replicate this at all.
Web server in Seattle (tried 10 different servers) -> SNAT router (2 different routers; old kernels and new kernels) -> Amazon S3 = doesn't work ~10% of the time
Web server in Seattle -> SNAT router -> any other website = works
Router box -> Amazon S3 = works
Web server in Victoria -> SNAT router in Victoria -> Amazon S3 = works
Things I've tried:
Disabling window scaling
Lowering the window size
upgrading the router to the newest kernel
Disabling the firewall entirely
In the failure case Amazon (or something along the way) sends us a 868 length packet instead of the expected 1500 byte packet. The server upon seeing the packets replies with a RST packet (error has occurred) and the connection is torn down.
Any help would be greatly appreciated!
Below are two TCP dumps-
------------ Begin Error Case TCP Dump -------------
tcpdump -r /tmp/s3doesntwork-died
reading from file /tmp/s3doesntwork-died, link-type EN10MB (Ethernet)
19:58:42.542189 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: S 193799772:193799772(0) win 5840 <mss 1460,sackOK,timestamp 760821159 0,nop,wscale 5>
19:58:42.544115 IP 189-81.amazon.com.www > locum.sparklit.com.39491: S 3148664267:3148664267(0) ack 193799773 win 8190 <mss 1460,nop,wscale 6,nop,nop,sackOK>
19:58:42.545176 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: . ack 1 win 183
19:58:42.545184 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: P 1:212(211) ack 1 win 183
19:58:42.548113 IP 189-81.amazon.com.www > locum.sparklit.com.39491: . ack 212 win 916
19:58:42.558108 IP 189-81.amazon.com.www > locum.sparklit.com.39491: . 1:1461(1460) ack 212 win 916
19:58:42.558117 IP 189-81.amazon.com.www > locum.sparklit.com.39491: . 1461:2921(1460) ack 212 win 916
19:58:42.558123 IP 189-81.amazon.com.www > locum.sparklit.com.39491: . 2921:4381(1460) ack 212 win 916
19:58:42.558128 IP 189-81.amazon.com.www > locum.sparklit.com.39491: . 4381:5841(1460) ack 212 win 916
19:58:42.559108 IP 189-81.amazon.com.www > locum.sparklit.com.39491: . 5841:7301(1460) ack 212 win 916
19:58:42.559118 IP 189-81.amazon.com.www > locum.sparklit.com.39491: . 7301:8129(828) ack 212 win 916
19:58:42.559138 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: R 193799984:193799984(0) win 0
19:58:42.559169 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: . ack 1461 win 274
19:58:42.559176 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: . ack 2921 win 365
19:58:42.559180 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: . ack 4381 win 457
19:58:42.559188 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: . ack 5841 win 548
19:58:42.560167 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: . ack 7301 win 639
19:58:45.308618 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: F 212:212(0) ack 7301 win 639
19:58:45.310512 IP 189-81.amazon.com.www > locum.sparklit.com.39491: R 3148671568:3148671568(0) win 8201
Update: Traceroute to Amazon
1 64.34.33.195 (64.34.33.195) 0.795 ms 0.775 ms 0.762 ms
2 six01-sea4.amazon.com (206.81.80.147) 0.746 ms 0.732 ms 0.715 ms
3 72.21.222.183 (72.21.222.183) 2.657 ms 2.651 ms 2.638 ms
4 72.21.222.179 (72.21.222.179) 2.618 ms 2.604 ms 2.591 ms
5 * * *
6 * * *
7 * * *
Update: The offending incoming packet that causes the RST to be sent
19:58:42.559118 IP (tos 0x0, ttl 57, id 18905, offset 0, flags [DF], proto TCP (6), length 868) 189-81.amazon.com.www > locum.sparklit.com.39491: ., cksum 0x9f6e (correct), 7301:8129(828) ack 212 win 916
0x0000: 4500 0364 49d9 4000 3906 05d7 cfab bd51 E..dI.#.9......Q
0x0010: 4022 21c5 0050 9a43 bbac ea50 0b8d 2730 #"!..P.C...P..'0
0x0020: 5010 0394 9f6e 0000 7c75 a901 cd57 0718 P....n..|u...W..
0x0030: a786 e954 4160 3734 f563 5029 e7ad 48a7 ...TA`74.cP)..H.
0x0040: 34c0 b11b 75a2 a341 c1e6 8aab a03c 31ee 4...u..A.....<1.
0x0050: 1496 c9ef df22 aadc b87e 8431 fc2a dcd6 ....."...~.1.*..
0x0060: e72d 8cf7 aa92 5b12 4923 3f51 50cd 5195 .-....[.I#?QP.Q.
0x0070: 7910 6ce4 0fc0 d63c f115 276b b7e7 5bf7 y.l....<..'k..[.
0x0080: 508e d8fa d655 c5b3 1638 3cd6 6cd1 198c P....U...8<.l...
0x0090: 1c7f 1b7e 59a4 4370 9c87 523d 0ae2 adb4 ...~Y.Cp..R=....
0x00a0: 4d8e 7ad5 7954 c6ac 79e3 9e05 4148 6c97 M.z.yT..y...AHl.
0x00b0: b711 f262 47fa 363f 9d52 bcd4 a58e 177f ...bG.6?.R......
0x00c0: b33b 1033 b530 7351 d8eb 29a9 dbcf 2c6b .;.3.0sQ..)...,k
0x00d0: b161 99e0 3e67 192b 8c9f a735 89ad f886 .a..>g.+...5....
0x00e0: 4d3a ff00 462e b0ad 8dec 8f04 9bdb 9121 M:..F..........!
0x00f0: 4263 0ac4 81c9 18e7 ae6a 1a65 d8db d3ee Bc.......j.e....
0x0100: 3722 b608 cf24 1182 2ba1 b39b 728a f29b 7"...$..+...r...
0x0110: df1e db68 9af5 b69a e51e 5923 2ed0 29fd ...h......Y#..).
0x0120: f0e4 6303 f8bb f4ae ef44 d5e3 bc67 8f70 ..c......D...g.p
0x0130: 5b88 8299 a30d 931e e1c0 38fc 6bca a917 [.........8.k...
0x0140: 7b9d 8a2d 2bb3 5ef7 9e0d 625e c59c d6dc {..-+.^...b^....
0x0150: e778 cd67 5c26 ecd2 a64b 6737 345b 643d .x.g\&...Kg74[d=
0x0160: 6a3d b57e f22f 98d5 455e b5da b546 0c60 j=.~./..E^...F.`
0x0170: 5c51 5281 8a69 4e69 888c af15 0b0a b240 \QR..iNi.......#
0x0180: c540 c334 0101 1935 04b5 6996 a091 7ad0 .#.4...5..i...z.
0x0190: 2676 ba0d 8bbc 30cc 3385 c7f2 a835 ab19 &v....0.3....5..
0x01a0: 2e0b 003a d75b e17b 453a 03b6 070a a7f4 ...:.[.{E:......
0x01b0: a6cf 671e 7270 6b59 ae5e 5f43 28eb 73cd ..g.rpkY.^_C(.s.
0x01c0: 53c2 8f34 9c8e 3e95 d268 fe0f 4864 4661 S..4..>..h..HdFa
0x01d0: 9008 2702 b75e 782d 81e0 0fc2 b3ae bc51 ..'..^x-.......Q
0x01e0: 0c00 e080 477a 9bb6 3b1f 08fc 7efd 943e ....Gz..;...~..>
0x01f0: 26eb ff00 163c 4bad 695e 1b97 51d2 2f6e &....<K.i^..Q./n
0x0200: 4cb6 f35b dca3 7c98 1d46 ec8f a62b c675 L..[..|..F...+.u
0x0210: 4fd9 dfc7 1a4b b2df e812 da63 fe7e 0b2f O....K.....c.~./
0x0220: eb8a fd38 bff1 d055 386f c735 cf5f f8fa ...8...U8o.5._..
0x0230: 7705 44ac 54f6 2723 f2ae d862 2a25 6b1c w.D.T.'#...b*%k.
0x0240: f2a5 06ee 7e6b a7c1 bd79 f2a2 2b1d c3b1 ....~k...y..+...
0x0250: ba5c d759 e03f 849a e787 3564 d6af 2d6d .\.Y.?....5d..-m
0x0260: db4e b7fd d48f 0ca1 8866 1c0e dcd7 db37 .N.......f.....7
0x0270: b2d9 eb2e 4dd6 9767 704f 5692 d949 fcf1 ....M..gpOV..I..
0x0280: 53da 7c3c d0fc 45a3 ea3a 4cf6 3f67 b379 S.|<..E..:L.?g.y
0x0290: a197 cbb5 7311 0dcf 20d6 8f11 2d99 2a94 ....s.......-.*.
0x02a0: 7a1e 69e1 9fda 77c5 7e0d d3ad 74f8 eeac z.i...w.~...t...
0x02b0: e6b3 b641 1c71 df5b 6085 1db7 a907 f3cd ...A.q.[`.......
0x02c0: 7a3e 81fb 6b4c 42ff 0069 6831 4ebd dec6 z>..kLB..ih1N...
0x02d0: e837 fe3a c335 3d9f ec75 e01d 576b 5c47 .7.:.5=..u..Wk\G
0x02e0: ab12 c3a7 f683 8fe9 5a29 fb07 7c31 3f32 ........Z)..|1?2
0x02f0: dbea 81fd 4ea7 2e7f 98ae 37ec 99aa 53e8 ....N.....7...S.
0x0300: cb5a 97ed cfe0 ad1f 4d6b 99f4 bd56 79c1 .Z......Mk...Vy.
0x0310: ff00 8f48 d151 c8ef 8627 15f4 1681 acc5 ...H.Q...'......
0x0320: e21d 0b4e d56d e378 adef add2 e238 e5c6 ...N.m.x.....8..
0x0330: f556 1900 e38c d781 d97e c3bf 0ce0 71f6 .V.......~....q.
0x0340: 9b1d 42ea 31fc 0fa9 cf8f fd0a be80 d2b4 ..B.1...........
0x0350: f834 8d3a d2c2 d13c ab4b 5896 1850 9270 .4.:...<.KX..P.p
0x0360: 8a30 073e .0.>
So we finally figured it out-
It turns out that our router was injecting the RST packets because Netfilter declared the packet invalid. There is a setting that makes netfitler more liberal so I tried enabling it (inet.ipv4.netfilter.ip_conntrack_tcp_be_liberal=1) and the connection is no longer torn down.
However, I still haven't figured out why netfilter declared that packet as invalid. Enabling "ip_conntrack_log_invalid" doesn't cause anything to be printed in the log.
This is a guess. Maybe running some traceroutes to the target target and collecting the hops. Then pinging each of the hops with a 1500 byte packet configured for a 100 count would help identify problems links.
The sender is entitled to send any length packet it likes between 1 and 1460 (in this case, being your apparent MTU). The question is why does your server send the RST?