lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Driver bug related to odd length pbufs


From: Robert
Subject: [lwip-users] Driver bug related to odd length pbufs
Date: Sun, 23 Feb 2003 20:47:04 -0500 (EST)

I am reposting this, I sent it out the other day, but it apparently never 
made it to the mailing list.  Below are more details regarding the bug I 
believe exists in the CS8900A driver related to odd length pbufs.

-- 
Best Regards,
Robert Laughlin


---------- Forwarded message ----------
On Thu, 20 Feb 2003, Michael Anburaj wrote:
> 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.

Yes, I see that your situation is different than the one I found.  In my 
case, my processor does not insist on any boundaries, so the chksum() code 
works properly, the odd byte at the end of the pbuf is detected and added 
to the checksum and the correct value is calculated.  I have tested this 
on live data.

The error I found is actually very similar, but occurs in a different
section, IE in the driver.  The pbufs are passed to the driver which takes
the bytes, two at a time, and sends them to the hardware.  The current
code assumes that any 16 bit write to the hardware will have all 16 bits
coming from the same pbuf.  However if the length of a pbuf (other than
the last one) is an odd number of bytes, then the final write of that pbuf
will have 8 bits from one pbuf and 8 bits from the next pbuf.  Worse yet,
all the bytes in the second pbuf will have to be shifted, since the 2nd
byte needs to be written as the MSB, and the 3rd byte needs to be written
as the LSB.

If you have a look at my source code, you can see how I handled it in my 
rewrite of the driver.  I cannot say whether this problem exists in 
drivers for other than the CS8900A, since that is the only driver I have 
looked at in detail.  Also I should add that odd length pbufs are not a 
problem to the driver unless a packet spans more than one pbuf, and the 
odd pbuf is before the final one.

The symptom caused by transmitting a packet consisting of more than one 
pbuf, where one of them other than the last has an odd number of bytes, is 
that the packet will be received with the data a bit "off" and a check sum 
error will almost certainly occur.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]