lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Incomplete TCP packet reception


From: Jeff Barber
Subject: Re: [lwip-users] Incomplete TCP packet reception
Date: Tue, 27 Oct 2009 08:35:52 -0400

This isn't a case of *IP fragmentation* so there won't be any IP
reassembly.  It's just that the TCP data is being sent in two
messages.  This is perfectly valid TCP behavior.

Strictly speaking, there's nothing in TCP that prevents the client
from sending you the entire request in 1-byte pieces if it wants to.
It's your responsibility to accept the data stream in whatever sized
chunks they're presented and reassemble it as needed for your
application.  lwIP *will* make sure that it's in the proper sequence,
so that if an earlier segment gets dropped somewhere en route, lwIP
will hold it for you until the previous segment gets retransmitted,
then give you the two segments in the correct order (assuming you
defined TCP_QUEUE_OOSEQ).

So, in the case of the HTTP capture you provided, there is a request
header telling you "Content-Length: 36".  This tells you that after
the end of the headers (i.e. after the blank line), you should expect
another 36 bytes of data.  You need to wait for those bytes to come in
before considering the request complete, even though they may not be
present in the same pbuf.

Jeff

On Tue, Oct 27, 2009 at 7:08 AM, Lou Cypher <address@hidden> wrote:
> I have an HTTPD implementation, derived from the raw one in contrib/, that
> showed a strange behavior receiving fragmented packets.
> Note: In the attached Wireshark capture there's a fragment of communication 
> that
> exhibits such problem. In the capture file .130 is the host/web-client, and 
> .199
> is the the lwIP 1.3.1 server.
>
> I'm receiving an HTTP POST message from a browser (in this case Google Chrome,
> but I have reports that could have happened with different ones), from a login
> page with a form that sends "username" and "password" fields.
> While I've always found browsers to fill a single packet with all the
> application headers, and the username/password payload, in this case the 
> request
> is split in two parts: the first one with just headers, the second with 
> payload.
>
> My modified httpd.c code recomposes the pbuf chain received in a single 
> buffer,
> as the tcp_recv() handler is called, and that works in all other cases, but 
> this
> one.
> In capture file: the POST request is composed of packet 4 and 6, but in 
> between
> there's a packet 5, coming from server: the lwIP server believes that packet 4
> has no followers, sees no username/password payload, and instructs the browser
> to reload the login page.
>
> Maybe I'm just unaware of what all this means, but... why (having 
> IP_REASSEMBLY
> defined to 1) the two packets aren't recomposed in a pbuf chain?
>
> lwIP (1.3.1) is configured with
> ----------------------------------------------------------------------
> #define  NO_SYS                         1
> #define  SYS_LIGHTWEIGHT_PROT           1
>
> #define  MEM_ALIGNMENT                  4
> #define  MEM_SIZE                       (128 * 1024)
>
> #define  MEMP_NUM_RAW_PCB               16      // 8
> #define  MEMP_NUM_UDP_PCB               8       // 4
> #define  MEMP_NUM_PBUF                  32      // default 16
> #define  MEMP_NUM_TCP_PCB               128     // 32   // default 5
> #define  MEMP_NUM_TCP_PCB_LISTEN        8
> #define  MEMP_NUM_TCP_SEG               256     // default 16
> #define  PBUF_POOL_SIZE                 128     // default 16
>
> #define  LWIP_DHCP                      1       // default 0
> #define  DHCP_DOES_ARP_CHECK            1
>
> #define  LWIP_AUTOIP                    1
> #define  LWIP_DHCP_AUTOIP_COOP          1
>
> #define  TCP_WND                        4096    // default 2048
> #define  TCP_MSS                        1460
> #define  TCP_SND_BUF                    (8 * TCP_MSS)
>
> #define  PBUF_LINK_HLEN                 16      // default 14
>
> #define  LWIP_NETCONN                   0       // default 1
> #define  LWIP_SOCKET                    0       // default 1
> #define  LWIP_COMPAT_SOCKETS            0
>
> #define  LWIP_NETIF_HOSTNAME            1
>
> #define  LWIP_DNS                       1
> ----------------------------------------------------------------------
>
> Lou
>
> ____________________________________________________________
> Receive Notifications of Incoming Messages
> Easily monitor multiple email accounts & access them with a click.
> Visit http://www.inbox.com/notifier and check it out!
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>




reply via email to

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