[PATCH] ieee80211: Crypto cleanup
Remove Host AP and Prism2 references from IEEE 802.11 crypto code. Clean
up coding style and some comments. Replace couple of kmalloc+memset with
kzalloc.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-2.6/include/net/ieee80211_crypt.h
===
--- wireless-2.6.orig/include/net/ieee80211_crypt.h
+++ wireless-2.6/include/net/ieee80211_crypt.h
@@ -1,10 +1,7 @@
/*
- * Original code based on Host AP (software wireless LAN access point) driver
- * for Intersil Prism2/2.5/3.
+ * This file defines the interface to the ieee80211 crypto module.
*
- * Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen
- * [EMAIL PROTECTED]
- * Copyright (c) 2002-2003, Jouni Malinen [EMAIL PROTECTED]
+ * Copyright (c) 2002-2006, Jouni Malinen [EMAIL PROTECTED]
*
* Adaption to a generic IEEE 802.11 stack by James Ketrenos
* [EMAIL PROTECTED]
@@ -17,9 +14,6 @@
* more details.
*/
-/*
- * This file defines the interface to the ieee80211 crypto module.
- */
#ifndef IEEE80211_CRYPT_H
#define IEEE80211_CRYPT_H
@@ -42,13 +36,13 @@ struct ieee80211_crypto_ops {
/* init new crypto context (e.g., allocate private data space,
* select IV, etc.); returns NULL on failure or pointer to allocated
* private data on success */
- void *(*init) (int keyidx);
+ void *(*init)(int keyidx);
/* deinitialize crypto context and free allocated private data */
- void (*deinit) (void *priv);
+ void (*deinit)(void *priv);
- int (*build_iv) (struct sk_buff * skb, int hdr_len,
-u8 *key, int keylen, void *priv);
+ int (*build_iv)(struct sk_buff *skb, int hdr_len,
+ u8 *key, int keylen, void *priv);
/* encrypt/decrypt return 0 on error or = 0 on success. The return
* value from decrypt_mpdu is passed as the keyidx value for
@@ -56,25 +50,25 @@ struct ieee80211_crypto_ops {
* encryption; if not, error will be returned; these functions are
* called for all MPDUs (i.e., fragments).
*/
- int (*encrypt_mpdu) (struct sk_buff * skb, int hdr_len, void *priv);
- int (*decrypt_mpdu) (struct sk_buff * skb, int hdr_len, void *priv);
+ int (*encrypt_mpdu)(struct sk_buff *skb, int hdr_len, void *priv);
+ int (*decrypt_mpdu)(struct sk_buff *skb, int hdr_len, void *priv);
/* These functions are called for full MSDUs, i.e. full frames.
* These can be NULL if full MSDU operations are not needed. */
- int (*encrypt_msdu) (struct sk_buff * skb, int hdr_len, void *priv);
- int (*decrypt_msdu) (struct sk_buff * skb, int keyidx, int hdr_len,
-void *priv);
+ int (*encrypt_msdu)(struct sk_buff *skb, int hdr_len, void *priv);
+ int (*decrypt_msdu)(struct sk_buff *skb, int keyidx, int hdr_len,
+ void *priv);
- int (*set_key) (void *key, int len, u8 * seq, void *priv);
- int (*get_key) (void *key, int len, u8 * seq, void *priv);
+ int (*set_key)(void *key, int len, u8 *seq, void *priv);
+ int (*get_key)(void *key, int len, u8 *seq, void *priv);
/* procfs handler for printing out key information and possible
* statistics */
- char *(*print_stats) (char *p, void *priv);
+ char * (*print_stats)(char *p, void *priv);
/* Crypto specific flag get/set for configuration settings */
- unsigned long (*get_flags) (void *priv);
- unsigned long (*set_flags) (unsigned long flags, void *priv);
+ unsigned long (*get_flags)(void *priv);
+ unsigned long (*set_flags)(unsigned long flags, void *priv);
/* maximum number of bytes added by encryption; encrypt buf is
* allocated with extra_prefix_len bytes, copy of in_buf, and
@@ -88,7 +82,7 @@ struct ieee80211_crypto_ops {
};
struct ieee80211_crypt_data {
- struct list_head list; /* delayed deletion list */
+ struct list_head list; /* delayed deletion list */
struct ieee80211_crypto_ops *ops;
void *priv;
atomic_t refcnt;
@@ -98,11 +92,11 @@ struct ieee80211_device;
int ieee80211_register_crypto_ops(struct ieee80211_crypto_ops *ops);
int ieee80211_unregister_crypto_ops(struct ieee80211_crypto_ops *ops);
-struct ieee80211_crypto_ops *ieee80211_get_crypto_ops(const char *name);
+struct ieee80211_crypto_ops * ieee80211_get_crypto_ops(const char *name);
void ieee80211_crypt_deinit_entries(struct ieee80211_device *, int);
void ieee80211_crypt_deinit_handler(unsigned long);
void ieee80211_crypt_delayed_deinit(struct ieee80211_device *ieee,
struct ieee80211_crypt_data **crypt);
void ieee80211_crypt_quiescing(struct ieee80211_device *ieee);
-#endif
+#endif /* IEEE80211_CRYPT_H */
Index: wireless-2.6/net/ieee80211/Kconfig
Re: [SOFTMAC] Reduce default rate to 11Mbps.
On Thu, Mar 23, 2006 at 10:43:38PM +, David Woodhouse wrote: This patch makes us default to 11M, which ought to work for most people. Is this code supposed to work with IEEE 802.11a (which would also use OFDM modulation)? If yes, please note that 11 Mbps is not a valid IEEE 802.11a TX rate. -- Jouni MalinenPGP id EFC895FA - 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: [SOFTMAC] Reduce scan dwell time
On Thu, Mar 23, 2006 at 08:16:04PM -0500, Dan Williams wrote: fixed it. Active scanning has been out of vogue as the default scan method for like 2 years with wireless-tools/WE, I'm not sure why softmac thinks it should be different here. Active scanning takes more power anyway, since you have to power up the card to transmit the probe requests. That's why wireless-tools and Wireless Extensions switched to passive scanning. Can you please point to some documentation/email thread/etc. describing this preference to use passive scanning? I was not aware of such a preference and have assumed that active scanning would be the preferred default because it is quite a bit faster and provides more complete results. I'd have issues with softmac doing active scanning unless _specifically_ requested to do so, by using the SIOCGIWMLME with a iw_scan_req structure requesting IW_SCAN_TYPE_ACTIVE. But _only_ then... Normal SIOCGIWSCAN shouldn't do active scanning. SIOCGIWSCAN does not request scanning, SIOCSIWSCAN does.. I don't understand what SIOCGIWMLME would have to do with this. SIOCSIWSCAN can use an optional iw_scan_req to control scan request. If this data is not present, I would assume that the drivers would do whatever they want and in many cases I would expect this to be active scan. -- Jouni MalinenPGP id EFC895FA - 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] net/ieee80211: report hidden ESSIDs as zero-length, nothidden
On Fri, Mar 24, 2006 at 10:57:22AM -0500, Dan Williams wrote: hidden this is something that ieee80211 does that's completely wrong. Drivers need to report the _exact_ ESSID from the air in their scan results. It's up to the user space app to deal with ESSID length of 0. I agree that hidden should not be used, but this is bit more complex than just reporting zero-length SSID. By the way, can we try to start getting rid of calling this ESSID; it's SSID and ESSID never made it to the IEEE 802.11 standard. Whatever component processes Probe Response frames, has to provide information from them to user space. If this is done in the kernel code, the BSS table should probably report multiple BSSID,SSID pairs even for the same BSSID in case of multi-SSID support in the AP. This is needed to handle cases where SSIDs use different security policy and this requires that active scan was used to probe for specific SSID(s). If this information is not available, reporting an empty SSID sounds like a good policy. -- Jouni MalinenPGP id EFC895FA - 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] net/ieee80211: report hidden ESSIDs as zero-length, not hidden
On Fri, Mar 24, 2006 at 11:05:02AM -0600, James Ketrenos wrote: Since the scan results are supposed to report networks found; the first agreement we need to make between user space and the kernel is how we define a 'network', and how do we determine when a network has been updated? Whenever a frame for matching BSSID is received(?) A direct scan for 'Bar' is sent, and the following is found via probe request: ssid_len=3, ssid=Bar, channel 1, BSSID: 00:0e:de:ad:be:ef and via beacons: ssid_len=3, ssid=Foo, channel 1, BSSID: 00:0e:de:ad:be:ef The network Bar is associated with, and time passes with no data or probe requests being sent (idle network). Beacons are received for Foo, but nothing for Bar (since the AP isn't beaconing hidden networks). Aside from the probe response for Bar, there are never any beacons that indicate that the network Bar still exists. Scan results *should* display Foo and Bar, but the current ieee80211 subsystem will filter out Bar once 15s has passed without receiving a probe response. Yes, I would like to see both Foo and Bar being reported to user space and neither should be timed out as long as Beacon frames are received for the shared BSSID. Currently ieee80211 does not differentiate between probe responses and beacons for collecting network data. To fix the problem we have now, ieee80211 needs to be changed to be able to distinguish between probe respones and beacons, and update all networks that match channel and MAC when a beacon is received (regardless of SSID) and update a specific network if the frame is a probe response. Agreed. Ideally user space should just register to receive all beacons and probe responses from the network device and do all the parsing and network management, with a timing interval specified for frequency to receive beacons/probe responses that have not changed (although one packet every 100ms isn't likely to cause too much thrash) Exporting the entire frame allows user space to provide information on 802.11h, 802.11e, 802.11i and other network capabilities that currently aren't exposed via the wireless extension interface. This is something I would like to see happening at least as an option. It would be useful to be able to replace all management frame processing by user space mechanism. This is exactly what hostapd does for AP mode with Host AP driver and Devicescape 802.11 code. Similar mechanism would be nice to have for client mode. Timing requirements for 802.11 management frames are not too strict (with a potential exception with Probe Response, but even that seems to work quite well on Linux when done from user space), so they can be easily handled in user space. Implementing things like 802.11r will be quite a bit easier if both the management frames (authentication, association) and EAPOL frames can be taken care of by the same component. Otherwise, large number of new kernel - user space interfaces will be needed for adding IEs and interacting with roaming and association. Doing this also has the advantage of being able to remove all scan and network collection logistics out of the kernel and into user space. Agreed. -- Jouni MalinenPGP id EFC895FA - 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: [SOFTMAC] Reduce scan dwell time
On Fri, Mar 24, 2006 at 12:38:40PM -0500, Dan Williams wrote: However, the problem with active scanning is that you have to power up the transmit components of the radio, while passive scanning, even though it takes a bit longer, doesn't necessarily require that. Active scanning takes more power. For some class of devices, that is certainly correct. For other classes, it does not really matter much (e.g., my laptop has large enough battery for me not to care about active scan). So what I'm arguing for here is that drivers should _default_ to passive scanning when given a scan request with no scan type information. But they should be able to do so when they get a request for an active scan using IW_SCAN_TYPE_ACTIVE. Drivers should default to using less power, and more only when the app requests so. Is battery use more important than accuracy of results and the amount of time needed to perform the operation? It's somewhat unfortunate that wireless.h defines ACTIVE scan type as 0 since then, that's what non-WE-18 apps would inadvertently set. And apps that are power-aware would be setting that bit anyway. Most drivers that are FullMAC do passive scanning without sending probe requests, AFAIK, and so do OK here. Please note that this field is in struct iw_scan_req and non-WE-18 apps do not know about that in the first place. In other words, it does not really matter what the value of IW_SCAN_TYPE_ACTIVE is.. The only open question I see here is what should happen if struct iw_scan_req is not included and my current understanding is that the driver is allowed to do either active or passive scanning based on its default and I just happen to think that the default would more likely be active scanning unless somehow (driver specific parameter) it has been modified to do something else. Have you actually observed that FullMAC drivers are using passive scanning (i.e., used a wireless sniffer to see what they are doing)? Most drivers I've looked at at this level are sending out probe request frames.. -- Jouni MalinenPGP id EFC895FA - 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] net/ieee80211: report hidden ESSIDs as zero-length, not
On Fri, Mar 24, 2006 at 11:41:14AM -0800, Jean Tourrilhes wrote: I've seen time where people said SSID when referring to the BSSID, so I just wanted the terminology to be without ambiguity. Well.. It is just somewhat funny to see ESSID being used in Linux wireless discussion when most other areas are using the correct term, SSID. I would assume that wireless.h and iwconfig documentation are the main reasons for this.. ;-) The problem of trying to keep probe response for longer period of time is that they may no longer be valid. As you roam around, things need to timeout/expire because they are no longer reachable. If beacon frames are received for the same BSSID, the probe responses are very likely still valid. The only thing expiring them would be configuration change in the AP.. But, before going into deep technical discussions, we may want to remind us what is the goal of this API. The goal is to present the user a list of potential networks that can be used by him, in the case he doesn't want to associate with a specific network. Not all associations need it, it's a convenience feature for finding open networks. It is also convenient for figuring out security policy for closed networks.. The network that don't send beacon do so to cloak themselves, Or to support multiple SSIDs with radios that cannot use multiple BSSIDs.. If the user know about this network via other means, he can still associate with it by entering manually the ESSID. This would work if there is only one hidden SSID. However, if there are more than one, it may be useful to be able to scan (without associating) multiple SSIDs. This was one of the reason for adding scan parameters in WE-18. The only thing debatable is about the current associated network, in case it's cloaked. This network has already been discovered (we are associated with it), therefore the user does not really require to see it in scan results, however it would be nice for completness. Maybe not in scan results, but the same parameters have to be available for WPA supplicant and fetching them from scan results is one convenient mechanism. In other words, proper WPA/WPA2 validation of WPA/RSN IEs requires that the Beacon/ProbeResp IEs are available for the current AP. -- Jouni MalinenPGP id EFC895FA - 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] net/ieee80211: report hidden ESSIDs as zero-length,not hidden
On Fri, Mar 24, 2006 at 09:31:56PM +, David Woodhouse wrote: wpa_supplicant appears to be aware of none of this -- it expects the SSID to be precisely correct in the scan results after it does an active probe for a specific SSID. Thus, it doesn't work when SSID broadcasting is turned off unless I apply the hack at http://david.woodhou.se/wpa_supplicant-hack.patch wpa_supplicant does indeed require that the scan results are reported correctly. I don't see much point in the results if they are not correct.. It is unfortunate if you need to use this kind of patch since it would not work very well in cases where there is more than one BSSID with hidden reported as the SSID.. Do we really expect to push this problem to userspace, or should the kernel drivers be assuming for themselves that the probe response _should_ have the same SSID as we actually probed for, then fixing it up accordingly? I think that whoever is responsible for processing Beacon and Probe Response frames should report SSIDs correctly. In case this is done in kernel code (which is the case for more or less all Linux drivers at the moment), this would need to be in kernel (but can and should be shared with all drivers). As an example, Host AP driver keeps a local list of detected BSSes and it keeps a separate entry for each SSID to support multi-SSID configuration. SIOCGIWSCAN will then get list of all detected BSSID,SSID combinations with SSID field updated based on Probe Response for the cases where Beacon frame used an empty SSID (or had another SSID in case of multi-SSID). In case scanning is moved to user space, this process would happen in an user space application instead. -- Jouni MalinenPGP id EFC895FA - 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 0/2] Host AP driver update
Please apply following two patches to Host AP driver in wireless-2.6. The second patch (Fix EAPOL frame encryption) is a trivial bug fix for a somewhat unfortunate bug and it could be a good candidate for a 2.6.16.x stable release ([EMAIL PROTECTED] cc'ed). -- Jouni MalinenPGP id EFC895FA - 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 2/2] hostap: Fix EAPOL frame encryption
Fixed encrypted of EAPOL frames from wlan#ap interface (hostapd). This
was broken when moving to use new frame control field defines in
net/ieee80211.h. hostapd uses Protected flag, not protocol version
(which was cleared in this function anyway). This fixes WPA group key
handshake and re-authentication.
http://hostap.epitest.fi/bugz/show_bug.cgi?id=126
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: linux-2.6.16/drivers/net/wireless/hostap/hostap_80211_tx.c
===
--- linux-2.6.16.orig/drivers/net/wireless/hostap/hostap_80211_tx.c
+++ linux-2.6.16/drivers/net/wireless/hostap/hostap_80211_tx.c
@@ -469,7 +469,7 @@ int hostap_master_start_xmit(struct sk_b
}
if (local-ieee_802_1x meta-ethertype == ETH_P_PAE tx.crypt
- !(fc IEEE80211_FCTL_VERS)) {
+ !(fc IEEE80211_FCTL_PROTECTED)) {
no_encrypt = 1;
PDEBUG(DEBUG_EXTRA2, %s: TX: IEEE 802.1X - passing
unencrypted EAPOL frame\n, dev-name);
--
--
Jouni MalinenPGP id EFC895FA
-
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 1/2] hostap: Make hostap_tx_encrypt() static
hostap_tx_encrypt() is used only inside hostap_80211_tx.c and there
are no plans to use it elsewhere in the future either, so let's make
it static. As a bonus, this should silence Coverity scanner from
complaining about bogus FORWARD_NULL case (CID: 274).
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: linux-2.6.16/drivers/net/wireless/hostap/hostap_80211_tx.c
===
--- linux-2.6.16.orig/drivers/net/wireless/hostap/hostap_80211_tx.c
+++ linux-2.6.16/drivers/net/wireless/hostap/hostap_80211_tx.c
@@ -299,8 +299,8 @@ int hostap_mgmt_start_xmit(struct sk_buf
/* Called only from software IRQ */
-struct sk_buff * hostap_tx_encrypt(struct sk_buff *skb,
- struct ieee80211_crypt_data *crypt)
+static struct sk_buff * hostap_tx_encrypt(struct sk_buff *skb,
+ struct ieee80211_crypt_data *crypt)
{
struct hostap_interface *iface;
local_info_t *local;
@@ -317,7 +317,7 @@ struct sk_buff * hostap_tx_encrypt(struc
}
if (local-tkip_countermeasures
- crypt crypt-ops strcmp(crypt-ops-name, TKIP) == 0) {
+ strcmp(crypt-ops-name, TKIP) == 0) {
hdr = (struct ieee80211_hdr_4addr *) skb-data;
if (net_ratelimit()) {
printk(KERN_DEBUG %s: TKIP countermeasures: dropped
@@ -535,5 +535,4 @@ int hostap_master_start_xmit(struct sk_b
EXPORT_SYMBOL(hostap_dump_tx_80211);
-EXPORT_SYMBOL(hostap_tx_encrypt);
EXPORT_SYMBOL(hostap_master_start_xmit);
Index: linux-2.6.16/drivers/net/wireless/hostap/hostap_80211.h
===
--- linux-2.6.16.orig/drivers/net/wireless/hostap/hostap_80211.h
+++ linux-2.6.16/drivers/net/wireless/hostap/hostap_80211.h
@@ -92,8 +92,6 @@ void hostap_dump_rx_80211(const char *na
void hostap_dump_tx_80211(const char *name, struct sk_buff *skb);
int hostap_data_start_xmit(struct sk_buff *skb, struct net_device *dev);
int hostap_mgmt_start_xmit(struct sk_buff *skb, struct net_device *dev);
-struct sk_buff * hostap_tx_encrypt(struct sk_buff *skb,
- struct ieee80211_crypt_data *crypt);
int hostap_master_start_xmit(struct sk_buff *skb, struct net_device *dev);
#endif /* HOSTAP_80211_H */
--
--
Jouni MalinenPGP id EFC895FA
-
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 1/6] hostap: Fix hw reset after CMDCODE_ACCESS_WRITE timeout
From: Adrian Bunk [EMAIL PROTECTED]
The Coverity checker (CID: 59) noted that the call to prism2_hw_reset()
was dead code. Move prism2_hw_reset() call to a place where it is
actually executed.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/hostap/hostap_hw.c
===
--- wireless-2.6.orig/drivers/net/wireless/hostap/hostap_hw.c
+++ wireless-2.6/drivers/net/wireless/hostap/hostap_hw.c
@@ -928,15 +928,15 @@ static int hfa384x_set_rid(struct net_de
res = hfa384x_cmd(dev, HFA384X_CMDCODE_ACCESS_WRITE, rid, NULL, NULL);
up(local-rid_bap_sem);
+
if (res) {
printk(KERN_DEBUG %s: hfa384x_set_rid: CMDCODE_ACCESS_WRITE
failed (res=%d, rid=%04x, len=%d)\n,
dev-name, res, rid, len);
- return res;
- }
- if (res == -ETIMEDOUT)
- prism2_hw_reset(dev);
+ if (res == -ETIMEDOUT)
+ prism2_hw_reset(dev);
+ }
return res;
}
--
--
Jouni MalinenPGP id EFC895FA
-
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 2/6] hostap: Fix ap_add_sta() return value verification
From: Adrian Bunk [EMAIL PROTECTED]
The Coverity checker (CID: 273) spotted this inconsequent NULL checking
(unconditionally dereferencing directly after checking for NULL
isn't a good idea). Return immediately to avoid this.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/hostap/hostap_ap.c
===
--- wireless-2.6.orig/drivers/net/wireless/hostap/hostap_ap.c
+++ wireless-2.6/drivers/net/wireless/hostap/hostap_ap.c
@@ -3141,7 +3141,7 @@ int hostap_add_sta(struct ap_data *ap, u
if (ret == 1) {
sta = ap_add_sta(ap, sta_addr);
if (!sta)
- ret = -1;
+ return -1;
sta-flags = WLAN_STA_AUTH | WLAN_STA_ASSOC;
sta-ap = 1;
memset(sta-supported_rates, 0, sizeof(sta-supported_rates));
--
--
Jouni MalinenPGP id EFC895FA
-
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 0/6] Host AP update (fixes for issues found by Coverity)
This set of patches fixes issues in Host AP driver found by Coverity. I don't think any of these are critical, but anyway, these should be fixed at some point. The diffs are against wireless-2.6 master branch, but should apply to more or less any recent version of Host AP with small offset differences. Please apply to the appropriate branch(es). -- Jouni MalinenPGP id EFC895FA - 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 3/6] hostap: Fix double free in prism2_config() error path
From: Eugene Teo [EMAIL PROTECTED]
The Coverity checker (CID: 930) spotted this double free on error path
(allocation failure). Do not free these here since generic error path
will take care of this.
Signed-off-by: Eugene Teo [EMAIL PROTECTED]
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/hostap/hostap_cs.c
===
--- wireless-2.6.orig/drivers/net/wireless/hostap/hostap_cs.c
+++ wireless-2.6/drivers/net/wireless/hostap/hostap_cs.c
@@ -585,8 +585,6 @@ static int prism2_config(dev_link_t *lin
parse = kmalloc(sizeof(cisparse_t), GFP_KERNEL);
hw_priv = kmalloc(sizeof(*hw_priv), GFP_KERNEL);
if (parse == NULL || hw_priv == NULL) {
- kfree(parse);
- kfree(hw_priv);
ret = -ENOMEM;
goto failed;
}
--
--
Jouni MalinenPGP id EFC895FA
-
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 4/6] hostap: Fix unlikely read overrun in CIS parsing
The Coverity checker (CID: 452, 453, 454, 455, 456) spotted this
unlikely read overrun of CIS buffer. Abort if CISTPL_CONFIG or
CISTPL_MANFID would not fit in buffer.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/hostap/hostap_plx.c
===
--- wireless-2.6.orig/drivers/net/wireless/hostap/hostap_plx.c
+++ wireless-2.6/drivers/net/wireless/hostap/hostap_plx.c
@@ -368,7 +368,7 @@ static int prism2_plx_check_cis(void __i
switch (cis[pos]) {
case CISTPL_CONFIG:
- if (cis[pos + 1] 1)
+ if (cis[pos + 1] 2)
goto cis_error;
rmsz = (cis[pos + 2] 0x3c) 2;
rasz = cis[pos + 2] 0x03;
@@ -390,7 +390,7 @@ static int prism2_plx_check_cis(void __i
break;
case CISTPL_MANFID:
- if (cis[pos + 1] 4)
+ if (cis[pos + 1] 5)
goto cis_error;
manfid1 = cis[pos + 2] + (cis[pos + 3] 8);
manfid2 = cis[pos + 4] + (cis[pos + 5] 8);
--
--
Jouni MalinenPGP id EFC895FA
-
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 5/6] hostap: Remove dead code (duplicated idx != 0)
The Coverity checker (CID: 58) spotted this duplicated idx != 0
validation for unicast keys in prism2_ioctl_siwencodeext().
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/hostap/hostap_ioctl.c
===
--- wireless-2.6.orig/drivers/net/wireless/hostap/hostap_ioctl.c
+++ wireless-2.6/drivers/net/wireless/hostap/hostap_ioctl.c
@@ -3358,10 +3358,6 @@ static int prism2_ioctl_siwencodeext(str
if (ext-ext_flags IW_ENCODE_EXT_SET_TX_KEY) {
if (!sta_ptr)
local-tx_keyidx = i;
- else if (i) {
- ret = -EINVAL;
- goto done;
- }
}
--
--
Jouni MalinenPGP id EFC895FA
-
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 6/6] hostap: Fix memory leak on PCI probe error path
The Coverity checker (CID: 659, 660) spotted this resource leak on PCI probe error path. Free private data structure if pci_enable_device() fails. Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: wireless-2.6/drivers/net/wireless/hostap/hostap_pci.c === --- wireless-2.6.orig/drivers/net/wireless/hostap/hostap_pci.c +++ wireless-2.6/drivers/net/wireless/hostap/hostap_pci.c @@ -307,7 +307,7 @@ static int prism2_pci_probe(struct pci_d memset(hw_priv, 0, sizeof(*hw_priv)); if (pci_enable_device(pdev)) - return -EIO; + goto err_out_free; phymem = pci_resource_start(pdev, 0); @@ -368,6 +368,8 @@ static int prism2_pci_probe(struct pci_d err_out_disable: pci_disable_device(pdev); prism2_free_local_data(dev); + + err_out_free: kfree(hw_priv); return -ENODEV; Index: wireless-2.6/drivers/net/wireless/hostap/hostap_plx.c === --- wireless-2.6.orig/drivers/net/wireless/hostap/hostap_plx.c +++ wireless-2.6/drivers/net/wireless/hostap/hostap_plx.c @@ -452,7 +452,7 @@ static int prism2_plx_probe(struct pci_d memset(hw_priv, 0, sizeof(*hw_priv)); if (pci_enable_device(pdev)) - return -EIO; + goto err_out_free; /* National Datacomm NCP130 based on TMD7160, not PLX9052. */ tmd7160 = (pdev-vendor == 0x15e8) (pdev-device == 0x0131); @@ -567,9 +567,6 @@ static int prism2_plx_probe(struct pci_d return hostap_hw_ready(dev); fail: - prism2_free_local_data(dev); - kfree(hw_priv); - if (irq_registered dev) free_irq(dev-irq, dev); @@ -577,6 +574,10 @@ static int prism2_plx_probe(struct pci_d iounmap(attr_mem); pci_disable_device(pdev); + prism2_free_local_data(dev); + + err_out_free: + kfree(hw_priv); return -ENODEV; } -- -- Jouni MalinenPGP id EFC895FA - 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: [RFC/PATCH 6/13] d80211: remove obsolete stuff
On Thu, Mar 16, 2006 at 05:45:48PM +0100, Jiri Benc wrote: On Wed, 15 Mar 2006 16:36:16 -0800, Jouni Malinen wrote: See the patch below. Is it viable? I'll test this with our low-level driver. This and similar change for ieee80211_get_buffered_bc() add more requirements for the low-level driver. It used to be enough to just know that the low-level code should ask for up to N beacon frames. However, with this change, the low-level driver would need to maintain a list of ifindexes for the virtual interfaces. This is somewhat against the original design of hiding all the virtual interfaces from low-level code. I like the approach, but I'm afraid it's not generic enough. The new code should cover all possibilities (even such hypothetical case as a card capable of multiple APs in its firmware with host-buffering of frames for STAs in PS mode). Your proposed change does not cover at least one case.. In a typical case of only-one-AP capable card the code will be nearly the same. In your case it indeed means one extra list. Agreed. Yes, I wanted to add ifindex into ieee80211_if_conf but apparently forgot to. See patch below. OK. I'll test this. This patch fixes some problems in interface configuration. - Pass interface ID to add_interface and remove_interface callbacks. This ID is used by a driver when calling ieee80211_beacon_get and ieee80211_get_buffered_bc functions. There is one more corner case that I did not remember yesterday: Atheros XR. It is using two BSSIDs and two different beacons per network interface (or at least our implementation of it is doing this; in theory, it could be possible to do this with two interfaces and bridging, but it gets somewhat complex for couple of cases).. With the current d80211 implementation, this can be handled by just multiplying bss_count with two. With per-ifindex call, this is more difficult. One option would be to modify the interface to return more than one skb in this case.. This might actually be useful way to handle all indexes if the beacons are to be sent at the same time. However, if beacons are to be sent at different times for different BSSes, it may be easier to just maintain the current mechanism (one call per virtual AP) and allow XR to return two beacon frames. -- Jouni MalinenPGP id EFC895FA - 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: [RFC/PATCH 3/13] d80211: non-shared interface types
On Mon, Mar 06, 2006 at 04:44:23PM +0100, Jiri Benc wrote:
This patch removes iwmode variable (local-conf.mode) shared by all
interfaces. Instead, every interface has its own type (STA/IBSS/AP/WDS).
Index: dscape/include/net/d80211.h
===
--- dscape.orig/include/net/d80211.h 2006-03-06 13:33:02.0 +0100
+++ dscape/include/net/d80211.h 2006-03-06 14:10:07.0 +0100
@@ -242,8 +242,6 @@ struct ieee80211_conf {
int freq; /* MHz */
int channel_val;/* hw specific value for the channel */
- int mode; /* IW_MODE_ */
-
This breaks bcm43xx-d80211 build. Do you happen to have a patch to fix
it? At least the experimental branch of your dscape.git seemed to show
the same issue:
CC [M] drivers/net/wireless/bcm43xx-d80211/bcm43xx_main.o
drivers/net/wireless/bcm43xx-d80211/bcm43xx_main.c: In function
‘bcm43xx_net_config’:
drivers/net/wireless/bcm43xx-d80211/bcm43xx_main.c:4412: error: ‘struct
ieee80211_conf’ has no member named ‘mode’
drivers/net/wireless/bcm43xx-d80211/bcm43xx_main.c:4413: error: ‘struct
ieee80211_conf’ has no member named ‘mode’
The same issue showed up with our low-level driver. How was the
low-level driver supposed to get this information with this change?
d80211 part is likely fine, since it has the interface type available
like you mentioned, but I don't think that this is available to
low-level drivers(?). In other words, keeping this int mode in struct
ieee80211_conf may be useful even if we change d80211 to do something
else internally.
Which driver did you use to test these changes? I have now successfully
tested both client and AP modes with bcm43xx_d80211 and Devicescape
driver for Atheros cards prior to applying these 13 changes. I would
like to verify that the new changes work properly before they are
applied into the wireless-2.6 tree. I can change our code easily, but I
would rather not touch bcm43xx_d80211 code to avoid any problems in
keeping the reverse engineered implementation clean as far as use of
proprietary information is concerned.
--
Jouni MalinenPGP id EFC895FA
-
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: [RFC/PATCH 1/13] d80211: allow WDS remote to by set by WE
On Mon, Mar 06, 2006 at 04:44:21PM +0100, Jiri Benc wrote: Setting of address of WDS remote peer wasn't possible by a WE call. Remote WDS peer can be understood as a remote AP and SIOCSIWAP/SIOCGIWAP are unused in WDS mode, so let's use them. This sounds good, but I was unable to get this working. I created a WDS link with initial peer address 00:01:02:03:04:05. This added the netdev and STA entry correctly. However, when I run iwconfig wds0 ap 00:11:22:33:44:55, I do not see any change in either the WDS data (/proc/net/ieee80211/wlan0/iface/wds0 did not show change in wds.peer) or STA info (00:11:22:33:44:55 was not added in /proc/net/ieee80211/wlan0/sta directory). Did I understand something incorrectly here? -- Jouni MalinenPGP id EFC895FA - 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: [RFC/PATCH 3/13] d80211: non-shared interface types
On Wed, Mar 15, 2006 at 06:47:40PM +0100, Jiri Benc wrote: On Wed, 15 Mar 2006 09:40:52 -0800, Jouni Malinen wrote: This breaks bcm43xx-d80211 build. Do you happen to have a patch to fix it? Yes, I do. Sorry for not posting it. This is a first part; it's just ugly and quick (but working) fix. Thanks! I'll try with this. In addition to fixing bcm43xx build, this was enough to remind me how the mode parameter is now available to low-level driver, so I'll test a similar change with our Atheros driver. One more driver is failing, though: drivers/net/wireless/rt2x00/rt2400pci.c: In function ‘rt2400pci_rxdone’: drivers/net/wireless/rt2x00/rt2400pci.c:756: warning: implicit declaration of function ‘ieee80211_rx’ drivers/net/wireless/rt2x00/rt2400pci.c: In function ‘rt2400pci_config_update’: drivers/net/wireless/rt2x00/rt2400pci.c:1468: error: ‘struct ieee80211_conf’ has no member named ‘mode’ drivers/net/wireless/rt2x00/rt2400pci.c: In function ‘rt2400pci_reset_tsf’: drivers/net/wireless/rt2x00/rt2400pci.c:1724: error: ‘struct ieee80211_conf’ has no member named ‘mode’ drivers/net/wireless/rt2x00/rt2400pci.c:1726: error: ‘struct ieee80211_conf’ has no member named ‘mode’ drivers/net/wireless/rt2x00/rt2400pci.c: In function ‘rt2400pci_init_hw’: drivers/net/wireless/rt2x00/rt2400pci.c:1972: error: ‘struct ieee80211_hw’ has no member named ‘set_mac_address’ I don't have rt2400 card in my current testbed (but should probably add one; I'm pretty sure I have such a card somewhere), so this is not critical for my current tests. Anyway, this will also need to be fixed before the d80211 changes can be merged into wireless-2.6. -- Jouni MalinenPGP id EFC895FA - 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: [RFC/PATCH 3/13] d80211: non-shared interface types
On Wed, Mar 15, 2006 at 06:59:53PM +0100, Jiri Benc wrote: On Wed, 15 Mar 2006 09:40:52 -0800, Jouni Malinen wrote: The same issue showed up with our low-level driver. How was the low-level driver supposed to get this information with this change? From struct ieee80211_if_conf in add_interface callback. This was the part I had already forgetten about.. If you have two interfaces running, one of STA type and of AP type, what should be the value of such global mode variable? It makes more sense to have per-interface mode and let driver decide what should be the mode it tells to the hardware. Agreed. The proposed change is much better way of doing this. Unfortunately, I'm not able to test AP mode as it's not supported by any available driver yet. For STA mode I use bcm43xx drivers. OK. I tested bcm43xx_dscape in AP mode yesterday and, to my surprise, it was actually almost working. It was not sending beacon frames, but once I convinced my client to not care about this, I was able to successfully associate in WPA-PSK/TKIP mode. Anyway, since I haven't yet got to the point of merging in needed changes for hostapd, that would be the next showstopper in allowing you to test this easily.. In other words, until I get that done, I better be prepared to use time on testing all the AP mode cases myself ;-). -- Jouni MalinenPGP id EFC895FA - 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: [RFC/PATCH 1/13] d80211: allow WDS remote to by set by WE
On Wed, Mar 15, 2006 at 07:24:05PM +0100, Jiri Benc wrote:
On Wed, 15 Mar 2006 09:52:26 -0800, Jouni Malinen wrote:
This sounds good, but I was unable to get this working. I created a WDS
link with initial peer address 00:01:02:03:04:05. This added the netdev
and STA entry correctly. However, when I run iwconfig wds0 ap
00:11:22:33:44:55, I do not see any change in either the WDS data
(/proc/net/ieee80211/wlan0/iface/wds0 did not show change in wds.peer)
or STA info (00:11:22:33:44:55 was not added in
/proc/net/ieee80211/wlan0/sta directory).
Interesting. It shouldn't be in any way different than using
PRISM2_HOSTAPD_UPDATE_IF ioctl.
I can't find any problem looking at the patch and I'm unable to try it
now - I have to find out why my notebook freezes first :-/
Neither did I at first, but after some debugging, I would assume that
you actually meant to return from ieee80211_ioctl_siwap() if the
previous address is identical to the new one, not if it has changed.. In
other words:
Index: wireless-2.6/net/d80211/ieee80211_ioctl.c
===
--- wireless-2.6.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-2.6/net/d80211/ieee80211_ioctl.c
@@ -1871,7 +1871,7 @@ static int ieee80211_ioctl_siwap(struct
return ieee80211_sta_set_bssid(dev, (u8 *) ap_addr-sa_data);
} else if (sdata-type == IEEE80211_SUB_IF_TYPE_WDS) {
if (memcmp(sdata-u.wds.remote_addr, (u8 *) ap_addr-sa_data,
- ETH_ALEN) != 0)
+ ETH_ALEN) == 0)
return 0;
return ieee80211_if_update_wds(dev, (u8 *) ap_addr-sa_data);
}
This was enough to fix wds.peer address and get rid of the old STA
entry. However, new STA entry was not added for the new peer address.
PS.
I have now tested AP mode up to and including patch 5/13. This was
still allowing multi-BSSID to be used successfully. Patch 6/13 breaks
multi-BSSID configuration since our low-level driver needs bssid_mask
and bss_count to be configured. I need to take a closer look at how this
can be avoided with the new add_interface notification and automatic
BSSID mask calculation at the low-level driver.
Patch 7/13 breaks everything since we currently start with radio
disabled by default.. I can change that to be the other way around to
avoid this, but there are still some cases that need to be resolved
(e.g., need to stop TX/RX when a radar is detected for the duration of
scan for a new channel). I don't want to bring down all network
interfaces for that, so some kind of mechanism for temporarily disabling
TX/RX would be useful to have.
--
Jouni MalinenPGP id EFC895FA
-
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: [RFC/PATCH 6/13] d80211: remove obsolete stuff
On Mon, Mar 06, 2006 at 04:44:26PM +0100, Jiri Benc wrote:
Because any number of interfaces may be added, bss_devs and sta_devs arrays
cannot be fixed-size arrays. We can make them linked lists, but they are
needed for optimalization only (and even that is questionable with
subsequent patches). Let's remove them; we will probably want something
similar later to speed up packet receiving, but let's not bother ourselves
now.
@@ -277,9 +277,6 @@ struct ieee80211_conf {
int antenna_def;
int antenna_mode;
- u8 bssid_mask[ETH_ALEN];/* ff:ff:ff:ff:ff:ff = 1 BSSID */
- int bss_count;
In theory, the low-level driver can determine the needed mask itself.
However, it would need to be somehow notified of allowed BSSID values.
By removing this entry, this information would need to fetched from
somewhere else before interfaces are added.
Most hardware implementations have storage for a single MAC address in
EEPROM (or something similar) and in some cases, no addresses are stored
with the card and some external store is needed for this. We have been
using this mechanism of passing the information from user space to avoid
problems in figuring out board specific mechanisms for storing extra
data. Do you have any ideas on what would be the best of getting this
information configured after this change?
--- dscape.orig/net/d80211/ieee80211.c2006-03-06 14:10:18.0
+0100
+++ dscape/net/d80211/ieee80211.c 2006-03-06 14:10:22.0 +0100
@@ -1569,17 +1569,14 @@ struct sk_buff * ieee80211_beacon_get(st
u8 *b_head, *b_tail;
int bh_len, bt_len;
- spin_lock_bh(local-sub_if_lock);
- if (bss_idx 0 || bss_idx = local-bss_dev_count)
- bdev = NULL;
- else {
- bdev = local-bss_devs[bss_idx];
+ bdev = dev_get_by_index(bss_idx);
This and similar change for ieee80211_get_buffered_bc() add more
requirements for the low-level driver. It used to be enough to just know
that the low-level code should ask for up to N beacon frames. However,
with this change, the low-level driver would need to maintain a list of
ifindexes for the virtual interfaces. This is somewhat against the
original design of hiding all the virtual interfaces from low-level
code.
I think the ifindex values could be made available from add/remove
interface calls that you added. Was that what you had in mind or is
there another mechanism for getting the needed ifindexes down? I need to
understand this bit better in order to be able to modify the low-level
driver to handle this kind of change. At the moment, this change does
not look very good to me because of the extra requirement added for the
low-level code as far as virtual interfaces are concerned.
--
Jouni MalinenPGP id EFC895FA
-
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: [RFC/PATCH 6/13] d80211: remove obsolete stuff
On Wed, Mar 15, 2006 at 04:41:56PM -0800, Simon Barber wrote: The more natural way for beacons to flow from the 80211.o to the low level driver would be for beacons to be passed down just like any other 802.11 frame is passed down - rather than having a special case for beacons and buffered MC data, where they are pulled. I would suggest making the qdisc aware of beacons, and then there is no special interface for passing beacons down - they are passed down just like other frames, with a special queue ID reserved for beacons and buffered multicast. This would simplify the 80211.o/low level interface. Sure, but it would also require good synchronization for sending the beacons just before they are needed for transmission.. If the wlan hardware implementation provides support for interrupts that request beacons at proper times, being able to use them for this is quite convenient. -- Jouni MalinenPGP id EFC895FA - 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: [2.6 patch] hostap_{pci,plx}.c: fix memory leaks
On Mon, Mar 13, 2006 at 11:28:41PM +0100, Adrian Bunk wrote: This patch fixes two memotry leaks spotted by the Coverity checker. Thanks. I'll make a bit different patch to resolve this and related PCI leaks in one change. I'm going through the Coverity reports for Host AP driver, so I'll include other fixes in a patch set, too. -- Jouni MalinenPGP id EFC895FA - 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: [RFC/PATCH 6/13] d80211: remove obsolete stuff
On Mon, Mar 06, 2006 at 08:07:26PM +0100, Jiri Benc wrote: On Mon, 6 Mar 2006 10:49:46 -0800, Jouni Malinen wrote: The reason for this optimization was in even high-end CPUs starting to run out of resources when running one radio with 2007 virtual STAs, Yes, I'm aware of that. But I'm afraid that hard-wired need for STA interfaces to have incremental MAC addresses is not acceptable - and this fact alone means degrading of performance in case of 2000+ STAs. Since this is not needed for most normal use cases, this is probably fine. However, being able to test with large number of STAs is very useful test case for AP functionality (number of APs crash if you try to associate that many STAs..) and performance. One approach could be to add a hash table for address to netdev mapping. If that is not easily doable, a (hopefully) small patch could of course be maintained separately, but I would prefer to see this operation mode as something that is supported in the stack by default. -- Jouni MalinenPGP id EFC895FA - 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: [RFC/PATCH 7/13] d80211: remove adm_status
On Mon, Mar 06, 2006 at 02:25:52PM -0800, Jean Tourrilhes wrote: Jouni Malinen wrote : This is used to implement radio on/off without having to change other parts of the configuration (e.g., set interfaces down). The airo driver use 'txpower' for that. txpower has a 'off' option, and with the airo driver this disable the whole MAC, leaving the interface up (and 'on' revert back). This is somewhat confusing parameter for disabling both transmit and receive (or the whole MAC for that matter). Other than that, I don't really have anything against using this for what the adm_status was used as long as the 'on' option returns the previously used TX level without user space program having to set it again. I haven't looked at what the current drivers are doing in this case. -- Jouni MalinenPGP id EFC895FA - 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 wireless-2.6 0/2] d80211: Devicescape 802.11 update
Here's couple of patches to the Devicescape 802.11 implementation. Please consider applying to the dscape branch of wireless-2.6 tree. -- Jouni MalinenPGP id EFC895FA - 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 wireless-2.6 2/2] d80211: Replace local AES implementation with Crypto API
Replace local AES implementation (net/d80211/aes.c) with calls to
Crypto API.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-2.6/net/d80211/aes.c
===
--- wireless-2.6.orig/net/d80211/aes.c
+++ /dev/null
@@ -1,564 +0,0 @@
-/* Based on Rijndael implementation that has been placed in the public domain,
- * although heavily modified.
- *
- * Modifications Copyright 2003, Instant802 Networks, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * Optimized both speed and size by removing not used key lengths (only
- * 128-bit is used in IEEE 802.11i).
- */
-
-/* Use 256-byte Te4 table instead of larger 1024-byte */
-#define SMALL_TE4
-
-/* Save data size by using only one 1k table, but with a drawback of having to
- * rotate entries at lookup. This can be useful, if the CPU supports free
- * rotate on memory read. However, if this is not the case, this is much slower
- * than four-table implementation. */
-/* #define ONLY_ONE_TABLE */
-
-
-/* --- start of code that is based on public domain AES implementation --- */
-
-/**
- * rijndael-alg-fst.c
- *
- * @version 3.0 (December 2000)
- *
- * Optimised ANSI C code for the Rijndael cipher (now AES)
- *
- * @author Vincent Rijmen [EMAIL PROTECTED]
- * @author Antoon Bosselaers [EMAIL PROTECTED]
- * @author Paulo Barreto [EMAIL PROTECTED]
- *
- * This code is hereby placed in the public domain.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS
- * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
- * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE
- * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
- * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
- * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
- * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
- * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
- * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-/*
-Te0[x] = S [x].[02, 01, 01, 03];
-Te1[x] = S [x].[03, 02, 01, 01];
-Te2[x] = S [x].[01, 03, 02, 01];
-Te3[x] = S [x].[01, 01, 03, 02];
-Te4[x] = S [x].[01, 01, 01, 01];
-*/
-
-static const u32 Te0[256] =
-{
- 0xc66363a5U, 0xf87c7c84U, 0xee99U, 0xf67b7b8dU,
- 0xfff2f20dU, 0xd66b6bbdU, 0xde6f6fb1U, 0x91c5c554U,
- 0x60303050U, 0x02010103U, 0xce6767a9U, 0x562b2b7dU,
- 0xe7fefe19U, 0xb5d7d762U, 0x4dababe6U, 0xec76769aU,
- 0x8fcaca45U, 0x1f82829dU, 0x89c9c940U, 0xfa7d7d87U,
- 0xeffafa15U, 0xb25959ebU, 0x8e4747c9U, 0xfbf0f00bU,
- 0x41adadecU, 0xb3d4d467U, 0x5fa2a2fdU, 0x45afafeaU,
- 0x239c9cbfU, 0x53a4a4f7U, 0xe4727296U, 0x9bc0c05bU,
- 0x75b7b7c2U, 0xe1fdfd1cU, 0x3d9393aeU, 0x4c26266aU,
- 0x6c36365aU, 0x7e3f3f41U, 0xf5f7f702U, 0x834fU,
- 0x6834345cU, 0x51a5a5f4U, 0xd1e5e534U, 0xf9f1f108U,
- 0xe2717193U, 0xabd8d873U, 0x62313153U, 0x2a15153fU,
- 0x0804040cU, 0x95c7c752U, 0x46232365U, 0x9dc3c35eU,
- 0x30181828U, 0x379696a1U, 0x0a05050fU, 0x2f9a9ab5U,
- 0x0e070709U, 0x24121236U, 0x1b80809bU, 0xdfe2e23dU,
- 0xcdebeb26U, 0x4e272769U, 0x7fb2b2cdU, 0xea75759fU,
- 0x1209091bU, 0x1d83839eU, 0x582c2c74U, 0x341a1a2eU,
- 0x361b1b2dU, 0xdc6e6eb2U, 0xb45a5aeeU, 0x5ba0a0fbU,
- 0xa45252f6U, 0x763b3b4dU, 0xb7d6d661U, 0x7db3b3ceU,
- 0x5229297bU, 0xdde3e33eU, 0x5e2f2f71U, 0x13848497U,
- 0xa65353f5U, 0xb9d1d168U, 0xU, 0xc1eded2cU,
- 0x40202060U, 0xe3fcfc1fU, 0x79b1b1c8U, 0xb65b5bedU,
- 0xd46a6abeU, 0x8dcbcb46U, 0x67bebed9U, 0x7239394bU,
- 0x944a4adeU, 0x984c4cd4U, 0xb05858e8U, 0x85cfcf4aU,
- 0xbbd0d06bU, 0xc5efef2aU, 0x4fe5U, 0xedfbfb16U,
- 0x864343c5U, 0x9a4d4dd7U, 0x6655U, 0x11858594U,
- 0x8a4545cfU, 0xe9f9f910U, 0x04020206U, 0xfe7f7f81U,
- 0xa05050f0U, 0x783c3c44U, 0x259f9fbaU, 0x4ba8a8e3U,
- 0xa25151f3U, 0x5da3a3feU, 0x804040c0U, 0x058f8f8aU,
- 0x3f9292adU, 0x219d9dbcU, 0x70383848U, 0xf1f5f504U,
- 0x63bcbcdfU, 0x77b6b6c1U, 0xafdada75U, 0x42212163U,
- 0x20101030U, 0xe51aU, 0xfdf3f30eU, 0xbfd2d26dU,
- 0x81cdcd4cU, 0x180c0c14U, 0x26131335U, 0xc3ecec2fU,
- 0xbe5f5fe1U, 0x359797a2U, 0x88ccU, 0x2e171739U,
- 0x93c4c457U, 0x55a7a7f2U, 0xfc7e7e82U, 0x7a3d3d47U,
- 0xc86464acU, 0xba5d5de7U, 0x3219192bU, 0xe6737395U,
- 0xc06060a0U, 0x19818198U, 0x9e4f4fd1U, 0xa3dcdc7fU,
- 0x4466U, 0x542a2a7eU, 0x3b9090abU, 0x0b83U,
- 0x8c4646caU, 0xc729U, 0x6bb8b8d3U, 0x2814143cU,
- 0xa7dede79U, 0xbc5e5ee2U, 0x160b0b1dU, 0xaddbdb76U
[PATCH wireless-2.6 0/5] d80211: Devicescape 802.11 update
Here's couple of patches to the Devicescape 802.11 implementation. Please consider applying to the dscape branch of wireless-2.6 tree. -- Jouni MalinenPGP id EFC895FA - 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 wireless-2.6 2/5] d80211: Update rx.skb after RX handler calls
RX handlers are allowed to change rx.skb pointer in the same way as TX handlers. In other words, ieee80211_rx() must use the new pointer after the RX handler loop has been completed to avoid freeing incorrect skb if the frame ends up being dropped after the skb pointer has been changed. Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: wireless-2.6/net/d80211/ieee80211.c === --- wireless-2.6.orig/net/d80211/ieee80211.c +++ wireless-2.6/net/d80211/ieee80211.c @@ -3325,6 +3325,7 @@ void __ieee80211_rx(struct net_device *d break; } } + skb = rx.skb; /* handlers are allowed to change skb */ if (res == TXRX_DROP || *handler == NULL) dev_kfree_skb(skb); -- -- Jouni MalinenPGP id EFC895FA - 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 wireless-2.6 1/5] d80211: Correct spelling for Devicescape
's' is not capitalized in Devicescape. Let's try to fix these cases before the incorrect spelling is copied into more places. Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: wireless-2.6/drivers/net/wireless/Kconfig === --- wireless-2.6.orig/drivers/net/wireless/Kconfig +++ wireless-2.6/drivers/net/wireless/Kconfig @@ -492,7 +492,7 @@ config PRISM54 source drivers/net/wireless/hostap/Kconfig config BCM43XX_D80211 - tristate Broadcom BCM43xx wireless support (DeviceScape stack) + tristate Broadcom BCM43xx wireless support (Devicescape stack) depends on PCI D80211 NET_RADIO EXPERIMENTAL select FW_LOADER ---help--- Index: wireless-2.6/drivers/net/wireless/rt2x00/Kconfig === --- wireless-2.6.orig/drivers/net/wireless/rt2x00/Kconfig +++ wireless-2.6/drivers/net/wireless/rt2x00/Kconfig @@ -5,7 +5,7 @@ config RT2X00 This will enable the experimental support for the Ralink drivers, developed in the rt2x00 project http://rt2x00.serialmonkey.com. - These drivers will make use of the DeviceScape ieee80211 stack. + These drivers will make use of the Devicescape ieee80211 stack. config RT2400PCI tristate Ralink rt2400 pci/pcmcia support -- -- Jouni MalinenPGP id EFC895FA - 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 wireless-2.6 3/5] d80211: Remove EXPORT_SYMTAB define
No need to define EXPORT_SYMTAB separatel here when this is built inside the current kernel tree. Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: wireless-2.6/net/d80211/ieee80211.c === --- wireless-2.6.orig/net/d80211/ieee80211.c +++ wireless-2.6/net/d80211/ieee80211.c @@ -7,10 +7,6 @@ * published by the Free Software Foundation. */ -#ifndef EXPORT_SYMTAB -#define EXPORT_SYMTAB -#endif - #include linux/config.h #include linux/version.h #include linux/module.h -- -- Jouni MalinenPGP id EFC895FA - 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 wireless-2.6 4/5] d80211: Add radar detection parameters
Add parameters for radar detection that were previously left as a
to-do item.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-2.6/include/net/d80211.h
===
--- wireless-2.6.orig/include/net/d80211.h
+++ wireless-2.6/include/net/d80211.h
@@ -300,6 +300,11 @@ struct ieee80211_conf {
unsigned int quiet_offset; /* how far into the beacon is the quiet
* period */
unsigned int quiet_period;
+ u8 radar_firpwr_threshold;
+ u8 radar_rssi_threshold;
+ u8 pulse_height_threshold;
+ u8 pulse_rssi_threshold;
+ u8 pulse_inband_threshold;
};
Index: wireless-2.6/net/d80211/hostapd_ioctl.h
===
--- wireless-2.6.orig/net/d80211/hostapd_ioctl.h
+++ wireless-2.6/net/d80211/hostapd_ioctl.h
@@ -336,12 +336,11 @@ struct prism2_hostapd_param {
u16 reason_code;
} mlme;
struct {
- unsigned int value;
- /* TODO
- int pulse_width;
- int num_pulse;
- int period;
- */
+ u8 radar_firpwr_threshold;
+ u8 radar_rssi_threshold;
+ u8 pulse_height_threshold;
+ u8 pulse_rssi_threshold;
+ u8 pulse_inband_threshold;
}radar;
struct {
unsigned int period;
Index: wireless-2.6/net/d80211/ieee80211_ioctl.c
===
--- wireless-2.6.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-2.6/net/d80211/ieee80211_ioctl.c
@@ -1328,7 +1328,12 @@ static int ieee80211_ioctl_set_quiet_par
static int ieee80211_ioctl_set_radar_params(struct net_device *dev,
struct prism2_hostapd_param *param)
{
- /* struct ieee80211_conf *conf = ieee80211_get_hw_conf(dev); */
+ struct ieee80211_conf *conf = ieee80211_get_hw_conf(dev);
+ conf-radar_firpwr_threshold = param-u.radar.radar_firpwr_threshold;
+ conf-radar_rssi_threshold = param-u.radar.radar_rssi_threshold;
+ conf-pulse_height_threshold = param-u.radar.pulse_height_threshold;
+ conf-pulse_rssi_threshold = param-u.radar.pulse_rssi_threshold;
+ conf-pulse_inband_threshold = param-u.radar.pulse_inband_threshold;
return 0;
}
--
--
Jouni MalinenPGP id EFC895FA
-
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 wireless-2.6 5/5] d80211: Whitespace cleanup - no functional changes
Let's clean up some of the whitespace use (extra lines, trailing
whitespace, incorrect indentation).
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-2.6/net/d80211/ieee80211.c
===
--- wireless-2.6.orig/net/d80211/ieee80211.c
+++ wireless-2.6/net/d80211/ieee80211.c
@@ -322,8 +322,7 @@ ieee80211_tx_h_rate_ctrl(struct ieee8021
extra.startidx = 0;
extra.endidx= tx-local-num_curr_rates;
-
-tx-u.tx.rate = rate_control_get_rate(tx-dev, tx-skb, extra);
+ tx-u.tx.rate = rate_control_get_rate(tx-dev, tx-skb, extra);
if (unlikely(extra.probe != NULL)) {
tx-u.tx.control-rate_ctrl_probe = 1;
tx-u.tx.probe_last_frag = 1;
@@ -375,7 +374,8 @@ ieee80211_tx_h_select_key(struct ieee802
tx-key = tx-sta-key;
else if (tx-sdata-default_key)
tx-key = tx-sdata-default_key;
- else if (tx-sdata-drop_unencrypted !(tx-sdata-eapol
ieee80211_is_eapol(tx-skb))) {
+ else if (tx-sdata-drop_unencrypted
+!(tx-sdata-eapol ieee80211_is_eapol(tx-skb))) {
I802_DEBUG_INC(tx-local-tx_handlers_drop_unencrypted);
return TXRX_DROP;
} else
@@ -408,7 +408,6 @@ ieee80211_tx_h_fragment(struct ieee80211
if (!tx-fragmented)
return TXRX_CONTINUE;
-
first = tx-skb;
hdrlen = ieee80211_get_hdrlen(tx-fc);
@@ -755,7 +754,6 @@ ieee80211_tx_h_misc(struct ieee80211_txr
!control-use_rts_cts)
control-use_cts_protect = 1;
-
/* Setup duration field for the first fragment of the frame. Duration
* for remaining fragments will be updated when they are being sent
* to low-level driver in ieee80211_tx(). */
@@ -777,7 +775,6 @@ ieee80211_tx_h_misc(struct ieee80211_txr
!(rate-flags IEEE80211_RATE_BASIC))
rate--;
-
if (control-use_rts_cts)
dur += ieee80211_frame_duration(tx-local, 10,
rate-rate, erp,
@@ -819,10 +816,10 @@ static void ieee80211_rate_limit(unsigne
local-rate_limit_bucket = local-rate_limit_burst;
local-rate_limit_timer.expires = jiffies + HZ;
add_timer(local-rate_limit_timer);
-}
-
+ }
}
+
static ieee80211_txrx_result
ieee80211_tx_h_rate_limit(struct ieee80211_txrx_data *tx)
{
@@ -841,7 +838,6 @@ ieee80211_tx_h_rate_limit(struct ieee802
}
-
static ieee80211_txrx_result
ieee80211_tx_h_check_assoc(struct ieee80211_txrx_data *tx)
{
@@ -1220,7 +1216,8 @@ static int ieee80211_master_start_xmit(s
control.sdata = pkt_data-sdata;
control.req_tx_status = pkt_data-req_tx_status;
control.do_not_encrypt = pkt_data-do_not_encrypt;
- control.pkt_type = pkt_data-pkt_probe_resp ? PKT_PROBE_RESP :
PKT_NORMAL;
+ control.pkt_type =
+ pkt_data-pkt_probe_resp ? PKT_PROBE_RESP : PKT_NORMAL;
control.requeue = pkt_data-requeue;
control.queue = pkt_data-queue;
@@ -1324,7 +1321,7 @@ static int ieee80211_subif_start_xmit(st
ret = 0;
goto fail;
}
-
+
/* receiver is QoS enabled, use a QoS type frame */
sta = sta_info_get(local, hdr.addr1);
if (sta) {
@@ -1334,7 +1331,7 @@ static int ieee80211_subif_start_xmit(st
}
sta_info_release(local, sta);
}
-
+
hdr.frame_control = cpu_to_le16(fc);
hdr.duration_id = 0;
hdr.seq_ctrl = 0;
@@ -1423,10 +1420,9 @@ static int ieee80211_subif_start_xmit(st
skb-nh.raw = skb-data + nh_pos;
skb-h.raw = skb-data + h_pos;
+ dev_queue_xmit(skb);
-dev_queue_xmit(skb);
-
-return 0;
+ return 0;
fail:
if (!ret)
@@ -1459,7 +1455,7 @@ ieee80211_mgmt_start_xmit(struct sk_buff
hdr = (struct ieee80211_hdr *) skb-data;
fc = le16_to_cpu(hdr-frame_control);
-pkt_data = (struct ieee80211_tx_packet_data *)skb-cb;
+ pkt_data = (struct ieee80211_tx_packet_data *) skb-cb;
memset(pkt_data, 0, sizeof(struct ieee80211_tx_packet_data));
pkt_data-sdata = sdata;
@@ -1467,7 +1463,7 @@ ieee80211_mgmt_start_xmit(struct sk_buff
WLAN_FC_GET_STYPE(fc) == WLAN_FC_STYPE_PROBE_RESP)
pkt_data-pkt_probe_resp = 1;
-skb-priority = 20; /* use hardcode priority for mgmt TX queue */
+ skb-priority = 20; /* use hardcoded priority for mgmt TX queue */
skb-dev = sdata-master;
/*
@@ -1480,8 +1476,6 @@ ieee80211_mgmt_start_xmit(struct sk_buff
hdr-frame_control = cpu_to_le16(fc);
}
-
-
pkt_data-do_not_encrypt = !(fc WLAN_FC_ISWEP);
sdata-stats.tx_packets++;
@@ -1567,8 +1561,6 @@ static void
Re: [wireless-2.6] d80211/ieee80211 symbol clash
On Thu, Feb 02, 2006 at 08:36:26PM +0100, Michael Buesch wrote: net/ieee80211/built-in.o: In function `ieee80211_rx': : multiple definition of `ieee80211_rx' net/d80211/built-in.o:: first defined here But how to solve it? I suggest to change all dscape function prefixes from ieee80211_FOO to d80211_FOO. I would rather not see this kind of change in the function names in net/d80211. I would be willing to live with the clashing symbols for the time being since the goal is to get into one stack in the end anyway. Linking in both stacks staticly or loading both as kernel modules at the same time is something that I don't see as a very strong requirement at the moment. -- Jouni MalinenPGP id EFC895FA - 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-2.6] d80211/ieee80211 symbol clash
On Thu, Feb 02, 2006 at 06:01:45PM -0500, Jeff Garzik wrote: Avoiding namespace clashes means that you avoid confusing all manner of common developer tools. In particular, 'make allyesconfig' is a valuable developer tool that should not be broken. I agree with this completely; I just would like to avoid the issues of doing large scale renames for a case that will hopefully be resolved anyway shortly by ending up with just one implementation. Don't take this as an endorsement for mass renaming, however. The smallest PRACTICAL solution may be simply renaming one of the clashing functions to ieee80211_rcv, for example. This would certainly be easier to handle than full renaming of all function names in net/d80211. -- Jouni MalinenPGP id EFC895FA - 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-2.6] d80211/ieee80211 symbol clash
On Thu, Feb 02, 2006 at 02:55:43PM -0800, shemminger wrote: But then the module autoloader is going to work correctly, and what about people using drivers that use conflicting stacks? Get the namespace issues sorted out before you consider getting it into the mainline. I thought that only one IEEE 802.11 stack was going to be going into the mainline, i.e., this issue will be automatically resolved at that point and it only applies to the non-mainline tree that allows both implementations to be used temporarily while we go through selecting what we want to see in the mainline tree. -- Jouni MalinenPGP id EFC895FA - 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] drivers/net/wireless: correct reported ssid lengths
On Mon, Jan 30, 2006 at 10:13:16AM -0800, Jean Tourrilhes wrote: On Fri, Jan 27, 2006 at 05:01:44PM -0800, Jouni Malinen wrote: It is spelled very clearly on my web site : --- # The HostAP driver is the reference implementation of Wireless Extensions for 802.11b devices, and is the reference implementation for iwpriv functionality. # The Aironet driver (version 1.4 and later from Ben) is an alternate reference implementation of Wireless Extensions for 802.11b devices. It implements fully WE-14 (Wireless Scanning and Wireless Events), and is different than HostAP. Unfortunately, this may cause some unclarity for this particular case. I seem to have used SSID length in Host AP driver (even though I now understand that it should probably have been len+1) and Aironet driver is using len+1.. The problem with documentations is that they are never in sync with the implementation, so potentially misleading. That's why we have reference implementations. And the reference implementations are not in sync in this particular case.. My current assumption is that both ioctls were expected to to include extra nul termination in SSID (even though I don't see much point with this) and the data field for SSID is expected to have that nul termination. In other words, if a user space program uses SSID as a octet string (like wpa_supplicant is doing), setting SSID would need to use len+1 and extra '\0' added to the end of SSID data (e.g., by clearing the structure before copying SSID). In case of getting the SSID, kernel driver would do similar changes and len-1 would be used in user space. Yep. After writing that paragraph (and after having sent that email), I looked at what Host AP driver was doing, and it was not following this.. In other words, Host AP driver has inconsistent definition of SSID length in SIOCGIWESSID (len) and SIOCSIWESSID (len+1). Or well, I think it accept both len and len+1 in SIOCSIWESSID, but wpa_supplicant is now using len+1. I would have preferred to see these ioctls use correct length and no expectation on the SSID data being a printable string. However, if the user space programs were to do this for SIOCSIWESSID, some drivers would configure incorrect SSID (the last octet missing). We can make this change, it you desire. At this point, I don't really see any need to change this in the API. However, I would like to see us having clear definition on what is the correct behavior so that the drivers can be fixed to do the same thing. I have nothing against changing Host AP driver to return len+1 in SIOCSIWESSID, if that doesn't break user space programs. Though, it sounds like it actually would have broken older versions (well, all released stable versions) which makes this change a bit unfortunate. Anyway, if I have used the API incorrectly, it could finally be the time to fix that after this many years ;-). -- Jouni MalinenPGP id EFC895FA - 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] drivers/net/wireless: correct reported ssid lengths
On Sat, Jan 28, 2006 at 11:07:10AM -0500, Dan Williams wrote: On Fri, 2006-01-27 at 17:01 -0800, Jouni Malinen wrote: On Thu, Jan 12, 2006 at 03:00:58PM -0500, Dan Williams wrote: 1) The patch preserves the null-termination of the ESSID, it just doesn't return the expanded length to accommodate that null. So yes, this may cause programs that simple copy the exact # of bytes, and then do string operations on it, to crash. Programs that simply do string operations on the returned essid regardless of length should be unaffected. Boundary conditions are interesting here, since as the ESSID approaches IW_MAX_ESSID (or whatever that is), which is 32, it was unclear what the effect of padding the returned ESSID buffer was anyway. If the ESSID from the AP actually was 32 bytes long, the padding null would go into byte 33 and likely be ignored by the calling program if it's badly coded. Agreed, I've mentioned that to Jean, but I don't remember anymore what was the expected way of handling 32-octet SSIDs. 2) ipw and madwifi-ng at least don't do what airo/etc do. So wouldn't those programs that have a problem with (1) also _already_ have a problem with ipw and madwifi? Those drivers don't pad with NULL and return len+1. They use the exact essid sent through SIOCSIWESSID. madwifi-ng actually checks for trailing /0 and removes that before setting the essid in hardware. Yes.. The correct behavior should be spelled out explicitly somewhere since there is still so much confusion about what exactly is the expected behavior. 3) I posted a patch to correct the observed problem in wpa_supplicant HEAD, which didn't work with atmel cards due to this issue. I was told in no uncertain terms by Henrik Brix Andersen [EMAIL PROTECTED] to Please fix the offending drivers instead of breaking wpa_supplicant. I actually have no idea if he has anything to do with wpa_supplicant, but I heard no further discussion on the topic and therefore decided to patch the drivers to do the right thing. This happened while I was travelling and did not have good access to my email for couple of weeks.. It's still on my to-do list, but going through all the email from past few weeks is going to take some time. I think that wpa_supplicant will have to try to cope with whatever the kernel drivers are doing. Unfortunately this means handling multiple different choices. Getting the SSID from the driver is somewhat easier, since wpa_supplicant can just determine what is the most likely interpretation of the returned. Setting SSID is more difficult, since some drivers may expect len+1 and some require len as SSID length.. Looking at your patch, it does indeed seem to be only for SIOCGIWESSID, so it is indeed something that will need to be merged into wpa_supplicant and I'll do that. Actually, wpa_supplicant started using real SSID length, but was changed in September 2004 to use len+1 after Jean explained what the SIOCSIWESSID was designed to do.. Are you sure this is really the case? The entire reason the patch was posted to wpa_supplicant lists was because I had problems with drivers that do len+1, which wpa_supplicant didn't accept. Yes, this change in 2004 was for SIOCSIWESSID. I had not looked at your patch when I wrote that, but you seem to be changing SIOCGIWESSID handling and that looks like a reasonable change. In any case, I don't have a problem with reverting the patch to the kernel drivers, but then we either need to: Before doing any more changes, I would really like to get consensus on what exactly WEXT requires so that we do not need to continue changing this in the future. Just to be sure that we understand all cases, I would like to see full list of cases and values for data and length field for SIOCGIWESSID and SIOCSIWESSID. My current assumption is that both ioctls were expected to to include extra nul termination in SSID (even though I don't see much point with this) and the data field for SSID is expected to have that nul termination. In other words, if a user space program uses SSID as a octet string (like wpa_supplicant is doing), setting SSID would need to use len+1 and extra '\0' added to the end of SSID data (e.g., by clearing the structure before copying SSID). In case of getting the SSID, kernel driver would do similar changes and len-1 would be used in user space. I would have preferred to see these ioctls use correct length and no expectation on the SSID data being a printable string. However, if the user space programs were to do this for SIOCSIWESSID, some drivers would configure incorrect SSID (the last octet missing). -- Jouni MalinenPGP id EFC895FA - 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 d80211]: Add support for WE-18
This patch addd Linux Wireless Extensions version 18 support into the
Devicescape 802.11 stack by converting the WE ioctl registration to use
the new dev-wireless_handlers mechanism and by adding support for the
ioctls that are needed for WPA/WPA2 in client mode. The private ioctl
versions of key configuration and MLME functions were not removed since
there are still user space programs using these. The old versions can be
removed from here once user space programs get updated to WE-18 (both
client and AP functionality).
I tested this version quickly with bcm43xx driver in dscape-all branch.
Both the patched wpa_supplicant 0.4.7 with driver_dscape.c and the default
driver_wext.c (WE-18) allowed WPA handshake to be completed. The goal is
to make it unnecessary to patch wpa_supplicant with a new driver
interface code (driver_dscape.c).
Please apply into the dscape-all branch (or whatever branch is
appropriate for this kind of change) of the wireless-2.6 tree.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: wireless-2.6/net/d80211/ieee80211.c
===
--- wireless-2.6.orig/net/d80211/ieee80211.c
+++ wireless-2.6/net/d80211/ieee80211.c
@@ -1,6 +1,6 @@
/*
* Copyright 2002-2005, Instant802 Networks, Inc.
- * Copyright 2005, Devicescape Software, Inc.
+ * Copyright 2005-2006, Devicescape Software, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -3874,6 +3874,8 @@ static struct net_device *ieee80211_if_a
memcpy(wds_dev-dev_addr, dev-dev_addr, ETH_ALEN);
wds_dev-hard_start_xmit = ieee80211_subif_start_xmit;
+ wds_dev-wireless_handlers =
+ (struct iw_handler_def *) ieee80211_iw_handler_def;
wds_dev-do_ioctl = ieee80211_ioctl;
wds_dev-change_mtu = ieee80211_change_mtu;
wds_dev-tx_timeout = ieee80211_tx_timeout;
@@ -4421,6 +4423,8 @@ struct net_device *ieee80211_alloc_hw(si
memcpy(dev-name, wlan%d, 7);
dev-hard_start_xmit = ieee80211_subif_start_xmit;
+ dev-wireless_handlers =
+ (struct iw_handler_def *) ieee80211_iw_handler_def;
dev-do_ioctl = ieee80211_ioctl;
dev-change_mtu = ieee80211_change_mtu;
dev-tx_timeout = ieee80211_tx_timeout;
@@ -4510,6 +4514,8 @@ struct net_device *ieee80211_alloc_hw(si
ether_setup(mdev);
mdev-hard_start_xmit = ieee80211_master_start_xmit;
+ mdev-wireless_handlers =
+ (struct iw_handler_def *) ieee80211_iw_handler_def;
mdev-do_ioctl = ieee80211_ioctl;
mdev-change_mtu = ieee80211_change_mtu;
mdev-tx_timeout = ieee80211_tx_timeout;
Index: wireless-2.6/net/d80211/ieee80211_i.h
===
--- wireless-2.6.orig/net/d80211/ieee80211_i.h
+++ wireless-2.6/net/d80211/ieee80211_i.h
@@ -515,6 +515,8 @@ int ieee80211_if_update_wds(struct net_d
/* ieee80211_ioctl.c */
int ieee80211_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
+extern const struct iw_handler_def ieee80211_iw_handler_def;
+
/* Set hw encryption from ieee80211 */
int ieee80211_set_hw_encryption(struct net_device *dev,
struct sta_info *sta, u8 addr[ETH_ALEN],
Index: wireless-2.6/net/d80211/ieee80211_ioctl.c
===
--- wireless-2.6.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-2.6/net/d80211/ieee80211_ioctl.c
@@ -1,6 +1,6 @@
/*
* Copyright 2002-2005, Instant802 Networks, Inc.
- * Copyright 2005, Devicescape Software, Inc.
+ * Copyright 2005-2006, Devicescape Software, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -466,43 +466,30 @@ int ieee80211_set_hw_encryption(struct n
}
-static int ieee80211_ioctl_set_encryption(struct net_device *dev,
- struct prism2_hostapd_param *param,
- int param_len)
+static int ieee80211_set_encryption(struct net_device *dev, u8 *sta_addr,
+ int idx, int alg, int set_tx_key, int *err,
+ const u8 *_key, size_t key_len)
{
struct ieee80211_local *local = dev-priv;
- int alg, ret = 0;
+ int ret = 0;
struct sta_info *sta;
struct ieee80211_key **key;
- int set_tx_key = 0, try_hwaccel = 1;
+ int try_hwaccel = 1;
struct ieee80211_key_conf *keyconf;
struct ieee80211_sub_if_data *sdata;
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
- param-u.crypt.err = 0;
- param-u.crypt.alg[HOSTAP_CRYPT_ALG_NAME_LEN - 1] = '\0';
-
- if (param_len
- (int) ((char *) param-u.crypt.key - (char *) param) +
- param-u.crypt.key_len
Re: [patch] drivers/net/wireless: correct reported ssid lengths
On Thu, Jan 12, 2006 at 03:00:58PM -0500, Dan Williams wrote: ESSIDs can technically include NULL characters. Drivers should not be adjusting the length of the ESSID before reporting it in their SIOCGIWESSID handlers. Breaks stuff like wpa_supplicant. Note that ipw drivers, which seem to currently be the most correct, don't have this problem. I'm still trying to go through the huge amount of email I've received during two-week time travelling and noticed this one just now. I did not see any discussion about this on netdev list, but I believe the change here is changes the WE user space interface and this has not been done previously in order to not break user space programs. I agree that the choice of SSID len+1 is unfortunate for a data structure that is not really a string but array of octets. However, that was the way SIOCGIWESSID/SIOCSIWESSID was designed if I have understood correctly (Jean cc'ed just in case). Is this change, if applied (or was it already applied?), an indication that we are now changing the WE interface in a way that is not backwards compatible and we are willing to break an existing kernel-user space interface? Actually, wpa_supplicant started using real SSID length, but was changed in September 2004 to use len+1 after Jean explained what the SIOCSIWESSID was designed to do.. -- Jouni MalinenPGP id EFC895FA - 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: [ANNOUNCE] RT2x00 ieee80211 stack switch
On Wed, Jan 04, 2006 at 01:35:08PM +0100, Jiri Benc wrote: On Tue, 03 Jan 2006 18:06:30 +0100, Johannes Berg wrote: How about - get rid of all the embedded algorithms (AES, Michael, RC4, CRC) and use the crypto layer from the kernel Definitely. Yes, that is also on my to-do list. The versions in Host AP driver (and well, now in net/ieee80211) are of newer design. With the possibility to rely on the kernel having crypto API, these should indeed be used. I haven't yet looked into whether ipw drivers have changed the crypto code enough to handle the case of hardware acceleration for all/some frames. This was missing from Host AP code due for TKIP/CCMP. - split out frame crypto stuff into modules like ieee80211 does (or maybe even use those?) Would be nice. See also a comment in ieee80211.c: /* TODO: implement register/unregister functions for adding TX/RX handlers * into ordered list */ Yes, this is indeed the goal here. Lots of the functionality could be moved into kernel modules that are loaded only if needed. That would speed up TX/RX path when smaller number of handlers are needed. What's with CONFIG_OAP_LEDS_WLAN? Shouldn't that LED handling function be a pointer that can be assigned to whatever one wants, and you could then get rid of IEEE80211_LEDS etc? LED handling seems strange. It probably depends on some other stuff not released by Devicescape, I would suspect something responsible for handling LEDs on their AP boxes or so. This is a very old interface for a customer. I don't think it was ever really used at Devicescape and I certainly don't see much need for it in the current version. In other words, it could just be removed. -- Jouni MalinenPGP id EFC895FA - 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: State of the Union: Wireless / 802.11 master device
On Wed, Jan 18, 2006 at 09:18:26AM +0100, Feyd wrote: With fullmac devices the master interface makes no sense, it cannot be used for neither the sniffing or QoS. The design where the master device is something else than net_device is cleaner, it treats both soft/fullmac devices equaly, without need to special-case one of them. This may be the case with designs that do not provide anything else than a simple interface for delivering and receiving frames. However, the benefits--and I would be prepared to say even requirements--of having a master device are extensive enough to use it with many wlan designs. If a generic design is desired for both types, even fullmac devices would need to keep the master netdev even if it is not really needed. Other option would be to make it optional to add the master netdev and have something else presenting the wlan device. In addition, even fullmac devices may have uses for master netdev. For example, in AP mode with dynamic VLAN configuration (RADIUS authentication server selecting which VLAN to use), there may be benefits of being able to use multiple virtual interfaces (netdevs) that would logically be collected into master netdev for scheduling and transmission. -- Jouni MalinenPGP id EFC895FA - 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: State of the Union: Wireless / 802.11 master device
On Tue, Jan 17, 2006 at 01:05:16PM +0100, Jiri Benc wrote: On Mon, 16 Jan 2006 19:07:51 -0800, Jouni Malinen wrote: Actually, there is a use for the master device. It can be used to monitor what is going on over the radio from all virtual APs/STAs, e.g., by running Ethereal on it. You can add a new soft monitor interface and use it instead. There is no need for separate master device. Sure, you can do it that way, too. However, this is not the only use. I just remembered another one: QoS. Devicescape 802.11 code uses a qdisc on the master interface to take care of determining which hardware TX queue to use with WMM (which uses four different TX queues). Each virtual interface do not include own queue and outgoing frames are queued through the master device (again, this is something that matches with VLAN implementation). For WMM, the frames in different classes would need to be scheduled from all virtual interfaces together, not just separately. Would there be a better way of doing this without using a master netdev and qdisc/netsched? -- Jouni MalinenPGP id EFC895FA - 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: State of the Union: Wireless / 802.11 master device
On Tue, Jan 17, 2006 at 02:55:31PM -0500, jamal wrote: On Tue, 2006-17-01 at 11:42 -0800, Jouni Malinen wrote: so if i understood correctly: You have a master netdevice which underneath it has child netdevices? I'm not sure what exactly child netdev means, but it sounds like something that could be indeed what the stack is using. The master netdev has a queue and all other netdevs do not use their own queue (i.e., they share the one used in the master netdev and all TX frames go through that). Each virtual interface do not include own queue and outgoing frames are queued through the master device (again, this is something that matches with VLAN implementation). If i understood you correctly, what you are doing is certainly reasonable. Instead of restructuring the netdevice layer to deal with with multiple independent h/ware tx queues you've added a mother device which does intermidiate queueing. The master netdev collects all TX frames and the special 802.11-aware qdisc takes care of scheduling them, e.g., based on WMM access categories to independent hardware TX queues. For WMM, the frames in different classes would need to be scheduled from all virtual interfaces together, not just separately. Would there be a better way of doing this without using a master netdev and qdisc/netsched? I havent been following the thread so i dont understand this problem. Can you explain it in details? Simon wrote some more details on related topic. The way I see this is that there can be multiple virtual netdevs (e.g., multiple virtual APs) using the same wlan radio. The frames for all these virtual APs should be able to share the same scheduling procedure, e.g., to allow voice calls get high priority regardless of which virtual AP is sending the frames for these traffic flows. Being able to set this all with existing tc tool for the master netdev looks like quite clean way of handling this. -- Jouni MalinenPGP id EFC895FA - 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: State of the Union: Wireless
On Wed, Jan 11, 2006 at 07:25:11PM +0100, Krzysztof Halasa wrote: 3. To have a master device which isn't represented by a network device (ifconfig doesn't show it etc.) but can be accessed only by the wireless tools. Or just using sysfs, echo and cat can be best tools. The slaves (netdevs) can be created and deleted at will. No obscure netdev with no apparent functionality and nothing special in the first, last or whichever netdev. Actually, there is a use for the master device. It can be used to monitor what is going on over the radio from all virtual APs/STAs, e.g., by running Ethereal on it. Isn't VLANs implemented in the same way with the netdev added by the driver (master device). The low-level wireless driver could do the same thing and then user space tools can add whatever virtual interfaces are needed. -- Jouni MalinenPGP id EFC895FA - 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] hostap: allow flashing firmware
On Fri, Dec 30, 2005 at 06:22:26PM -0500, Pavel Roskin wrote: Host AP driver has code to support writing firmware to non-volatile memory, a.k.a. flash. This code has been extensively tested when Host AP was a standalone driver. Add a configuration option to the kernel to allow enabling this functionality. Improve the description of the RAM download option. Mention cards that require it. Remove obsolete scary comment. I'm not completely against this change, but that scary comment is there on purpose and it is not fully obsolete. It is still possible to get HFA3841 cards into state which require hardware modifications to recover from (i.e., they are as good as dead for most users). Taken into this account, I would prefer that the help text for HOSTAP_FIRMWARE_NVRAM would include a warning about the potential issues of using incorrect firmware images. In most cases, RAM (volatile) download can be used to upgrade the firmware without having to modify the flash contents. This is also what the current Windows drivers are doing. -- Jouni MalinenPGP id EFC895FA - 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: Broadcom 43xx first results
On Tue, Dec 06, 2005 at 02:47:28PM -0800, Jean Tourrilhes wrote: DeviceScape stack : drivers using it : ? potential drivers : hostap, ipw2100, ipw2200, r8180, adm8211 It's mainly used with Atheros chipsets nowadays, but it has been used with couple of other chipsets, too, including Prism2/2.5/3 and parts of Host AP driver. If you want to use the DeviceScape stack instead of the IPW stack, my first question is how do you plan to migrate the drivers using it to the new stack. Currently, people are hard at work targetting the IPW stack (see above), I don't want them to have to throw away all their work. No matter how this is done, I think it is quite likely that lot of work has to be thrown away in the sense that it does not end up being in the kernel. Having n+1 implementations for generic 802.11 functionality is a good proof of this already being the case. I wouldn't say all work is thrown away, though, even if lots of code will get thrown away. It is good to get understanding on what kind of specific requirements each chipset has in order to be able to accommodate them in the 802.11 design for Linux. In particular, iwp2*00 are working today in the kernel, and I expect that they would be migrated to the new stack at the stack switchover. As both the IPW and the DeviceScape stacks are derived from the HostAP stack, that should not be too hard. Devicescape code is not actually derived from Host AP code. The user space component is same (hostapd), but the kernel side is completely new implementation. As far as IPW is concerned, some parts of it is indeed derived from Host AP (I can never remember which one, but either TX or RX; while the other side was new design for some reason). Also, what puzzle me is that Jouni doesn't seem to have anounced any plan to port his HostAP driver to his DeviceScape stack. If there is one driver that should use it, that's HostAP. Prism2/2.5/3 is getting somewhat old nowadays and I certainly prefer other chipset designs that do not have a large firmware component preventing driver/802.11 stack from doing things. Anyway, I have actually used Devicescape code with Prism2/2.5/3 cards by taking the low-level parts of the Host AP driver. This just happened to be two-three years ago and that code has found no use after that, so it has not been maintained. I would certainly like to get rid of maintaining many parts of Host AP driver by getting it to use shared IEEE 802.11 code. I have been quite occupied with other projects lately which has made it more difficult to get much progress done here. Anyway, the current goal is to free up my time by end of this year so that I could start concentrating on the open source IEEE 802.11 stack for Linux 2.6. One of the things I would like to do is to make sure that there is somewhat more complete setup available for testing the Devicescape code as part of open source development. I'm most familiar with Atheros chipset nowadays, so I would probably prefer to work with that and maybe Prism2 (i.e., support from Host AP driver) would be a good example of a firmware-based design, so those could be the easiest low-level drivers to get available using Devicescape 802.11 code. Getting ipw2x00 working with some kind of mix of the 802.11 stacks would be good think to do in order to make it easier to maintain existing functionality if larger changes for net/ieee80211 code is desired. My goal is to get something into kernel tree that allows all types of chipset designs to benefit from the same implementation of 802.11 functionality. I'm not sure what would be the best way to achieve this quickly, but I have to admit that I would prefer the design used in Devicescape implementation over the code that is currently in Linux 2.6 tree. I need to take a closer look at what could be done to merge the 802.11 code in a way that would not break existing in-tree drivers that are using net/ieee80211 (i.e., mainly ipw2x00). I'm afraid quite large changes will be needed to make the current in-tree code more usable for devices that use very minimal firmware or no firmware at all. In addition, the issue of dropping AP code from Host AP when merging in the version that ipw2x00 was using needs more attention when deciding what kind of design would allow all drivers to work with shared IEEE 802.11 stack. -- Jouni MalinenPGP id EFC895FA - 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: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)
On Wed, Nov 23, 2005 at 09:24:05AM -0500, jamal wrote: Well, thats certainly one way. Then the oper state machines you are working on + stacking will work well. But this depends on if you can justify the reason for those virtual devices. With wireless you can probably justify to map the radio layer to a virtual device if you have a card that has multiple radios; i dont know how it would work if you join different access points (and each requiring authentication phase) with a standard 802.11 - someone told me a while back, this may be common for mobility so that handoff from one access point to another is easier. The case where one radio in client mode is associating with multiple APs is usually done by having multiple virtual netdevs, i.e., one for each association. At least that's the way I have implemented it and seen another implementation using the same design. In that way, supplicant doesn't even need to know about these associations being done through the same radio and it can just handle them as it would take care of multiple radios. -- Jouni MalinenPGP id EFC895FA - 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: [2.6 patch] rename hostap.c to hostap_main.c
On Sun, Nov 06, 2005 at 01:53:43AM +0100, Adrian Bunk wrote:
I wanted to remove the #include hostap_ioctl.c from hostap.c and build
hostap_ioctl.c separately, but this doesn't work since hostap.c has the
same name as the module.
Is this patch changing anything in hostap.c or is it just a rename of
the file? Patch file is not exactly ideal for this kind of changes and I
hope git has a better way of storing this kind of rename.
I would rather not rename the file, but if this is the only way of
getting the module built in pieces, I'm okay with the change (assuming
nothing else changed in hostap.c in this changeset).
+++ linux-2.6.14-rc5-mm1-full/drivers/net/wireless/hostap/Makefile
2005-11-06 00:14:57.0 +0100
@@ -1,5 +1,7 @@
-obj-$(CONFIG_HOSTAP_CS) += hostap_cs.o
-obj-$(CONFIG_HOSTAP_PLX) += hostap_plx.o
-obj-$(CONFIG_HOSTAP_PCI) += hostap_pci.o
+obj-$(CONFIG_HOSTAP) += hostap.o
+
+obj-$(CONFIG_HOSTAP_CS) += hostap_cs.o
+obj-$(CONFIG_HOSTAP_PLX) += hostap_plx.o
+obj-$(CONFIG_HOSTAP_PCI) += hostap_pci.o
Why were the hostap_{cs,plx,pci} lines changed? I prefer the original
version of those lines (i.e., no extra padding).
--
Jouni MalinenPGP id EFC895FA
-
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 2/2] [NETFILTER] remove bogus hand-coded htonll()
On Sat, Sep 03, 2005 at 10:43:15AM +0200, Harald Welte wrote:
htonll() is nothing else than cpu_to_be64(), so we'd rather call the
latter.
Actually, the htonll() implementation does not seem to be doing what
cpu_to_be64() is doing.. However, I would assume this is a bug in
htonll() and this change to use cpu_to_be64() is fixing that. Can this
bug cause any major problems in the current implementation?
-u_int64_t htonll(u_int64_t in)
-{
- u_int64_t out;
- int i;
-
- for (i = 0; i sizeof(u_int64_t); i++)
- ((u_int8_t *)out)[sizeof(u_int64_t)-1] = ((u_int8_t *)in)[i];
I would assume that the first index should have had '-i' added to it, if
the purpose is to swap byte order.. The code here is leaving some
arbitrary data in 7 bytes of the 64-bit variable and setting
(u8*)out[7] = (u8*)in[7] in somewhat inefficient way ;-). In addition,
this looks more like swap-8-bytes-unconditionally than doing this based
on host byte order..
--
Jouni MalinenPGP id EFC895FA
-
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: ifplugd (was: Re: ieee80211 patches)
On Fri, Sep 02, 2005 at 10:34:03AM -0700, Jean Tourrilhes wrote: Another part of the problem is that the notion of carrier detection only apply to some technology (mostly Ethernet). With Wireless, there is no notion of carrier. You can somewhat *emulate* it using the association, but that work only in Managed mode. If you are in Ad-Hoc or Master mode, there is simply *no* way to emulate any carrier sense. Even in Managed mode, this is somewhat limited to plaintext and static WEP configurations. With IEEE 802.1X and WPA, the situation gets somewhat more complex. EAPOL frames need to be sent after the association, but no other data frames are allowed before full authentication has been completed. I would like to see things like DHCP client being started (or kicked to actually do something) when the authentication has been completed, not before that.. The netdev itself needs to be set UP before authentication, though. -- Jouni MalinenPGP id EFC895FA - 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: ieee80211 patches
On Thu, Sep 01, 2005 at 05:26:07PM +0200, Jiri Benc wrote: The current implementation of ieee80211 as is in ieee80211 branch contains ugly hack so it works with ethernet frames externally (which are internally converted to and from 802.11 frames). Because 802.3 and 802.11 have the same format of MAC address, it is somehow possible - until you get to WDS and similar features. On the other hand, it allows direct bridging between ethernet and 802.11 network. WDS works fine with Ethernet connection. WDS links are point-to-point links with two addresses (RA, TA) coming from the link end-points and two addresses (DA, SA) from the Ethernet frame. One of our patches fixes this so ieee80211 works with 802.11 frames. This breaks bridging for now (uhm... it isn't change in userspace, is it?). Later, the 802.11-802.3 conversion interface will be added to the bridging code where it logically belongs. Please do not break bridging between wlan and Ethernet interface. IEEE 802.11 development really needs to start looking at what is needed for AP (Master) mode and WDS links. Both of these are often used with bridging. I believe that the order here should be to first implement the conversion interface and only after that change to 802.11 frames. In many cases, I'm not even sure that move to 802.11 frames is that good of an idea. Let's at least make sure it does not break more than what is really needed. Things like variable header size (e.g., QoS vs. non-QoS for data frames) is likely to cause problems for many areas. Even if most of the kernel code would handle this (would it?), there are number of important user space programs that may be quite confused since they are used to sending and receiving Ethernet frames with fixed header size. Does this mean that user space programs will need to learn when to include QoS fields in the headers if they are required to send frames for which they need to set both the source and destination MAC addresses (e.g., RSN pre-authentication)? With 802.11-802.3 conversion, these kind of problems are solved by removing the need to know about 802.11 details from user space. -- Jouni MalinenPGP id EFC895FA - 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 ieee80211-wifi 3/5] ieee80211: Fix debug comments ipw-ieee80211
Debug variables and procfs dir should be ieee80211, not ipw. Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: netdev-2.6/include/net/ieee80211.h === --- netdev-2.6.orig/include/net/ieee80211.h +++ netdev-2.6/include/net/ieee80211.h @@ -158,11 +158,11 @@ const char *escape_essid(const char *ess * * To add your debug level to the list of levels seen when you perform * - * % cat /proc/net/ipw/debug_level + * % cat /proc/net/ieee80211/debug_level * - * you simply need to add your entry to the ipw_debug_levels array. + * you simply need to add your entry to the ieee80211_debug_level array. * - * If you do not see debug_level in /proc/net/ipw then you do not have + * If you do not see debug_level in /proc/net/ieee80211 then you do not have * CONFIG_IEEE80211_DEBUG defined in your kernel configuration * */ -- -- Jouni MalinenPGP id EFC895FA - 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 ieee80211-wifi 1/5] ieee80211: Remove WIRELESS_EXT 17 support
No need to maintain support for WIRELESS_EXT 17 since this kernel tree is already using WIRELESS_EXT 18. Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: netdev-2.6/include/net/ieee80211.h === --- netdev-2.6.orig/include/net/ieee80211.h +++ netdev-2.6/include/net/ieee80211.h @@ -24,15 +24,6 @@ #include linux/kernel.h /* ARRAY_SIZE */ #include linux/wireless.h -#if WIRELESS_EXT 17 -#define IW_QUAL_QUAL_INVALID 0x10 -#define IW_QUAL_LEVEL_INVALID 0x20 -#define IW_QUAL_NOISE_INVALID 0x40 -#define IW_QUAL_QUAL_UPDATED 0x1 -#define IW_QUAL_LEVEL_UPDATED 0x2 -#define IW_QUAL_NOISE_UPDATED 0x4 -#endif - #define IEEE80211_DATA_LEN 2304 /* Maximum size for the MA-UNITDATA primitive, 802.11 standard section 6.2.1.1.2. -- -- Jouni MalinenPGP id EFC895FA - 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 ieee80211-wifi 4/5] hostap: Update version
Version 0.4.4 of Host AP driver was released, so let's sync the version number in netdev-2.6 tree. Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: netdev-2.6/drivers/net/wireless/hostap/hostap_config.h === --- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_config.h +++ netdev-2.6/drivers/net/wireless/hostap/hostap_config.h @@ -1,7 +1,7 @@ #ifndef HOSTAP_CONFIG_H #define HOSTAP_CONFIG_H -#define PRISM2_VERSION 0.4.1-kernel +#define PRISM2_VERSION 0.4.4-kernel /* In the previous versions of Host AP driver, support for user space version * of IEEE 802.11 management (hostapd) used to be disabled in the default -- -- Jouni MalinenPGP id EFC895FA - 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 ieee80211-wifi 2/5] ieee80211: Remove EAPOL debug
IEEE 802.11 code has no business touching payloads of EAPOL frames.
There are some EAPOL structures defined for debugging and these were
confusingly called EAP types which they are not. Let's just remove these
before someone else starts using them in the kernel.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: netdev-2.6/include/net/ieee80211.h
===
--- netdev-2.6.orig/include/net/ieee80211.h
+++ netdev-2.6/include/net/ieee80211.h
@@ -56,35 +56,6 @@ struct ieee80211_hdr_3addr {
__le16 seq_ctl;
} __attribute__ ((packed));
-enum eap_type {
- EAP_PACKET = 0,
- EAPOL_START,
- EAPOL_LOGOFF,
- EAPOL_KEY,
- EAPOL_ENCAP_ASF_ALERT
-};
-
-static const char *eap_types[] = {
- [EAP_PACKET]= EAP-Packet,
- [EAPOL_START] = EAPOL-Start,
- [EAPOL_LOGOFF] = EAPOL-Logoff,
- [EAPOL_KEY] = EAPOL-Key,
- [EAPOL_ENCAP_ASF_ALERT] = EAPOL-Encap-ASF-Alert
-};
-
-static inline const char *eap_get_type(int type)
-{
- return (type = ARRAY_SIZE(eap_types)) ? Unknown : eap_types[type];
-}
-
-struct eapol {
- u8 snap[6];
- __be16 ethertype;
- u8 version;
- u8 type;
- __be16 length;
-} __attribute__ ((packed));
-
#define IEEE80211_1ADDR_LEN 10
#define IEEE80211_2ADDR_LEN 16
#define IEEE80211_3ADDR_LEN 24
@@ -202,7 +173,6 @@ const char *escape_essid(const char *ess
#define IEEE80211_DL_STATE (13)
#define IEEE80211_DL_MGMT (14)
#define IEEE80211_DL_FRAG (15)
-#define IEEE80211_DL_EAP (16)
#define IEEE80211_DL_DROP (17)
#define IEEE80211_DL_TX(18)
@@ -217,7 +187,6 @@ const char *escape_essid(const char *ess
#define IEEE80211_DEBUG_STATE(f, a...) IEEE80211_DEBUG(IEEE80211_DL_STATE, f,
## a)
#define IEEE80211_DEBUG_MGMT(f, a...) IEEE80211_DEBUG(IEEE80211_DL_MGMT, f,
## a)
#define IEEE80211_DEBUG_FRAG(f, a...) IEEE80211_DEBUG(IEEE80211_DL_FRAG, f,
## a)
-#define IEEE80211_DEBUG_EAP(f, a...) IEEE80211_DEBUG(IEEE80211_DL_EAP, f, ##
a)
#define IEEE80211_DEBUG_DROP(f, a...) IEEE80211_DEBUG(IEEE80211_DL_DROP, f,
## a)
#define IEEE80211_DEBUG_TX(f, a...) IEEE80211_DEBUG(IEEE80211_DL_TX, f, ## a)
#define IEEE80211_DEBUG_RX(f, a...) IEEE80211_DEBUG(IEEE80211_DL_RX, f, ## a)
Index: netdev-2.6/net/ieee80211/ieee80211_rx.c
===
--- netdev-2.6.orig/net/ieee80211/ieee80211_rx.c
+++ netdev-2.6/net/ieee80211/ieee80211_rx.c
@@ -628,14 +628,8 @@ int ieee80211_rx(struct ieee80211_device
if (crypt !(fc IEEE80211_FCTL_PROTECTED) !ieee-open_wep) {
if (/*ieee-ieee802_1x */
ieee80211_is_eapol_frame(ieee, skb)) {
-#ifdef CONFIG_IEEE80211_DEBUG
/* pass unencrypted EAPOL frames even if encryption is
* configured */
- struct eapol *eap = (struct eapol *)(skb-data +
- 24);
- IEEE80211_DEBUG_EAP(RX: IEEE 802.1X EAPOL frame: %s\n,
- eap_get_type(eap-type));
-#endif
} else {
IEEE80211_DEBUG_DROP(
encryption configured, but RX
@@ -645,16 +639,6 @@ int ieee80211_rx(struct ieee80211_device
}
}
-#ifdef CONFIG_IEEE80211_DEBUG
- if (crypt !(fc IEEE80211_FCTL_PROTECTED)
- ieee80211_is_eapol_frame(ieee, skb)) {
- struct eapol *eap = (struct eapol *)(skb-data +
- 24);
- IEEE80211_DEBUG_EAP(RX: IEEE 802.1X EAPOL frame: %s\n,
- eap_get_type(eap-type));
- }
-#endif
-
if (crypt !(fc IEEE80211_FCTL_PROTECTED) !ieee-open_wep
!ieee80211_is_eapol_frame(ieee, skb)) {
IEEE80211_DEBUG_DROP(
Index: netdev-2.6/net/ieee80211/ieee80211_tx.c
===
--- netdev-2.6.orig/net/ieee80211/ieee80211_tx.c
+++ netdev-2.6/net/ieee80211/ieee80211_tx.c
@@ -292,15 +292,6 @@ int ieee80211_xmit(struct sk_buff *skb,
goto success;
}
-#ifdef CONFIG_IEEE80211_DEBUG
- if (crypt !encrypt ether_type == ETH_P_PAE) {
- struct eapol *eap = (struct eapol *)(skb-data +
- sizeof(struct ethhdr) - SNAP_SIZE - sizeof(u16));
- IEEE80211_DEBUG_EAP(TX: IEEE 802.11 EAPOL frame: %s\n,
- eap_get_type(eap-type));
- }
-#endif
-
/* Save source and destination addresses */
memcpy(dest, skb-data, ETH_ALEN);
memcpy(src, skb-data+ETH_ALEN, ETH_ALEN);
--
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe netdev
[PATCH ieee80211-wifi 5/5] hostap: Fix hash values for product strings
hostap_cs: 0.4.1-kernel (Jouni Malinen [EMAIL PROTECTED]) pcmcia: hostap_cs: invalid hash for product string BUFFALO: is 0x1b01a57b, should be 0x2decece3 pcmcia: see Documentation/pcmcia/devicetable.txt for details pcmcia: hostap_cs: invalid hash for product string WLI-CF-S11G: is 0xefd5102a, should be 0x82067c18 pcmcia: see Documentation/pcmcia/devicetable.txt for details This patch fixes them. Signed-off-by: Kalle Valo [EMAIL PROTECTED] Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: netdev-2.6/drivers/net/wireless/hostap/hostap_cs.c === --- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_cs.c +++ netdev-2.6/drivers/net/wireless/hostap/hostap_cs.c @@ -987,7 +987,7 @@ static struct pcmcia_device_id hostap_cs SMC, SMC2632W, Version 01.02, 0xc4f8b18b, 0x474a1f2a, 0x4b74baa0), PCMCIA_DEVICE_PROD_ID12(BUFFALO, WLI-CF-S11G, - 0x1b01a57b, 0xefd5102a), + 0x2decece3, 0x82067c18), PCMCIA_DEVICE_PROD_ID12(Compaq, WL200_11Mbps_Wireless_PCI_Card, 0x54f7c49c, 0x15a75e5b), PCMCIA_DEVICE_PROD_ID12(INTERSIL, HFA384x/IEEE, -- -- Jouni MalinenPGP id EFC895FA - 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] hostap: Fix null pointer dereference in prism2_pccard_card_present()
On Sun, Aug 28, 2005 at 07:26:12PM -0400, Jeff Garzik wrote: applied, but let us know when the root cause is found... local-hw_priv was initialized only after the interrupt handler was registered. This could trigger a NULL pointer dereference in prism2_pccard_card_present() that assumed that local-hw_priv is always set (and it should have been). Fix this by setting local-hw_priv before registering the interrupt handler. Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: netdev-2.6/drivers/net/wireless/hostap/hostap_cs.c === --- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_cs.c +++ netdev-2.6/drivers/net/wireless/hostap/hostap_cs.c @@ -772,6 +772,13 @@ static int prism2_config(dev_link_t *lin goto failed; link-priv = dev; + iface = netdev_priv(dev); + local = iface-local; + local-hw_priv = hw_priv; + hw_priv-link = link; + strcpy(hw_priv-node.dev_name, dev-name); + link-dev = hw_priv-node; + /* * Allocate an interrupt line. Note that this does not assign a * handler to the interrupt, unless the 'Handler' member of the @@ -817,13 +824,6 @@ static int prism2_config(dev_link_t *lin link-state |= DEV_CONFIG; link-state = ~DEV_CONFIG_PENDING; - iface = netdev_priv(dev); - local = iface-local; - local-hw_priv = hw_priv; - hw_priv-link = link; - strcpy(hw_priv-node.dev_name, dev-name); - link-dev = hw_priv-node; - local-shutdown = 0; sandisk_enable_wireless(dev); -- Jouni MalinenPGP id EFC895FA - 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 ieee80211-wifi 3/9] hostap: Use void *hw_priv instead of #ifdef in local data
Replace hardware model specific #ifdef's in struct local_info with
void *hw_priv that is pointing to cs/pci/plx specific data
structure. This removes unneeded #ifdef's and as such, is a step
towards making it possible to share objects for hostap_hw.c and
hostap_download.c with cs/pci/plx drivers without having to compile
and link the same code separately for each one.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_cs.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_cs.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_cs.c
@@ -40,6 +40,14 @@ module_param(ignore_cis_vcc, int, 0444);
MODULE_PARM_DESC(ignore_cis_vcc, Ignore broken CIS VCC entry);
+/* struct local_info::hw_priv */
+struct hostap_cs_priv {
+ dev_node_t node;
+ dev_link_t *link;
+ int sandisk_connectplus;
+};
+
+
#ifdef PRISM2_IO_DEBUG
static inline void hfa384x_outb_debug(struct net_device *dev, int a, u8 v)
@@ -203,8 +211,9 @@ static int prism2_event(event_t event, i
static int prism2_pccard_card_present(local_info_t *local)
{
- if (local-link != NULL
- ((local-link-state (DEV_PRESENT | DEV_CONFIG)) ==
+ struct hostap_cs_priv *hw_priv = local-hw_priv;
+ if (hw_priv-link != NULL
+ ((hw_priv-link-state (DEV_PRESENT | DEV_CONFIG)) ==
(DEV_PRESENT | DEV_CONFIG)))
return 1;
return 0;
@@ -224,12 +233,14 @@ static void sandisk_set_iobase(local_inf
{
int res;
conf_reg_t reg;
+ struct hostap_cs_priv *hw_priv = local-hw_priv;
reg.Function = 0;
reg.Action = CS_WRITE;
reg.Offset = 0x10; /* 0x3f0 IO base 1 */
- reg.Value = local-link-io.BasePort1 0x00ff;
- res = pcmcia_access_configuration_register(local-link-handle, reg);
+ reg.Value = hw_priv-link-io.BasePort1 0x00ff;
+ res = pcmcia_access_configuration_register(hw_priv-link-handle,
+ reg);
if (res != CS_SUCCESS) {
printk(KERN_DEBUG Prism3 SanDisk - failed to set I/O base 0 -
res=%d\n, res);
@@ -239,8 +250,9 @@ static void sandisk_set_iobase(local_inf
reg.Function = 0;
reg.Action = CS_WRITE;
reg.Offset = 0x12; /* 0x3f2 IO base 2 */
- reg.Value = (local-link-io.BasePort1 0xff00) 8;
- res = pcmcia_access_configuration_register(local-link-handle, reg);
+ reg.Value = (hw_priv-link-io.BasePort1 0xff00) 8;
+ res = pcmcia_access_configuration_register(hw_priv-link-handle,
+ reg);
if (res != CS_SUCCESS) {
printk(KERN_DEBUG Prism3 SanDisk - failed to set I/O base 1 -
res=%d\n, res);
@@ -272,8 +284,9 @@ static int sandisk_enable_wireless(struc
tuple_t tuple;
cisparse_t *parse = NULL;
u_char buf[64];
+ struct hostap_cs_priv *hw_priv = local-hw_priv;
- if (local-link-io.NumPorts1 0x42) {
+ if (hw_priv-link-io.NumPorts1 0x42) {
/* Not enough ports to be SanDisk multi-function card */
ret = -ENODEV;
goto done;
@@ -290,9 +303,9 @@ static int sandisk_enable_wireless(struc
tuple.TupleData = buf;
tuple.TupleDataMax = sizeof(buf);
tuple.TupleOffset = 0;
- if (pcmcia_get_first_tuple(local-link-handle, tuple) ||
- pcmcia_get_tuple_data(local-link-handle, tuple) ||
- pcmcia_parse_tuple(local-link-handle, tuple, parse) ||
+ if (pcmcia_get_first_tuple(hw_priv-link-handle, tuple) ||
+ pcmcia_get_tuple_data(hw_priv-link-handle, tuple) ||
+ pcmcia_parse_tuple(hw_priv-link-handle, tuple, parse) ||
parse-manfid.manf != 0xd601 || parse-manfid.card != 0x0101) {
/* No SanDisk manfid found */
ret = -ENODEV;
@@ -300,9 +313,9 @@ static int sandisk_enable_wireless(struc
}
tuple.DesiredTuple = CISTPL_LONGLINK_MFC;
- if (pcmcia_get_first_tuple(local-link-handle, tuple) ||
- pcmcia_get_tuple_data(local-link-handle, tuple) ||
- pcmcia_parse_tuple(local-link-handle, tuple, parse) ||
+ if (pcmcia_get_first_tuple(hw_priv-link-handle, tuple) ||
+ pcmcia_get_tuple_data(hw_priv-link-handle, tuple) ||
+ pcmcia_parse_tuple(hw_priv-link-handle, tuple, parse) ||
parse-longlink_mfc.nfn 2) {
/* No multi-function links found */
ret = -ENODEV;
@@ -311,13 +324,14 @@ static int sandisk_enable_wireless(struc
printk(KERN_DEBUG %s: Multi-function SanDisk ConnectPlus detected
- using vendor-specific initialization\n, dev-name);
- local-sandisk_connectplus = 1;
+ hw_priv-sandisk_connectplus = 1;
reg.Function = 0;
reg.Action
[PATCH ieee80211-wifi 2/9] hostap: Remove experimental PCI bus master/DMA code
PCI version of Prism2.5/3 has undocumented DMA support for TX/RX data,
but this seems to have some hardware bugs that prevent it from being
used properly for TX. RX side could possibly be made to work reliably.
Even though DMA support would be very useful for saving host CPU (from
about 40% to 5-10% when operating at maximum throughput), it seems to
be best to just remove this code finally. The implementation has
always been commented out by default and has received very limited
testing. The code may have already been broken number of times and I
don't have much interested in trying to verify whether it works or
not. Getting this out makes it easier to maintain the driver and
allows some cleanups that have been partly postponed because of this
experimental bus master/DMA code.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_wlan.h
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_wlan.h
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_wlan.h
@@ -787,10 +787,6 @@ struct local_info {
struct prism2_helper_functions *func;
- int bus_master_threshold_tx;
- int bus_master_threshold_rx;
- u8 *bus_m1_buf;
-
u8 *pda;
int fw_ap;
#define PRISM2_FW_VER(major, minor, variant) \
@@ -897,14 +893,6 @@ struct local_info {
#ifdef PRISM2_PCI
void __iomem *mem_start;
-#ifdef PRISM2_BUS_MASTER
- /* bus master for BAP0 (TX) */
- int bus_m0_tx_idx;
- u8 *bus_m0_buf;
-
- /* bus master for BAP1 (RX) */
- struct sk_buff *rx_skb;
-#endif /* PRISM2_BUS_MASTER */
#endif /* PRISM2_PCI */
/* NOTE! Do not add common entries here after hardware version
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_common.h
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_common.h
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_common.h
@@ -343,8 +343,8 @@ enum {
PRISM2_PARAM_MONITOR_ALLOW_FCSERR = 16,
PRISM2_PARAM_HOST_ENCRYPT = 17,
PRISM2_PARAM_HOST_DECRYPT = 18,
- PRISM2_PARAM_BUS_MASTER_THRESHOLD_RX = 19,
- PRISM2_PARAM_BUS_MASTER_THRESHOLD_TX = 20,
+ /* PRISM2_PARAM_BUS_MASTER_THRESHOLD_RX = 19, REMOVED 2005-08-14 */
+ /* PRISM2_PARAM_BUS_MASTER_THRESHOLD_TX = 20, REMOVED 2005-08-14 */
PRISM2_PARAM_HOST_ROAMING = 21,
PRISM2_PARAM_BCRX_STA_KEY = 22,
PRISM2_PARAM_IEEE_802_1X = 23,
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_config.h
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_config.h
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_config.h
@@ -13,37 +13,6 @@
/* Maximum number of events handler per one interrupt */
#define PRISM2_MAX_INTERRUPT_EVENTS 20
-/* Use PCI bus master to copy data to/from BAP (only available for
- * hostap_pci.o).
- *
- * Note! This is extremely experimental. PCI bus master is not supported by
- * Intersil and it seems to have some problems at least on TX path (see below).
- * The driver code for implementing bus master support is based on guessing
- * and experimenting suitable control bits and these might not be correct.
- * This code is included because using bus master makes a huge difference in
- * host CPU load (something like 40% host CPU usage to 5-10% when sending or
- * receiving at maximum throughput).
- *
- * Note2! Station firmware version 1.3.5 and primary firmware version 1.0.7
- * have some fixes for PCI corruption and these (or newer) versions are
- * recommended especially when using bus mastering.
- *
- * NOTE: PCI bus mastering code has not been updated for long time and it is
- * not likely to compile and it will _not_ work as is. Only enable this if you
- * are prepared to first fix the implementation..
- */
-/* #define PRISM2_BUS_MASTER */
-
-#ifdef PRISM2_BUS_MASTER
-
-/* PCI bus master implementation seems to be broken in current
- * hardware/firmware versions. Enable this to use enable command to fix
- * something before starting bus master operation on TX path. This will add
- * some latency and an extra interrupt to each TX packet. */
-#define PRISM2_ENABLE_BEFORE_TX_BUS_MASTER
-
-#endif /* PRISM2_BUS_MASTER */
-
/* Include code for downloading firmware images into volatile RAM. */
#define PRISM2_DOWNLOAD_SUPPORT
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_hw.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_hw.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_hw.c
@@ -83,18 +83,6 @@ static int dtim_period[MAX_PARM_DEVICES]
module_param_array(dtim_period, int, NULL, 0444);
MODULE_PARM_DESC(dtim_period, DTIM period);
-#if defined(PRISM2_PCI) defined(PRISM2_BUS_MASTER)
-static int bus_master_threshold_rx[MAX_PARM_DEVICES] = { 100, DEF_INTS
[PATCH ieee80211-wifi 0/9] hostap/ieee80211: hostap update and small changes to ieee80211
This set of patches merges a bug fix for the Host AP driver (patch 1), does some cleanup for different hardware models (patches 2-3), continues conversion to generic ieee80211 code (patches 4-6), and tests how we can handle changes that have a dependency to modify ieee80211 and hostap at the same time (patches 7-9). Please apply to suitable branch(es) in netdev-2.6. Patches 1-6 should be clear enough since they are touching only hostap (ieee80211-wifi). Patch 7 is a fix for ieee80211. Patch 8 is the most complex one: it changes three different components (ieee80211, hostap, ipw2200) due to a renamed define. Patch 9 is for hostap (ieee80211-wifi) only. Is this kind of set of patches ok for you to apply or what would be the best way of dealing with the changes done in patches 7-9? It is ok to apply just patches 1-6 if 7-9 need further changes. PS. I was asked to cc my patches to ieee80211-devel mailing list. The changes here are still mainly for hostap, but there are couple of small changes to net/ieee80211.h and the renamed define affects net/ieee80211 and ipw2200. Please let me know, if this is not suitable for the ieee80211-devel list. -- Jouni MalinenPGP id EFC895FA - 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 ieee80211-wifi 7/9] ieee80211: Fix frame control pver mask
IEEE 802.11 frame control has two bits reserved for protocol
version. IEEE80211_FCTL_VERS was not used anywhere, but I would assume
it was supposed to be a mask for the protocol field and as such, it
should be 0x0003, not 0x0002. This matches with WLAN_FC_PVER
definition in hostap.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: netdev-2.6/include/net/ieee80211.h
===
--- netdev-2.6.orig/include/net/ieee80211.h
+++ netdev-2.6/include/net/ieee80211.h
@@ -103,7 +103,7 @@ struct eapol {
#defineMAX_FRAG_THRESHOLD 2346U
/* Frame control field constants */
-#define IEEE80211_FCTL_VERS0x0002
+#define IEEE80211_FCTL_VERS0x0003
#define IEEE80211_FCTL_FTYPE 0x000c
#define IEEE80211_FCTL_STYPE 0x00f0
#define IEEE80211_FCTL_TODS0x0100
--
--
Jouni MalinenPGP id EFC895FA
-
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 ieee80211-wifi 5/9] hostap: Replace hostap_ieee80211_hdr with ieee80211_hdr
Replace hostap-specific struct hostap_ieee80211_hdr with struct
ieee80211_hdr from net/ieee80211.h.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_80211.h
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_80211.h
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_80211.h
@@ -1,17 +1,6 @@
#ifndef HOSTAP_80211_H
#define HOSTAP_80211_H
-struct hostap_ieee80211_hdr {
- u16 frame_control;
- u16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
- u16 seq_ctrl;
- u8 addr4[6];
-} __attribute__ ((packed));
-
-
struct hostap_ieee80211_mgmt {
u16 frame_control;
u16 duration;
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_80211_rx.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_80211_rx.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_80211_rx.c
@@ -6,10 +6,10 @@
void hostap_dump_rx_80211(const char *name, struct sk_buff *skb,
struct hostap_80211_rx_status *rx_stats)
{
- struct hostap_ieee80211_hdr *hdr;
+ struct ieee80211_hdr *hdr;
u16 fc;
- hdr = (struct hostap_ieee80211_hdr *) skb-data;
+ hdr = (struct ieee80211_hdr *) skb-data;
printk(KERN_DEBUG %s: RX signal=%d noise=%d rate=%d len=%d
jiffies=%ld\n,
@@ -19,7 +19,7 @@ void hostap_dump_rx_80211(const char *na
if (skb-len 2)
return;
- fc = le16_to_cpu(hdr-frame_control);
+ fc = le16_to_cpu(hdr-frame_ctl);
printk(KERN_DEBUGFC=0x%04x (type=%d:%d)%s%s,
fc, HOSTAP_FC_GET_TYPE(fc), HOSTAP_FC_GET_STYPE(fc),
fc WLAN_FC_TODS ? [ToDS] : ,
@@ -31,7 +31,7 @@ void hostap_dump_rx_80211(const char *na
}
printk( dur=0x%04x seq=0x%04x\n, le16_to_cpu(hdr-duration_id),
- le16_to_cpu(hdr-seq_ctrl));
+ le16_to_cpu(hdr-seq_ctl));
printk(KERN_DEBUGA1= MACSTR A2= MACSTR A3= MACSTR,
MAC2STR(hdr-addr1), MAC2STR(hdr-addr2), MAC2STR(hdr-addr3));
@@ -51,7 +51,7 @@ int prism2_rx_80211(struct net_device *d
int hdrlen, phdrlen, head_need, tail_need;
u16 fc;
int prism_header, ret;
- struct hostap_ieee80211_hdr *hdr;
+ struct ieee80211_hdr *hdr;
iface = netdev_priv(dev);
local = iface-local;
@@ -70,8 +70,8 @@ int prism2_rx_80211(struct net_device *d
phdrlen = 0;
}
- hdr = (struct hostap_ieee80211_hdr *) skb-data;
- fc = le16_to_cpu(hdr-frame_control);
+ hdr = (struct ieee80211_hdr *) skb-data;
+ fc = le16_to_cpu(hdr-frame_ctl);
if (type == PRISM2_RX_MGMT (fc WLAN_FC_PVER)) {
printk(KERN_DEBUG %s: dropped management frame with header
@@ -215,21 +215,21 @@ prism2_frag_cache_find(local_info_t *loc
/* Called only as a tasklet (software IRQ) */
static struct sk_buff *
-prism2_frag_cache_get(local_info_t *local, struct hostap_ieee80211_hdr *hdr)
+prism2_frag_cache_get(local_info_t *local, struct ieee80211_hdr *hdr)
{
struct sk_buff *skb = NULL;
u16 sc;
unsigned int frag, seq;
struct prism2_frag_entry *entry;
- sc = le16_to_cpu(hdr-seq_ctrl);
+ sc = le16_to_cpu(hdr-seq_ctl);
frag = WLAN_GET_SEQ_FRAG(sc);
seq = WLAN_GET_SEQ_SEQ(sc) 4;
if (frag == 0) {
/* Reserve enough space to fit maximum frame length */
skb = dev_alloc_skb(local-dev-mtu +
- sizeof(struct hostap_ieee80211_hdr) +
+ sizeof(struct ieee80211_hdr) +
8 /* LLC */ +
2 /* alignment */ +
8 /* WEP */ + ETH_ALEN /* WDS */);
@@ -267,13 +267,13 @@ prism2_frag_cache_get(local_info_t *loca
/* Called only as a tasklet (software IRQ) */
static int prism2_frag_cache_invalidate(local_info_t *local,
- struct hostap_ieee80211_hdr *hdr)
+ struct ieee80211_hdr *hdr)
{
u16 sc;
unsigned int seq;
struct prism2_frag_entry *entry;
- sc = le16_to_cpu(hdr-seq_ctrl);
+ sc = le16_to_cpu(hdr-seq_ctl);
seq = WLAN_GET_SEQ_SEQ(sc) 4;
entry = prism2_frag_cache_find(local, seq, -1, hdr-addr2, hdr-addr1);
@@ -441,7 +441,7 @@ hostap_rx_frame_mgmt(local_info_t *local
u16 stype)
{
if (local-iw_mode == IW_MODE_MASTER) {
- hostap_update_sta_ps(local, (struct hostap_ieee80211_hdr *)
+ hostap_update_sta_ps(local, (struct ieee80211_hdr *)
skb-data);
}
@@ -519,7 +519,7 @@ static inline struct net_device *prism2_
[PATCH ieee80211-wifi 4/9] hostap: Remove extra defines
Remove unused defines that are already available from generic kernel
header files.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_wlan.h
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_wlan.h
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_wlan.h
@@ -18,13 +18,6 @@
* prism2_send_mgmt() sends these with dev_queue_xmit() to prism2_tx(). */
#define ETH_P_HOSTAP ETH_P_CONTROL
-#ifndef ARPHRD_IEEE80211
-#define ARPHRD_IEEE80211 801
-#endif
-#ifndef ARPHRD_IEEE80211_PRISM
-#define ARPHRD_IEEE80211_PRISM 802
-#endif
-
/* ARPHRD_IEEE80211_PRISM uses a bloated version of Prism2 RX frame header
* (from linux-wlan-ng) */
struct linux_wlan_ng_val {
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_common.h
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_common.h
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_common.h
@@ -7,14 +7,6 @@
#define MACSTR %02x:%02x:%02x:%02x:%02x:%02x
-#ifndef ETH_P_PAE
-#define ETH_P_PAE 0x888E /* Port Access Entity (IEEE 802.1X) */
-#endif /* ETH_P_PAE */
-
-#define ETH_P_PREAUTH 0x88C7 /* IEEE 802.11i pre-authentication */
-
-
-
/* IEEE 802.11 defines */
#define WLAN_FC_PVER (BIT(1) | BIT(0))
--
--
Jouni MalinenPGP id EFC895FA
-
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 ieee80211-wifi 2/3] hostap: Capability field is called ESS, not BSS
Remove backwards compatibility define for WLAN_CAPABILITY_ESS now that net/ieee80211.h defines this. Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: netdev-2.6/drivers/net/wireless/hostap/hostap_common.h === --- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_common.h +++ netdev-2.6/drivers/net/wireless/hostap/hostap_common.h @@ -19,9 +19,6 @@ #define WLAN_FC_ISWEP BIT(14) #define WLAN_FC_ORDER BIT(15) -#define WLAN_CAPABILITY_ESS WLAN_CAPABILITY_BSS - - /* Information Element IDs */ #define WLAN_EID_SSID 0 #define WLAN_EID_SUPP_RATES 1 -- -- Jouni MalinenPGP id EFC895FA - 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 02/12] hostap update
From: Adrian Bunk [EMAIL PROTECTED] EXPORT_SYMTAB does nothing. There's no need to define something if it doesn't have any effect. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: netdev-2.6/drivers/net/wireless/hostap/hostap.c === --- netdev-2.6.orig/drivers/net/wireless/hostap/hostap.c +++ netdev-2.6/drivers/net/wireless/hostap/hostap.c @@ -12,10 +12,6 @@ * more details. */ -#ifndef EXPORT_SYMTAB -#define EXPORT_SYMTAB -#endif - #include linux/config.h #include linux/version.h #include linux/module.h -- -- Jouni MalinenPGP id EFC895FA - 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 00/12] hostap update
This set of patches updates Host AP driver in the ieee80211-wifi branch of the netdev-2.6 git tree with changes from my CVS repository and from additional contributed patches from the past couple of months. Please apply to the suitable branch(es) in netdev-2.6. -- Jouni MalinenPGP id EFC895FA - 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 06/12] hostap update
Add MODULE_VERSION information for the Host AP kernel modules and
update the version string to indicate which version of the external
Host AP driver is included in the kernel tree.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/wireless/hostap/hostap.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap.c
@@ -37,6 +37,7 @@
MODULE_AUTHOR(Jouni Malinen);
MODULE_DESCRIPTION(Host AP common routines);
MODULE_LICENSE(GPL);
+MODULE_VERSION(PRISM2_VERSION);
/* Old hostap_crypt module is now part of hostap module. */
#include hostap_crypt.c
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_crypt_ccmp.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_crypt_ccmp.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_crypt_ccmp.c
@@ -36,6 +36,7 @@
MODULE_AUTHOR(Jouni Malinen);
MODULE_DESCRIPTION(Host AP crypt: CCMP);
MODULE_LICENSE(GPL);
+MODULE_VERSION(PRISM2_VERSION);
#define AES_BLOCK_LEN 16
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_crypt_tkip.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_crypt_tkip.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_crypt_tkip.c
@@ -38,6 +38,7 @@
MODULE_AUTHOR(Jouni Malinen);
MODULE_DESCRIPTION(Host AP crypt: TKIP);
MODULE_LICENSE(GPL);
+MODULE_VERSION(PRISM2_VERSION);
struct hostap_tkip_data {
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_crypt_wep.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_crypt_wep.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_crypt_wep.c
@@ -19,6 +19,7 @@
#include asm/string.h
#include hostap_crypt.h
+#include hostap_config.h
#ifndef CONFIG_CRYPTO
#error CONFIG_CRYPTO is required to build this module.
@@ -30,6 +31,7 @@
MODULE_AUTHOR(Jouni Malinen);
MODULE_DESCRIPTION(Host AP crypt: WEP);
MODULE_LICENSE(GPL);
+MODULE_VERSION(PRISM2_VERSION);
struct prism2_wep_data {
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_cs.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_cs.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_cs.c
@@ -32,6 +32,7 @@ MODULE_DESCRIPTION(Support for Intersil
cards (PC Card).);
MODULE_SUPPORTED_DEVICE(Intersil Prism2-based WLAN cards (PC Card));
MODULE_LICENSE(GPL);
+MODULE_VERSION(PRISM2_VERSION);
static int ignore_cis_vcc;
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_pci.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_pci.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_pci.c
@@ -31,6 +31,7 @@ MODULE_DESCRIPTION(Support for Intersil
PCI cards.);
MODULE_SUPPORTED_DEVICE(Intersil Prism2.5-based WLAN PCI cards);
MODULE_LICENSE(GPL);
+MODULE_VERSION(PRISM2_VERSION);
/* FIX: do we need mb/wmb/rmb with memory operations? */
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_plx.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_plx.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_plx.c
@@ -34,6 +34,7 @@ MODULE_DESCRIPTION(Support for Intersil
cards (PLX).);
MODULE_SUPPORTED_DEVICE(Intersil Prism2-based WLAN cards (PLX));
MODULE_LICENSE(GPL);
+MODULE_VERSION(PRISM2_VERSION);
static int ignore_cis;
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_config.h
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_config.h
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_config.h
@@ -1,7 +1,7 @@
#ifndef HOSTAP_CONFIG_H
#define HOSTAP_CONFIG_H
-#define PRISM2_VERSION CVS
+#define PRISM2_VERSION 0.4.1-kernel
/* In the previous versions of Host AP driver, support for user space version
* of IEEE 802.11 management (hostapd) used to be disabled in the default
--
--
Jouni MalinenPGP id EFC895FA
-
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 07/12] hostap update
Added support for setting channel mask for scan requests
('iwpriv wlan0 scan_channels 0x00ff' masks scans to use channels 1-8).
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_common.h
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_common.h
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_common.h
@@ -423,6 +423,7 @@ enum {
PRISM2_PARAM_PRIVACY_INVOKED = 37,
PRISM2_PARAM_TKIP_COUNTERMEASURES = 38,
PRISM2_PARAM_DROP_UNENCRYPTED = 39,
+ PRISM2_PARAM_SCAN_CHANNEL_MASK = 40,
};
enum { HOSTAP_ANTSEL_DO_NOT_TOUCH = 0, HOSTAP_ANTSEL_DIVERSITY = 1,
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_hw.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_hw.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_hw.c
@@ -3374,6 +3374,7 @@ prism2_init_local_data(struct prism2_hel
* cnfDbmAdjust, if available */
local-auth_algs = PRISM2_AUTH_OPEN | PRISM2_AUTH_SHARED_KEY;
local-sram_type = -1;
+ local-scan_channel_mask = 0x;
#if defined(PRISM2_PCI) defined(PRISM2_BUS_MASTER)
local-bus_master_threshold_rx = GET_INT_PARM(bus_master_threshold_rx,
card_idx);
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_ioctl.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_ioctl.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_ioctl.c
@@ -1664,7 +1664,8 @@ static int prism2_request_hostscan(struc
local = iface-local;
memset(scan_req, 0, sizeof(scan_req));
- scan_req.channel_list = __constant_cpu_to_le16(local-channel_mask);
+ scan_req.channel_list = cpu_to_le16(local-channel_mask
+ local-scan_channel_mask);
scan_req.txrate = __constant_cpu_to_le16(HFA384X_RATES_1MBPS);
if (ssid) {
if (ssid_len 32)
@@ -1693,7 +1694,8 @@ static int prism2_request_scan(struct ne
local = iface-local;
memset(scan_req, 0, sizeof(scan_req));
- scan_req.channel_list = __constant_cpu_to_le16(local-channel_mask);
+ scan_req.channel_list = cpu_to_le16(local-channel_mask
+ local-scan_channel_mask);
scan_req.txrate = __constant_cpu_to_le16(HFA384X_RATES_1MBPS);
/* FIX:
@@ -2338,6 +2340,10 @@ static const struct iw_priv_args prism2_
IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, drop_unencrypte },
{ PRISM2_PARAM_DROP_UNENCRYPTED,
0, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, getdrop_unencry },
+ { PRISM2_PARAM_SCAN_CHANNEL_MASK,
+ IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, scan_channels },
+ { PRISM2_PARAM_SCAN_CHANNEL_MASK,
+ 0, IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, getscan_channel },
};
@@ -2699,6 +2705,10 @@ static int prism2_ioctl_priv_prism2_para
local-drop_unencrypted = value;
break;
+ case PRISM2_PARAM_SCAN_CHANNEL_MASK:
+ local-scan_channel_mask = value;
+ break;
+
default:
printk(KERN_DEBUG %s: prism2_param: unknown param %d\n,
dev-name, param);
@@ -2890,6 +2900,10 @@ static int prism2_ioctl_priv_get_prism2_
*param = local-drop_unencrypted;
break;
+ case PRISM2_PARAM_SCAN_CHANNEL_MASK:
+ *param = local-scan_channel_mask;
+ break;
+
default:
printk(KERN_DEBUG %s: get_prism2_param: unknown param %d\n,
dev-name, *param);
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_wlan.h
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_wlan.h
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_wlan.h
@@ -680,7 +680,8 @@ struct local_info {
char essid[MAX_SSID_LEN + 1];
char name[MAX_NAME_LEN + 1];
int name_set;
- u16 channel_mask;
+ u16 channel_mask; /* mask of allowed channels */
+ u16 scan_channel_mask; /* mask of channels to be scanned */
struct comm_tallies_sums comm_tallies;
struct net_device_stats stats;
struct proc_dir_entry *proc;
--
--
Jouni MalinenPGP id EFC895FA
-
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 10/12] hostap update
From: Brandon Enochs [EMAIL PROTECTED] line 129 of hostap_80211_rx.c should read: LWNG_SETVAL(mactime, 2, 0, 4, rx_stats-mac_time); not: LWNG_SETVAL(mactime, 2, 0, 0, rx_stats-mac_time); The length field is incorrect. Signed-off-by: Jouni Malinen [EMAIL PROTECTED] Index: netdev-2.6/drivers/net/wireless/hostap/hostap_80211_rx.c === --- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_80211_rx.c +++ netdev-2.6/drivers/net/wireless/hostap/hostap_80211_rx.c @@ -123,7 +123,7 @@ int prism2_rx_80211(struct net_device *d hdr-f.did = LWNG_CAP_DID_BASE | (i 12); \ hdr-f.status = s; hdr-f.len = l; hdr-f.data = d LWNG_SETVAL(hosttime, 1, 0, 4, jiffies); - LWNG_SETVAL(mactime, 2, 0, 0, rx_stats-mac_time); + LWNG_SETVAL(mactime, 2, 0, 4, rx_stats-mac_time); LWNG_SETVAL(channel, 3, 1 /* no value */, 4, 0); LWNG_SETVAL(rssi, 4, 1 /* no value */, 4, 0); LWNG_SETVAL(sq, 5, 1 /* no value */, 4, 0); -- -- Jouni MalinenPGP id EFC895FA - 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 08/12] hostap update
Cleaned up scan result processing by converting struct
hfa384x_scan_result into struct hfa384x_hostscan_result. This removes
special cases from result processing since the results are only used
in one, hostscan, format.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_info.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_info.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_info.c
@@ -160,7 +160,7 @@ static void prism2_host_roaming(local_in
{
struct hfa384x_join_request req;
struct net_device *dev = local-dev;
- struct hfa384x_scan_result *selected, *entry;
+ struct hfa384x_hostscan_result *selected, *entry;
int i;
unsigned long flags;
@@ -244,9 +244,10 @@ static void prism2_info_scanresults(loca
int left)
{
u16 *pos;
- int new_count;
+ int new_count, i;
unsigned long flags;
- struct hfa384x_scan_result *results, *prev;
+ struct hfa384x_scan_result *res;
+ struct hfa384x_hostscan_result *results, *prev;
if (left 4) {
printk(KERN_DEBUG %s: invalid scanresult info frame
@@ -260,11 +261,18 @@ static void prism2_info_scanresults(loca
left -= 4;
new_count = left / sizeof(struct hfa384x_scan_result);
- results = kmalloc(new_count * sizeof(struct hfa384x_scan_result),
+ results = kmalloc(new_count * sizeof(struct hfa384x_hostscan_result),
GFP_ATOMIC);
if (results == NULL)
return;
- memcpy(results, pos, new_count * sizeof(struct hfa384x_scan_result));
+
+ /* Convert to hostscan result format. */
+ res = (struct hfa384x_scan_result *) pos;
+ for (i = 0; i new_count; i++) {
+ memcpy(results[i], res[i],
+ sizeof(struct hfa384x_scan_result));
+ results[i].atim = 0;
+ }
spin_lock_irqsave(local-lock, flags);
local-last_scan_type = PRISM2_SCAN;
@@ -335,9 +343,9 @@ static void prism2_info_hostscanresults(
spin_lock_irqsave(local-lock, flags);
local-last_scan_type = PRISM2_HOSTSCAN;
- prev = local-last_hostscan_results;
- local-last_hostscan_results = results;
- local-last_hostscan_results_count = new_count;
+ prev = local-last_scan_results;
+ local-last_scan_results = results;
+ local-last_scan_results_count = new_count;
spin_unlock_irqrestore(local-lock, flags);
kfree(prev);
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_ioctl.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_ioctl.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_ioctl.c
@@ -663,7 +663,7 @@ static int hostap_join_ap(struct net_dev
struct hfa384x_join_request req;
unsigned long flags;
int i;
- struct hfa384x_scan_result *entry;
+ struct hfa384x_hostscan_result *entry;
iface = netdev_priv(dev);
local = iface-local;
@@ -1795,10 +1795,8 @@ static int prism2_ioctl_siwscan(struct n
#ifndef PRISM2_NO_STATION_MODES
static char * __prism2_translate_scan(local_info_t *local,
- struct hfa384x_scan_result *scan,
- struct hfa384x_hostscan_result *hscan,
- int hostscan,
- struct hostap_bss_info *bss, u8 *bssid,
+ struct hfa384x_hostscan_result *scan,
+ struct hostap_bss_info *bss,
char *current_ev, char *end_buf)
{
int i, chan;
@@ -1806,17 +1804,18 @@ static char * __prism2_translate_scan(lo
char *current_val;
u16 capabilities;
u8 *pos;
- u8 *ssid;
+ u8 *ssid, *bssid;
size_t ssid_len;
char *buf;
if (bss) {
ssid = bss-ssid;
ssid_len = bss-ssid_len;
+ bssid = bss-bssid;
} else {
- ssid = hostscan ? hscan-ssid : scan-ssid;
- ssid_len = le16_to_cpu(hostscan ? hscan-ssid_len :
- scan-ssid_len);
+ ssid = scan-ssid;
+ ssid_len = le16_to_cpu(scan-ssid_len);
+ bssid = scan-bssid;
}
if (ssid_len 32)
ssid_len = 32;
@@ -1850,8 +1849,7 @@ static char * __prism2_translate_scan(lo
if (bss) {
capabilities = bss-capab_info;
} else {
- capabilities = le16_to_cpu(hostscan ? hscan-capability :
- scan-capability);
+ capabilities = le16_to_cpu(scan-capability);
}
if (capabilities
Re: [-mm patch] include/net/ieee80211.h must #include linux/wireless.h
On Wed, Jul 27, 2005 at 09:51:00PM +0200, Adrian Bunk wrote: gcc found an (although perhaps harmless) bug: CC net/ieee80211/ieee80211_crypt.o In file included from net/ieee80211/ieee80211_crypt.c:21: include/net/ieee80211.h:26:5: warning: WIRELESS_EXT is not defined +++ linux-2.6.13-rc3-mm1-full/include/net/ieee80211.h 2005-07-22 18:38:10.0 +0200 +#include linux/wireless.h #if WIRELESS_EXT 17 #define IW_QUAL_QUAL_INVALID 0x10 Wouldn't the proper fix be to just remove this backwards compatibility code since WIRELESS_EXT is actually 18 in this tree anyway.. Is there valid need to keep this header file compatible with older kernel versions? -- Jouni MalinenPGP id EFC895FA - 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 ieee80211-wifi 1/2] hostap: Start using net/ieee80211.h
Preparations for starting to use net/ieee80211 instead of private
IEEE 802.11 implementation. Include net/ieee80211.h and
net/ieee80211_crypt.h into files that will be needed these in the
future. Remove duplicate definitions from hostap_common.h and
rename WLAN_FC_GET_{TYPE,STYPE} macros for now sinc net/ieee80211.h
is using incompatible definitions. This will be resolved in the
future by updating Host AP to use the versions that do not shift
type/stype.
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/wireless/hostap/hostap.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap.c
@@ -26,6 +26,8 @@
#include linux/rtnetlink.h
#include linux/wireless.h
#include net/iw_handler.h
+#include net/ieee80211.h
+#include net/ieee80211_crypt.h
#include asm/uaccess.h
#include hostap_wlan.h
@@ -596,7 +598,7 @@ void hostap_dump_rx_header(const char *n
fc = __le16_to_cpu(rx-frame_control);
printk(KERN_DEBUGFC=0x%04x (type=%d:%d) dur=0x%04x seq=0x%04x
data_len=%d%s%s\n,
- fc, WLAN_FC_GET_TYPE(fc), WLAN_FC_GET_STYPE(fc),
+ fc, HOSTAP_FC_GET_TYPE(fc), HOSTAP_FC_GET_STYPE(fc),
__le16_to_cpu(rx-duration_id), __le16_to_cpu(rx-seq_ctrl),
__le16_to_cpu(rx-data_len),
fc WLAN_FC_TODS ? [ToDS] : ,
@@ -625,7 +627,7 @@ void hostap_dump_tx_header(const char *n
fc = __le16_to_cpu(tx-frame_control);
printk(KERN_DEBUGFC=0x%04x (type=%d:%d) dur=0x%04x seq=0x%04x
data_len=%d%s%s\n,
- fc, WLAN_FC_GET_TYPE(fc), WLAN_FC_GET_STYPE(fc),
+ fc, HOSTAP_FC_GET_TYPE(fc), HOSTAP_FC_GET_STYPE(fc),
__le16_to_cpu(tx-duration_id), __le16_to_cpu(tx-seq_ctrl),
__le16_to_cpu(tx-data_len),
fc WLAN_FC_TODS ? [ToDS] : ,
@@ -668,13 +670,13 @@ int hostap_80211_get_hdrlen(u16 fc)
{
int hdrlen = 24;
- switch (WLAN_FC_GET_TYPE(fc)) {
+ switch (HOSTAP_FC_GET_TYPE(fc)) {
case WLAN_FC_TYPE_DATA:
if ((fc WLAN_FC_FROMDS) (fc WLAN_FC_TODS))
hdrlen = 30; /* Addr4 */
break;
case WLAN_FC_TYPE_CTRL:
- switch (WLAN_FC_GET_STYPE(fc)) {
+ switch (HOSTAP_FC_GET_STYPE(fc)) {
case WLAN_FC_STYPE_CTS:
case WLAN_FC_STYPE_ACK:
hdrlen = 10;
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_hw.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_hw.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_hw.c
@@ -48,9 +48,10 @@
#include linux/rtnetlink.h
#include linux/wireless.h
#include net/iw_handler.h
+#include net/ieee80211.h
+#include net/ieee80211_crypt.h
#include asm/irq.h
-
#include hostap_80211.h
#include hostap.h
#include hostap_ap.h
@@ -1890,7 +1891,7 @@ static int prism2_tx_80211(struct sk_buf
hdr_len = 24;
memcpy(txdesc.frame_control, skb-data, hdr_len);
fc = le16_to_cpu(txdesc.frame_control);
- if (WLAN_FC_GET_TYPE(fc) == WLAN_FC_TYPE_DATA
+ if (HOSTAP_FC_GET_TYPE(fc) == WLAN_FC_TYPE_DATA
(fc WLAN_FC_FROMDS) (fc WLAN_FC_TODS) skb-len = 30) {
/* Addr4 */
memcpy(txdesc.addr4, skb-data + hdr_len, ETH_ALEN);
@@ -2521,10 +2522,10 @@ static void prism2_txexc(local_info_t *l
PDEBUG(DEBUG_EXTRA,retry_count=%d tx_rate=%d fc=0x%04x
(%s%s%s::%d%s%s)\n,
txdesc.retry_count, txdesc.tx_rate, fc,
- WLAN_FC_GET_TYPE(fc) == WLAN_FC_TYPE_MGMT ? Mgmt : ,
- WLAN_FC_GET_TYPE(fc) == WLAN_FC_TYPE_CTRL ? Ctrl : ,
- WLAN_FC_GET_TYPE(fc) == WLAN_FC_TYPE_DATA ? Data : ,
- WLAN_FC_GET_STYPE(fc),
+ HOSTAP_FC_GET_TYPE(fc) == WLAN_FC_TYPE_MGMT ? Mgmt : ,
+ HOSTAP_FC_GET_TYPE(fc) == WLAN_FC_TYPE_CTRL ? Ctrl : ,
+ HOSTAP_FC_GET_TYPE(fc) == WLAN_FC_TYPE_DATA ? Data : ,
+ HOSTAP_FC_GET_STYPE(fc),
fc WLAN_FC_TODS ? ToDS : ,
fc WLAN_FC_FROMDS ? FromDS : );
PDEBUG(DEBUG_EXTRA,A1= MACSTR A2= MACSTR A3=
Index: netdev-2.6/drivers/net/wireless/hostap/hostap_80211_rx.c
===
--- netdev-2.6.orig/drivers/net/wireless/hostap/hostap_80211_rx.c
+++ netdev-2.6/drivers/net/wireless/hostap/hostap_80211_rx.c
@@ -21,7 +21,7 @@ void hostap_dump_rx_80211(const char *na
fc = le16_to_cpu(hdr-frame_control);
printk(KERN_DEBUGFC=0x%04x (type=%d:%d)%s%s,
- fc, WLAN_FC_GET_TYPE(fc), WLAN_FC_GET_STYPE(fc),
+ fc, HOSTAP_FC_GET_TYPE(fc), HOSTAP_FC_GET_STYPE(fc),
fc WLAN_FC_TODS ? [ToDS] : ,
fc
