Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
* Bastian Bittorf bitt...@bluebottle.com [18.07.2012 17:43]: 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. [...] another issues was found, see https://dev.openwrt.org/ticket/7552#comment:69 ...under high load and have found that probably some of the silent freezes are due to overflow of the RX DMA buffer, seems like b43 does not handlre such a situation at all. https://dev.openwrt.org/attachment/ticket/7552/840-b43-workaround-rx-fifo-overflow.patch the patch is working so far, but is only a workaround. has somebody a better code-idea? bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
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.00. 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
Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
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 i cannot answer this question - interesting idea. i like to test your patch, simply do a dummy tx in both cases. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
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? the simple approach is installing horst on another router or your pc. ofcourse you get a full dump with wireshark sniffing on your monitor-interface. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
2012/8/22 Hauke Mehrtens ha...@hauke-m.de: 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ł. Does your kernel include commit bad6919469662b7c92bc6353642777b36bac Author: francesco.gring...@ing.unibs.it francesco.gring...@ing.unibs.it Date: Fri Dec 16 18:34:56 2011 +0100 b43: avoid packet losses in the dma worker code. ? I have a lot of things on my TODO list, including that. Right now I just want to focus on BCM4706 support, which slowly moves into mainline. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
On 08/22/2012 07:49 PM, Rafał Miłecki wrote: 2012/8/22 Hauke Mehrtens ha...@hauke-m.de: 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ł. Does your kernel include commit bad6919469662b7c92bc6353642777b36bac Author: francesco.gring...@ing.unibs.it francesco.gring...@ing.unibs.it Date: Fri Dec 16 18:34:56 2011 +0100 b43: avoid packet losses in the dma worker code. ? I have a lot of things on my TODO list, including that. Right now I just want to focus on BCM4706 support, which slowly moves into mainline. This patch is included. I used compat-wireless-2012-07-16 plus some more backport patches for b43. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
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.00. 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? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
Hi, I was happy to see this post since I've been wanting to move away from tbe brcm-2.4 build for quite some time. Unfortunately I have not been able to fix mine using this method. I am on a WRT54GS. I tried: iw dev wlan0 set bitrates legacy-2.4 6 9 12 18 24 36 48 54 It seems to got a little longer before hanging, but a large file copy will still cause the wireless to hang after a few minutes. Of course wifi up will still revive the wireless. Should I be making the equivalent iw set bitrates on the client machine as well (I have a laptop connected to the router)? If so that may not be practical since not all of my client machines are on linux (my wife's windows laptop, and my tivo doesn't expose advanced wireless config). Also, you mention putting wifi up in a cron script. Does doing that sever already extablished connections? So if I did this in the middle of a large file copy, would it break the connection? I wonder if a temporary solution might be to hack the b43 driver such that it would refuse to change from g to b speeds regardless of client settings. I'm no kernel dev, but it might be worth toying with. One more question: What build of openwrt are you using? I am on Backfire 10.03.1, r29592. Perhaps I should be trying this trick on a development snapshot instead. Thanks for the work investigating this, Bastion. 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
On Thu, Aug 16, 2012 at 4:25 PM, Bastian Bittorf bitt...@bluebottle.comwrote: am on a WRT54GS. I tried: iw dev wlan0 set bitrates legacy-2.4 6 9 12 18 24 36 48 54 are you in adhoc or ap-mode? I am in ap mode. Should I be making the equivalent iw set bitrates on the client machine as well (I have a laptop connected to the router)? yes, ofcourse. otherwise it doesnt make sense, because it seems that the situation will come up, when mudulation changes (fast) between OFDM and non-OFDM. (e.g. 11 vs. 12mbit or 5.5 vs. 6 mbit) I tried the same bitrate setting on my linux laptop. It seemed to last much longer before eventually stalling. I configmed that the bitrates stayed within the desired set. By constantly running iwconfig wlan0 on the laptop to see the current bitrate for the connection. It may be still eventually stalling because I am not on the latest development snapshot, so I will upgrade and try again. If so that may not be practical since not all of my client machines are on linux (my wife's windows laptop, and my tivo doesn't expose advanced wireless config). but you can hardware them to 802.11g IMHO I never thought of that. I'll see if I can find a way to do that. Also, you mention putting wifi up in a cron script. Does doing that sever already extablished connections? So if I did this in the middle of a large file copy, would it break the connection? no, it will just continue, you can take this for a start: http://intercity-vpn.de/files/openwrt/cron.minutely_checkwifi.sh Thanks for your cronscript. I will definitely try this. It may be enough to keep it working well enough until a real fix is here. I wonder if a temporary solution might be to hack the b43 driver such that it would refuse to change from g to b speeds regardless of client settings. I'm no kernel dev, but it might be worth toying with. yes, that would be a solution but i think thats not (easy) possible: the decoding is done in hardware IMHO, but maybe its enough to say in the beacons i can only speak x.y One more question: What build of openwrt are you using? I am on Backfire 10.03.1, r29592. Perhaps I should be trying this trick on a development snapshot instead. yes, we are using recent trunk, e.g. r32764 or newer. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
1) why does a band change (can be seen through minstrel) is a problem? Because IIRC b43 doesn't support anything other than 2.4GHz at all. 8-) sorry, i used the wrong term band: (fast) changing between b and g rates are the problem. you can easily reproduce, when you force this by: iw dev $WIFIDEV set bitrates legacy-2.4 11 12 (use only b-rate 11 and g-rate 12) So minstrel will happily change/try both, wifi will stop. The same with: iw dev $WIFIDEV set bitrates legacy-2.4 5.5 6 bye, Bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
What chip is in your WRT54G? We tested both: 4318 (Buffalo HP54G) and 4306 (Linksys WRT54GL) bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
1) why does a band change (can be seen through minstrel) is a problem? Because IIRC b43 doesn't support anything other than 2.4GHz at all. It's not a change between 2.4 and 5 GHz. Wifi stops working if the bitrate changes between 11b (1, 2, 5.5, 11) and 11g (6, 9, 12, 18, 24, 36, 48, 54) rates So if we tell the system to only use 11g rates, wifi doesn't stop. Andi ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
