Re: [PATCH 2/7] d80211: add support for SIOCSIWRATE and SIOCGIWRATE
I am sorry for the late response. please read my comment bellow. Jiri Benc wrote: On Thu, 21 Sep 2006 09:59:39 -0700, mabbas wrote: I can not see how does it break per-STA TX rate limit, especially PRISM2_HOSTAPD_SET_RATE_SETS almost doing the same thing. I am not saying the patch is correct I just want to know how to fix it to get it in. As Jouni wrote, it's not useful to change the per-radio rate table. You want to limit the rates you are using to communicate with the current AP while not limiting other virtual interfaces. (Imagine you have the card that is capable to associate to two APs at the same time. You don't want to limit rates for both APs with SIOCSIWRATE.) To do that I think the following is needed: 1. Add 'allowed_rates' field to struct sta_info. It defaults to 0x. (Or perhaps call it 'disabled_rates' and make it default to 0.) Should I add the new field to sta_info or to ieee80211_sub_if_data. If we added to sta_info then it wont be persistent. We will loose SIOCSIWRATE restriction once we associate with new AP. Then in 3 we bitmask sta-curr_rates with ieee80211_sub_if_data::allowed_rates and this will solve the problem for IBSS as well. 2. The SIOCSIWRATE handler: If the interface is not in a STA mode, return -EOPNOTSUPP. Otherwise, modify the allowed_rates field of the sta entry belonging to the current AP. 3. Bitmask sta-curr_rates with sta-allowed_rates (or ~sta-disabled_rates) in various places (ieee80211_ioctl_add_sta, ieee80211_rx_mgmt_assoc_resp, ieee80211_rx_bss_info; please check for other places). In IBSS and AP mode setting this (per-STA, of course, which is not supported by WE, btw.) can be useful as well but it can be done later. Jiri Thanks Mohamed - 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: [d80211 patch 1/1] setting bss freq and phymode using rx_status
actaully we dont even need local-conf.channel. rx_status-channel holds
the channel
we physically received the frame on. channel hold the value from ds. if
they are not equal then
adjust freq. Attached is the modified patch
Signed-off-by: Mohamed Abbas [EMAIL PROTECTED]
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index a933d92..a0746b9 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -1539,12 +1539,12 @@ #endif
}
- bss-hw_mode = local-conf.phymode;
+ bss-hw_mode = rx_status-phymode;
bss-channel = channel;
- bss-freq = local-conf.freq;
- if (channel != local-conf.channel
- (local-conf.phymode == MODE_IEEE80211G ||
- local-conf.phymode == MODE_IEEE80211B)
+ bss-freq = rx_status-freq;
+ if (channel != rx_status-channel
+ (bss-hw_mode == MODE_IEEE80211G ||
+ bss-hw_mode == MODE_IEEE80211B)
channel = 1 channel = 14) {
static const int freq_list[] = {
2412, 2417, 2422, 2427, 2432, 2437, 2442,
[d80211 patch 1/1] setting bss freq and phymode using rx_status
this patch is a replacement for d80211-iwlist-fix.patch. Now we set bss's phymode and freq using rx_status. The low level driver need to set these values. Signed-off-by: Mohamed Abbas [EMAIL PROTECTED] diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c index a933d92..ddbaf14 100644 --- a/net/d80211/ieee80211_sta.c +++ b/net/d80211/ieee80211_sta.c @@ -1539,9 +1539,9 @@ #endif } - bss-hw_mode = local-conf.phymode; + bss-hw_mode = rx_status-phymode; bss-channel = channel; - bss-freq = local-conf.freq; + bss-freq = rx_status-freq; if (channel != local-conf.channel (local-conf.phymode == MODE_IEEE80211G || local-conf.phymode == MODE_IEEE80211B)
Re: [PATCH 1/7] d80211: add SIOCSIWTXPOW, SIOCGIWTXPOW, SIOCSIWPOWER and SIOCGIWPOWER
Jiri Benc wrote:
Hi,
sorry for the long delay.
On Mon, 28 Aug 2006 13:45:18 -0700, mabbas wrote:
[...]
+static int ieee80211_ioctl_siwtxpow(struct net_device *dev,
+ struct iw_request_info *info,
+union iwreq_data *wrqu,
+char *extra)
+{
+ int rc = 0;
+ struct ieee80211_conf *conf = ieee80211_get_hw_conf(dev);
+
+ if (wrqu-txpower.flags != IW_TXPOW_DBM)
+ rc = -EINVAL;
+ else
+ conf-power_level = wrqu-txpower.value;
+
+
+ ieee80211_ioctl_set_radio_enabled(dev, !wrqu-txpower.disabled);
Expecting implicit call of ieee80211_hw_config in
ieee80211_ioctl_set_radio_enabled doesn't look like a good idea. If the
latter function is changed (to call hw_config only if the radio_enabled
field isn't the same as before), the SIOCSIWTXPOW ioctl won't have any
effect.
I'd prefer setting conf-radio_enabled directly and calling of
ieee80211_hw_config explicitly.
Also, always double check that you do error handling correctly (functions
usually return something on purpose). (Hm, I already told you in this
specific case. Please also double check that you haven't missed any comment
before resending patches.)
What about adding a new callback function fot txpower.
ieee80211_hw_config callback still confusing if txpower was
changed for channel change or because the user setting txpower limit.
+ return rc;
+}
+
+static int ieee80211_ioctl_siwpower(struct net_device *dev,
+ struct iw_request_info *info,
+union iwreq_data *wrqu,
+char *extra)
+{
+ struct ieee80211_conf *conf = ieee80211_get_hw_conf(dev);
+
+ if (wrqu-power.disabled) {
+ conf-power_management_enable = 0;
+ if (ieee80211_hw_config(dev))
+ return -EINVAL;
+ return 0;
This is wrong. Return the error code you've got from ieee80211_hw_config.
Ok
+ }
+
+ if (wrqu-power.flags IW_POWER_TYPE)
+ return -EINVAL;
+
+ switch (wrqu-power.flags IW_POWER_MODE) {
+ case IW_POWER_ON: /* If not specified */
+ case IW_POWER_MODE: /* If set all mask */
+ case IW_POWER_ALL_R:/* If explicitely state all */
+ break;
+ default:/* Otherwise we don't support it */
+ return -EINVAL;
+ }
+
+ conf-power_management_enable = 1;
+
+ if (ieee80211_hw_config(dev))
+ return -EINVAL;
Ditto.
Thanks,
Jiri
-
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/7] d80211: add support for SIOCSIWRATE and SIOCGIWRATE
Jiri Benc wrote: On Wed, 30 Aug 2006 10:19:19 -0700, Jouni Malinen wrote: On Mon, Aug 28, 2006 at 01:45:34PM -0700, mabbas wrote: This patch modify d80211 to add SIOCSIWRATE and SIOCGIWRATE commands. this patch almost does the same thing as in PRISM2_HOSTAPD_SET_RATE_SETS. I don't think I would like to get this applied since this seems to be changing the design on how the per-STA TX rate limiting is done in a way that does not match the original design and no justification has been given for that change so far. Some comments below. I agree with Jouni. We definitely want similar feature but it needs to be carefully designed (and no, we are not limited by the limitations of WE). I'm not going to apply the patch. Jiri I can not see how does it break per-STA TX rate limit, especially PRISM2_HOSTAPD_SET_RATE_SETS almost doing the same thing. I am not saying the patch is correct I just want to know how to fix it to get it in. Mohamed - 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 7/7] d80211: getting wrong freq value if we did hardware scan
Jiri Benc wrote:
On Mon, 28 Aug 2006 13:57:28 -0700, mabbas wrote:
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index a933d92..374193e 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -1543,8 +1543,6 @@ #endif
bss-channel = channel;
bss-freq = local-conf.freq;
if (channel != local-conf.channel
- (local-conf.phymode == MODE_IEEE80211G ||
-local-conf.phymode == MODE_IEEE80211B)
channel = 1 channel = 14) {
The patch doesn't look correct. As I already wrote, no hackish guessing of
the phymode from channel numbers, please.
Are there any problems with just using rx_status-phymode instead of
local-conf.phymode (other than drivers don't set that field as that can
be easily fixed)?
Excellent idea here I will fix this patch to use rx_status-phymode if
set otherwise it will use the default algorithm already exist.
Thanks,
Jiri
-
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 5/7] d80211: indicate if unassociate/radio off status
Dan Williams wrote: On Thu, 2006-09-21 at 19:01 +0200, Jiri Benc wrote: On Mon, 28 Aug 2006 13:49:35 -0700, mabbas wrote: This patch indicate unassociated and radio off status in name field NAK. Fix SIOCGIWAP handler instead. Right; the _one_ place anyone should ever have to check for unassociated status is SIOCGIWAP. That's it. Lets not put stuff in two different places. If it's all 0s, all 4s (stupid prism) or all Fs (i forget who does that), it's invalid and you're not connected. About the worst thing we can start doing is having to parse arbitrary strings to find out driver/card status. That's the same problem with hidden which hope DIES DIES DIES with d80211. If the AP is hidden, then it has a _blank_ SSID, not hacked to hidden. For radio off, that may be a legitimate thing that's not covered in WE yet. But isn't that the domain of SIOCGIWPOWER, or is that just used to set PM modes and not return current status? [1] Dan [1] which would seem like an oversight to correct in nl80211 SIOCGIWPOWER is for power save mode it has nothing to do with radio off, we can indicate radio off in txpower field i guess. I have question regarding SIOCGIWAP. if I do #iwconfig ap 00:13:23:87:150:150, wont iwconfig always show 00:13:23:87:150:150 for SIOCGIWAP regardless if we associated or not? can we display blank in this case to indicate not connected? Mohamed Jiri - 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 5/7] d80211: indicate if unassociate/radio off status
Dan Williams wrote: On Thu, 2006-09-21 at 12:47 -0700, mabbas wrote: Dan Williams wrote: On Thu, 2006-09-21 at 19:01 +0200, Jiri Benc wrote: On Mon, 28 Aug 2006 13:49:35 -0700, mabbas wrote: This patch indicate unassociated and radio off status in name field NAK. Fix SIOCGIWAP handler instead. Right; the _one_ place anyone should ever have to check for unassociated status is SIOCGIWAP. That's it. Lets not put stuff in two different places. If it's all 0s, all 4s (stupid prism) or all Fs (i forget who does that), it's invalid and you're not connected. About the worst thing we can start doing is having to parse arbitrary strings to find out driver/card status. That's the same problem with hidden which hope DIES DIES DIES with d80211. If the AP is hidden, then it has a _blank_ SSID, not hacked to hidden. For radio off, that may be a legitimate thing that's not covered in WE yet. But isn't that the domain of SIOCGIWPOWER, or is that just used to set PM modes and not return current status? [1] Dan [1] which would seem like an oversight to correct in nl80211 SIOCGIWPOWER is for power save mode it has nothing to do with radio off, we can indicate radio off in txpower field i guess. I have question regarding SIOCGIWAP. if I do #iwconfig ap 00:13:23:87:150:150, wont iwconfig always show 00:13:23:87:150:150 for SIOCGIWAP regardless if we associated or not? can we display blank in this case to indicate not connected? That's kind a hole in the WE API. In this case, I think, SIOCGIWAP should always return the BSSID of the current association, or none if there is no association. Doing an iwconfig ap xx:xx:xx:xx:xx:xx should make the driver internally locked to that BSSID, such that until you clear that lock, SIOCGIWAP should only show either that BSSID or 00:00:00:00:00:00. SIOCGIWAP should not return a valid BSSID when there is no association. Hopefully nl80211 can fix this omission in WE. Dan I can fix the patch to do just that if we agree on that. Mohamed Jiri - 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 1/7] d80211: add SIOCSIWTXPOW, SIOCGIWTXPOW, SIOCSIWPOWER and SIOCGIWPOWER
Jiri Benc wrote: On Thu, 21 Sep 2006 12:57:01 -0700, mabbas wrote: if the user set txpoer using iwconfig command, the driver will clap all txpower to this value for all available channels if channels original txpower is higher than txpower value. Looks like a job for the stack. If the stack takes care about that and always pass the correct value to a driver, is there still a reason for the driver to know where the request originated from? Jiri if the stack handle it then no need to know. When I call ieee80211_register_hw with driver's channel, rate and txpower info. the txpower values are overwritten by ieee80211_init_client. I get all the txpower info from EEPROMin the NIC and they are different that what d80211 default to. Is there is away to keep the value the driver passed in ieee80211_register_hw? Mohamed - 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: [d80211] connecting to B-mode AP
Simon Barber wrote: Why is it necessary to set phymode to B? - a G client can connect perfectly well to a B AP. We need this information for rate scaling and we need to send the NIC different command depends on the AP connection type. Mohamed Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mabbas Sent: Thursday, September 14, 2006 4:25 PM To: netdev@vger.kernel.org Subject: [d80211] connecting to B-mode AP When I connect to b-mode only AP and then run iwconf it shows it as a G-mode AP. I guess when we set frequency it look through all the modes and set the mode to the first channel it founds. since B and G share the same frequencies it will set phymode to G. How can we force it to set phymode to the AP we are associating with. - 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 - 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 - 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: [d80211] connecting to B-mode AP
I see your point here, although some one will file some bugs against the driver about showing G while associating with B-mode AP. By the way how can you figure if the AP is B/G other than the rates? Simon Barber wrote: But it's not the AP connection type that determines what rates are available - it's the available rate set - this is independent of whether the card is B or G. A G AP may only advertise B rates, even though it's a G AP. I still don't see any need to change the phytype. Simon -Original Message- From: mabbas [mailto:[EMAIL PROTECTED] Sent: Friday, September 15, 2006 10:19 AM To: Simon Barber Cc: netdev@vger.kernel.org Subject: Re: [d80211] connecting to B-mode AP Simon Barber wrote: Why is it necessary to set phymode to B? - a G client can connect perfectly well to a B AP. We need this information for rate scaling and we need to send the NIC different command depends on the AP connection type. Mohamed Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mabbas Sent: Thursday, September 14, 2006 4:25 PM To: netdev@vger.kernel.org Subject: [d80211] connecting to B-mode AP When I connect to b-mode only AP and then run iwconf it shows it as a G-mode AP. I guess when we set frequency it look through all the modes and set the mode to the first channel it founds. since B and G share the same frequencies it will set phymode to G. How can we force it to set phymode to the AP we are associating with. - 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 - 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 - 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 - 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: [d80211] some issues regarding iwconfig parameters sequence
Dan Williams wrote: On Wed, 2006-09-13 at 14:00 -0700, mabbas wrote: Hi I have some problem connecting if I don't follow some parameters sequence in iwconfig command for example if I issues the following # iwconfig wlan0 essid test ap xx:xx:xx:xx:xx:xx #iwconfif wlan0 channel 9 Any reason you don't stick all the commands on one iwconfig line, or why you don't do the channel first? Some operations with WEXT are undefined, and I think command ordering is one of them. However, I believe that the card/driver should be keeping all the attributes set, and any time an attribute changes that would break a current association or operation (like locking the channel), then the card/driver should be restarting association/auth with the new attribute set. the driver/card do not do any authentication itself. d80211 will start the authentication for us and I don't think it is a good idea to redo the same thing that d80211 already has. I don't mind to stick the commands on one iwconfig but still it will break in IBSS if the channel parameter was last and also user will complain about it, I can force it on them. in d80211 if essid and bssid set it will start authentication with default channel and authentication will timeout then after the second command kicks in to tune to the right channel the retry counter of authentication will be at maximum and we wont authenticate, same problem exist for IBSS it will start searching but once we call #iwconfif wlan0 channel 9 this will stop scanning and we stop IBSS searching . I That seems wrong; once you set the channel, d80211 should be resetting the current assoc/auth stuff, and restarting the association with the current parameters/attributes from scratch, but now only on channel 9. WEXT didn't really have a good way to package a full set of association/auth parameters; the commit-handler stuff kind of did that, but if the commands got broken up then the semantics of what happened when were pretty undefined. Dan attached a patch for workaround this problem. I am not sure this is the right way to fix just attached to illustrate the problem. Mohamed - 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 - 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
[d80211] some issues regarding iwconfig parameters sequence
Hi
I have some problem connecting if I don't follow some parameters
sequence in iwconfig command for example if I issues the following
# iwconfig wlan0 essid test ap xx:xx:xx:xx:xx:xx
#iwconfif wlan0 channel 9
in d80211 if essid and bssid set it will start authentication with
default channel and authentication will timeout then after the second
command kicks in to tune to the right channel the retry counter of
authentication will be at maximum and we wont authenticate, same problem
exist for IBSS it will start searching but once we call #iwconfif wlan0
channel 9 this will stop scanning and we stop IBSS searching . I
attached a patch for workaround this problem. I am not sure this is the
right way to fix just attached to illustrate the problem.
Mohamed
Signed-off-by: Mohamed Abbas [EMAIL PROTECTED]
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index 3ffdc5c..9bd385b 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -1852,6 +1852,29 @@ static int ieee80211_ioctl_giwmode(struc
return 0;
}
+#define IEEE80211_AUTH_TIMEOUT (HZ / 5)
+#define IEEE80211_AUTH_MAX_TRIES 3
+#define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
+#define IEEE80211_ASSOC_MAX_TRIES 3
+
+void ieee80211_reset_tries(struct net_device *dev,
+ struct ieee80211_if_sta *ifsta,
+ int was_scanning)
+{
+
+ if ((ifsta-state == IEEE80211_AUTHENTICATE)
+ (ifsta-auth_tries IEEE80211_AUTH_MAX_TRIES)) {
+ ifsta-auth_tries = 0;
+ ifsta-auth_transaction = -1;
+ mod_timer(ifsta-timer, jiffies + IEEE80211_AUTH_TIMEOUT);
+ } else if ((ifsta-assoc_tries IEEE80211_ASSOC_MAX_TRIES)
+ (ifsta-state == IEEE80211_ASSOCIATE)) {
+ ifsta-assoc_tries = 0;
+ mod_timer(ifsta-timer, jiffies + IEEE80211_ASSOC_TIMEOUT);
+ } if (ifsta-state == IEEE80211_IBSS_SEARCH was_scanning)
+ mod_timer(ifsta-timer, jiffies + 2 * HZ);
+ return;
+}
int ieee80211_ioctl_siwfreq(struct net_device *dev,
struct iw_request_info *info,
@@ -1898,8 +1921,23 @@ int ieee80211_ioctl_siwfreq(struct net_d
}
if (set) {
+ struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_if_sta *ifsta;
+ int ret;
+ int was_scanning;
+
+ sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ ifsta = sdata-u.sta;
+
+ was_scanning = local-sta_scanning;
local-sta_scanning = 0; /* Abort possible scan */
- return ieee80211_hw_config(dev);
+
+ ret = ieee80211_hw_config(dev);
+
+ if (!ret)
+ ieee80211_reset_tries(dev, ifsta, was_scanning);
+
+ return ret;
}
return -EINVAL;
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index e94cb4d..6a3011c 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -2346,7 +2346,7 @@ int ieee80211_sta_set_ssid(struct net_de
return ieee80211_sta_find_ibss(dev, ifsta);
}
- if (ifsta-bssid_set ifsta-state != IEEE80211_AUTHENTICATE)
+ if (ifsta-bssid_set )
ieee80211_sta_new_auth(dev, ifsta);
return 0;
[PATCH 0/7] d80211: support more wireless command
the following patches are based on earlier patched. I did separate each set of command into its own patch with enhanced based on you comments. - 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/7] d80211: report supported rates and channels in SIOCGIWRANGE
This patch modify d80211 to report more information like supported
rate and channel in SIOCGIWRANGE command.
Signed-off-by: Mohamed Abbas [EMAIL PROTECTED]
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index 89a58e3..3d8156c 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -1566,6 +1566,10 @@ static int ieee80211_ioctl_giwrange(stru
struct iw_point *data, char *extra)
{
struct iw_range *range = (struct iw_range *) extra;
+ int i,j,c,n;
+ int skip = 0;
+ struct ieee80211_local *local = dev-ieee80211_ptr;
+ struct ieee80211_hw_modes *bg = NULL;
data-length = sizeof(struct iw_range);
memset(range, 0, sizeof(struct iw_range));
@@ -1581,6 +1585,55 @@ static int ieee80211_ioctl_giwrange(stru
range-min_frag = 256;
range-max_frag = 2346;
+ j = 0;
+ for (i = 0; i local-num_curr_rates j IW_MAX_BITRATES; i++) {
+ struct ieee80211_rate *rate = local-curr_rates[i];
+
+ if (rate-flags IEEE80211_RATE_SUPPORTED) {
+ range-bitrate[j] = rate-rate * 10;
+ j++;
+ }
+ }
+ range-num_bitrates = j;
+
+ c = 0;
+ for (i = 0; i local-hw-num_modes; i++) {
+ struct ieee80211_hw_modes *mode = local-hw-modes[i];
+
+ for (j = 0;
+ j mode-num_channels c IW_MAX_FREQUENCIES; j++) {
+ struct ieee80211_channel *chan = mode-channels[j];
+
+ /* skip any repeated bg channel */
+ skip = 0;
+ if (bg
+ ((mode-mode == MODE_IEEE80211G) ||
+ (mode-mode == MODE_IEEE80211B))) {
+
+for (n = 0; n bg-num_channels; n++) {
+ if (bg-channels[0].chan == chan-chan){
+ skip = 1;
+ break;
+ }
+}
+ }
+
+ if (skip)
+continue;
+
+ range-freq[c].i = chan-chan;
+ range-freq[c].m = chan-freq * 10;
+ range-freq[c].e = 1;
+ c++;
+ }
+ if (!bg ((mode-mode == MODE_IEEE80211G) ||
+ (mode-mode == MODE_IEEE80211B)))
+ bg = mode;
+
+ }
+ range-num_channels = c;
+ range-num_frequency = c;
+
return 0;
}
[PATCH 6/7] d80211: diplay supported rates in readable format
This patch modify d80211 to report supported rates in readable
format in iwlist scan command.
Signed-off-by: Mohamed Abbas [EMAIL PROTECTED]
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index a933d92..b2e45a4 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -2714,15 +2714,21 @@ ieee80211_sta_scan_result(struct net_dev
current_ev = iwe_stream_add_point(current_ev, end_buf, iwe,
buf);
- p = buf;
- p += sprintf(p, supp_rates=);
- for (i = 0; i bss-supp_rates_len; i++)
- p+= sprintf(p, %02x, bss-supp_rates[i]);
- memset(iwe, 0, sizeof(iwe));
- iwe.cmd = IWEVCUSTOM;
- iwe.u.data.length = strlen(buf);
- current_ev = iwe_stream_add_point(current_ev, end_buf, iwe,
- buf);
+ /* dispaly all support rates in readable format */
+ p = current_ev + IW_EV_LCP_LEN;
+ iwe.cmd = SIOCGIWRATE;
+ /* Those two flags are ignored... */
+ iwe.u.bitrate.fixed = iwe.u.bitrate.disabled = 0;
+
+ for (i = 0; i bss-supp_rates_len; i++) {
+ iwe.u.bitrate.value = ((bss-supp_rates[i]
+ 0x7f) * 50);
+ p = iwe_stream_add_value(current_ev, p,
+ end_buf, iwe, IW_EV_PARAM_LEN);
+ }
+ /* Check if we added any rate */
+ if((p - current_ev) IW_EV_LCP_LEN)
+ current_ev = p;
kfree(buf);
break;
[PATCH 5/7] d80211: indicate if unassociate/radio off status
This patch indicate unassociated and radio off status
in name field
Signed-off-by: Mohamed Abbas [EMAIL PROTECTED]
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index 89a58e3..44b2698 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -1538,6 +1538,19 @@ static int ieee80211_ioctl_giwname(struc
char *name, char *extra)
{
struct ieee80211_local *local = dev-ieee80211_ptr;
+ struct ieee80211_sub_if_data *sdata;
+
+ sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ if (!local-conf.radio_enabled) {
+ strcpy(name, radio off);
+return 0;
+ } else if (sdata-type == IEEE80211_IF_TYPE_STA) {
+ if ((sdata-u.sta.state != IEEE80211_ASSOCIATED) ||
+ (sdata-u.sta.probereq_poll)) {
+ strcpy(name, unassociated);
+ return 0;
+ }
+ }
switch (local-conf.phymode) {
case MODE_IEEE80211A:
[PATCH 4/7] d80211: add support for SIOCSIWNICKN SIOCGIWNICKN
This patch modify d80211 to add nick wireless command
Signed-off-by: Mohamed Abbas [EMAIL PROTECTED]
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index 0d2d79d..02242c6 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -241,6 +241,7 @@ struct ieee80211_if_sta {
IEEE80211_IBSS_SEARCH, IEEE80211_IBSS_JOINED
} state;
struct timer_list timer;
+ u8 nick[IW_ESSID_MAX_SIZE];
u8 bssid[ETH_ALEN], prev_bssid[ETH_ALEN];
u8 ssid[IEEE80211_MAX_SSID_LEN];
size_t ssid_len;
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index 89a58e3..956eabb 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -2153,6 +2153,39 @@ static void ieee80211_ioctl_unmask_chann
}
+static int ieee80211_ioctl_siwnick(struct net_device *dev,
+ struct iw_request_info *info,
+ union iwreq_data *wrqu, char *extra)
+{
+ struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_if_sta *ifsta;
+
+ sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ ifsta = sdata-u.sta;
+ if (wrqu-data.length = IW_ESSID_MAX_SIZE)
+ return -E2BIG;
+
+ memset(ifsta-nick, 0, sizeof(ifsta-nick));
+ memcpy(ifsta-nick, extra, wrqu-data.length);
+ return 0;
+}
+
+static int ieee80211_ioctl_giwnick(struct net_device *dev,
+ struct iw_request_info *info,
+ union iwreq_data *wrqu, char *extra)
+{
+ struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_if_sta *ifsta;
+
+ sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ ifsta = sdata-u.sta;
+
+ wrqu-data.length = strlen(ifsta-nick) + 1;
+ memcpy(extra, ifsta-nick, wrqu-data.length);
+ wrqu-data.flags = 1; /* active */
+ return 0;
+}
+
static int ieee80211_ioctl_test_mode(struct net_device *dev, int mode)
{
struct ieee80211_local *local = dev-ieee80211_ptr;
@@ -3138,8 +3171,8 @@ static const iw_handler ieee80211_handle
(iw_handler) ieee80211_ioctl_giwscan, /* SIOCGIWSCAN */
(iw_handler) ieee80211_ioctl_siwessid, /* SIOCSIWESSID */
(iw_handler) ieee80211_ioctl_giwessid, /* SIOCGIWESSID */
- (iw_handler) NULL,/* SIOCSIWNICKN */
- (iw_handler) NULL,/* SIOCGIWNICKN */
+ (iw_handler) ieee80211_ioctl_siwnick, /* SIOCSIWNICKN */
+ (iw_handler) ieee80211_ioctl_giwnick, /* SIOCGIWNICKN */
(iw_handler) NULL,/* -- hole -- */
(iw_handler) NULL,/* -- hole -- */
(iw_handler) NULL,/* SIOCSIWRATE */
[PATCH 7/7] d80211: getting wrong freq value if we did hardware scan
In this patch we search all A-BAND available channels to get the right
frequency value. this might not be the right thing to do in beacon
parsing. Another approach is to have a static array of the maximum
A-BAND channel number then we can map from channel to frequency fast. we
can set the values of this array at run time.
This patch modify d80211 to fix getting wrong frequency value
for scan implemented in hardware. With harware scan we might get
beacon of a network that is on different channel that in
local-conf.channel causing set freq to wrong value.
Signed-off-by: Mohamed Abbas [EMAIL PROTECTED]
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index a933d92..374193e 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -1543,8 +1543,6 @@ #endif
bss-channel = channel;
bss-freq = local-conf.freq;
if (channel != local-conf.channel
- (local-conf.phymode == MODE_IEEE80211G ||
- local-conf.phymode == MODE_IEEE80211B)
channel = 1 channel = 14) {
static const int freq_list[] = {
2412, 2417, 2422, 2427, 2432, 2437, 2442,
@@ -1553,6 +1551,32 @@ #endif
/* IEEE 802.11g/b mode can receive packets from neighboring
* channels, so map the channel into frequency. */
bss-freq = freq_list[channel - 1];
+
+ if (bss-hw_mode != MODE_IEEE80211G
+ bss-hw_mode != MODE_IEEE80211B)
+ bss-hw_mode = MODE_IEEE80211G;
+
+ } else if (channel != local-conf.channel ) {
+ int j, i;
+ int b_found = 0;
+
+ /* not a bg channel search in other mode */
+ for (i = 0; i local-hw-num_modes; i++) {
+ struct ieee80211_hw_modes *mode = local-hw-modes[i];
+
+ if ((mode-mode != MODE_IEEE80211G)
+ (mode-mode != MODE_IEEE80211B)){
+for (j = 0; mode-num_channels; j++)
+if (mode-channels[j].chan == channel) {
+ bss-freq = mode-channels[j].freq;
+ b_found = 1;
+ bss-hw_mode = mode-mode;
+ break;
+}
+ }
+ if (b_found)
+break;
+ }
}
bss-timestamp = timestamp;
bss-last_update = jiffies;
