On Mon, Jun 15, 2009 at 6:34 PM, Stefan Lippers-Hollmann<s....@gmx.de> wrote: > Hi > > On Monday 15 June 2009, Alexander Monakov wrote: > [...] >> I'm using Asus wl-138g v2 card (4318 chipset) in managed mode with a >> Cisco wireless AP. I am able to use both ndiswrapper and b43 driver >> with open source firmware. The ndiswrapper solution has worked fine >> for me for months; b43/openfwwf — not quite so: it tends to >> deauthenticate seconds after associating. > [...] > > Are you sure that your "Asus wl-138g v2" really is a "core revision 5" > chipset, which is all OpenFWWF claims to support yet? > > At least my own Asus wl-138g v2 indentifies itself as > b43-phy0: Broadcom 4318 WLAN found (core revision 9) > in dmesg and as such isn't even supposed to be covered by OpenFWWF at all, > yet (yes, it does work with OpenFWWF nevertheless, but with worse > performance and link reliability, but that's to be expected as long as > OpenFWWF doesn't have dedicated support for core revision 9).
Oops. My apologies. I have completely missed this fact, and my card is indeed rev.9 (how was I supposed to know that, anyway? I fail to find it on openfwwf site). I'll be happy to test openfwwf again when it's ready for rev.9. I have tested b43 from 2.6.30 with 4.150 firmware today, and it seems to be fine (it was not this good with older kernels, I swear!): there have not been any apparent problems when testing with iperf, but there still are occasional disassociations with reason 2 when downloading via ftp for a long time. In wireshark on bcm4318 I see that driver sends one probe after 2-seconds silence (no rx _and_ tx), and then sends deauthentication packet with reason 2 in params after two more seconds. The kernel log reads: ... multiple PHY error messages ... [87262.212293] b43-phy6 ERROR: PHY transmission error [87265.146802] b43-phy6 debug: Wireless interface stopped [87265.146851] b43-phy6 debug: DMA-32 rx_ring: Used slots 2/64, Failed frames 0/0 = 0.0%, Average tries 0.00 [87265.146897] b43-phy6 debug: DMA-32 tx_ring_AC_BK: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 [87265.151290] b43-phy6 debug: DMA-32 tx_ring_AC_BE: Used slots 172/256, Failed frames 54/109944 = 0.0%, Average tries 1.55 [87265.157956] b43-phy6 debug: DMA-32 tx_ring_AC_VI: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 [87265.164634] b43-phy6 debug: DMA-32 tx_ring_AC_VO: Used slots 2/256, Failed frames 2/18 = 11.1%, Average tries 2.16 [87265.171290] b43-phy6 debug: DMA-32 tx_ring_mcast: Used slots 0/256, Failed frames 0/0 = 0.0%, Average tries 0.00 [87265.327966] b43-phy6: Loading firmware version 410.2160 (2007-05-26 15:32:10) [87265.348001] b43-phy6 debug: Chip initialized [87265.348093] b43-phy6 debug: 32-bit DMA initialized [87265.365044] b43-phy6 debug: Wireless interface started [87269.142140] wlan0: no probe response from AP 00:18:74:d1:1a:c0 - disassociating Strangely, iw event does not register deauth packet. If I re-assign ESSID (without changing it, just iwconfig wlan0 essid XXX), the card reassociates, and ftp transfer continues. Why does automatic reassociation not work in this case? Why there was only one probe? What might be the reason for 'b43-phy6 debug: Wireless interface stopped'? And to answer Michael's question about iperf on openfwwf: > What does iperf in UDP mode show? Does it also show these bursts? No, the throughput is quite stable (unstable for tcp). With 4.150 firmware, throughput is also stable for both udp and tcp. Thanks. -- Alexander Monakov _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
