On Wed, Feb 20, 2002 at 09:57:11PM -0700, Ben Greear wrote:
> Here is some more debugging. It appears that protocol is not
> correct, or maybe I'm just not printing it out correctly???
> Code that generated it is below...
>
> 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
> Packet received, data_len: 82 data_off: 68 skb->len: 96 skb->data:
> skb->protocol: 0x8 skb->data addr: c14be4d2
> 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 79 9d 10 0c 02 00 99 71 74 3c 65 a5
> 0e 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: c14be4e0
> 45 00 00 54 00 00 40 00 40 01 e0 41 ac 01 01 01
> ac 01 01 64 08 00 79 9d 10 0c 02 00 99 71 74 3c
> 65 a5 0e 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

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.

-- 
David Gibson			| For every complex problem there is a
davidgibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]