Skip to contentSkip to conversation

hostapd cleanups

PATCH Applied Johannes Berg 3 participants 13 messages Aug 14, 2007 – Aug 16, 2007

lore
Share & tools
lore
#0 lore raw

cover hostapd cleanups

This patch series contains some updates for hostapd, corresponding to the ioctls removals in the kernel.

I'm not entirely sure about the removal of PRISM2_PARAM_NEXT_MODE but the API is totally useless at the moment since hardly anything kernel seems to differentiate between B and G channels and G drivers don't support B channels.

johannes

#1 lore raw

PATCH 1/4 hostapd: remove enable/disable calls

This isn't really useful since mac80211 always enables the radio when the interface is brought up.

---
 hostapd/driver_devicescape.c |    6 ------
 1 file changed, 6 deletions(-)
hostapd/driver_devicescape.c +0 -6
@@ -2075,9 +2075,6 @@ static void * i802_init(struct hostapd_d
 	if (i802_init_sockets(drv))
 		goto failed;
 
-	/* Enable the radio by default. */
-	(void) hostap_ioctl_prism2param(drv, PRISM2_PARAM_RADIO_ENABLED, 1);
-
 	return drv;
 
 failed:
@@ -2091,9 +2088,6 @@ static void i802_deinit(void *priv)
 	struct i802_driver_data *drv = priv;
 	struct nl_msg *msg;
 
-	/* Disable the radio. */
-	(void) hostap_ioctl_prism2param(drv, PRISM2_PARAM_RADIO_ENABLED, 0);
-
 	(void) hostapd_set_iface_flags(drv, 0);
 
 	if (drv->ioctl_sock >= 0)
#2 lore raw

Re: [PATCH 1/4] hostapd: remove enable/disable calls

Quoted 2 lines · Johannes Berg

This isn't really useful since mac80211 always enables the radio when the interface is brought up.

Thanks, applied. I think this parameter was originally used (with another name, though) for disabling the radio when a radar was detected. The benefit of being able to do this without bringing down the interface was to not lose IP configuration. Anyway, the radar stuff is very likely to take a different direction, so getting rid of this parameter should be fine.

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
#3 lore raw

PATCH 2/4 hostapd: use SIOCSIWGENIE

In reply to Johannes Berg

Use SIOCSIWGENIE instead of PRISM2_HOSTAPD_SET_GENERIC_INFO_ELEM.

---
 hostapd/driver_devicescape.c |   26 +++++++++-----------------
 1 file changed, 9 insertions(+), 17 deletions(-)
hostapd/driver_devicescape.c +9 -17
@@ -694,28 +694,20 @@ static int i802_set_generic_elem(const c
 				 const u8 *elem, size_t elem_len)
 {
 	struct i802_driver_data *drv = priv;
-	struct prism2_hostapd_param *param;
-	u8 *buf;
-	size_t blen;
-	int ret = 0;
+	struct iwreq iwr;
 
-	blen = sizeof(*param) + elem_len;
-	buf = os_zalloc(blen);
-	if (buf == NULL)
-		return -1;
+	memset(&iwr, 0, sizeof(iwr));
 
-	param = (struct prism2_hostapd_param *) buf;
-	param->cmd = PRISM2_HOSTAPD_SET_GENERIC_INFO_ELEM;
-	param->u.set_generic_info_elem.len = elem_len;
-	memcpy(param->u.set_generic_info_elem.data, elem, elem_len);
+	os_strlcpy(iwr.ifr_name, drv->hapd->conf->iface, IFNAMSIZ);
+	iwr.u.data.length = elem_len;
+	iwr.u.data.pointer = (void*)elem;
 
-	if (hostapd_ioctl_iface(ifname, drv, param, blen)) {
-		printf("%s: Failed to set generic info element\n", drv->iface);
-		ret = -1;
+	if (ioctl(drv->ioctl_sock, SIOCSIWGENIE, &iwr) < 0) {
+		perror("Failed to set generic info element");
+		return -1;
 	}
-	free(buf);
 
-	return ret;
+	return 0;
 }
 
 
#4 lore raw

Re: [PATCH 2/4] hostapd: use SIOCSIWGENIE

Quoted 1 line · Johannes Berg

Use SIOCSIWGENIE instead of PRISM2_HOSTAPD_SET_GENERIC_INFO_ELEM.

Thanks, applied.

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
#5 lore raw

PATCH 3/4 hostapd: use nl80211 for add/remove iface

In reply to Johannes Berg
---
 hostapd/driver_devicescape.c |  217 +++++++++++++++++++------------------------
 1 file changed, 99 insertions(+), 118 deletions(-)
hostapd/driver_devicescape.c +99 -118
@@ -786,56 +786,108 @@ static int i802_set_tx_queue_params(void
 }
 
 
-static int i802_bss_add(void *priv, const char *ifname, const u8 *bssid)
+static void nl80211_remove_iface(struct i802_driver_data *drv, int ifidx)
 {
-	struct i802_driver_data *drv = priv;
-	struct prism2_hostapd_param *param;
+	struct nl_msg *msg;
 
-	param = os_zalloc(sizeof(struct prism2_hostapd_param) + ETH_ALEN);
-	if (param == NULL)
+	msg = nlmsg_alloc();
+	if (!msg)
+		goto nla_put_failure;
+
+	genlmsg_put(msg, 0, 0, genl_family_get_id(drv->nl80211), 0,
+		    0, NL80211_CMD_DEL_VIRTUAL_INTERFACE, 0);
+	NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, ifidx);
+	if (nl_send_auto_complete(drv->nl_handle, msg) < 0 ||
+	    nl_wait_for_ack(drv->nl_handle) < 0)
+	nla_put_failure:
+		printf("Failed to remove interface.\n");
+	nlmsg_free(msg);
+}
+
+
+static int nl80211_create_iface(struct i802_driver_data *drv,
+				const char *ifname,
+				enum nl80211_iftype iftype,
+				const u8 *addr)
+{
+	struct nl_msg *msg;
+	int ifidx;
+	struct ifreq ifreq;
+	struct iwreq iwr;
+
+	msg = nlmsg_alloc();
+	if (!msg)
 		return -1;
 
-	param->cmd = PRISM2_HOSTAPD_ADD_IF;
-	param->u.if_info.type = HOSTAP_IF_BSS;
-	memcpy(param->u.if_info.data, bssid, ETH_ALEN);
-	os_strlcpy((char *) param->u.if_info.name, ifname, IFNAMSIZ);
-
-	if (hostapd_ioctl(drv, param,
-			  sizeof(struct prism2_hostapd_param) + ETH_ALEN)) {
-		printf("Could not add bss iface: %s.\n", ifname);
-		free(param);
+	genlmsg_put(msg, 0, 0, genl_family_get_id(drv->nl80211), 0,
+		    0, NL80211_CMD_ADD_VIRTUAL_INTERFACE, 0);
+	NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX,
+		    if_nametoindex(drv->hapd->conf->iface));
+	NLA_PUT_STRING(msg, NL80211_ATTR_IFNAME, ifname);
+	NLA_PUT_U32(msg, NL80211_ATTR_IFTYPE, iftype);
+
+	if (nl_send_auto_complete(drv->nl_handle, msg) < 0 ||
+	    nl_wait_for_ack(drv->nl_handle) < 0) {
+	nla_put_failure:
+		printf("Failed to create interface %s.\n", ifname);
+		nlmsg_free(msg);
 		return -1;
 	}
 
-	free(param);
+	nlmsg_free(msg);
 
-	return 0;
+	ifidx = if_nametoindex(ifname);
+
+	if (ifidx <= 0)
+		return -1;
+
+	if (addr) switch (iftype) {
+	case NL80211_IFTYPE_AP:
+		/*
+		 * This is how it works in mac80211 right now, but who gets to
+		 * handle multiple AP devices with different BSSIDs but the
+		 * same MAC?
+		 * In fact, I think we should be changing the BSSID here and
+		 * not the MAC address... but mac80211 doesn't support that!
+		 */
+		os_strlcpy(ifreq.ifr_name, ifname, IFNAMSIZ);
+		memcpy(ifreq.ifr_hwaddr.sa_data, addr, ETH_ALEN);
+		ifreq.ifr_hwaddr.sa_family = ARPHRD_ETHER;
+
+		if (ioctl(drv->ioctl_sock, SIOCSIFHWADDR, &ifreq)) {
+			nl80211_remove_iface(drv, ifidx);
+			return -1;
+		}
+		break;
+	case NL80211_IFTYPE_WDS:
+		memset(&iwr, 0, sizeof(iwr));
+		os_strlcpy(iwr.ifr_name, ifname, IFNAMSIZ);
+		iwr.u.addr.sa_family = ARPHRD_ETHER;
+		memcpy(iwr.u.addr.sa_data, addr, ETH_ALEN);
+		if (ioctl(drv->ioctl_sock, SIOCSIWAP, &iwr))
+			return -1;
+		break;
+	default:
+		/* nothing */
+		break;
+	}
+
+	return ifidx;
 }
 
 
-static int i802_bss_remove(void *priv, const char *ifname)
+static int i802_bss_add(void *priv, const char *ifname, const u8 *bssid)
 {
-	struct i802_driver_data *drv = priv;
-	struct prism2_hostapd_param *param;
-	int ret = 0;
-
-	param = os_zalloc(sizeof(struct prism2_hostapd_param) + ETH_ALEN);
-	if (param == NULL)
+	if (nl80211_create_iface(priv, ifname, NL80211_IFTYPE_AP, bssid) < 0)
 		return -1;
+	return 0;
+}
 
-	param->cmd = PRISM2_HOSTAPD_REMOVE_IF;
-	param->u.if_info.type = HOSTAP_IF_BSS;
-	os_strlcpy((char *) param->u.if_info.name, ifname, IFNAMSIZ);
-
-	if (hostapd_ioctl(drv, param,
-			  sizeof(struct prism2_hostapd_param) + ETH_ALEN)) {
-		printf("Could not remove iface: %s.\n", ifname);
-		ret = -1;
-	}
-
-	free(param);
 
-	return ret;
+static int i802_bss_remove(void *priv, const char *ifname)
+{
+	nl80211_remove_iface(priv, if_nametoindex(ifname));
+	return 0;
 }
 
 
@@ -970,13 +1022,13 @@ static int i802_set_short_slot_time(void
 }
 
 
-static int i802_if_type(enum hostapd_driver_if_type type)
+static enum nl80211_iftype i802_if_type(enum hostapd_driver_if_type type)
 {
 	switch (type) {
 	case HOSTAPD_IF_VLAN:
-		return HOSTAP_IF_VLAN;
+		return NL80211_IFTYPE_AP_VLAN;
 	case HOSTAPD_IF_WDS:
-		return HOSTAP_IF_WDS;
+		return NL80211_IFTYPE_WDS;
 	}
 	return -1;
 }
@@ -986,32 +1038,8 @@ static int i802_if_add(const char *iface
 		       enum hostapd_driver_if_type type, char *ifname,
 		       const u8 *addr)
 {
-	struct i802_driver_data *drv = priv;
-	struct prism2_hostapd_param *param;
-
-	param = malloc(sizeof(struct prism2_hostapd_param) + ETH_ALEN);
-	if (!param)
+	if (nl80211_create_iface(priv, ifname, i802_if_type(type), addr) < 0)
 		return -1;
-	memset(param, 0, sizeof(param));
-
-	param->cmd = PRISM2_HOSTAPD_ADD_IF;
-	param->u.if_info.type = i802_if_type(type);
-	if (addr)
-		memcpy(param->u.if_info.data, addr, ETH_ALEN);
-	else
-		memset(param->u.if_info.data, 0, ETH_ALEN);
-	os_strlcpy((char *) param->u.if_info.name, ifname, IFNAMSIZ);
-
-	/* FIX: should the size have + ETH_ALEN ? */
-	if (hostapd_ioctl_iface(iface, drv, param,
-				sizeof(struct prism2_hostapd_param))) {
-		printf("Could not add iface: %s.\n", ifname);
-		free(param);
-		return -1;
-	}
-
-	os_strlcpy(ifname, (char *) param->u.if_info.name, IFNAMSIZ);
-	free(param);
 	return 0;
 }
 
@@ -1027,28 +1055,7 @@ static int i802_if_update(void *priv, en
 static int i802_if_remove(void *priv, enum hostapd_driver_if_type type,
 			  const char *ifname, const u8 *addr)
 {
-	struct i802_driver_data *drv = priv;
-	struct prism2_hostapd_param *param;
-
-	param = malloc(sizeof(struct prism2_hostapd_param) + ETH_ALEN);
-	if (!param)
-		return -1;
-	memset(param, 0, sizeof(param));
-
-	param->cmd = PRISM2_HOSTAPD_REMOVE_IF;
-	param->u.if_info.type = i802_if_type(type);
-	if (addr)
-		memcpy(param->u.if_info.data, addr, ETH_ALEN);
-	else
-		memset(param->u.if_info.data, 0, ETH_ALEN);
-	os_strlcpy((char *) param->u.if_info.name, ifname, IFNAMSIZ);
-	if (hostapd_ioctl(drv, param, sizeof(struct prism2_hostapd_param))) {
-		printf("Could not remove iface: %s.\n", ifname);
-		free(param);
-		return -1;
-	}
-
-	free(param);
+	nl80211_remove_iface(priv, if_nametoindex(ifname));
 	return 0;
 }
 
@@ -1546,7 +1553,6 @@ static int i802_init_sockets(struct i802
 	struct sockaddr_ll addr;
 	struct iwreq iwr;
 	char buf[IFNAMSIZ];
-	struct nl_msg *msg;
 	socklen_t optlen;
 	int optval;
 	int idx;
@@ -1584,28 +1590,14 @@ static int i802_init_sockets(struct i802
 		return -1;
 	}
 
-	/* conjure a monitor interface */
-	msg = nlmsg_alloc();
-	if (!msg) {
-		printf("Failed to allocate netlink message.\n");
-		return -1;
-	}
 	snprintf(buf, IFNAMSIZ, "mon.%s", hapd->conf->iface);
 	buf[IFNAMSIZ-1] = '\0';
-	genlmsg_put(msg, 0, 0, genl_family_get_id(drv->nl80211), 0,
-		    0, NL80211_CMD_ADD_VIRTUAL_INTERFACE, 0);
-	NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX,
-		    if_nametoindex(hapd->conf->iface));
-	NLA_PUT_STRING(msg, NL80211_ATTR_IFNAME, buf);
-	NLA_PUT_U32(msg, NL80211_ATTR_IFTYPE, NL80211_IFTYPE_MONITOR);
-	if (nl_send_auto_complete(drv->nl_handle, msg) < 0 ||
-	    nl_wait_for_ack(drv->nl_handle) < 0) {
-	nla_put_failure:
-		nlmsg_free(msg);
-		printf("Failed to create monitor interface %s.\n", buf);
+
+	drv->monitor_ifidx = nl80211_create_iface(drv, buf,
+						  NL80211_IFTYPE_MONITOR,
+						  NULL);
+	if (drv->monitor_ifidx < 0)
 		return -1;
-	}
-	nlmsg_free(msg);
 
 	/*
 	 * TODO: try disabling receiving control frames on the monitor iface,
@@ -1631,7 +1623,7 @@ static int i802_init_sockets(struct i802
 
 	memset(&addr, 0, sizeof(addr));
 	addr.sll_family = AF_PACKET;
-	drv->monitor_ifidx = addr.sll_ifindex = if_nametoindex(buf);
+	addr.sll_ifindex = drv->monitor_ifidx;
 	HOSTAPD_DEBUG(HOSTAPD_DEBUG_MINIMAL,
 		      "Opening raw packet socket for monitor (%d)\n",
 		      addr.sll_ifindex);
@@ -2078,7 +2070,6 @@ failed:
 static void i802_deinit(void *priv)
 {
 	struct i802_driver_data *drv = priv;
-	struct nl_msg *msg;
 
 	(void) hostapd_set_iface_flags(drv, 0);
 
@@ -2088,17 +2079,7 @@ static void i802_deinit(void *priv)
 	eloop_unregister_read_sock(drv->monitor_sock);
 	close(drv->monitor_sock);
 
-	msg = nlmsg_alloc();
-	if (msg) {
-		genlmsg_put(msg, 0, 0, genl_family_get_id(drv->nl80211), 0,
-			    0, NL80211_CMD_DEL_VIRTUAL_INTERFACE, 0);
-		NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, drv->monitor_ifidx);
-		if (nl_send_auto_complete(drv->nl_handle, msg) < 0 ||
-		    nl_wait_for_ack(drv->nl_handle) < 0)
-		nla_put_failure:
-			printf("Failed to remove monitor interface.\n");
-		nlmsg_free(msg);
-	}
+	nl80211_remove_iface(drv, drv->monitor_ifidx);
 	nl_cache_free(drv->nl_cache);
 	nl_handle_destroy(drv->nl_handle);
 
#6 lore raw

PATCH 4/4 hostapd: remove PRISM2_PARAM_NEXT_MODE

In reply to Johannes Berg

802.11 A is easily distinguishable based on frequency, and the difference between 802.11B/G isn't really done well in mac80211 with most 802.11G drivers supporting only 802.11G channels and no B channels

---
What reason is there anyway for distinguishing between an 802.11G and an 802.11B channel? Regulatory? In that case, well, needs lots of work.

 hostapd/driver_devicescape.c |   14 --------------
 1 file changed, 14 deletions(-)
hostapd/driver_devicescape.c +0 -14
@@ -367,20 +367,6 @@ static int i802_set_freq(void *priv, int
 	struct i802_driver_data *drv = priv;
 	struct iwreq iwr;
 
-	switch (mode) {
-	case HOSTAPD_MODE_IEEE80211A:
-		mode = MODE_IEEE80211A;
-		break;
-	case HOSTAPD_MODE_IEEE80211B:
-		mode = MODE_IEEE80211B;
-		break;
-	case HOSTAPD_MODE_IEEE80211G:
-		mode = MODE_IEEE80211G;
-		break;
-	}
-
-	hostap_ioctl_prism2param(drv, PRISM2_PARAM_NEXT_MODE, mode);
-
 	memset(&iwr, 0, sizeof(iwr));
 	os_strlcpy(iwr.ifr_name, drv->hapd->conf->iface, IFNAMSIZ);
 	iwr.u.freq.m = freq;
#7 lore raw

Re: [PATCH 4/4] hostapd: remove PRISM2_PARAM_NEXT_MODE

Quoted 3 lines · Johannes Berg

802.11 A is easily distinguishable based on frequency, and the difference between 802.11B/G isn't really done well in mac80211 with most 802.11G drivers supporting only 802.11G channels and no B channels

Agreed on 802.11a vs. b/g as long as frequency is used for configuration (as is the case here; channel numbers would not have been unique). Dropping the b vs. g is somewhat unfortunate, though.

Quoted 2 lines

What reason is there anyway for distinguishing between an 802.11G and an 802.11B channel? Regulatory? In that case, well, needs lots of work.

The original reason for adding that was that some hardware designs have separate modes for 802.11b and 802.11g and there may be cases where the 802.11b mode would be preferred. I'm not sure about all the differences in hardware, but I would assume this could include power use (save power by being able to use slower internal frequency since there is less things to do and by disabling some functionality) and maybe in some cases just the fact of disabling all non-802.11b extensions.

Furthermore, frequency may not be unique in future with additional PHY changes. Having option of setting both a "mode" and frequency is a pair is a good way of making sure the design is more future proof in this area.

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
#8 lore raw

Re: [PATCH 4/4] hostapd: remove PRISM2_PARAM_NEXT_MODE

Quoted 20 lines · Jouni Malinen
Quoted 3 lines · Johannes Berg

802.11 A is easily distinguishable based on frequency, and the difference between 802.11B/G isn't really done well in mac80211 with most 802.11G drivers supporting only 802.11G channels and no B channels

Agreed on 802.11a vs. b/g as long as frequency is used for configuration (as is the case here; channel numbers would not have been unique). Dropping the b vs. g is somewhat unfortunate, though.

Quoted 2 lines

What reason is there anyway for distinguishing between an 802.11G and an 802.11B channel? Regulatory? In that case, well, needs lots of work.

The original reason for adding that was that some hardware designs have separate modes for 802.11b and 802.11g and there may be cases where the 802.11b mode would be preferred. I'm not sure about all the differences in hardware, but I would assume this could include power use (save power by being able to use slower internal frequency since there is less things to do and by disabling some functionality) and maybe in some cases just the fact of disabling all non-802.11b extensions.

Quoted 5 lines

Furthermore, frequency may not be unique in future with additional PHY changes. Having option of setting both a "mode" and frequency is a pair is a good way of making sure the design is more future proof in this area.

Just a small example as everybody knows the major distinction is in modulation schema i.e. CCK vs. OFDM. 11b only devices are deaf to OFDM traffic so we use CTS/RTS to overcome it which in turn slows the traffic. Sometime B-only or even G-only (no CCK rates) environments are required. I've used to have laptops with 11b only cards so I've configured the AP to B only not slowing even more the traffic.

Quoted 7 lines

--
Jouni Malinen PGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#9 lore raw

Re: [PATCH 4/4] hostapd: remove PRISM2_PARAM_NEXT_MODE

Quoted 6 lines · Tomas Winkler

Just a small example as everybody knows the major distinction is in modulation schema i.e. CCK vs. OFDM. 11b only devices are deaf to OFDM traffic so we use CTS/RTS to overcome it which in turn slows the traffic. Sometime B-only or even G-only (no CCK rates) environments are required. I've used to have laptops with 11b only cards so I've configured the AP to B only not slowing even more the traffic.

That's more a matter of only announcing B channels though, not a reason for telling the hardware that a B channel was selected.

Of course, it is not inconceivable that hardware may support turning off OFDM completely, I just haven't seen any yet :)

johannes

#10 lore raw

Re: [PATCH 4/4] hostapd: remove PRISM2_PARAM_NEXT_MODE

In reply to Jouni Malinen
Quoted 3 lines · Jouni Malinen

Agreed on 802.11a vs. b/g as long as frequency is used for configuration (as is the case here; channel numbers would not have been unique). Dropping the b vs. g is somewhat unfortunate, though.

Agreed. I can live with leaving it in.

Quoted 4 lines

Furthermore, frequency may not be unique in future with additional PHY changes. Having option of setting both a "mode" and frequency is a pair is a good way of making sure the design is more future proof in this area.

Agreed as well, the plan for nl80211 was to have the tuple set together. I quite dislike the idea of this internal "next_mode" state but I suppose it's the best we have now.

However, this is the reason David Woodhouse couldn't get his Broadcom based card to work in B mode, hostapd tried to select a B mode channel and b43 doesn't offer any since it offers G mode. Should the burden be on the driver authors here, or should we somehow select a G channel if B isn't available?

johannes

#11 lore raw

Re: [PATCH 4/4] hostapd: remove PRISM2_PARAM_NEXT_MODE

Quoted 3 lines · Johannes Berg

Agreed as well, the plan for nl80211 was to have the tuple set together. I quite dislike the idea of this internal "next_mode" state but I suppose it's the best we have now.

I don't linke next_mode either, so if this is combined to a single atomic operation, it would be quite a bit better way to do this.

Quoted 5 lines

However, this is the reason David Woodhouse couldn't get his Broadcom based card to work in B mode, hostapd tried to select a B mode channel and b43 doesn't offer any since it offers G mode. Should the burden be on the driver authors here, or should we somehow select a G channel if B isn't available?

I would assume that the quick workaround for this would have been to change the configuration file to use 802.11g instead of the default i802.11b.. Anyway, the design used here does indeed assume that the driver exports all supported mode/channel pairs and in case the hardware card supports 802.11g, the driver would most likely claim support for both 802.11b and 802.11g channels.

Adding code for reverting back to 802.11g version would, in theory, be fine for most cases, but it does have some issues.. If I remember correctly, channel 14 may only be used with 802.11b mode in Japan, so the list of 802.11b and 802.11g channels is not the same. In this particular case, though, the workaround of using 802.11g list would not cause a problem (the other direction would potentially have).

Signature · 1 line
Jouni Malinen                                            PGP id EFC895FA
#12 lore raw

Re: [PATCH 4/4] hostapd: remove PRISM2_PARAM_NEXT_MODE

Quoted 2 lines · Jouni Malinen

I don't linke next_mode either, so if this is combined to a single atomic operation, it would be quite a bit better way to do this.

Yeah, we'll have that if somebody gets around to it.

Quoted 3 lines

I would assume that the quick workaround for this would have been to change the configuration file to use 802.11g instead of the default i802.11b..

Oh, it was :) But it wasn't obvious.

Quoted 11 lines

Anyway, the design used here does indeed assume that the driver exports all supported mode/channel pairs and in case the hardware card supports 802.11g, the driver would most likely claim support for both 802.11b and 802.11g channels.

Adding code for reverting back to 802.11g version would, in theory, be fine for most cases, but it does have some issues.. If I remember correctly, channel 14 may only be used with 802.11b mode in Japan, so the list of 802.11b and 802.11g channels is not the same. In this particular case, though, the workaround of using 802.11g list would not cause a problem (the other direction would potentially have).

Hmm. That seems like something to be integrated with the regulatory code rather than the driver.

johannes