Re: quetion on beacon irq and multibss
On Friday 10 April 2009 02:14:59 Francesco Gringoli wrote: Ok but what`about MBSS? Is it already implemented in b43? I found some old patches from Johannes but they required fw hacking, I can't find traces of them inside the current kernel. So I would assume MBSS is not yet implemented. No. Very latest firmware kind of implements this (It can do 2 BSS). If you're going to implement it, you should probably look at how they did it. (Basically beacons are pushed via DMA to hardware). If openfw does not raise the interrupt, PS most likely is broken and the firmware cannot work on AP with PS stations associated. Uh, interesting. I completely missed this. I must say I'm not familiar with PS. The beacon interrupt is basically always triggered when the firmware is ready to receive a new beacon. It's a locking mechanism to prevent concurrent accesses to the template ram. If an update is not required, the driver will disable the interrupt. But if the driver needs to update the beacon (for example due to TIM changes), the driver unmasks the interrupt and updates the beacon on interrupt. So I think the beacon IRQ handling in the firmware is trivial. I could remember incorrectly, but I think it just raises it every time it's done handling one beacon. Note that there is some weirdness built in, though. For example if both beacon-valid flags are set that's a special condition and it does _not_ mean both beacons are valid. Look at the driver. There are some comments. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43 Hostap Performance
On Fri, Apr 10, 2009 at 12:28 AM, Francesco Gringoli francesco.gring...@ing.unibs.it wrote: On Apr 9, 2009, at 11:56 PM, Michael Buesch wrote: 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 Can you please release the patch you used to transmit frames using b43 directly, with a complete bypass of the stack? Also, what results do you get if you instead try to use mac80211's radiotap injection feature (which bypasses most, but not all of mac80211)? Thanks, Gábor -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
b43legacy AP
I'd like to try and get b43legacy running in AP mode this weekend. Can anyone tell me what modifications to b43legacy need to be made in order to do so? The last time I tried, I applied the two patches by Larry to address beaconing issues in b43legacy without much success. My tests indicated that hostapd seemed capable of communicating with b43legacy and my 4306 rev 2 through nl80211 but that the card was still not producing any beacons when monitored remotely. The only sign of failure from hostapd is the repeated message of MGMT (TX callback) fail whenever hostapd received a probe for the ssid it configured the interface for. This isn't much information to go on but it points us in a direction to where the problem(s) may exist. Again, any help would be appreciated. Regards, David Ellingsworth ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43legacy AP
On Fri, Apr 10, 2009 at 3:30 PM, Larry Finger larry.fin...@lwfinger.net wrote:
David Ellingsworth wrote:
I'd like to try and get b43legacy running in AP mode this weekend. Can
anyone tell me what modifications to b43legacy need to be made in
order to do so? The last time I tried, I applied the two patches by
Larry to address beaconing issues in b43legacy without much success.
My tests indicated that hostapd seemed capable of communicating with
b43legacy and my 4306 rev 2 through nl80211 but that the card was
still not producing any beacons when monitored remotely. The only sign
of failure from hostapd is the repeated message of MGMT (TX callback)
fail whenever hostapd received a probe for the ssid it configured the
interface for. This isn't much information to go on but it points us
in a direction to where the problem(s) may exist. Again, any help
would be appreciated.
There may be problems that are unique to your 4306 rev 2, but b43legacy with
my
patches runs as an AP just fine.
My configuration is as follows:
LAN === eth0 -- BCM4312/1 as AP ~~ laptop with BCM4318.
As my BCM4312/1 uses ucode5 firmware, I only have to change the ssb_tbl
entries
to have it use either b43 or b43legacy.
I started with b43 driving the AP. I use hostapd v0.6.8 as the basis for the
AP
and the current wireless-testing as my kernel. My hostapd.conf contains the
following:
==
interface=wlan0
driver=nl80211
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
debug=0
dump_file=/tmp/hostapd.dump
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
hw_mode=g
channel=11
beacon_int=100
dtim_period=2
max_num_sta=255
rts_threshold=2347
fragm_threshold=2346
macaddr_acl=0
ignore_broadcast_ssid=0
wme_enabled=1
wme_ac_bk_cwmin=4
wme_ac_bk_cwmax=10
wme_ac_bk_aifs=7
wme_ac_bk_txop_limit=0
wme_ac_bk_acm=0
wme_ac_be_aifs=3
wme_ac_be_cwmin=4
wme_ac_be_cwmax=10
wme_ac_be_txop_limit=0
wme_ac_be_acm=0
wme_ac_vi_aifs=2
wme_ac_vi_cwmin=3
wme_ac_vi_cwmax=4
wme_ac_vi_txop_limit=94
wme_ac_vi_acm=0
wme_ac_vo_aifs=2
wme_ac_vo_cwmin=2
wme_ac_vo_cwmax=3
wme_ac_vo_txop_limit=47
wme_ac_vo_acm=0
eapol_key_index_workaround=0
eap_server=0
own_ip_addr=127.0.0.1
wpa=1
wpa_passphrase=123456789
==
I created a file dhcpd.conf, which contains
==
option domain-name-servers 192.168.1.1;
default-lease-time 600;
max-lease-time 7200;
ddns-update-style none; ddns-updates off;
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.200 192.168.0.229;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;
}
==
My script to control the AP is as follows:
==
#!/bin/sh
# Script to start/stop a hostapd-based access point
#
# Symbols for needed programs
IPTABLES=/usr/sbin/iptables
IFCONFIG=/sbin/ifconfig
DHCPD=/usr/sbin/dhcpd
HOSTAPD=/usr/local/bin/hostapd
# Symbols for internal and external interfaces
NET_INT=wlan0
NET_EXT=eth0
# IP address for the AP
INT_ADDR=192.168.0.1
case $1 in
start)
echo Starting AP mode for $NET_INT at address $INT_ADDR
# Disable packet forwarding
echo 0 /proc/sys/net/ipv4/ip_forward
# Stop hostapd and dhcpd daemons
killproc hostapd
killproc dhcpd
#Set up forwarding
$IPTABLES -t nat -A POSTROUTING -o $NET_EXT -j MASQUERADE
$IPTABLES -A FORWARD -i $NET_EXT -o $NET_INT -m state \
--state RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A FORWARD -i $NET_INT -o $NET_EXT -j ACCEPT
# Enable packet forwarding
echo 1 /proc/sys/net/ipv4/ip_forward
# Get the internal interface in the right state
$IFCONFIG $NET_INT down
$IFCONFIG $NET_INT up
$IFCONFIG $NET_INT $INT_ADDR
# dhcpd needs to have a leases file available - create it if needed
if [ ! -f /var/lib/dhcp/db/dhcpd.leases ]; then
touch /var/lib/dhcp/db/dhcpd.leases
fi
# Bring up the DHCP server
$DHCPD -cf /root/dhcpd.conf $NET_INT
# Bring up hostapd
$HOSTAPD -B /root/hostapd.conf
;;
stop)
echo Stopping AP mode on $NET_INT
# Stop hostapd and dhcpd daemons
killproc hostapd
killproc dhcpd
;;
*)
echo Usage: $0 {start|stop}
exit 1
;;
esac
===
The first thing I found when using b43 as the AP host was that many hundreds
of
PHY transmission errors were generated every second. I got rid of those be
eliminating the code that reports the error in
drivers/net/wireless/b43/main.c.
I also made the same
