Re: Fwd: That whole Linux stealing our code thing
Adrian Bunk wrote: On Sat, Sep 01, 2007 at 01:37:18PM -0400, Constantine A. Murenin wrote: On 01/09/07, Jeff Garzik [EMAIL PROTECTED] wrote: Constantine A. Murenin wrote: This will hopefully help diminish certain myths about the code licensing. What myth? The myth that Theo understands dual licensing? Reyk's code was never dual licensed, so it's not like it even matters to the original dispute. It's no longer dual licenced in the FreeBSD tree because the FreeBSD people removed the GPL choice of the dual licenced code 3 months ago. So all of Theo's accusations of people breaking the law by making this dual licenced code GPL-only apply as well to the FreeBSD people... Sigh, why actually check the facts when you can make them up. The code in question is my code. It has my copyright (modulo bits shared with onoe-san who was consulted on the switch from dual-bsd/gpl to bsd only in freebsd). Of course what was amusing was how after I changed the license on the current code in freebsd certain folks retroactively applied the license changes to code that was 3 years old. But is there a point to all this nonsense? I dual-licensed the code so folks could adopt and use it however they saw fit. As I've said before I don't care what people do with the work I give away so long as they don't claim it's their own. That said, I don't see what exact wording you consider inaccurate. Both the FreeBSD and Linux people draw the logical conclusion that this Alternatively means everyone can always choose to remove one of the two choices alternatively offered. According to Theo, that is breaking the law... I've yet to see FreeBSD people speak up so again you're just spouting jibberish. I am speaking up as the author of the code that set the dual license in place. I have the definitive say and I have said that any of my code that is dual-licensed can be made gpl only. Sam - 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] Marvell Libertas 8388 802.11b/g USB driver
David Young wrote:
On Fri, Dec 15, 2006 at 09:52:20PM -0500, Michael Wu wrote:
On Friday 15 December 2006 17:51, Marcelo Tosatti wrote:
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -168,6 +168,23 @@ struct ieee80211_radiotap_header {
* Unitless indication of the Rx/Tx antenna for this packet.
* The first antenna is antenna 0.
*
+ * IEEE80211_RADIOTAP_RX_FLAGS u_int16_t bitmap
+ *
+ * Properties of received frames. See flags defined below.
+ *
+ * IEEE80211_RADIOTAP_TX_FLAGS u_int16_t bitmap
+ *
+ * Properties of transmitted frames. See flags defined below.
+ *
+ * IEEE80211_RADIOTAP_RTS_RETRIES u_int8_tdata
+ *
+ * Number of rts retries a transmitted frame used.
+ *
+ * IEEE80211_RADIOTAP_DATA_RETRIES u_int8_tdata
+ *
+ * Number of unicast retries a transmitted frame used.
+ *
+ *
* IEEE80211_RADIOTAP_FCS u32 data
*
* FCS from frame in network byte order.
@@ -187,7 +204,11 @@ enum ieee80211_radiotap_type {
IEEE80211_RADIOTAP_ANTENNA = 11,
IEEE80211_RADIOTAP_DB_ANTSIGNAL = 12,
IEEE80211_RADIOTAP_DB_ANTNOISE = 13,
- IEEE80211_RADIOTAP_EXT = 31,
+ IEEE80211_RADIOTAP_RX_FLAGS = 14,
+ IEEE80211_RADIOTAP_TX_FLAGS = 15,
+ IEEE80211_RADIOTAP_RTS_RETRIES = 16,
+ IEEE80211_RADIOTAP_DATA_RETRIES = 17,
+ IEEE80211_RADIOTAP_EXT = 31
};
/* Channel flags. */
Did you send this part to netbsd also? We really don't want to fork
radiotap. ;) Also, this should be in a separate patch, but I'm guessing it's
all rolled together for convenience.
No, especially since NetBSD is where I keep the authoritative definitions.
How have you defined RX_FLAGS and TX_FLAGS?
BTW, IEEE80211_RADIOTAP_FCS (above) never made it into radiotap. No bit
is reserved.
Tell that to everyone that implements it.
Sam
-
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] Marvell Libertas 8388 802.11b/g USB driver
Sam Leffler wrote:
David Young wrote:
On Fri, Dec 15, 2006 at 09:52:20PM -0500, Michael Wu wrote:
On Friday 15 December 2006 17:51, Marcelo Tosatti wrote:
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -168,6 +168,23 @@ struct ieee80211_radiotap_header {
* Unitless indication of the Rx/Tx antenna for this packet.
* The first antenna is antenna 0.
*
+ * IEEE80211_RADIOTAP_RX_FLAGS u_int16_t bitmap
+ *
+ * Properties of received frames. See flags defined below.
+ *
+ * IEEE80211_RADIOTAP_TX_FLAGS u_int16_t bitmap
+ *
+ * Properties of transmitted frames. See flags defined below.
+ *
+ * IEEE80211_RADIOTAP_RTS_RETRIES u_int8_tdata
+ *
+ * Number of rts retries a transmitted frame used.
+ *
+ * IEEE80211_RADIOTAP_DATA_RETRIES u_int8_tdata
+ *
+ * Number of unicast retries a transmitted frame used.
+ *
+ *
* IEEE80211_RADIOTAP_FCS u32 data
*
* FCS from frame in network byte order.
@@ -187,7 +204,11 @@ enum ieee80211_radiotap_type {
IEEE80211_RADIOTAP_ANTENNA = 11,
IEEE80211_RADIOTAP_DB_ANTSIGNAL = 12,
IEEE80211_RADIOTAP_DB_ANTNOISE = 13,
- IEEE80211_RADIOTAP_EXT = 31,
+ IEEE80211_RADIOTAP_RX_FLAGS = 14,
+ IEEE80211_RADIOTAP_TX_FLAGS = 15,
+ IEEE80211_RADIOTAP_RTS_RETRIES = 16,
+ IEEE80211_RADIOTAP_DATA_RETRIES = 17,
+ IEEE80211_RADIOTAP_EXT = 31
};
/* Channel flags. */
Did you send this part to netbsd also? We really don't want to fork
radiotap. ;) Also, this should be in a separate patch, but I'm guessing
it's
all rolled together for convenience.
No, especially since NetBSD is where I keep the authoritative definitions.
How have you defined RX_FLAGS and TX_FLAGS?
BTW, IEEE80211_RADIOTAP_FCS (above) never made it into radiotap. No bit
is reserved.
Tell that to everyone that implements it.
My mistake. David pointed out correctly that the mechanism for adding
the FCS out-of-line (IEEE80211_RADIOTAP_FCS) was not used. Instead
there is a flag bit that tells whether or not FCS is present (inline) in
the data. This flag bit is what I was thinking of--it's honored by
ethereal (aka wireshark), kismet, tcpdump, etc.
Sam
-
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: Problem authenticating using WPA with bcm43xx-softmac
Johannes Berg wrote: On Wed, 2006-06-07 at 10:47 -0500, Larry Finger wrote: I have a little more information on what is happening. Great. In IEEE Std 802.11i-2004, which defines the WPA protocol, Figure 11a shows the sequence of exchanges needed to associate. Both bcm43xx-softmac and ndiswrapper go through the Open System Authentication process. Right, you always have to do that. Where they seem to diverge is in the STA's Association Request (Security Parameters) step. With ndiswrapper, the AP responds with a WPA EAPOL-Key message; whereas with softmac, the AP sends back the invalid pairwise cipher message and rejects the association. Interesting. That's strange. Can anyone point to a reference that states what the content of the Association Request should be to get the AP to respond with the EAPOL-Key message? Unfortunately, I have no possibility of implementing a sniffer to see what a correct message contains. Well, it should be shown in the 802.11i spec too. Beware of the order of IE's in the management frames; some AP's are touchy about this. Sam - 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
[Fwd: Re: [PATCH 15/16] ipw2200: switch to the new ipw2200-fw-3.0 image format]
---BeginMessage--- I don't see how to verify the image being loaded is appropriate for the operating mode. The old fw header had a mode field (0 bss, 1 ibss, 2 monitor) but the new one does not--unless it's encoded in the version field? Sam ---End Message---
Re: wireless: recap of current issues (configuration)
Stuffed Crust wrote: On Sun, Jan 15, 2006 at 11:53:55AM -0800, Sam Leffler wrote: The above is a great synopsis but there is more. For example to support roaming (and sometimes for ap operation) you want to do background scanning; this ties in to power save mode if operating as a station. Opportunistic roaming is one of those things that has many knobs to twiddle, and depends a lot on the needs of the users. But we're not actually in powersave mode -- the 802.11 stack can spit out the NULL frames to tell the AP to buffer traffic for us. This is trivial to do. The way you implement bg scanning is to notify the ap you are going into power save mode before you leave the channel (in sta mode). Hence bg scanning and power save operation interact. Scans should be specified as non-distruptive so the hardware driver has to twiddle whatever bits are necessary to return the hardware to the same state that it was in before the scan kicked in. Beyond that, the scanning smarts are all in the 802.11 stack. The driver should be as dumb as possible. :) See above. Doing bg scanning well is a balancing act and restoring hardware state is the least of your worries (hopefully); e.g. what's the right thing to do when you get a frame to transmit while off-channel scanning, how often should you return to the bss channel? Background scanning, yes -- but there are all sorts of different thresholds and types of 'scanning' to be done, depending on how disruptive you are willing to be, and how capable the hardware is. Most thin MACs don't filter out foreign BSSIDs on the same channel when you're joined, which makes some things a lot easier. Er, you need to listen to at least beacons from other ap's if you're in 11g so you can detect overlapping bss and enable protection. There are other ways to handle this but that's one. Further you want to order your channel list to hit the most likely channels first in case you are scanning for a specific ap--e.g. so you can stop the foreground scan and start to associate. With my scenarios, the driver performs the sweep in the order it was given -- if the hardware supports it, naturally. Channel ordering is useful no matter who specifies it. If you offload the ordering to the upper layers then they need to be aware of the regdomain constraints. Probably not a big deal but then you need to synchronize info between layers or export it. And there's other regdomain-related info that may want to be considered such as max txpower. I'm just saying if you want to do a good job there's lots of work here. In terms of beacon miss processing some parts have a hardware beacon miss interrupt based on missed consecutive beacons but others require you to detect beacon miss in software. Other times you need s/w bmiss detection because you're doing something like build a repeater when the station virtual device can't depend on the hardware to deliver a bmiss interrupt. Of course. The stack is going to need a set of timers regardless of the hardware's capabilities, but having (sane) hardware beacon miss detection capabilities makes it a bit more robust. Scanning (and roaming) is really a big can 'o worms. Oh, I know. I've burned out many brain cells trying to build supportable solutions for our customers. I don't recall seeing well-developed scanning code in either of the proposed stacks. Sam - 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: wireless: recap of current issues (configuration)
Stuffed Crust wrote: On Mon, Jan 16, 2006 at 03:55:55PM +0100, Johannes Berg wrote: I really don't see why a plain STA mode card should be required to carry around all the code required for AP operation -- handling associations of clients, powersave management wrt. buffering, ... Sure, fragmentation From the perspective of the hardware driver, there is little AP or STA-specific code, especially when IBSS is thrown in. Thick MACs excepted, there's little more than frame tx/rx, and hardware control twiddling. The AP/STA smarts happen in the 802.11 stack. And, speaking from experience, it is very hard to separate them cleanly, at least not without incurring even more overall complexity and bloat. It's far simpler to build them intertwined, then add a bunch of #ifdefs if you want to disable AP or STA mode individually to save space. Perhaps you haven't hit some of the more recent standards that place more of a burden on the ap implementation? Also some vendor-specific protocol features suck up space for ap mode only and it is nice to be able to include them only as needed. There are several advantages to splitting up the code such as reduced audit complexity and real space savings but I agree that it is an open question whethere there's a big gain to modularizing the code by operating mode. Sam - 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: wireless: recap of current issues (configuration)
Stuffed Crust wrote: On Mon, Jan 16, 2006 at 09:54:15AM -0800, Sam Leffler wrote: The way you implement bg scanning is to notify the ap you are going into power save mode before you leave the channel (in sta mode). Hence bg scanning and power save operation interact. That is not powersave operation -- that is telling the AP we are going into powersave, but not actually going into powersave -- Actual powersave operation would need to be disabled if we go into a scan, as we need to have the rx path powered up and ready to hear anything out there for the full channel dwell time. Please read what I wrote again. Station mode power save work involves communicating with the ap and managing the hardware. The first interacts with bg scanning. We haven't even talked about how to handle sta mode power save. See above. Doing bg scanning well is a balancing act and restoring hardware state is the least of your worries (hopefully); e.g. what's the right thing to do when you get a frame to transmit while off-channel scanning, how often should you return to the bss channel? Disallow all other transmits (either by failing them altogether, or by buffering them up, which I think is better) while performing the scan. Not necessarily in my experience. If we are (continually) scanning because we don't have an association, then we shouldn't be allowing any traffic through the stack anyway. If you do not have an association you are not doing bg scanning. At the end of each scan pass, you return to the original channel, then return scan complete to the stack/userspace. at this point any pending transmits can go out, and if another scan pass is desired, it will happen then. If you wait until the end of the scan to return to the bss channel then you potentially miss buffered mcast frames. You can up the station's listen interval but that only gets you so far. As I said there are tradeoffs in doing this. Er, you need to listen to at least beacons from other ap's if you're in 11g so you can detect overlapping bss and enable protection. There are other ways to handle this but that's one. If you can't hear the traffic, then it doesn't count for purposes of ER protection -- but that said, this only matters for AP operation, so APs shouldn't filter out anyone else's becacons. STAs should respect the use ER Protection bit in the AP's beacon, so can filter out traffic that doesn't match the configured BSSID. Sorry I meant this was needed for ap operation. Oh, I know. I've burned out many brain cells trying to build supportable solutions for our customers. I don't recall seeing well-developed scanning code in either of the proposed stacks. I've only looked into the pre-2.6-merged HostAP stack, so I can't comment on what's publically available. I'll have a look at the GPL'ed DeviceScape stack when I have more time. Most of what I've going on about is derived from my experience from commercial 802.11 work I've done over the past few years. Ditto. Sam - 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: wireless: recap of current issues (configuration)
Stefan Rompf wrote: Am Freitag 13 Januar 2006 23:32 schrieb Johannes Berg: [Changing mode of virtual devices] IMHO there's not much point in allowing changes. I have a feeling that might create icky issues you don't want to have to tackle when the solution is easy by just not allowing it. Part of my thinking is that different virtual types have different structures associated, so changing it needs re-creating structures anyway. And different virtual device types might even be provided by different kernel modules so you don't carry around AP mode if you don't need it. Even though it is a bit more work on kernel side, we should allow changing the mode of virtual devices. Let's face it, even though we find multi-BSS capabilities very interesting, 999 of 1000 users won't care due to the two facts that IPW firmware IMHO doesn't allow it and virtual interfaces are limited to one channel anyway. These users rightfully expect to have one interface and be able to do all configurations on it. My experience is that once you can create+destroy virtual devices you'll never want mode changing. From a usability standpoint when you switch modes you typically have to reconfigure lots of settings and doing destroy old followed by create new is easier. Depending on how things tie into hotplug you may also find things getting complicated. Within the kernel having the operating mode of a virtual device not change is very good. First it lets you isolate the rules for mix+match of different virtual devices at create. Second you can partition code so, for example, only code required to support an ap is loaded when an ap mode virtual device exists. There are other less obvious reasons such as firmware-based devices can load firmware based on the operating mode at create time but if you allow mode switching then you need to unload+load on the fly. All these things can be handled with switching modes but the complexity is significant and the gain is minimal. The big stumbling block I found to going with virtual devices is that it affects user apps. I looked at doing things like auto-create a station device for backwards compatibility but decided against it. If you really want this behaviour it can be done by user code. Sam - 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: wireless: recap of current issues (configuration)
Stefan Rompf wrote: Am Samstag 14 Januar 2006 14:47 schrieb Ulrich Kunitz: They one problem I can see is scanning over several frequencies. If two virtual devices are doing this at the same time, we have a conflict. Maybe each WiPHY would have only one active interface, I think scanning can be easily serialized. We use a parameter structure that describes which channels / SSIDs should be scanned. The stack guarantees that there will be only one active scan, results are written to a WiPHY device specific list. When querying results, the same structure is used to filter on that list. You must serialize shared state changes. Scanning is just one example but an important one as after a channel change all virtual devices must be notified so, for example, they can recreate beacon frames if they are operating in ap mode. Doing a good job scanning is important if you want roaming to work well (but also is important for ap operation, e.g. when radar detection requires a channel change). Sam - 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: wireless: recap of current issues (configuration)
Stuffed Crust wrote: On Sat, Jan 14, 2006 at 05:07:01PM -0500, Jeff Garzik wrote: This can be accomplished by passing a static table to the register_wiphy_device() call (or perhaps via a struct wiphy_dev parameter) or through a more explicit, dynamic interface like: wiphy_register_supported_frequency(hw, 2412). For completely programmable hardware, the stack should interact with a module like ieee80211_geo, to help ensure the hardware stays within legal limits. While there is much to debate about where to draw the functionality line, completely programmable hardware is the norm these days. ... and said code would be responsible for driving the scanning state machines, and also for more esoteric functions like handling RADAR traps, automatic channel switching, etc. Handling scans is quite interesting -- I've seen hardware which requires manual channel changing (including full RF parameter specification), host timing for the channel dwell time, and manual probe request issuance.. and on the other end of the spectrum, a simple issue scan command that takes few, if any, parameters. And unfortunately, many things in between. This leads me to belive that the internal scan workflow should work something like this: * Userspace app issues scan request (aka refresh AP list) * Knowing the hardware frequency capabilities, the 802.11 stack applies 802.11d and regdomain rules to the available frequency set, and issues multiple internal scan request commands to the hardware driver. (eg perform an initial passive sweep across the entire 2.4G band, perform an active scan on frequencies 2412-2437 looking for ssid HandTossed, perform an active scan on frequencies 5200-5400 looking for ssid HandTossed, etc) (note that ideally, userspace apps/libs would be at least partially aware of 802.11d rules, but the kernel must do the RightThing if told to scan all available channels for any access points) * The hardware driver takes this scan request, and maps it into the capabilities of the hardware: Hardware A: (very thin MAC) - Using library code, generates an appropriate probe request frame, translates it into a format the hardware expects/needs, and schedules it appropriately. - Loops through the frequency set specified, and for each: - Issues a channel change command - Immediately transmits the probe request (for active scans) - Dwells for an appropriate time - RX'ed beacon/probe response frames come down as regular 802.11 frames into the stack - Moves to the next channel Hardware B: (thinner MAC) - Using library code, generates an appropriate probe request frame, and translate it into a format the hardware expects. - Program the probe request frame into the hardware as a probe template. - Loops through the frequency set specified, and for each: - Issues a channel change command - Wait for a scan complete signal - RX'ed beacon/probe response frames come down as regular 802.11 frames into the stack - Moves to the next channel Hardware C: (thick MAC, ala prism2 or prism54) - Issues a hardware scan request - Waits for the hardware to signal scan complete - Requests hardware scan results - For each scan result, the hardware returns: - Translate result into an 802.11 probe response frame and pass down the regular RX path. So as you can see, I think the channel iteration, dwell, etc should be performed by the hardware driver itself, as the variation at the logical tell the hardware perform a scan step is so extreme. * Meanwhile, the 802.11 stack is receiving the beacons/probe responses from the hardware via the regular rx path. It diverts these (and other 802.11 management/control) frames, decodes them, and then adds them to the stack's internal list of available stations, updating any internal states/counters as necessary. (These frames could also be echoed to a special netdev interface if desired) (stuff like detecting an AP going away depends on us noticing a lack of beacons arriving, for example. Most hardware does not notify us of this event. Likewise, we should expire other APs from our list if they go away.. etc. For AP operation we need to maintain this STA list, period -- so why not use it across the board? But this is another discussion for another time..) * The 802.11 stack issues a MLME-Scan-Complete notification to userspace. * Interested userspace apps see this event, then query the scan results and presents them to the user in some pretty format, or alternatively perform automatic roaming based on scan results. The above is a great synopsis but there is more. For example to support roaming (and sometimes for ap operation) you want to do background scanning;
