I have a situation where the server is Mac OS X and client is windows 7. The dump is taken on windows machine. I see that the negotiated window size is 32k (see syn packets) on both windows and mac but the bytes in flight are much more than that. Same is reported by cloudshark's graphs of data/time. In this case the tcp send and receive buffers were set at default on both windows and mac. I took another dump after increasing the send and recv buffers to 128k on mac to see if the announcement changes during the connection establishment, which didn't happen and still a window of 32k was announced but the bytes in flight and cloudshark's graphs reported an increase in data. The latency was 500ms between both the connections. Why is this announcement just 32k? Is it normal (or even possible) to have more bytes in flight than the tcp window? asked 20 Nov '12, 03:38  Aditya Patawari |
2 Answers:
From the trace you provided I don't see a chance that those packets are what really happens on the wire. Both OS X and Windows 7 in every way use Window Scaling, advertise their MSS and in most cases provide SACK which are always seen inside TCP options during the handshake. Since in the trace you uploaded both SYN packets are free of options, I would not further investigate the issue, due to the fact that those packets cannot be captured from a real network transmission. Your observation is true anyways, a TCP sender must not send more unacknowledged data than the advertised recieve window allows. answered 20 Nov '12, 05:11  Landi |
Hi Aditya, Are these the original pcap-files or have they been altered/anonymized in any way? There are no TCP Options set in the handshake for instance, which is odd considering you're using OS X and Windows 7 :-) You're right, if a receiver announces a windows size of 32k, the sender is not allowed to send more than 32k of data before receiving an acknowledgement. answered 20 Nov '12, 04:30  holmahenkel showing 5 of 6 show 1 more comments |
No. They are not altered in anyway. Is there a possibility that windows tcpdump didn't capture the packets properly?
not altered in any way?
So, the MAC addresses, with the ASCII representation LOCAL (4c:4f:43:41:4c:20) and REMOTE (52:45:4d:4f:54:45) and the IP address 0.0.0.0 are just incidental?
Trust me, it hasn't been touched. I think that address 0.0.0.0 is because it is listening on all the interfaces or maybe because tcpdump is behaving differently on windows.
Pretty sure that it is a bogus trace. IP 0.0.0.0 is never used in unicast communication; only DHCP negotiations using broadcast frames have it because the client node has no IP yet. My bet is, you're using a software network simulator that allows to capture, leading to bogus stuff in the headers - which means the simulator doesn't do it's job too well.
The "listening on 0.0.0.0" is a local system thing, and has nothing to do with IPs that are actually used on "the wire" in directional communications.
It is not a bogus trace. I would have had no issues in accepting any alteration. People are not killed for modifying the traces for anonymity. I'll make sure that next time I take some screenshots while taking the dump.
Anyway, I understand from Landi's answer that the trace is more or less useless so I would not spend my time on this.
Sorry if my comment sounded offensive, it wasn't meant to be. It is just that a trace with addresses like that can't be captured under normal circumstances. I think it is wise not to spend any more time on it.