buglwIP - A Lightweight TCP/IP stack - Bugs: bug #2679, Data packet split on odd...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #2679: Data packet split on odd boundaries -> causes exception

Submitted by:  Michael Anburaj <michaelanburaj>
Submitted on:  Fri 28 Feb 2003 10:27:45 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: Crash ErrorStatus: Fixed
Privacy: PublicAssigned to: Leon Woestenberg <leonwoestenberg>
Open/Closed: ClosedPlanned Release: None
lwIP version: None

Fri 04 Feb 2005 01:42:56 PM UTC, comment #2:

Fixed this, but probably 32-bit optimized checksum routines (if they exist for lwIP) will still fail on 16-bit aligned access. (Some processors do not allow access of 32-bit words on 16-bit boundaries).

Leon Woestenberg <likewise>
Project Member
Tue 18 Jan 2005 09:06:10 PM UTC, comment #1:

--Fix added--

Data packets split over Odd byte boundaries (issue discussed over -unavailable- around 28 Feb 2003).

Source: Current CVS source

Symptom: On processors (ARM, MIPS & like cores), which do not allow unaligned access (or turned off to optimize data access), when odd byte packets are sent to LwIP stack - The packet data alignment gets broken due to packet split on odd byte boundaries, causes an unaligned access exception.

Detail description:

Lets say we want to send two packets:
Packet1 : Size 45 bytes
Packet2 : Size 300 bytes

netconn_write() is called twice consecutively for sending the above 2 packets. The netconn->pcb.tcp->snd_buf sets the buffer size limit for data to be packed together for sending.

Packet1 Packet2

-------- ----------------------------
| 45 | | 300 |
-------- ----------------------------

|
|
| After 2 consecutive netconn_write() calls
|
V

Snd_buf (256 bytes) snd_buf (256
bytes)
_______|________________ __|_____ _
( ) (

-------- ----------------- ----------
| 45 + 211 | | 89 |
-------- ----------------- ----------

The second packet's remaining bytes (89 byte data - packet data starting on a odd byte boundary) when sent to lwip_chksum() routine subsequently, which does a 16 bit access - causes Alignment fault (memory access exception). This holds true on all processor platforms that don't allow unaligned memory access.

Fix:
The fix I have proposed here evens the snd_buf. So, when a odd number of bytes (N) packet is sent, N+1 byte space is assumed for snd_buf.

I have included the patch for the same along with this.

Email me back for more details on this.

Thanks,
-Michael (michaelanburaj at yahoo.com).

Michael Anburaj <michaelanburaj>
Fri 28 Feb 2003 10:27:45 AM UTC, original submission:

Any processor with alignment error check turned on will suffer this issue.

Lets say we want to send two packets:
Packet1 : Size 45 bytes
Packet2 : Size 300 bytes

netconn_write() is called twice consecutively for sending the above 2 packets. The netconn->pcb.tcp->snd_buf sets the buffer size limit for data to be packed together for sending.

Packet1 Packet2

-------- ----------------------------
| 45 | | 300 |
-------- ----------------------------

|
|
| After 2 consecutive netconn_write() calls
|
V

buffer (256 bytes) buffer (256
bytes)
_______|________________ __|_____
( ) (

-------- ----------------- ----------
| 45 + 211 | | 89 |
-------- ----------------- ----------

The second packet’s 2nd half (89 byte data - packet data starting on an odd byte boundary) when sent to lwip_chksum() routine, which does a 16 bit access causes Alignment fault (memory access exception). This holds true on all processor platforms that don’t allow unaligned memory access.

Another explanation (to give a better picture):

This issue happens well in advance within the LwIP code.

In an LwIP application, netconn_accept() returns 'netconn' structure upon receiving new application data packet <HTTP> on a particular port.

The netconn->pcb.tcp->snd_buf variable is equal to 256 (no idea who sets this number). Following this, netconn_write() is called (to send out packets) & the value of netconn->pcb.tcp->snd_buf gradually reduces by the amount of data sent out (in bytes). As I understand ‘netconn->pcb.tcp->snd_buf’ sets the limit of data sent in an instance within the loop inside netconn_write().

Now lets consider that the application has the following data packets to be sent out.

PACK1 : Size = 45 bytes long, &PACK1[0] = 0x00001000
PACK2 : Size = 300 bytes long, &PACK2[0] = 0x00002000

After the 1st netconn_write( .. PACK1 .. ), netconn->pcb.tcp->snd_buf = 256-45 = 211 <after PACK1 is processed>.

Then the application sends the second packet by calling netconn_write( .. PACK2 .. ).

Within netconn_write()’s loop, 211 bytes of PACK2 is 1st processed & then it tries to process the remaining data (data staring at PACK2[211]).

This data packet starting at PACK2[211] is eventually sent to lwip_chksum(), which access data within packet as half-words (16 bits). The very 1st access will result in doing a 16-bit access at address (0x2000 + 211) <- this address is not half-word aligned, so the processor aborts.

This was evident when running Adam's sample code (modified version) on a MIPS 4Kc (32 bit platform) processor board.

Michael Anburaj <michaelanburaj>

 

Attached Files
file #2378:  oddbyte.tar added by michaelanburaj (10KiB - application/x-tar - Fix (patch))

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 4 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Fri 04 Feb 2005 01:42:56 PM UTClikewiseStatusNone=>Fixed
  Assigned toNone=>leonwoestenberg
  Open/ClosedOpen=>Closed
Tue 18 Jan 2005 09:06:10 PM UTCmichaelanburajAttached File-=>Added oddbyte.tar, #2078

Back to the top


Powered by Savane 3.1-cleanup1