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
Re: [d80211] some issues regarding iwconfig parameters sequence
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. > 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
[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;
