[lwip-users] Important issue!!! Data packet split on odd boundaries -> causes exception

[Michael Anburaj]

Hi,

This issue is not getting due attention!! Any
processor with alignment error check turned on will
suffer this issue. Surprising that others did not come
across this.


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 a 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.

Please decide in favour of any one statement:
1. There may be mistakes in the application that
should lead to this error.
2. Its a LwIP bug! (if so, please advice me regarding
bug filing & fixing process thats being followed for
LwIP).

I have also included with this the earlier
correspondance at the bottom..

Thanks,
-Mike.



Hi Robert,

As I understand it correctly, you had some issue that
was happening at the driver. But, what I am facing
here is happening well in advance within the LwIP
code.

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

The netconn->pcb.tcp->snd_buf is equal to 256 (no idea
who sets this number). Following this, upon doing a
netconn_write() the value of netconn->pcb.tcp->snd_buf
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

<Note: Let me know if these numbers are permitted to
be sent through the socket interface. Or is it the
application’s responsibility to round the packet size
to even boundary by byte stuffing>

Now the application calls netconn_write(…PACK1…).
netconn->pcb.tcp->snd_buf = 256-45 = 211 <after this
packet is processed>.

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

Within netconn_write()’s loop 1st it process 211 byes
of PACK2. 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 does access the data
within the 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.

As of now I don’t see any connection between this
issue & the underlying EthernetIF or the Ethernet
driver. I am pretty new to this <LwIP & TCP/IP stuff>.
If I am wrong please help me understand it.

And also this was run on a MIPS 4Kc (32 bit platform)
processor with the Ethernet peripheral in SAA9730.

Thanks,
-Mike.





__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/