When the client initiates the connection with the SYN bit set, Wireshark (and TCPDump) show the MSS as being 1460. However, when the same packet is delivered to the host, Wireshark (and TCPDump) show the MSS as being 1416.
Can anybody please explain why there's a discrepancy of 44 bytes?
The image below shows the MSS received by the host. Sorry but I don't have a screenshot showing the client's initial SYN 1460 MSS.
During actual data transfer, the 1416 is used as an MSS (1404 for payload and 12 for options such as the TSVal)
My original thought was that it has something to do with Path MTU discovery, and that some space is being reserved for any additional headers that may be added on while the packet is making it's way from the sender to the destination. Am I correct in thinking so? If so, is there a way to find a breakdown of how these are being used?
After consulting the university's network admin, we concluded that that a lower MSS was being imposed by the network for load reasons.
Related
I am doing some TCP related experiment between two virtualbox VMs. On the client side, I sent out a TCP syn packet with the MSS option of 1400 bytes. However, it seems that the server (sender) ignored this option and sent out a packet with very large payload, something like 10000+ bytes.Why didn't the MSS option honored by the server? BTW, the server is a Nginx server.
Below this some PCAP showing the problem. First is the SYN packet with MSS = 1400.
Second is the payload sent by the server:
As can be seen that the payload size is 11200.
BTW the MTU on the interface is 1500 bytes.
Thanks.
By discussion with Jim.The issue this LRO/GRO. Please turn that off if we want to see the packets as they appears on the wire.
I'm troubleshooting a MTU/MSS issue that is causing fragmentation over a PPPoE service. Below is a packet dump of a TCP 3-Way Handshake from a different service (that is working as expected) that relates to my question.
I understand the way PMTUD works as this: by setting the Don't Fragment (DF) bit to 1 in the IP header, a router along the path to the destination that requires fragmentation of the packet sends an ICMP back to the host to adjust the MSS size accordingly. However, my understanding is that this will only happen when fragmentation occurs (packets greater than the path MTU). This suggests that PMTUD works during the data exchange phase, NOT when TCP 3-Way Handshake is negotiated (since these are small packets, 78 bytes in this case).
In the above packet capture the SYN packet sends a MSS=1460 (which is too large, due to the 8 byte overhead of PPPoE) and the SYN/ACK response from the server sends back the correct MSS=1452. What mechanism does TCP use to determine the MSS during this exchange?
Maybe, the server hasn't computed the MSS during this three-way handshake. For instance, if the system administrator has observed a lot of fragmentation, he can have set the MSS of the whole system to 1452 (with the command ip tcp adjust-mss 1452), so when you are doing the three-way handshake, the server only advertises its default MSS. Is it applicable to your case?
What you're probably seeing here is the result of what's known as MSS clamping where the network on which the server is attached to modifies the MSS in the outgoing SYN/ACK packets to signal to the sender to use a lower MSS. This is commonly done on networks that perform some form of tunnelling such as PPPoE on ADSL.
I've been doing some work with C# Networking using UDP. I'm getting on fine but need the answer to a couple of fundamental questions I'm having problems testing:
Currently I'm sending data in a ~16000 byte datagrams, which according to wireshark is getting split into several 1500 byte packets (because of max packet size limits) and then reassembled at the other end.
Am I right in understanding the datagram will be received complete at the other end OR not at all. IE it's an all or nothing thing. There is no chance of ending up with a fragmented datagram due to packet loss?
Therefore, I only need to ACK per datagram, rather than ensuring my datagrams are < 1500 bytes and ACK each one?
I've looked in a lot of places but there seems to be a lot of confusion between the differences between datagrams and the underlying packets...
Thanks for you help!
There is no chance of ending up with a fragmented datagram due to packet loss?
I believe that's true: that fragmentation and fragment reassembly is handled by the protocol layer below UDP, i.e. that it's handled by the "IP" layer, which will error if it fails to reassemble the packet-fragments into a datagram (for example, search for "fragment" in RFC 792).
http://www.pcvr.nl/tcpip/udp_user.htm#11_5 says,
"The IP layer at the destination performs the reassembly. The goal is to make fragmentation and reassembly transparent to the transport layer (TCP and UDP), which it is, except for possible performance degradation."
As you may now 16 bit UDP length field indicates that you can send a total of 65535 bytes. However, the data can be theoretically (sizeof(IP Header) + sizeof(UDP Header)) = 65535-(20+8) = 65507 bytes.
But this does not mean that all applications that are using UDP will send this amount of data as an example DNS packets limits to 512 bytes. This is because you don't get any ACK packets from server. This is one reason that packets may get lost in the network (packet transmission problems and loss). Secondly intermediate nodes may encapsulate datagrams inside of another protocol, as an example IPSEC or other protocols do that.
For UDP there is no ACK packets, so in your case if underlying application uses UDP you should not see any ACK packets. Secondly, some of the server limit their sizes to the max UDP packets depending on the application, so if you have data transfer from client to server you should see same bytes e.g 512 bytes. going and coming back in wireshark. Mostly, source makes the request and destination sends X bytes UDP datagrams back.
These links may be good for your questions:
Wireshark UDP analysis
RFC 1122 (states that 576 is the minimum maximum reassembly buffer size)
Am I right in understanding the datagram will be received complete at the other end OR not at all. IE it's an all or nothing thing. There is no chance of ending up with a fragmented datagram due to packet loss?
That is correct.
Therefore, I only need to ACK per datagram, rather than ensuring my datagrams are < 1500 bytes and ACK each one?
I don't understand this question. You need to ACK each datagram regardless of its size, and you should make them < 1500 bytes so they won't get fragmented. Otherwise you may never be able to transmit any specific datagrams at all, if it repeatedly gets fragmented and a fragment repeatedly gets lost.
I want to identify an UDP or TCP packet that have its source IP address faked. My guess is that even if the packet is faked with a program such has hping, the MAC src address is still the same on all the faked packets, is this correct?
If my idea is not correct, how can I identify such packets that are being faked and looks like it has different source for each and every packet?
Thanks.
MAC addresses can be faked too.
With TCP, its easy to identify / handle this. You'll reply to a fake SYN packet with a SYN-ACK. If it was a real client, it'd reply with an ACK to complete the handshake. Only caveat is that you'll have to implement syn-cookies so that you don't create state & use up resources while waiting for an ACK.
With UDP, there is no way to know, since the protocol is connection-less. If you send a reply to the fake packet, you're not guaranteed a response from a "real" client. So there is no way to identify a fake one.
The way I see it, UDP and TCP have nothing to do with this. You're talking about only layer 2 (MAC) and layer 3 (IP). Even at that though, you have no way of knowing, because the source MAC address should be that of the closest router to the recipient (assuming the packet did not originate in your subnet.) So you should see the same MAC address for most all inbound packets (again, internet traffic only).
Now there are profiling tools like p0f that work on signatures of packets, and you could try and do some heuristics based on that information, but nothing very concreted could be determined.
From the packet you can get the MAC address of the nearest node. Yeah you can send ACK packet to the fake source address(IP) and then use Traceroute command to know the path of the source packet, so that you can atleast find the location of the originating. It works well in TCP and you can have acknowledgement also.
I am analyzing wireshark log files, when I make a request to a web page using firefox through a proxy server.
Following are details of connection establishment:
I have noted "maximum segment size" when I open options branch in the TCP segment details of the [SYN] message from my PC to the proxy server - it says 1460 bytes
Similarly, maximum segment size eof the [SYN,ACK] message from the proxy server to my PC - it says 1460 bytes
After establishing the TCP connection, should not each of the TCP frames sent from proxy server to my PC be of 1460 bytes? I am puzzled that why are they 590 bytes. Please advice how the 590 size is being set
A plausible explanation is that 590 turns out to be the Path MTU for the particular connection.
In other words whereby the client (one of the end nodes of the connection)accepts packets of a maximum of of 1460 bytes payload, some node(s) on the way accepts smaller packets. For efficiency purposes, the Path MTU Discovery allows the originator of a packet to size it so that it would fit the smaller MTU encountered on the path, and hence avoid fragmentation.
BTW:
1460 is a very common MTU (well MSS), because it it corresponds to 1500, Ethernet v2's maximum, minus 20+20= 40 bytes for the IP header overhead)
See the following Wikipedia entry for an overview of MTU (Maximum Transmission Unit) and a basic description of the Path MTU Discovery method (Basically setting the the DF i.e. do-not-fragment flag and relying on the ICMP ""Destination Unreachable (Datagram Too Big)" messages to detect that some node on the way couldn't handle the packet, and hence try with smaller size until it goes through).
Also, I suggest inspecting the packets when the connection is to a different host, maybe a peer on the very same network segment, without going through the proxy mentioned. Chances are you will then start seeing 1460 bytes frames.