Hi Kieran, Am 17.05.2011 16:23, schrieb Kieran Mansley: > On Tue, 2011-05-17 at 16:12 +0200, Thomas Richter (TCD - DE/Dresden) > wrote: >> The next sequence by the sender is a TCP_ZeroWindowProbe sequence >> (some >> infos to TCP Analyze Sequence Numbers with Wireshark: >> http://wiki.wireshark.org/TCP_Analyze_Sequence_Numbers). But lwIP >> responses not with a sequence TCP_ZeroWindowProbeAck, it sends a new >> TCP_ZeroWindow sequence. > Do you have definitions for things like TCP_ZeroWindowProbeAck? As far > as I'm aware the form that a zero window probe should take is not > defined; it can be anything that will result in an ACK being sent by the > other end, and I didn't think there was a particular form that the ACK > to a zero window probe had to take. Sorry, I have not definitions for the TCP_ZeroWindowProbeAck. I try to understand the behavior of the communication. The Wireshark analysis gives me the result: "This frame ACKs a segment we have not seen (lost?)"
> > The zero window probe in your case has 1 byte of payload. lwIP is > accepting and acknowledging that byte. As far as I know this is legal. Yes, you have right. Thanks for the tip. The TCP_ZeroWindowProbe is in the first case always "0x00" and in the second case (with lwIP) different (also sometimes "0x00"). >> Why lwIP reacts different? > Different implementations of a specification will have different > behaviours where that behaviour is not defined by the specification. Sorry, the different behavior is ok. >> What can I do that the acknowledge number not increases? > Change the implementation of lwIP. Out of interest, why do you care > about this? I´m searching for a possibility to continue the way which I have selected. I have invested in so much time for this project. Now I will come to an end. Thomas _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
