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

[Ben Greear]

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


Packet received, hdr:
00 60 b3 69 56 67 00 02 2d 0b 27 a0 00 5c aa aa
03 00 00 00 08 00
eh->h_proto: 8  hdr.ethertype: 8 ntohs(eh->h_proto): 800
Packet received, data_len: 82  data_off: 68 skb->len: 96 skb->data:
skb->protocol: 0x8  skb->data addr: c14bedd2
00 60 b3 69 56 67 00 02 2d 0b 27 a0 08 00 45 00
00 54 00 00 40 00 40 01 e0 41 ac 01 01 01 ac 01
01 64 08 00 3a c3 d1 0e 03 00 96 79 74 3c ea 74
09 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15
16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35

After eth_type_trans, data_len: 82  data_off: 68 skb->len: 82 skb->data:
skb->protocol: 0x8  skb->data addr: c14bede0
45 00 00 54 00 00 40 00 40 01 e0 41 ac 01 01 01
ac 01 01 64 08 00 3a c3 d1 0e 03 00 96 79 74 3c
ea 74 09 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23
24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33
34 35



> 
> 


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