lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #34669] Inverted byte order in TCP_BUILD_MSS_OPTION


From: Andrea Sacco
Subject: [lwip-devel] [bug #34669] Inverted byte order in TCP_BUILD_MSS_OPTION
Date: Fri, 28 Oct 2011 09:18:24 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a2) Gecko/20111027 Firefox/9.0a2

URL:
  <http://savannah.nongnu.org/bugs/?34669>

                 Summary: Inverted byte order in TCP_BUILD_MSS_OPTION
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: socket
            Submitted on: ven 28 ott 2011 09:18:23 GMT
                Category: TCP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: 1.4.0

    _______________________________________________________

Details:

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



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: ven 28 ott 2011 09:18:23 GMT  Name: google.com.request.png  Size: 140kB 
 By: socket
screenshots
<http://savannah.nongnu.org/bugs/download.php?file_id=24226>

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?34669>

_______________________________________________
  Messaggio inviato con/da Savannah
  http://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]