openvswitch and hostap?

Discussion:

James Harper

2014-11-15 00:01:22 UTC

Is hostap compatible with openvswitch? If so, do I need to do anything extra?

When I add wlan0 to the vswitch manually, nothing can authenticate. When I put bridge= in the config file, hostapd fails to start. strace says it is looking for some files in /sys that don't exist (/sys/class/net/wlan0/brport/bridge). Those relate to the legacy bridge code, and openvswitch doesn't even have a compatibility layer for that anymore.

I had a look around /sys and there doesn't seem to be anything that would allow hostapd to determine if the wlan interface is part of a bridge or not...

Thanks

James

James Harper

2014-11-15 01:28:20 UTC

Permalink

I just threw this patch together. It runs the 'ovs-vsctl port-to-br' command to determine the name of the bridge, falling back to the old bridge detection method if that fails.

It could be further developed to also add and remove the interface etc, but that's not really the way openvswitch works - interfaces are sticky wrt bridge membership and you don't need to re-add them each boot etc.

Another option would be to add a config parameter that says "don't do any bridge configuration".

James

diff --git a/src/drivers/linux_ioctl.c b/src/drivers/linux_ioctl.c
index 837971d..0fc132a 100644
--- a/src/drivers/linux_ioctl.c
+++ b/src/drivers/linux_ioctl.c
@@ -203,9 +203,24 @@ int linux_br_del_if(int sock, const char *brname, const char *ifname)

