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 -- http://www.hailfinger.org/
