Re: [PATCH, RFT] bcm43xx: AccessPoint mode
Hi all, Sorry for answering years after the patch post, I didn't have time to test this take2 patch before. I had a first look at it a couple of days ago, but... you know, that was not my day. Well, it does not work 100%, but at least it's very promising. We are able to create a bssid and correctly send beacon frames out. [...] For my very own situation, that is : - Apple Mini with a BCM 4306 (BigEndian) - Linux/Win32 boxes with USB and PCMCIA wifi cards (mostly 802.11b usb at the moment) Current status is this one : - master mode functionnal - dhcp serving, good uptime - no encryption, WEP or WPA of any kind tested yet - a nice 1.2MB/s bandwidth (I'm testing with a 802.11b at client side, and AFAIK, bcm43xx does not handle 802.11g yet, does it ?) *BUT* a big issue : I got a per-connection hang-up at client side on strong workloads, for both win32 and linux client side, with my usb dongle (which is running ndiswrapper on *nux, sorry for that, I'm ashamed of it, silly me, I know, but well... No choice, and the device was given me free of charge so...). Typical scenario is a ssh session on one hand and a ftp transfer on the other. The ftp hangs, while the ssh session stays up and going. I got no problem with the PCMCIA card (a rock-solid WG511T), on both linux and win32. Of course, the bcm43xx does not say anything about this (if it had said so, I would have posted logs along with this complain), so my conclusion would be : Why on earth is this a per-connection issue ? where do I miss something ? if I'm really missing packets on one connection, why is the other one continuing to live ? I may have forgotten a subtle detail of the TCP/IP behaviour here... Or may that be all about window scaling and fragmentation ? I can not see anything else... I would at least like to know what to test, as I'm a little bit confused here. Yes, I'll try to dig around the ip window and timeout stuff by tonight... Anyway, I would like to thank again and again Alexander and Michael for the work done, that is really impressive. Great work ! Best regards, F. B. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFT] bcm43xx: AccessPoint mode
On Wednesday 28 June 2006 21:27, Francois Barre wrote: Hi all, Sorry for answering years after the patch post, I didn't have time to test this take2 patch before. I had a first look at it a couple of days ago, but... you know, that was not my day. Well, it does not work 100%, but at least it's very promising. We are able to create a bssid and correctly send beacon frames out. [...] For my very own situation, that is : - Apple Mini with a BCM 4306 (BigEndian) - Linux/Win32 boxes with USB and PCMCIA wifi cards (mostly 802.11b usb at the moment) Current status is this one : - master mode functionnal - dhcp serving, good uptime - no encryption, WEP or WPA of any kind tested yet - a nice 1.2MB/s bandwidth (I'm testing with a 802.11b at client side, and AFAIK, bcm43xx does not handle 802.11g yet, does it ?) *BUT* a big issue : I got a per-connection hang-up at client side on strong workloads, for both win32 and linux client side, with my usb dongle (which is running ndiswrapper on *nux, sorry for that, I'm ashamed of it, silly me, I know, but well... No choice, and the device was given me free of charge so...). Typical scenario is a ssh session on one hand and a ftp transfer on the other. The ftp hangs, while the ssh session stays up and going. I got no problem with the PCMCIA card (a rock-solid WG511T), on both linux and win32. Of course, the bcm43xx does not say anything about this (if it had said so, I would have posted logs along with this complain), so my conclusion would be : Why on earth is this a per-connection issue ? where do I miss something ? if I'm really missing packets on one connection, why is the other one continuing to live ? I may have forgotten a subtle detail of the TCP/IP behaviour here... Well, I doubt it is a bcm43xx issue. But maybe. Not sure. Do you run some QoS stuff? Some other quota stuff? -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFT] bcm43xx: AccessPoint mode
Well, I doubt it is a bcm43xx issue. But maybe. Not sure. Do you run some QoS stuff? Some other quota stuff? Yes, a special QoS rule that cuts off connections from devices that do not use a GPL driver. Long life to the penguin ! Soon, my HiFi will cut off the whole drum section of the DRM songs I'll ask it to play, and I'm thinking about how to teach my oven not to bake GM Food :-p. More seriously, no, I do not have any QoS nor quota service running. Instead, I was more thinking about a beacon at high rates, but I do not have enough 802.11 knowledge to know what is advertised during connection... Maybe the netdev guys would have a clue, a tool, or a bright idea ? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFT] bcm43xx: AccessPoint mode
On Mon, 19 Jun 2006 11:07:34 +0200, Michael Buesch wrote: Well, it does not work 100%, but at least it's very promising. We are able to create a bssid and correctly send beacon frames out. Great work! I was even able to ping. (Tried only open system authentication for now, it seems it works quite well.) Please give it a testrun. Final note about hostapd: hostapd snapshot 0.5-2006-06-10 seems to work in the sense that it is able to bring up the device. hostapd snapshot 0.5-2006-06-11 seems to fail. 0.5-2006-06-19 works with the patch. Important notes from Alexander Tsvyashchenko's initial mail follow: [...] Although my previous patch to hostapd to make it interoperable with bcm43xx dscape has been merged already in their CVS version, due to the subsequent changes in dscape stack current hostapd is again incompartible :-( So, to test this patch, the patch to hostapd should be applied. Or, if you don't want to patch hostapd (untested, but should work): iwpriv wlan0 param 1046 1 ip link set wmgmt0 name wmaster0ap hostapd /path/to/hostapd.conf iwpriv wlan0 param 1046 0 I used hostapd snapshot 0.5-2006-06-10, patch for it is attached. The patch is very hacky and requires tricky way to bring everything up, but as dscape stack is changed quite constantly, I just do not want to waste time fixing it in proper way only to find a week later that dscape handling of master interface was changed completely once more and everything is broken again ;-) Hopefully we will convert the whole hostapd-stack communication to netlink in some near future ;-) 2) Insert modules (80211, rate_control and bcm43xx-d80211) modprobe bcm43xx-d80211 is enough, other modules will load automatically. 4) ifconfig wlan0 up (this should be done by hostapd actually, but its operation with current dscape stack seems to be broken) hostapd tries to open (put to 'up' state) wmgmt0 earlier than wlan0, which is not possible. It should open wlan0 first; even more, opening of wmgmt0 is not necessary as it will be opened automatically when wlan0 is opened. 6) iwconfig wlan0 essid your-SSID-name (this also should not be required, but current combination of hostapd + dscape doesn't seem to generate config_interface callback when setting beacon, so this is required just to force call of config_interface). The stack currently has very limited support for cards with beacon templates. ieee80211_beacon_get function is not designed in a way it is used in bcm43xx. Although this seems to be easy to fix now, we will run into other problems later (with TIM elements mainly). I need to look how PS mode works in bcm chipsets to find a correct solution for this. Do you have any ideas? Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH, RFT] bcm43xx: AccessPoint mode
Hi,
This patch enables the usage of a bcm43xx card as AP with
the Devicescape 802.11 stack.
Well, it does not work 100%, but at least it's very promising.
We are able to create a bssid and correctly send beacon frames out.
This patch is tested on BE and LE machines.
There seem to be issues with Devicescape and/or hostap.
Trying to authenticate from a STA to the AP does not work. The
packet is simply not processed. I was able to catch the auth
request on the AP (using the wonderful dscape virtual interfaces).
So the AP receives the packet, but loses it somewhere in the
stack or hostapd.
Well, thanks to Alexander Tsvyashchenko and the OpenWRT team for
the hard work to figure out how this all works.
My part on this patch is mainly endianess fixes.
Please give it a testrun.
Final note about hostapd:
hostapd snapshot 0.5-2006-06-10 seems to work in the sense
that it is able to bring up the device.
hostapd snapshot 0.5-2006-06-11 seems to fail.
I did not look into this more close, yet.
Important notes from Alexander Tsvyashchenko's initial mail follow:
--
1) This version deals with TIM in cleaner way (though, PS mode is still
not supported) - instead of patching dscape stack to skip TIM
generation, it strips TIM when writing probe response template and
leaves it when writing beacon template.
2) As in current dscape stack management interface seems to be no longer
passed to the driver, all interface handling is left as it is, no
changes there should be made anymore.
...
Known limitations:
1) PS mode is not supported.
Testing instructions:
Although my previous patch to hostapd to make it interoperable with
bcm43xx dscape has been merged already in their CVS version, due to
the subsequent changes in dscape stack current hostapd is again
incompartible :-( So, to test this patch, the patch to hostapd should be
applied.
I used hostapd snapshot 0.5-2006-06-10, patch for it is attached.
The patch is very hacky and requires tricky way to bring everything up,
but as dscape stack is changed quite constantly, I just do not want to
waste time fixing it in proper way only to find a week later that
dscape handling of master interface was changed completely once more and
everything is broken again ;-)
The patch for dscape stack that is attached is not 100% necessary, but it
seems to allow operating clients that request PS mode to be enabled at
AP (verified with PDA client), the only thing it contains is disabling
actual PS handling in dscape.
So, the following sequence should be used to test AP mode:
1) take hostapd snapshot 0.5-2006-06-10 (other recent versions should
work OK also, though), apply the hostapd patch attached.
2) Insert modules (80211, rate_control and bcm43xx-d80211)
3) iwconfig wlan0 mode master
4) ifconfig wlan0 up (this should be done by hostapd actually, but
its operation with current dscape stack seems to be broken)
5) Start hostapd (f.e. hostapd -B /etc/hostapd.conf), config file can
look like:
=
interface=wlan0
driver=devicescape
ssid=OpenWrt
channel=1
send_probe_response=0
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
debug=4
=
6) iwconfig wlan0 essid your-SSID-name (this also should not be
required, but current combination of hostapd + dscape doesn't seem to
generate config_interface callback when setting beacon, so this is
required just to force call of config_interface).
Index:
wireless-dev-dscapeports/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
---
wireless-dev-dscapeports.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-06-17 21:26:10.0 +0200
+++ wireless-dev-dscapeports/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-06-18 23:36:31.0 +0200
@@ -152,7 +152,7 @@
u32 status;
status = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
- if (!(status BCM43xx_SBF_XFER_REG_BYTESWAP))
+ if (status BCM43xx_SBF_XFER_REG_BYTESWAP)
val = swab32(val);
bcm43xx_write32(bcm, BCM43xx_MMIO_RAM_CONTROL, offset);
@@ -312,7 +312,7 @@
}
}
-void bcm43xx_tsf_write(struct bcm43xx_private *bcm, u64 tsf)
+static void bcm43xx_time_lock(struct bcm43xx_private *bcm)
{
u32 status;
@@ -320,7 +320,19 @@
status |= BCM43xx_SBF_TIME_UPDATE;
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, status);
mmiowb();
+}
+
+static void bcm43xx_time_unlock(struct bcm43xx_private *bcm)
+{
+ u32 status;
+
+ status = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
+ status = ~BCM43xx_SBF_TIME_UPDATE;
+ bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, status);
+}
+static void bcm43xx_tsf_write_locked(struct bcm43xx_private *bcm, u64 tsf)
+{
/* Be careful with the in-progress timer.
* First zero out the low register, so we have a full
* register-overflow duration to complete the operation.
@@ -350,10
