This removes the VLAN stuff from hostapd.
The VLAN stuff in mac80211 cannot possibly work, it doesn't actually do
anything with those VLAN type interfaces. Also, when I added the VLAN
type to cfg80211 I must have been rather convinced of the idea; I no
longer am in favour of doing it in the wireless stack. The recently
added "macvlan" "driver" shows how you can do VLANs based on destination
address, what we will need is something like "smacvlan" that does VLANs
based on source address.
Signed-off-by: Johannes Berg <[email protected]>
---
hostapd/ChangeLog | 2 ++
hostapd/driver_devicescape.c | 16 ----------------
2 files changed, 2 insertions(+), 16 deletions(-)
--- hostap.orig/hostapd/driver_devicescape.c 2007-08-15 00:36:51.000000000 +0200
+++ hostap/hostapd/driver_devicescape.c 2007-08-15 00:36:56.000000000 +0200
@@ -1135,21 +1135,6 @@ static struct hostapd_hw_modes * i802_ge
}
-static int i802_set_sta_vlan(void *priv, const u8 *addr, const char *ifname,
- int vlan_id)
-{
- struct i802_driver_data *drv = priv;
- struct prism2_hostapd_param param;
-
- memset(¶m, 0, sizeof(param));
- param.cmd = PRISM2_HOSTAPD_SET_STA_VLAN;
- memcpy(param.sta_addr, addr, ETH_ALEN);
- os_strlcpy(param.u.set_sta_vlan.vlan_name, ifname, IFNAMSIZ);
- param.u.set_sta_vlan.vlan_id = vlan_id;
- return hostapd_ioctl(drv, ¶m, sizeof(param));
-}
-
-
static void handle_data(struct hostapd_data *hapd, u8 *buf, size_t len,
u16 stype)
{
@@ -2170,5 +2155,4 @@ const struct wpa_driver_ops wpa_driver_d
.if_update = i802_if_update,
.if_remove = i802_if_remove,
.get_hw_feature_data = i802_get_hw_feature_data,
- .set_sta_vlan = i802_set_sta_vlan,
};
--- hostap.orig/hostapd/ChangeLog 2007-08-15 00:40:25.000000000 +0200
+++ hostap/hostapd/ChangeLog 2007-08-15 00:40:55.000000000 +0200
@@ -16,6 +16,8 @@ ChangeLog for hostapd
either need to support this or will have to use the WPA/RSN IEs from
hostapd; currently, the included madwifi and bsd driver interfaces do
not have support for this)
+ * removed VLAN support from devicescape driver, the kernel isn't up
+ to it and it need not live in the wireless stack at all.
2007-05-28 - v0.6.0
* added experimental IEEE 802.11r/D6.0 support
On Wed, Aug 15, 2007 at 02:24:49PM +0200, Johannes Berg wrote:
> This removes the VLAN stuff from hostapd.
>
> The VLAN stuff in mac80211 cannot possibly work, it doesn't actually do
> anything with those VLAN type interfaces. Also, when I added the VLAN
> type to cfg80211 I must have been rather convinced of the idea; I no
> longer am in favour of doing it in the wireless stack. The recently
> added "macvlan" "driver" shows how you can do VLANs based on destination
> address, what we will need is something like "smacvlan" that does VLANs
> based on source address.
This doesn't sound like a good idea. How would macvlan-based alternative
solve the problem of having different group keys for each VLAN?
--
Jouni Malinen PGP id EFC895FA
On Wed, 2007-08-15 at 18:22 -0700, Jouni Malinen wrote:
> This doesn't sound like a good idea. How would macvlan-based alternative
> solve the problem of having different group keys for each VLAN?
Ah. I never considered that was even possible. Wouldn't it make more
sense to allow binding group keys to STAs too, instead of making the
only within the interface? That way you could possibly even get hw accel
for those.
johannes
On Wed, 2007-08-15 at 18:22 -0700, Jouni Malinen wrote:
> This doesn't sound like a good idea. How would macvlan-based alternative
> solve the problem of having different group keys for each VLAN?
This is actually more complicated than it seems.
Currently, we have this code doing key selection:
if (rx->sdata->type == IEEE80211_IF_TYPE_STA)
always_sta_key = 0;
else
always_sta_key = 1;
if (rx->sta && rx->sta->key && always_sta_key) {
rx->key = rx->sta->key;
which means that we'll always use the per-sta key unless that sta
doesn't have one configured (can that happen?!). And if we do have a sta
key, then we don't handle multicast/broadcast frames correctly as I've
just confirmed in the "meaningless TKIP messages" thread.
Reading 802.11, it seems that there are basically the following keys we
need to know about at this level:
* PTKs
* GTKs
* STKs
For the purposes of mac80211, however, PTKs and STKs should be identical
as far as I can tell, they are just STA keys, used to send and receive
unicast frames to/from that STA.
Hence, the way I see it, initially key selection should simply work as
follows:
(1) if the frame is unicast and there is a key for the sending STA,
use it; it will be a PTK or STK
(2) otherwise, use the key based on the key index, in an IBSS take into
account the transmitter; the found key will be a GTK or WEP key
based on that, I don't understand what ieee80211_rx_h_load_key is doing;
is there a scenario where this selection doesn't work?
I'll try to come up with a fix first that also makes dynamic WEP work,
stay tuned.
Now, anyhow, this thread was about VLANs, so it appears that what we'll
have to do is modify the code to take into account VLAN group keys.
johannes
On Thu, Aug 16, 2007 at 03:20:14PM +0200, Johannes Berg wrote:
> On Wed, 2007-08-15 at 18:22 -0700, Jouni Malinen wrote:
>
> > This doesn't sound like a good idea. How would macvlan-based alternative
> > solve the problem of having different group keys for each VLAN?
>
> Ah. I never considered that was even possible. Wouldn't it make more
> sense to allow binding group keys to STAs too, instead of making the
> only within the interface? That way you could possibly even get hw accel
> for those.
That would break the broadcast domain and if someone really want that,
they could create a VLAN per STA.. The purpose of using different group
keys per VLAN is to allow each VLAN to have a separate broadcast domain,
i.e., all broadcast packets to STAs bound to this VLAN are available to
all STAs in this VLAN (and only to them).
Since in 802.11 BSS networks, broadcast frames are only sent by the AP,
hw acceleration can be made to work fine with this kind of
configuration. As far as the clients are concerned, they don't even know
about the existance of different VLANs and group keys and as such, this
looks a standard AP to them. As far as the AP is concerned, it will need
to have support for using multiple keys with hwaccel and way of indexing
them with each transmitted frame. Taken into account how support for
hwaccel to unicast frames is implemented, this is quite a simple
extension to that.
--
Jouni Malinen PGP id EFC895FA
This removes the VLAN stuff from hostapd.
The VLAN stuff in mac80211 cannot possibly work, it doesn't actually do
anything with those VLAN type interfaces. Also, when I added the VLAN
type to cfg80211 I must have been rather convinced of the idea; I no
longer am in favour of doing it in the wireless stack. The recently
added "macvlan" "driver" shows how you can do VLANs based on destination
address, what we will need is something like "smacvlan" that does VLANs
based on source address.
Signed-off-by: Johannes Berg <[email protected]>
---
Rediffed to apply just on top of the eloop fix I just sent and not
require any other patches.
hostapd/ChangeLog | 2 ++
hostapd/driver_devicescape.c | 18 ------------------
2 files changed, 2 insertions(+), 18 deletions(-)
--- hostap.orig/hostapd/driver_devicescape.c 2007-08-15 14:21:37.000000000 +0200
+++ hostap/hostapd/driver_devicescape.c 2007-08-15 14:21:58.000000000 +0200
@@ -972,8 +972,6 @@ static int i802_set_short_slot_time(void
static int i802_if_type(enum hostapd_driver_if_type type)
{
switch (type) {
- case HOSTAPD_IF_VLAN:
- return HOSTAP_IF_VLAN;
case HOSTAPD_IF_WDS:
return HOSTAP_IF_WDS;
}
@@ -1141,21 +1139,6 @@ static struct hostapd_hw_modes * i802_ge
}
-static int i802_set_sta_vlan(void *priv, const u8 *addr, const char *ifname,
- int vlan_id)
-{
- struct i802_driver_data *drv = priv;
- struct prism2_hostapd_param param;
-
- memset(¶m, 0, sizeof(param));
- param.cmd = PRISM2_HOSTAPD_SET_STA_VLAN;
- memcpy(param.sta_addr, addr, ETH_ALEN);
- os_strlcpy(param.u.set_sta_vlan.vlan_name, ifname, IFNAMSIZ);
- param.u.set_sta_vlan.vlan_id = vlan_id;
- return hostapd_ioctl(drv, ¶m, sizeof(param));
-}
-
-
static void handle_data(struct hostapd_data *hapd, u8 *buf, size_t len,
u16 stype, struct ieee80211_frame_info *fi)
{
@@ -2000,5 +1983,4 @@ const struct wpa_driver_ops wpa_driver_d
.if_update = i802_if_update,
.if_remove = i802_if_remove,
.get_hw_feature_data = i802_get_hw_feature_data,
- .set_sta_vlan = i802_set_sta_vlan,
};
--- hostap.orig/hostapd/ChangeLog 2007-08-15 14:21:37.000000000 +0200
+++ hostap/hostapd/ChangeLog 2007-08-15 14:21:37.000000000 +0200
@@ -16,6 +16,8 @@ ChangeLog for hostapd
either need to support this or will have to use the WPA/RSN IEs from
hostapd; currently, the included madwifi and bsd driver interfaces do
not have support for this)
+ * removed VLAN support from devicescape driver, the kernel isn't up
+ to it and it need not live in the wireless stack at all.
2007-05-28 - v0.6.0
* added experimental IEEE 802.11r/D6.0 support
On Thu, 2007-08-16 at 20:06 -0700, Jouni Malinen wrote:
> That would break the broadcast domain and if someone really want that,
> they could create a VLAN per STA..
Yeah, I was a bit confused here.
> The purpose of using different group
> keys per VLAN is to allow each VLAN to have a separate broadcast domain,
> i.e., all broadcast packets to STAs bound to this VLAN are available to
> all STAs in this VLAN (and only to them).
Right.
> Since in 802.11 BSS networks, broadcast frames are only sent by the AP,
> hw acceleration can be made to work fine with this kind of
> configuration.
True.
> As far as the clients are concerned, they don't even know
> about the existance of different VLANs and group keys and as such, this
> looks a standard AP to them. As far as the AP is concerned, it will need
> to have support for using multiple keys with hwaccel and way of indexing
> them with each transmitted frame. Taken into account how support for
> hwaccel to unicast frames is implemented, this is quite a simple
> extension to that.
True as well, however, have you considered IBSS networks? As far as I
can tell, there you are actually able to put STAs into VLANs as well,
but you need to use per-VLAN group keys for receiving too.
johannes