[Top][All Lists]
[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
>