[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] ip_reass
From: |
Ed Sutter |
Subject: |
Re: [lwip-users] ip_reass |
Date: |
Thu, 09 Oct 2008 18:26:54 -0400 |
User-agent: |
Thunderbird 2.0.0.17 (Windows/20080914) |
Ok, I've spoken to a few folks off-line about this, and have narrowed it
down a bit further. There's either a bug or I'm not configuring something
properly...
I'm running LWIP 1.3.0 on a Blackfin, which is picky about accessing longs
on long-word boundaries. I have MEM_ALIGNMENT set to 4. My network generates
occasional fragmented IP packets, and it causes the function
ip_reass_chain_frag_into_datagram_and_validate() to crash.
Here's the flow...
The packet is received and buffered up using pbuf_alloc() (with each payload
aligned on a 4-byte boundary) then that set of pbufs is passed to
ethernet_input().
The ethernet_input() function then sees that it is IP, increments the payload
pointer by 14 (size of ethernet header) and passes the pbufs to ip_input().
Note that at this point, the payload pointer is no longer aligned on a 4-byte
boundary because the original 4-byte-aligned payload pointer is incremented
by 14.
Next, ip_input() sees that the packet is a fragment, so it calls ip_reass()
which then calls ip_reass_chain_frag_into_datagram_and_validate(). About 15
lines from the top, this function overlays a "helper" structure pointer on
the payload area (which is no longer 4-byte aligned). The helper structure's
first member is a pointer which is initialized to NULL, this causes the crash
because loading the pointer is a 4-byte-wide access, but the pointer is not on
a 4-byte aligned address.
This is only seen on an alignment-sensitive processor when an fragment is
received. I made a simple change to the helper structure to fix this (see
below); however, I would like to make sure that there isn't some other
configuration parameter that I should be setting to avoid this.
I changed this...
struct ip_reass_helper {
struct pbuf *next_pbuf; <<<< this member access is not aligned
u16_t start;
u16_t end;
};
to this...
struct ip_reass_helper {
PACK_STRUCT_FIELD(u16_t start);
PACK_STRUCT_FIELD(struct pbuf *next_pbuf); <<<< now it is
PACK_STRUCT_FIELD(u16_t end);
};
and my crash has disappeared. Putting the 'start' member above the next_pbuf
pointer will naturally align the pointer, which as far as I can tell will
always be mis-aligned by 2 bytes when MEM_ALIGNMENT is set to 4.
Is this a valid fix or am I just configuring something incorrectly to cause
this crash?
Sorry for the verbosity!
Ed
Jonathan Larmour wrote:
Ed Sutter wrote:
Hey folks,,
I'm using 1.3.0, been running fine for quite a while now.
I just crashed somewhere in ip_reass() as a result of an
incoming IP fragment (MF bit set in header). Are there any
known problems with IP_REASSEMBLY in lwip1.3.0?
I know of an issue with fragmentation, but not reassembly:
https://savannah.nongnu.org/patch/?6528
If anything the discussion there shows that reassembly should work.
Jifl
- [lwip-users] ip_reass, Ed Sutter, 2008/10/08
- Re: [lwip-users] ip_reass, Jonathan Larmour, 2008/10/09
- Re: [lwip-users] ip_reass,
Ed Sutter <=
- R: [lwip-users] ip_reass, Ceresoli Luca, 2008/10/10
- Re: R: [lwip-users] ip_reass, Ed Sutter, 2008/10/10
- Re: R: [lwip-users] ip_reass, Kieran Mansley, 2008/10/10
- Re: R: [lwip-users] ip_reass, address@hidden, 2008/10/10
- Re: R: [lwip-users] ip_reass, Kieran Mansley, 2008/10/10
- Re: R: [lwip-users] ip_reass, Ed Sutter, 2008/10/11
- Re: R: [lwip-users] ip_reass, Simon Goldschmidt, 2008/10/11
- Re: R: [lwip-users] ip_reass, Ed Sutter, 2008/10/11
- Re: [lwip-users] ip_reass, address@hidden, 2008/10/17
- R: R: [lwip-users] ip_reass, Ceresoli Luca, 2008/10/10