Gateworks 2348 and ath problem

Sam Leffler sam at errno.com
Thu Nov 30 08:51:38 PST 2006


John Hay wrote:
>> Ok, I built a kernel without all those options, but it didn't make a
>> difference. I also tried sta mode and it still looks the same. Some
>> new info that I have is that when I do a tcpdump on the arm box itself,
>> adding -y IEEE802_11_RADIO makes a difference. Without it the outgoing
>> packets looks ok, but with it 2 bytes are added between the ether (802.11)
>> header and the ip(v6) header.
> 
> Ok, I found the problem. Using LLC_SNAPFRAMELEN works better than
> sizeof(struct llc). LLC_SNAPFRAMELEN is defined as 8 and sizeof()
> returns 10. Doing a grep in net/ if see that LLC_SNAPFRAMELEN is used
> a lot, so I guess this is the correct way go. I nobody has anything
> against it, I can commit it.
> 
> With this patch traffic seems to flow normally over the atheros wifi
> link. I have not done too much testing, but olsrd works and I can ssh
> to it.

Very strange.  I did not need this change on my systems and was not
seeing the problem.  But what you found makes sense.

> 
> I see a lot of rix packets:
> 
> Nov 30 15:49:29 arm-tst kernel: rix 2632 (0) bad ratekbps 0 mode 1
> Nov 30 15:49:29 arm-tst kernel: rix 2632 (0) bad ratekbps 0 mode 1
> Nov 30 15:49:30 arm-tst kernel: rix 2633 (0) bad ratekbps 0 mode 1
> Nov 30 15:49:30 arm-tst kernel: rix 2633 (0) bad ratekbps 0 mode 1
> Nov 30 15:49:30 arm-tst kernel: rix 2601 (0) bad ratekbps 0 mode 1
> 
> I don't see it on our wrap and soekris boxes, but they are running
> 6-stable... Well I have seen it, but that was if I put the link in
> 11b mode, not in 11a or 11g mode. I'm using 11a at the moment.
> 
> Sam, are they related to the rate changes you made recently? 

No they are unrelated.  These are the complaints I saw in my testing and
hadn't had time to resolve.  They appear to be caused by extracting
bogus rate codes from the h/w descriptors and then feeding them back
into the rate control module.  I'm still trying to get a new hal out for
testing and that hal will have the descriptor state split into
cache+uncached areas so I'd prefer to chase any problems like this w/
that code and not code that's about to be replaced.

	Sam


More information about the freebsd-arm mailing list