Of course, you are right on the header length. I suppose I was using the new math to come up with 16. Now that you bring it up, it is sort of weird that it's set to 16 by default. I suppose there is some historical reason for this value, but haven't really bothered to look into it. I left it at 16 in my port, and so far everything is kosher.
For what it's worth, I verified that I also have the same 2-byte alignment issue you're seeing, using UDP and the MEM_ALIGNMENT set to 4. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Robert Goeffringmann > Sent: Thursday, February 08, 2007 9:35 AM > To: Mailing list for lwIP users > Subject: Re: [lwip-users] porting lwip to a mips system > > Sorry if I'm being stupid, but isn't the link header size always > 2 x 6 bytes mac + 2 bytes ethertype? > > In any case, changing it to 16 doesn't have any influence on this at all. > The code in pbuf.c behaves exactly the same as with PBUF_LINK_HLEN=14, due > to that alignment code and the size of the ethernet header is hardcoded in > etharp.c. > > Regards, > Robert. > > ----- Original Message ----- > From: "Taranowski, Thomas (SWCOE)" <[EMAIL PROTECTED]> > To: "Mailing list for lwIP users" <[email protected]> > Sent: Wednesday, February 07, 2007 12:14 AM > Subject: RE: [lwip-users] porting lwip to a mips system > > > Out of curiosity, why did you define the PBUF_LINK_HLEN to be 14? If > you are using 802.3, it should typically be 16. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Robert Goeffringmann > Sent: Tuesday, February 06, 2007 12:45 PM > To: [email protected] > Subject: [lwip-users] porting lwip to a mips system > > Hello! > > I am currently trying to get lwip to work on a PlayStation 2. > In this process, I've been facing some rather strange effects and I am > wondering if things are actually meant to work this way... > > The first issue I ran into was the sys_arch_protect function. > My system works with multiple threads and implements the semaphore > functions > as well. > First I tried to implement sys_arch_protect by disabling interrupts. > This doesn't work because certain functions (e.g. pbuf_free in pbuf.c) > will > use sys_arch_protect (thereby disabling interrupts) and will then (while > > interrupts are still disabled) call functions which use semaphores for > inter-thread protection (in this case, pbuf_free may call mem_free). > And well... obviously you can't wait for a semaphore if you've disabled > interrupts in order to prevent thread switching. > The way I understand it, pbuf_free could even be changed so that it > doesn't > need to disable interrupts if the pbuf it's being called on is a memory > buffer. > Or did I overlook a good reason why it works like this? > At some point I had the feeling that this situation occurs with other > functions as well, but so far I couldn't find any. > Anyways, if this can't be changed, I suppose it would be better to > mention > this behaviour in the sys_arch.txt. :) > Now as I implemented sys_arch_protect using a recursive mutex, it works. > > > The problem I am facing right now is the alignment of packets. > I've set MEM_ALIGNMENT to 4 in my lwipopts.h. > Now, if my netif driver receives a packet, it invokes pbuf_alloc, > receives a correctly aligned buffer, fills it with data and passes it to > > lwip. > Works smoothly. > > However, if an application sends tcp data (using the socket api, I > didn't > try anything else), all the packets that lwip sends to my netif driver > for > outputting are misaligned by 2 bytes. And looking at pbuf.c, this > actually > seems to be the intention... > I defined PBUF_LINK_HLEN as 14 bytes. > Now, when tcp_enqueue calls pbuf_alloc, pbuf_alloc first computes the > size > it needs for headers. In this case, that's: > 20 (PBUF_TRANSPORT_HLEN) + 20 (PBUF_IP_HLEN) + 14 (PBUF_LINK_HLEN) = 54 > bytes. > This is then rounded up to 56 bytes in order to match my MEM_ALIGNMENT > of 4 > and pbuf->payload is set to that offset, so payload is correctly > aligned. > However, later these header sizes get substracted again and so the > pbuf's > payload > points to an address which is 2 bytes off from the necessary alignment > when > it's passed to netif->linkoutput. > This is especially annoying as I have to pass the data as doublewords of > 4 > bytes to the hardware's I/O port. > So basically, I have to read it from memory in units of 2 bytes, put it > together to make dwords and pass it to the HW port. > Even worse, though, if the pbuf is splitted, the splits occur in the > middle > of a dword, which makes it even more difficult. > > Is this really the intention? > > Thanks in advance :) > Robert. > > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
