diff mbox

openvswitch and hostap?

Message ID 52b3cc5d340e4427aaaf4dd7003e7fa3@HKNPR04MB0388.apcprd04.prod.outlook.com
State Changes Requested
Headers show

Commit Message

James Harper Nov. 15, 2014, 1:28 a.m. UTC 
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

Comments

Helmut Schaa Nov. 19, 2014, 4:39 p.m. UTC | #1 
On Sat, Nov 15, 2014 at 2:28 AM, James Harper <james@ejbdigital.com.au> wrote:
> 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 Nov. 19, 2014, 5:42 p.m. UTC | #2 
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

2014-11-19 9:39 GMT-07:00 Helmut Schaa <helmut.schaa@googlemail.com>:

> On Sat, Nov 15, 2014 at 2:28 AM, James Harper <james@ejbdigital.com.au>
> wrote:
> > 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
> _______________________________________________
> HostAP mailing list
> HostAP@lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>
Helmut Schaa Nov. 19, 2014, 5:55 p.m. UTC | #3 
On Wed, Nov 19, 2014 at 6:42 PM, Junguk Cho <jmanbal@gmail.com> wrote:
> 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.

> 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 Nov. 19, 2014, 6:06 p.m. UTC | #4 
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

2014-11-19 10:55 GMT-07:00 Helmut Schaa <helmut.schaa@googlemail.com>:

> On Wed, Nov 19, 2014 at 6:42 PM, Junguk Cho <jmanbal@gmail.com> wrote:
> > 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.
>
> > 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
>
James Harper Nov. 20, 2014, 10:05 a.m. UTC | #5 
> 

> On Sat, Nov 15, 2014 at 2:28 AM, James Harper <james@ejbdigital.com.au>

> wrote:

> > 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/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 Nov. 23, 2014, 7:35 p.m. UTC | #6 
On Sat, Nov 15, 2014 at 01:28:20AM +0000, James Harper wrote:
> 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".

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.
James Harper Nov. 24, 2014, 7:32 a.m. UTC | #7 
> 
> On Sat, Nov 15, 2014 at 01:28:20AM +0000, James Harper wrote:
> > 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".
> 
> 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 .."?

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.

> 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
Dan Williams Nov. 24, 2014, 6:26 p.m. UTC | #8 
On Sun, 2014-11-23 at 21:35 +0200, Jouni Malinen wrote:
> On Sat, Nov 15, 2014 at 01:28:20AM +0000, James Harper wrote:
> > 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".
> 
> 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
Chan, Rio Dec. 1, 2014, 5:23 a.m. UTC | #9 
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 Dec. 1, 2014, 4:16 p.m. UTC | #10 
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


On 11/30/2014 09:23 PM, Chan, Rio wrote:
> 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):
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> HostAP mailing list
> HostAP@lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>
Arend van Spriel Dec. 1, 2014, 5:19 p.m. UTC | #11 
On 12/01/14 17:16, Ben Greear wrote:
> 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

> Thanks,
> Ben
>
>
> On 11/30/2014 09:23 PM, Chan, Rio wrote:
>> 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):
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> HostAP mailing list
>> HostAP@lists.shmoo.com
>> http://lists.shmoo.com/mailman/listinfo/hostap
>>
>
>
Ben Greear Dec. 1, 2014, 5:22 p.m. UTC | #12 
On 12/01/2014 09:19 AM, Arend van Spriel wrote:
> On 12/01/14 17:16, Ben Greear wrote:
>> 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

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
diff mbox

Patch

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