On Apr 9, 2009, at 11:56 PM, Michael Buesch wrote: > On Thursday 09 April 2009 23:47:25 Francesco Gringoli wrote: >> >> On Apr 6, 2009, at 5:04 PM, Michael Buesch wrote: >> >>>>> >>>>> Well, you know that lots of cards don't work correctly with b43. >>>>> I bet you're using a BCM4318 flavor. >>>>> >>>> >>>> Sadly, yes, it is a BCM4318. I've tried moving further away from >>>> the >>>> AP, as well as decreasing the txpower output.. neither seemed to >>>> help >>>> any. I suspect something else may be the cause of the poor >>>> performance >>>> that I'm seeing. I'll try to rule out the card as a problem tonight >>>> by >>>> setting up an Ad-Hoc network under Windows XP. If I observe good >>>> performance then maybe b43 is the issue... In which case.. I'll >>>> start >>>> the painful process of comparing the Windows driver to b43. If I >>>> find >>>> any discrepancies, I'll send them to the reverse engineers to be >>>> posted with the rest of the specs. Then maybe you or someone else >>>> can >>>> make the appropriate changes to b43. >>> >>> 4318 currently is not usable in AP mode due to low but (for AP mode) >>> significant >>> packet loss in high transmission rates. >>> I doubt this will change unless Broadcom releases some code. >> Michael, >> >> is this for all 4318? I'm doing extensive testing these days with >> both >> 4318 and 4306 on x86. I always get very good performance with latest >> hostapd on 2.6.29-rc2-wl. I can also reach maximum theoretical >> throughput if I choose channel 14 to limit interferences. I get max >> throughput independently of the board running hostapd and traffic >> direction. >> >> All this applies to both AP and stations being x86 linux based, e.g., >> if I try to join an x86 AP running b43 from my macbook I can get good >> performance only occasionally. >> >> Good performance also if the station is a linksys wrt54gl (it uses a >> 4318). I can't instead run hostapd successfully on these linksys. > > 4318 is good enough for STA mode, but in AP mode it doesn't work > correctly, because > it simply loses too many packets. So it loses important management > frames, etc... . > If you limit the TX rate to 24M it becomes usable, however. > 4306 is _much_ better in AP mode. You mean that it misses to transmit some frames? Do you have hypotheses on why AP mode should complete change the behavior of the board from "good enough" to "not working correctly"? The only difference between station and AP mode AFAIK is that AP mode honors the TBTT condition and transmit the beacon when a beacon is needed. I say honor since that condition and the other about beacon needed are raised also in station mode but they are not handled. I'm confused. > > > Of course, there always are exceptions to these rules, because there > are about > a million completely different 4318 and and 4306 cards out there. > So you might be lucky to pick one of the few 4318 that works well in > AP mode, or > you might pick one of the few 4306 that don't work too well. Ok, that could be. I have only 4318 branded as Asus, they are all equal. Probably the fact the linksys does not work in AP mode confirm what you say.
I have noticed, however a strange fact with these 4318 based linksys: when I set one of them in AP mode, beaconing is perfect and I can join it from other stations. When I ping the AP from stations I get echo reply. If, instead, I ping stations from the AP, no packet is sent! at all; if I telnet from stations to the AP, e.g., to port 22, 3whs ends but then the TCP session dies. The strange fact is that it seems that there are problems for all the frames whose generation involves a contest switching from userspace to kernel, in other words a complete cross of the mac80211+b43 layers. If instead, on the AP, I completely bypass the network stack and directly ask b43 to transmit a frame (with a modified b43) the frame is transmitted, at every rate I choose (I choose the rate inside the kernel code, I'm not referring to the rate set by iwconfig). Do you have some of these flawed 4318? -Francesco > > > -- > Greetings, Michael. ------- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
