[PATCH 0/4] hostapd cleanups

[PATCH 0/4] hostapd cleanups

[Johannes Berg]

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

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

[Johannes Berg]

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

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>

---
 hostapd/driver_devicescape.c |    6 ------
 1 file changed, 6 deletions(-)

--- hostap.orig/hostapd/driver_devicescape.c	2007-08-14 11:32:34.000000000 +0200
+++ hostap/hostapd/driver_devicescape.c	2007-08-14 11:32:34.000000000 +0200
@@ -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)

-- 

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

[Jouni Malinen]

On Tue, Aug 14, 2007 at 11:32:55AM +0200, Johannes Berg wrote:
> 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.

-- 
Jouni Malinen                                            PGP id EFC895FA

[PATCH 2/4] hostapd: use SIOCSIWGENIE

[Johannes Berg]

Use SIOCSIWGENIE instead of PRISM2_HOSTAPD_SET_GENERIC_INFO_ELEM.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>

---
 hostapd/driver_devicescape.c |   26 +++++++++-----------------
 1 file changed, 9 insertions(+), 17 deletions(-)

--- hostap.orig/hostapd/driver_devicescape.c	2007-08-14 11:32:34.000000000 +0200
+++ hostap/hostapd/driver_devicescape.c	2007-08-14 11:32:35.000000000 +0200
@@ -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;
 }
 
 

-- 

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

[Jouni Malinen]

On Tue, Aug 14, 2007 at 11:32:56AM +0200, Johannes Berg wrote:
> Use SIOCSIWGENIE instead of PRISM2_HOSTAPD_SET_GENERIC_INFO_ELEM.

Thanks, applied.

-- 
Jouni Malinen                                            PGP id EFC895FA

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

[Johannes Berg]

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
 hostapd/driver_devicescape.c |  217 +++++++++++++++++++------------------------
 1 file changed, 99 insertions(+), 118 deletions(-)

--- hostap.orig/hostapd/driver_devicescape.c	2007-08-14 11:32:35.000000000 +0200
+++ hostap/hostapd/driver_devicescape.c	2007-08-14 11:32:35.000000000 +0200
@@ -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);
 

-- 

[PATCH 4/4] hostapd: remove PRISM2_PARAM_NEXT_MODE

[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

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>

---
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(-)

--- hostap.orig/hostapd/driver_devicescape.c	2007-08-14 11:32:35.000000000 +0200
+++ hostap/hostapd/driver_devicescape.c	2007-08-14 11:32:36.000000000 +0200
@@ -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;

-- 

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

[Jouni Malinen]

On Tue, Aug 14, 2007 at 11:32:58AM +0200, Johannes Berg wrote:
> 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.

> 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.

-- 
Jouni Malinen                                            PGP id EFC895FA

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

[Tomas Winkler]

On 8/15/07, Jouni Malinen <j@w1.fi> wrote:
> On Tue, Aug 14, 2007 at 11:32:58AM +0200, Johannes Berg wrote:
> > 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.
>
> > 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.
>

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.




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

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

On Wed, 2007-08-15 at 10:29 +0300, Tomas Winkler wrote:

> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On Tue, 2007-08-14 at 19:41 -0700, Jouni Malinen wrote:

> 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.

> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

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

[Jouni Malinen]

On Wed, Aug 15, 2007 at 12:44:42PM +0200, Johannes Berg wrote:

> 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.

> 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).

-- 
Jouni Malinen                                            PGP id EFC895FA

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

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

On Wed, 2007-08-15 at 18:38 -0700, Jouni Malinen wrote:

> 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.

> 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.

> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]