int linux_br_get(char *brname, const char *ifname)
{
+ FILE *ovs;
char path[128], brlink[128], *pos;
+ char cmd[128], *tmp;
ssize_t res;

+ os_snprintf(cmd, sizeof(cmd), "ovs-vsctl port-to-br %s",
+ ifname);
+ ovs = popen(cmd, "r");
+ if (ovs) {
+ if (fscanf(ovs, "%m[^ \t\r\n]", &tmp) == 1) {
+ os_strlcpy(brname, tmp, IFNAMSIZ);
+ free(tmp);
+ pclose(ovs);
+ return 0;
+ }
+ pclose(ovs);
+ }
+
os_snprintf(path, sizeof(path), "/sys/class/net/%s/brport/bridge",
ifname);
res = readlink(path, brlink, sizeof(brlink));

Helmut Schaa

2014-11-19 16:39:07 UTC

Permalink

Post by James Harper
I just threw this patch together. It runs the 'ovs-vsctl port-to-br' command to determine the name of the bridge, falling back to the old bridge detection method if that fails.
It could be further developed to also add and remove the interface etc, but that's not really the way openvswitch works - interfaces are sticky wrt bridge membership and you don't need to re-add them each boot etc.
Another option would be to add a config parameter that says "don't do any bridge configuration".

Main problem is that if the wlanX interface is bridged hostapd needs
access for grabbing EAPOL frames off from the bridge device.
So it needs to know the bridge interface.

I'm using this one but did not consider sending it upstream as it is
quite a hack:
https://github.com/hschaa/hostapd/commit/c89daaeca4ee90c8bc158e37acb1b679c823d7ab

Helmut

Junguk Cho

2014-11-19 17:42:50 UTC

Permalink

Hi, I have same issue.

When I add wlanX to bridge in openvswitch, the bridge does not reply EAPOL
frame
even though I set up rules between wlanX and br0 with in_port and out_port
fileds.

I can only see EAPOL (Message 1 of 4 ) in bridge with tcpdump but it did
not reply.
So I assumed EAPOL authentication is related to wlanX.

Is it right? Just wondering why it did not reply to EAPOL message.

Would you please clarify "I'm using this one but did not *consider sending
it upstream* as it is quite a hack"?

Thanks,
Junguk

Post by James Harper

Post by James Harper
I just threw this patch together. It runs the 'ovs-vsctl port-to-br'

command to determine the name of the bridge, falling back to the old bridge
detection method if that fails.

Post by James Harper
It could be further developed to also add and remove the interface etc,

but that's not really the way openvswitch works - interfaces are sticky wrt
bridge membership and you don't need to re-add them each boot etc.

Post by James Harper
Another option would be to add a config parameter that says "don't do

any bridge configuration".
Main problem is that if the wlanX interface is bridged hostapd needs
access for grabbing EAPOL frames off from the bridge device.
So it needs to know the bridge interface.
I'm using this one but did not consider sending it upstream as it is
https://github.com/hschaa/hostapd/commit/c89daaeca4ee90c8bc158e37acb1b679c823d7ab
Helmut
_______________________________________________
HostAP mailing list
http://lists.shmoo.com/mailman/listinfo/hostap

Helmut Schaa

2014-11-19 17:55:00 UTC

Permalink

Post by Junguk Cho
When I add wlanX to bridge in openvswitch, the bridge does not reply EAPOL
frame
even though I set up rules between wlanX and br0 with in_port and out_port
fileds.
I can only see EAPOL (Message 1 of 4 ) in bridge with tcpdump but it did not
reply.
So I assumed EAPOL authentication is related to wlanX.
Is it right? Just wondering why it did not reply to EAPOL message.

hostapd needs to know about the bridge/ovs interface to register a
PF_PACKET socket for EAPOL frames.
Otherwise hostapd opens a socket on wlanX but since EAPOL frames are
data frames they end up being bridged and hostapd never receives them.

Post by Junguk Cho
Would you please clarify "I'm using this one but did not consider sending it
upstream as it is quite a hack"?

I'm using the patch referenced in my previous email but it is more of
a hack then a clean patch ...

Helmut

Junguk Cho

2014-11-19 18:06:59 UTC

Permalink

Oh, I made a mistake.
I did not use hostapd, I only used wpa_supplicant with ovs to use wlan0 as
just port.

My context is a little different, but I think it is the same reason.
Wpa_supplicant use -i option, so I assumed it is the same reason.

Thanks,
Junguk

Post by Junguk Cho

Post by Junguk Cho
When I add wlanX to bridge in openvswitch, the bridge does not reply

EAPOL

Post by Junguk Cho
frame
even though I set up rules between wlanX and br0 with in_port and

out_port

Post by Junguk Cho
fileds.
I can only see EAPOL (Message 1 of 4 ) in bridge with tcpdump but it did

not

Post by Junguk Cho
reply.
So I assumed EAPOL authentication is related to wlanX.
Is it right? Just wondering why it did not reply to EAPOL message.

Post by Junguk Cho
Would you please clarify "I'm using this one but did not consider

sending it

Post by Junguk Cho
upstream as it is quite a hack"?

I'm using the patch referenced in my previous email but it is more of
a hack then a clean patch ...
Helmut

James Harper

2014-11-20 10:05:08 UTC

Permalink

Post by James Harper

Post by James Harper
I just threw this patch together. It runs the 'ovs-vsctl port-to-br' command

to determine the name of the bridge, falling back to the old bridge detection
method if that fails.

Post by James Harper
It could be further developed to also add and remove the interface etc, but

that's not really the way openvswitch works - interfaces are sticky wrt bridge
membership and you don't need to re-add them each boot etc.

Post by James Harper
Another option would be to add a config parameter that says "don't do any

bridge configuration".
Main problem is that if the wlanX interface is bridged hostapd needs
access for grabbing EAPOL frames off from the bridge device.
So it needs to know the bridge interface.
I'm using this one but did not consider sending it upstream as it is
https://github.com/hschaa/hostapd/commit/c89daaeca4ee90c8bc158e37acb
1b679c823d7ab

I think all you really need to do is the detection (the iface-to-br like both yours and my patch does). Adding and removing ports from a bridge is kind of out of place in a program like hostapd, especially with ovs as it remembers port membership anyway. I can kind of see why you might want it with the legacy bridge code, but I still wouldn't do it that way.

It’s a shame ovs doesn't provide the same /sys namespace as bridge... if it did we wouldn't even be having this discussion :(

James

Jouni Malinen

2014-11-23 19:35:55 UTC

Permalink

I cannot really claim to be familiar with Open vSwitch and why it would
be used with a WLAN interface, so could you please provide some more
details on what exact fails without this change? Do you configure the
bridge=<ifname> parameter in hostapd.conf? If so, does this fail with
"nl80211: Adding interface .. into bridge .."?

The default behavior in hostapd will likely need to continue to manage
some bridge cases, e.g., due to limitations on WLAN interface not being
allowed to be add to Linux bridge in station mode (i.e., it needs to
happen only after hostapd has been started). While it would be possible
to do something external to manage this, I'm not aware of very good ways
of doing that (especially with dynamic VLAN interface addition adding
complexity).

I think I'd rather handle Open vSwitch in as simple way as possible and
that may indeed be that not doing anything apart from providing the
bridge ifname in hostapd.conf so that packet sockets can be bound to
receive frames from the correct interface.

Would it be simpler to detect that the configured bridge netdev is Open
VSwitch case rather than the Linux bridge? I'd assume the latter could
at least be identified pretty easily, so the linux_br_add_if() call
could be skipped if brname is not recognized as the Linux bridge.

--
Jouni Malinen PGP id EFC895FA

James Harper

2014-11-24 07:32:59 UTC

Permalink

Post by James Harper

Post by James Harper
I just threw this patch together. It runs the 'ovs-vsctl port-to-br' command

to determine the name of the bridge, falling back to the old bridge detection
method if that fails.

Post by James Harper
It could be further developed to also add and remove the interface etc, but

that's not really the way openvswitch works - interfaces are sticky wrt bridge
membership and you don't need to re-add them each boot etc.

Post by James Harper
Another option would be to add a config parameter that says "don't do any
bridge configuration".

I can't remember exactly what the error was, but it definitely fails with some error. Basically the bridge interface exists but hostapd can't access the /sys/xxx files it expects and gives up an error.

Post by James Harper
The default behavior in hostapd will likely need to continue to manage
some bridge cases, e.g., due to limitations on WLAN interface not being
allowed to be add to Linux bridge in station mode (i.e., it needs to
happen only after hostapd has been started). While it would be possible
to do something external to manage this, I'm not aware of very good ways
of doing that (especially with dynamic VLAN interface addition adding
complexity).
I think I'd rather handle Open vSwitch in as simple way as possible and
that may indeed be that not doing anything apart from providing the
bridge ifname in hostapd.conf so that packet sockets can be bound to
receive frames from the correct interface.
Would it be simpler to detect that the configured bridge netdev is Open
VSwitch case rather than the Linux bridge? I'd assume the latter could
at least be identified pretty easily, so the linux_br_add_if() call
could be skipped if brname is not recognized as the Linux bridge.

I had considered that too. If I understand what you are saying, it would be:
. detect bridge= option
. detect that bridge interface itself already exists
. detect that /sys/.../bridge doesn't exist
. assume that the user knows what they are doing and don't touch any bridge stuff

My patch simplifies the user experience though. Ovs already has the wlanX interface added as a bridge port (even if it appears later it is still already configured as a bridge port), so you simply say interface=wlan0 and hostapd figures out the rest.

I assume Linux will continue to support the old bridge code for a long while yet, but I use openvswitch everywhere else so had hoped it could 'just work' with hostapd too.

James

Chan, Rio

2014-12-01 05:23:25 UTC

Permalink

Hi wifi Champs:

I was stuck on those 2 "memory leak" issue, can any one here help me to solve this issue?

The wifi driver I used here is coming from this git: https://github.com/TI-OpenLink/wl18xx/tree/ol_r8.a8.06

The code I used is here: https://github.com/TI-OpenLink/wl18xx/blob/ol_r8.a8.06/net/mac80211/scan.c

The memory leak dump is in the below.

I looked up the issue list, and I found 1 of them is very similar with the issue I met here:

Please take a look at this link: http://marc.info/?l=linux-wireless&m=136256227623873&w=2

So, any one can help me to solve this issue?

Thanks and appreciated.

BR Rio

comm "softirq", pid 0, jiffies 8888021 (age 10622.593s)

hex dump (first 32 bytes):

00 f4 b2 cf 00 f4 b2 cf 08 f4 b2 cf 08 f4 b2 cf ................

11 2a ff d0 10 b8 fd d0 00 00 00 00 08 41 88 00 .*...........A..

backtrace:

[<c01254bc>] create_object+0x10c/0x25c

[<c068273c>] kmemleak_alloc+0x44/0x78

[<c01228f0>] __kmalloc+0x140/0x228

[<bf075aa0>] cfg80211_inform_bss_frame+0x74/0x1fc [cfg80211]

[<bf0b5ca4>] ieee80211_bss_info_update+0x58/0x300 [mac80211]

[<bf0b6038>] ieee80211_scan_rx+0xec/0x1c0 [mac80211]

[<bf0cc56c>] ieee80211_rx+0x700/0x79c [mac80211]

[<bf14e564>] wl1271_flush_deferred_work+0x34/0x7c [wlcore]

[<bf14e5d0>] wl1271_netstack_work+0x24/0x34 [wlcore]

[<c0067510>] process_one_work+0x13c/0x4b4

[<c0067a1c>] worker_thread+0x194/0x3e0

[<c006c8d0>] kthread+0x98/0xa4

[<c004f7c4>] do_exit+0x0/0x80c

[<ffffffff>] 0xffffffff

unreferenced object 0xd0e168c0 (size 192):

comm "softirq", pid 0, jiffies 7839220 (age 18816.335s)

hex dump (first 32 bytes):

00 09 6d 69 74 61 63 77 6c 61 6e 01 06 98 24 b0 ..mitacwlan...$.

48 60 6c 05 04 01 03 00 00 07 0c 54 57 20 38 03 H`l........TW 8.

backtrace:

[<c01254bc>] create_object+0x10c/0x25c

[<c068273c>] kmemleak_alloc+0x44/0x78

[<c01228f0>] __kmalloc+0x140/0x228

[<bf075310>] cfg80211_bss_update_bss+0x180/0x238 [cfg80211]

[<bf075750>] cfg80211_bss_update+0xe4/0x3c0 [cfg80211]

[<bf075b78>] cfg80211_inform_bss_frame+0x14c/0x1fc [cfg80211]

[<bf0b5ca4>] ieee80211_bss_info_update+0x58/0x300 [mac80211]

[<bf0b6038>] ieee80211_scan_rx+0xec/0x1c0 [mac80211]

[<bf0cc56c>] ieee80211_rx+0x700/0x79c [mac80211]

[<bf14e564>] wl1271_flush_deferred_work+0x34/0x7c [wlcore]

[<bf14e5d0>] wl1271_netstack_work+0x24/0x34 [wlcore]

[<c0067510>] process_one_work+0x13c/0x4b4

[<c0067a1c>] worker_thread+0x194/0x3e0

[<c006c8d0>] kthread+0x98/0xa4

[<c004f7c4>] do_exit+0x0/0x80c

[<ffffffff>] 0xffffffff

unreferenced object 0xd0ca2c00 (size 512):

Ben Greear

2014-12-01 16:16:23 UTC

Permalink

What kernel version is this? I remember fixing some leaks in this
area back in the 3.9 kernels (I think, maybe it was a different kernel...)

Thanks,
Ben

I was stuck on those 2 “memory leak” issue, can any one here help me to solve this issue?
The wifi driver I used here is coming from this git: https://github.com/TI-OpenLink/wl18xx/tree/ol_r8.a8.06
The code I used is here: https://github.com/TI-OpenLink/wl18xx/blob/ol_r8.a8.06/net/mac80211/scan.c
The memory leak dump is in the below.
Please take a look at this link: http://marc.info/?l=linux-wireless&m=136256227623873&w=2
So, any one can help me to solve this issue?
Thanks and appreciated.
BR Rio
comm "softirq", pid 0, jiffies 8888021 (age 10622.593s)
00 f4 b2 cf 00 f4 b2 cf 08 f4 b2 cf 08 f4 b2 cf ................
11 2a ff d0 10 b8 fd d0 00 00 00 00 08 41 88 00 .*...........A..
[<c01254bc>] create_object+0x10c/0x25c
[<c068273c>] kmemleak_alloc+0x44/0x78
[<c01228f0>] __kmalloc+0x140/0x228
[<bf075aa0>] cfg80211_inform_bss_frame+0x74/0x1fc [cfg80211]
[<bf0b5ca4>] ieee80211_bss_info_update+0x58/0x300 [mac80211]
[<bf0b6038>] ieee80211_scan_rx+0xec/0x1c0 [mac80211]
[<bf0cc56c>] ieee80211_rx+0x700/0x79c [mac80211]
[<bf14e564>] wl1271_flush_deferred_work+0x34/0x7c [wlcore]
[<bf14e5d0>] wl1271_netstack_work+0x24/0x34 [wlcore]
[<c0067510>] process_one_work+0x13c/0x4b4
[<c0067a1c>] worker_thread+0x194/0x3e0
[<c006c8d0>] kthread+0x98/0xa4
[<c004f7c4>] do_exit+0x0/0x80c
[<ffffffff>] 0xffffffff
comm "softirq", pid 0, jiffies 7839220 (age 18816.335s)
00 09 6d 69 74 61 63 77 6c 61 6e 01 06 98 24 b0 ..mitacwlan...$.
48 60 6c 05 04 01 03 00 00 07 0c 54 57 20 38 03 H`l........TW 8.
[<c01254bc>] create_object+0x10c/0x25c
[<c068273c>] kmemleak_alloc+0x44/0x78
[<c01228f0>] __kmalloc+0x140/0x228
[<bf075310>] cfg80211_bss_update_bss+0x180/0x238 [cfg80211]
[<bf075750>] cfg80211_bss_update+0xe4/0x3c0 [cfg80211]
[<bf075b78>] cfg80211_inform_bss_frame+0x14c/0x1fc [cfg80211]
[<bf0b5ca4>] ieee80211_bss_info_update+0x58/0x300 [mac80211]
[<bf0b6038>] ieee80211_scan_rx+0xec/0x1c0 [mac80211]
[<bf0cc56c>] ieee80211_rx+0x700/0x79c [mac80211]
[<bf14e564>] wl1271_flush_deferred_work+0x34/0x7c [wlcore]
[<bf14e5d0>] wl1271_netstack_work+0x24/0x34 [wlcore]
[<c0067510>] process_one_work+0x13c/0x4b4
[<c0067a1c>] worker_thread+0x194/0x3e0
[<c006c8d0>] kthread+0x98/0xa4
[<c004f7c4>] do_exit+0x0/0x80c
[<ffffffff>] 0xffffffff
_______________________________________________
HostAP mailing list
http://lists.shmoo.com/mailman/listinfo/hostap

--
Ben Greear <***@candelatech.com>
Candela Technologies Inc http://www.candelatech.com

Arend van Spriel

2014-12-01 17:19:54 UTC

Permalink

Post by Ben Greear
What kernel version is this? I remember fixing some leaks in this
area back in the 3.9 kernels (I think, maybe it was a different kernel...)

The toplevel Makefile in the referred github repo says:

VERSION = 3
PATCHLEVEL = 12
SUBLEVEL = 0
EXTRAVERSION = -rc1
NAME = One Giant Leap for Frogkind

Regards,
Arend

Post by Ben Greear
Thanks,
Ben

Ben Greear

2014-12-01 17:22:45 UTC

Permalink

Post by Arend van Spriel

Post by Ben Greear
What kernel version is this? I remember fixing some leaks in this
area back in the 3.9 kernels (I think, maybe it was a different kernel...)

VERSION = 3
PATCHLEVEL = 12
SUBLEVEL = 0
EXTRAVERSION = -rc1
NAME = One Giant Leap for Frogkind

I'm not sure when the fixes that Johannes and I worked on when in,
and too busy right now to check..but you might do some searching in
mainline kernel and see if they are in your git tree.

Thanks,
Ben

--
Ben Greear <***@candelatech.com>
Candela Technologies Inc http://www.candelatech.com

Dan Williams

2014-11-24 18:26:20 UTC

Permalink

Post by Jouni Malinen

I cannot really claim to be familiar with Open vSwitch and why it would
be used with a WLAN interface, so could you please provide some more
details on what exact fails without this change? Do you configure the
bridge=<ifname> parameter in hostapd.conf? If so, does this fail with
"nl80211: Adding interface .. into bridge .."?
The default behavior in hostapd will likely need to continue to manage
some bridge cases, e.g., due to limitations on WLAN interface not being
allowed to be add to Linux bridge in station mode (i.e., it needs to
happen only after hostapd has been started). While it would be possible
to do something external to manage this, I'm not aware of very good ways
of doing that (especially with dynamic VLAN interface addition adding
complexity).
I think I'd rather handle Open vSwitch in as simple way as possible and
that may indeed be that not doing anything apart from providing the
bridge ifname in hostapd.conf so that packet sockets can be bound to
receive frames from the correct interface.
Would it be simpler to detect that the configured bridge netdev is Open
VSwitch case rather than the Linux bridge? I'd assume the latter could
at least be identified pretty easily, so the linux_br_add_if() call
could be skipped if brname is not recognized as the Linux bridge.

OVS bridges aren't regular Linux bridge devices, so you can't use the
standard linux bridge detection mechanism. They are really just
passthrough netdevs that put most of the flow logic and switching
decisions in userspace.

They do return 'openvswitch' as the driver name for ETHTOOL_GDRVINFO, or
you can look at the 'driver' link for the device in sysfs which will be
"openvswitch".

But unfortunately I think you do need ovs-vsctl for adding/removing
ports to/from the OVS bridge netdev. I don't believe there's a way to
do it with netlink.

Dan