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

[Ben Greear]

Here is what the received packet header looks like with
the latest 'testing' driver.  It looks like the 08 06
should be where the 00 44 is, if I understand things correctly.

Packet received, hdr:
00 60 b3 69 56 67 00 02 2d 0b 27 a0 00 44 aa aa
03 00 00 00 08 06

Thanks,
Ben

Ben Greear wrote:

> I just tried the 'testing' release of the orinoco_cs
> driver...it works much better (I can see pings going
> to my laptop, and being responded to.)
> 
> However, I never see the ping response on the cube's cmd line (I do
> see the rx packet counters bumping correctly, though).
> 
> Arp is working though, for whatever reason...
> 
> Ben Greear wrote:
> 
>>
>>
>> Martijn van Oosterhout wrote:
>>
>>> On Tue, Feb 19, 2002 at 09:51:43PM -0700, Ben Greear wrote:
>>>
>>>> The interesting thing is that when I ping between the other machines, I
>>>> see packets received on the cube.  When I ping from the cube to the 
>>>> laptop,
>>>> while sniffing the wireless port on the laptop with tcpdump, I see 
>>>> this:
>>>>
>>>>
>>>> [time-stamp] 0:60:b3:69:56:67 > Broadcast null I (s=85,r=85,C) len=50
>>>> (more of the same)
>>>>
>>>
>>> Was there not something about structure padding that caused some 
>>> structures
>>> to be padded differently on Arms than on other architectures, causing
>>> transmitted packets to be unreadable to anyone else?
>>>
>>> I beleive it was fixed in a more recent version, the one shipped with 
>>> the
>>> kernel source is pretty old now.
>>
>>
>>
>>
>> I'll check that out in just a second (or maybe tomorrow :)
>>
>> I put in some prints deep in the driver in the orinoco_xmit method:
>>
>>
>>                if (1) {
>>                   int i = 0;
>>                   const unsigned char* dbg = (const unsigned 
>> char*)(&hdr);
>>                   for (i = 0; i<(sizeof(hdr)); i++) {
>>                      printk("%02hx ", (unsigned short)(dbg[i]));
>>                   }
>>                   printk("\n");
>>                }
>>         err  = hermes_bap_pwrite(hw, USER_BAP, &hdr, sizeof(hdr),
>>                      txfid, 0);
>>
>>
>> I see this printed out...it should be an arp from what I can tell:
>>
>> Feb 20 06:46:46 CerfLinux kern.warn eh->h_proto: 0x608  ntohs: 0x806
>> Feb 20 06:46:46 CerfLinux kern.warn Ethernet-II frame, len: 60, 
>> sizeof(hdr)...
>> Feb 20 06:46:46 CerfLinux kern.warn 00 00 00 00 00 00 00 00 00 00 00 
>> 00 06 00 08 00 00 00 ff ff ff ff ff ff 00 60 b3 69 56 67 00 00 00
>> 00 00 00 00 00 00 00 00 00 00 00 44 00 ff ff ff ff ff ff 00 60 b3 69 
>> 56 67 00 44 00 00 aa aa 03 00 00 00 08 06
>>
>> It really doesn't look too correct to me!
>>
>>
>> I also receive this packet every now and then...not sure what it's 
>> supposed to
>> be.  This is for code that prints out 'hdr' in __orinoco_ev_rx:
>>
>> Feb 20 06:48:46 CerfLinux kern.warn ERROR: rx pkt failed for some 
>> reason, hdr: (len: 70)
>> Feb 20 06:48:46 CerfLinux kern.warn 05 2e 50 31 6a 71 13 36 14 00 03 
>> 00 00 00 a6 73 52 b8 d8 73 7a 70 31 3c 58 49 c4 44 c6 3a 52 9d 14
>> 6d 89 44 7c e0 28 e0 a2 96 78 ee 00 00 af a0 90 69 ad 40 fd 40 b0 be 
>> 6a 05 00 00 06 09 04 00 12 02 22 02 12 02
>>
>>
>> Thanks for the link,
>> Ben
>>
>>
>>>
>>> http://ozlabs.org/people/dgibson/dldwd/
>>>
>>> HTH,
>>>
>>
>>
> 
> 


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