Fri 28 Oct 2011 09:18:23 AM UTC, original submission:
The TCP_BUILD_MSS_OPTION macro writes the MSS value and the related option-type and option-length fields with an inverted byte order.
According to [1] the Maximum Size Segment option should be written into the TCP header with the following bytes order:
+--------+--------+---------+--------+
|00000010|00000100| max seg size |
+--------+--------+---------+--------+
Kind=2 Length=4
Also a Wireshark data acquisition of a generic TCP communication trace shows the same pattern [2].
The TCP_BUILD_MSS_OPTION macro has to problems:
- the MSS value is never changed, the packet option will result always with the default value of 536 defined into TCP_MSS define
- the byte order of the option field is written inverted, the kind field will results in the 4th bytes and the LSB of the data field will results in the 1st one (e.g. MSS=536 => 0x02040218)
The solution will be to invert the TCP_BUILD_MSS_OPTION bytes order like that:
#define TCP_BUILD_MSS_OPTION(x) (x) = htonl(((u32_t)2) | \
((u32_t)4 << 8) | \
(((u32_t)TCP_MSS / 256) << 16) | \
(TCP_MSS & 255) << 24)
with MSS=536 this will result in opts=0x18020402, allowing the tcp_parseopt function to properly parse the option.
Kindest regards,
Andrea Sacco
References
[1] RFC 793 - Transmission Control Protocol - 3.1 pp 18-19
[2] Wireshark screenshot, google.com request/response
|