Ar6K Driver problems

[Arnaud Derasse]

hello,

I used Wireshark to analyse the packet between my computer and the Ar6k 
target device.
Pings and ARP are correct.
The chip is freezing when the following packet is sent :

Connecting to 192.168.0.2[192.168.0.2]:80
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Description: SDIO MX27: - TX DMA DataDump

Offset                   Data                               ASCII       
--------------------------------------------------------------------------
0000    02 00 54 00 00 00 00 00 00 0C 6E 74 88 83 00 12    ..T.......nt....
0010    CF 8E EB 43 00 44 AA AA 03 00 00 00 08 00 45 00    ...C.D........E.
0020    00 3C FF 5B 40 00 40 06 BA 07 C0 A8 00 06 C0 A8    .<.[@. at .........
0030    00 02 CC 08 00 50 31 78 13 C2 00 00 00 00 A0 02    .....P1x........
0040    16 D0 B1 AF 00 00 02 04 05 B4 04 02 08 0A 00 01    ................
0050    EC 99 00 00 00 00 01 03 03 01 00 00 00 00 00 00    ................
0060    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0070    00 00 00 00 00 00 00 00 00 00 02 00 01 00 00 00    ................
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

This packet is a TCP SYN packet to port 80 at 192.168.0.2 and seems to 
be correct.
There is some data for the Ar6K, since i do not have the documentation I 
can't analyse it.
The first 8 Bytes are for the Ar6K, then it's the begining of Ethernet 
Frame. This packet is never received by the host computer.

When I use SSH from my computer and try to connect to the Ar6K device, 
the problem is the same.
The host pc send the first TCP SYN packet, I can see the packet on the 
Ar6K with the DMA Dumps
But the ar6k freeze when the ACK is sent.

The driver tries to send the packet multiple times but the ar6k is 
freezed after the first "target debug" message. (see log attache on my 
first mail ).

I really have no idea of what it could be.

Regards,
Arnaud Derasse


Carl-Daniel Hailfinger a écrit :
> On 17.07.2008 13:42, Arnaud Derasse wrote:
>   
>>> You can see if this is the problem by sending abnormal pings, you can
>>> both floodping and change the size of ping payload, see man ping.
>>>       
>> We already tried big pings It's working fine :
>> ping -s 2048 is working.
>>     
>
> You may want to test ping from both sides and also make sure to use the
> "-M do" parameter to ping.
>
>
>   
>> 2048 bytes is maybe not enought.
>>
>> The strange thing is : If we wget an ip with no machine, we have the
>> same problem.
>> wget http://unused.ip.address
>>
>> On a computer, this returns a timeout , on the target with ar6k, we
>> have exactly the same log as if we used a valid address. This is the
>> proof the problem is with sending the query, not receiving something
>> too big.
>>     
>
> A tcpdump of the traffic on both sides should allow you to determine the
> packet which doesn't get through. Try to replicate the same effect with
> ping afterwards. It's also possible that the packet which gets the
> driver/chip stuck is not the last packet seen on the receiving end, but
> the one before that.
> Unless the wireless firmware is interpreting the TCP/ICMP/IP headers, it
> should be possible to reproduce the bug with a combination of pings from
> each side, thereby hopefully leading to a simpler testcase.
> Looking at layer 2 (especially the packets without data payload) is
> probably most instructive, though.
>
> Regards,
> Carl-Daniel
>
>