More on the Orinoco + XI-825 + StrongARM platform...

Ben Greear greearb at candelatech.com
Fri Feb 22 04:55:02 EST 2002


Now that I got the NIC working with the compile option,
I tried a ping -f

Both the laptop (running the orinoco driver in 2.4.17-pre2)
and the cube show similar errors.  However, it appears that
most of the packets are being sent and received correctly,
though there are definately some drops too.

(I commented out the verbose printing in the cube driver, btw...)

Here's from the cube:

eth1: Tx error, status 1 (FID=0212)
eth1: Tx error, status 1 (FID=0264)
eth1: Tx error, status 1 (FID=02FD)
eth1: Tx error, status 1 (FID=018E)
eth1: Tx error, status 1 (FID=037B)
eth1: Tx error, status 1 (FID=01F4)
eth1: Tx error, status 1 (FID=025F)
eth1: Tx error, status 1 (FID=0314)
eth1: Tx error, status 1 (FID=02E0)

Any ideas?


David Gibson wrote:

> On Wed, Feb 20, 2002 at 10:30:31PM -0700, Ben Greear wrote:
> 
>>
>>David Gibson wrote:
>>
>>
>>
>>>Huh, weirder and weirder.  The de-encapsulated packet data looks
>>>correct but eth_trans_type() appears to be misbehaving.  The Ethernet
>>>header is big-endian so the 08 00 protocol should give protocol 0x800,
>>>not 0x8 - so it looks like there is some subtl endian problem, buried
>>>within there.
>>>
>>
>>I added some more printing...the ntohs() value for the header seems
>>correct.  The really baffling thing is that arps seem to work
>>(as shown by the tcpdump trace I just sent):
>>
>>I'll be more than happy to throw in some ntohs or visa/versa
>>calls to test things out...but I'm unclear of exactly where
>>I should start poking...
>>
>>Note that the regular ethernet driver works fine, too, so I
>>suspect the orinoco somehow...
>>
> 
> Well, that's logical.  Except that at the point you're printing out
> the data the packet looks fine.  In fact I just figured out that even
> the protocol is ok, because skb->protocol is stored in network order.
> But by the time the packet reaches tcpdump, the first two bytes of the
> IP header have gone missing.  But I can't see anything in the driver
> which could possibly mangle the data between your printk()s and the
> netif_rx().  The IP header is even 4-byte aligned.
> 
> 


-- 
Ben Greear <greearb at candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear






More information about the wireless mailing list