WRT54g / b43 / mac802.11 BREAKTHROUGH

Sat Aug 25 10:50:59 EDT 2012

On 08/22/2012 11:19 PM, Larry Finger wrote:
> On 08/22/2012 04:05 PM, Hauke Mehrtens wrote:
>> On 08/22/2012 08:45 PM, Larry Finger wrote:
>>> On 08/22/2012 11:21 AM, Hauke Mehrtens wrote:
>>>> On 07/18/2012 01:56 PM, Bastian Bittorf wrote:
>>>>> hi devs!
>>>>>
>>>>> yesterday we had a breaktrough debugging b43 in our hackspace
>>>>> maschinenraum/m18[1,2]
>>>>> at weimar.freifunk.net[3,4] - since a long time our darling wrt54g
>>>>> suffers from a
>>>>> hanging wifi and bad performance[5], but the workaround is easy: now
>>>>> it's up to
>>>>> you to fix the rootcause.
>>>>>
>>>>> our testsetup, where we could _reproduce_ reliably a stopping TX is
>>>>> like this:
>>>>>
>>>>> laptop ---lan--- "A"-wrt54g/adhoc ~~~   air  ~~~ "B"-anyrouter/adhoc
>>>>>
>>>>> now make a testdownload with the laptop from B.
>>>>> wireless will stop working after ~10 seconds.
>>>>>
>>>>> wifi up will reanimate and our freifunk-cron.minutely-check
>>>>> will do this automagically. (read further, this is not the solution)
>>>>>
>>>>> we tried to limit the rateset to e.g. lower rates, but this does NOT
>>>>> change
>>>>> the behaviour. what works is: define a rateset on BOTH router which
>>>>> makes
>>>>> it impossible to change the band, e.g.:
>>>>>
>>>>> iw dev $WIFIDEV set bitrates legacy-2.4 1 2 5.5 11
>>>>> OR
>>>>> iw dev $WIFIDEV set bitrates legacy-2.4 6 9 12 18 24 36 48 54
>>>>>
>>>>> now we had a great performance, 10 Gigabytes of wireless transfer,
>>>>> no stopping TX anymore and an empty box of beer. three things to do
>>>>> now:
>>>>>
>>>>> 1) why does a band change (can be seen through minstrel) is a problem?
>>>>>
>>>>> 2) we have to make in config-option to force a band, or a rateset:
>>>>>      e.g. uci set wireless.radio0.hwmode=11g
>>>>>      e.g. uci set wireless.radio0.bitrates='6 9 12 18 24 36 48 54'
>>>>>
>>>>> 3) spread to word:
>>>>>      there is a great frustration in the community about b43,
>>>>>      but the old drivers _have_ to die, it's about time - really.
>>>>>
>>>>> thanks for your work,
>>>>> bye storchi, andi, bastian + m18 crew
>>>>>
>>>>> [1] http://blog.maschinenraum.tk/
>>>>> [2]
>>>>> http://blog.maschinenraum.tk/2012/07/15/bitcoin-vending-machine-exchange-euro-coins-for-bitcoin-wallets/
>>>>>
>>>>>
>>>>> [3] http://wireless.subsignal.org
>>>>> [4] http://wireless.subsignal.org/index.php?title=Main_Page_en
>>>>> [5] https://dev.openwrt.org/ticket/7552
>>>>
>>>> I tried this on some of my devices (BCM4318 G-PHY and BCM4322 N-PHY)
>>>> and
>>>> it is easily reproducible on all tested devices when restricting the
>>>> rates to 11 and 12 MBit/s.
>>>>
>>>> I have the Broadcom device working as an Access point (on a MIPS SoC)
>>>> and a Laptop with an Intel Wifi device is connected to it. I generated
>>>> the traffic with iperf. If the Access Points sends the traffic the
>>>> problem occurs, if it is just receiving there is not problem.
>>>>
>>>> After the problem occurred b43_generate_txhdr is called rarely ( every
>>>> ~10 seconds) and I am not able to stay connected or connect to the
>>>> network any more. I am not familiar with the internal flow in b43 or
>>>> mac80211 could someone give me a hint where to look.
>>>>
>>>> I can not see any special changes between CCK and OFDM rates before it
>>>> goes down there are many changes without a problem before it goes down.
>>>>
>>>> Currently I do not have a Broadcom wifi card running in a x86 device
>>>> just mips devices could someone try to reproduce the problem on a x86
>>>> device.
>>>>
>>>> I added the b43 mailing list and Rafał.
>>>
>>> Hauke or Bastian,
>>>
>>> Do you have any info whether the failure occurs with the change from
>>> OFDM to CCK, or vice versa? I am wondering if the radio needs a dummy
>>> transmission when the switch happens. I will try to put together a patch
>>> to test that hypothesis.
>>>
>>> Larry
>>
>> It is strange. The stop does not occur directly after changing from OFDM
>> to CCK or vice versa. TX seams to still work, but the device does not
>> receive anything any more.
>>
>> Here are some logs from my device:
>> http://hauke-m.de/files/b43/wifi-stop/2012-08-22/b43-ap-block.txt
>> Patch used:
>> http://hauke-m.de/files/b43/wifi-stop/2012-08-22/b43-ap-block.patch
>>
>> "iw dev wlan0 set bitrates legacy-2.4 11 12" was issued at ~120.000000.
>>
>> How do I monitor this particular channel with an other wifi card to get
>> most of the packages, with aircrack I am unable to set the channel?
> 
> Thanks for the log and the patch you used.
> 
> You should be able to use Kismet and set the channel; however, I usually
> let it capture everything, and then use wireshark to analyze the pcap
> file. That way, it is fairly easy to set filters to exclude the unwanted
> traffic from other AP and STA sources.
> 
> I don't use wireshark to capture the data because the box I use does not
> have a GUI desktop, and the command-line kismet is perfect for that setup.
> 
> Larry

Hi Larry,

I did some further debugging and saw that the driver gets an interrupt
indicating some new received frames, but b43_dma_rx does not fetch any
new frames.

Here are some logs from my device:
http://hauke-m.de/files/b43/wifi-stop/2012-08-25/b43-ap-block-2.log
Patch used:
http://hauke-m.de/files/b43/wifi-stop/2012-08-25/b43-ap-block-2.patch

Sometime after 210 my wifi client disconnects from the network.

With PIO the AP goes down when trying to connect to it with a wifi client.

Hauke