Re: [lwip-users] Data packets splitting on odd boundaries -> causes exception

[Michael Anburaj]

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.

--- Robert <address@hidden> wrote:
> On Thu, 20 Feb 2003, Michael Anburaj wrote:
> > I agree, it should be an easy fix for me to fix
> the
> > len at tcp_enqueue() function by rounding it to
> even
> > byte boundary (the lwip_chksum() does a 16bit
> access)
> > before doing “pcb->snd_buf -= len;”. Does this
> mean
> > that it’s a bug? If so, how should I log it? & who
> > will fix it in the CVS repository?
> 
> Several months back I reported a bug in the CS8900A
> driver, that it could
> not properly handle odd length pbufs.  For my
> project, I was able to solve
> this problem.  My fix will not fix the bug in the
> CVS code however, since
> my driver assumes an 8 bit interface to the CS8900
> chip.  If you are using
> the CS8900 chip, you will need to fix this bug
> before you can transmit odd
> len pbufs.  Note this bug is related to the number
> of bytes in each pbuf,
> which is not necessarily related to the packet size.
> 
> I would appreciate a link be added from the lwIP
> pages to my project when 
> someone has a spare moment.  The URL is: 
> 
> http://www.dscinet.com/eZ80/OpenEZ/index.html
> 
> 
> Best Regards,
> Robert Laughlin
> 
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/lwip-users


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