Regression in 3.9 caused by "bridge: respect RFC2863 operational state"

Regression in 3.9 caused by "bridge: respect RFC2863 operational state"

[Felix Fietkau]

Hi,

commit 576eb62598f10c8c7fd75703fe89010cdcfff596
Author: stephen hemminger <shemminger@vyatta.com>
Date:   Fri Dec 28 18:15:22 2012 +0000

bridge: respect RFC2863 operational state

This commit breaks putting a mac80211 4-address client mode interface in
a bridge and using it with WPA encryption.

wpa_supplicant has to receive EAP frames for authentication from the
bridge interface, since the rx handler hook steals them from the
wireless interface. However, it also keeps the interface operstate to
IF_OPER_DORMANT for as long as the WPA handshake is incomplete, which
causes the bridge code to drop EAP packets.

In the long run, I'd like to sort out this mess by passing EAP frames to
userspace via nl80211 - but since that will require userspace changes,
what do we do about this issue in the mean time?

- Felix

Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state"

[Krishna Chaitanya]

On Thu, May 2, 2013 at 12:32 AM, Felix Fietkau <nbd-p3rKhJxN3npAfugRpC6u6w@public.gmane.org> wrote:
>
> In the long run, I'd like to sort out this mess by passing EAP frames to
> userspace via nl80211 - but since that will require userspace changes,
> what do we do about this issue in the mean time?

One quick solution i can think of is:

Temporarily we can make the interface UP as soon as
we are associated and then drop the data packets except for
EAPOL-KEY (ETH_H_PAE) frames in the mac80211.

ieee80211_frame_allowed has a rule to drops the unencrypted data frames
we just need to add a rule to drop encrypted data frames.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state"

[Felix Fietkau]

On 2013-05-01 10:21 PM, Stephen Hemminger wrote:
> What about using AF_PACKET bound to underlying wireless device and the
> packet type. You can even use BPF to filter.
As far as I know, AF_PACKET only works when not binding it to the packet
type (otherwise it get stolen by the rx handler).
Not binding it to the packet type and using BPF to filter is expensive
on small embedded devices with small caches. Still, this requires
userspace changes, so we need a different solution.

> Another alternative would be to have bridge accept control frames on
> dormant device but not send.
Sounds good, will you send a patch for that?

- Felix

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state"

[Stephen Hemminger]

On Wed, 01 May 2013 23:06:16 +0200
Felix Fietkau <nbd-p3rKhJxN3npAfugRpC6u6w@public.gmane.org> wrote:

> On 2013-05-01 10:21 PM, Stephen Hemminger wrote:
> > What about using AF_PACKET bound to underlying wireless device and the
> > packet type. You can even use BPF to filter.
> As far as I know, AF_PACKET only works when not binding it to the packet
> type (otherwise it get stolen by the rx handler).

You can do AF_PACKET and it gets handle before rx_handler.

> Not binding it to the packet type and using BPF to filter is expensive
> on small embedded devices with small caches. Still, this requires
> userspace changes, so we need a different solution.
> 
> > Another alternative would be to have bridge accept control frames on
> > dormant device but not send.
> Sounds good, will you send a patch for that?
> 
> - Felix
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state"

[Felix Fietkau]

On 2013-05-02 12:49 AM, Stephen Hemminger wrote:
> On Wed, 01 May 2013 23:06:16 +0200
> Felix Fietkau <nbd-p3rKhJxN3npAfugRpC6u6w@public.gmane.org> wrote:
> 
>> On 2013-05-01 10:21 PM, Stephen Hemminger wrote:
>> > What about using AF_PACKET bound to underlying wireless device and the
>> > packet type. You can even use BPF to filter.
>> As far as I know, AF_PACKET only works when not binding it to the packet
>> type (otherwise it get stolen by the rx handler).
> 
> You can do AF_PACKET and it gets handle before rx_handler.
If I don't bind it to a protocol, it ends up in ptype_all, if I do, it
ends up in &ptype_base. ptype_all is processed before the rx_handler,
ptype_base is processed after the rx handler.
Hooking into ptype_all wastes tons of CPU cycles, hooking into
ptype_base does not solve the problem.

- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state"

[YanBo]

 Sorry to pick up this thread again,  it looks this issue still
existed  in the newer 4.3 kernel. (The EAP frames can not be received
by wireless interface due to the bridge interface,
http://marc.info/?l=linux-wireless&m=136743495526905&w=2)

 Wonder is anyone know some update for this issue?  Currently the only
workaround is make the 4-address  AP and STA associated in security
mode firstly and then create the bridge, the renew key configuration
also need be disable at the hostapd side to  avoid renew the key at
bridge status.

Thanks
Yanbo
> On Wed, May 1, 2013 at 5:53 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> >
> > On 2013-05-02 12:49 AM, Stephen Hemminger wrote:
> > > On Wed, 01 May 2013 23:06:16 +0200
> > > Felix Fietkau <nbd@openwrt.org> wrote:
> > >
> > >> On 2013-05-01 10:21 PM, Stephen Hemminger wrote:
> > >> > What about using AF_PACKET bound to underlying wireless device and the
> > >> > packet type. You can even use BPF to filter.
> > >> As far as I know, AF_PACKET only works when not binding it to the packet
> > >> type (otherwise it get stolen by the rx handler).
> > >
> > > You can do AF_PACKET and it gets handle before rx_handler.
> > If I don't bind it to a protocol, it ends up in ptype_all, if I do, it
> > ends up in &ptype_base. ptype_all is processed before the rx_handler,
> > ptype_base is processed after the rx handler.
> > Hooking into ptype_all wastes tons of CPU cycles, hooking into
> > ptype_base does not solve the problem.
> >
> > - Felix
> > --
> > 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: Regression in 3.9 caused by "bridge: respect RFC2863 operational state"

[Shajakhan, Mohammed Shafi (Mohammed Shafi)]

Hi all,

Any updates on this please. 

Thanks,
shafi

-----Original Message-----
From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of YanBo
Sent: Friday, December 04, 2015 8:01 AM
To: nbd@openwrt.org; Malinen, Jouni; kvalo@codeaurora.org
Cc: Stephen Hemminger; Krishna Chaitanya; linux-wireless; Sebastian Gottschall; Johannes Berg; netdev; hostap@lists.infradead.org
Subject: Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state"

 Sorry to pick up this thread again,  it looks this issue still existed  in the newer 4.3 kernel. (The EAP frames can not be received by wireless interface due to the bridge interface,
http://marc.info/?l=linux-wireless&m=136743495526905&w=2)

 Wonder is anyone know some update for this issue?  Currently the only workaround is make the 4-address  AP and STA associated in security mode firstly and then create the bridge, the renew key configuration also need be disable at the hostapd side to  avoid renew the key at bridge status.

Thanks
Yanbo
> On Wed, May 1, 2013 at 5:53 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> >
> > On 2013-05-02 12:49 AM, Stephen Hemminger wrote:
> > > On Wed, 01 May 2013 23:06:16 +0200 Felix Fietkau <nbd@openwrt.org> 
> > > wrote:
> > >
> > >> On 2013-05-01 10:21 PM, Stephen Hemminger wrote:
> > >> > What about using AF_PACKET bound to underlying wireless device 
> > >> > and the packet type. You can even use BPF to filter.
> > >> As far as I know, AF_PACKET only works when not binding it to the 
> > >> packet type (otherwise it get stolen by the rx handler).
> > >
> > > You can do AF_PACKET and it gets handle before rx_handler.
> > If I don't bind it to a protocol, it ends up in ptype_all, if I do, 
> > it ends up in &ptype_base. ptype_all is processed before the 
> > rx_handler, ptype_base is processed after the rx handler.
> > Hooking into ptype_all wastes tons of CPU cycles, hooking into 
> > ptype_base does not solve the problem.
> >
> > - Felix
> > --
> > 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
--
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: Regression in 3.9 caused by "bridge: respect RFC2863 operational state"

[YanBo]

There is a fixing in
http://git.openwrt.org/?p=openwrt.git;a=blob_plain;f=target/linux/generic/patches-4.3/120-bridge_allow_receiption_on_disabled_port.patch
for your reference.

Yanbo

On Tue, Jan 19, 2016 at 7:45 AM, Shajakhan, Mohammed Shafi (Mohammed
Shafi) <mohammed-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org> wrote:
> Hi all,
>
> Any updates on this please.
>
> Thanks,
> shafi
>
> -----Original Message-----
> From: linux-wireless-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-wireless-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of YanBo
> Sent: Friday, December 04, 2015 8:01 AM
> To: nbd-p3rKhJxN3npAfugRpC6u6w@public.gmane.org; Malinen, Jouni; kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org
> Cc: Stephen Hemminger; Krishna Chaitanya; linux-wireless; Sebastian Gottschall; Johannes Berg; netdev; hostap-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Subject: Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state"
>
>  Sorry to pick up this thread again,  it looks this issue still existed  in the newer 4.3 kernel. (The EAP frames can not be received by wireless interface due to the bridge interface,
> http://marc.info/?l=linux-wireless&m=136743495526905&w=2)
>
>  Wonder is anyone know some update for this issue?  Currently the only workaround is make the 4-address  AP and STA associated in security mode firstly and then create the bridge, the renew key configuration also need be disable at the hostapd side to  avoid renew the key at bridge status.
>
> Thanks
> Yanbo
>> On Wed, May 1, 2013 at 5:53 PM, Felix Fietkau <nbd-p3rKhJxN3npAfugRpC6u6w@public.gmane.org> wrote:
>> >
>> > On 2013-05-02 12:49 AM, Stephen Hemminger wrote:
>> > > On Wed, 01 May 2013 23:06:16 +0200 Felix Fietkau <nbd-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
>> > > wrote:
>> > >
>> > >> On 2013-05-01 10:21 PM, Stephen Hemminger wrote:
>> > >> > What about using AF_PACKET bound to underlying wireless device
>> > >> > and the packet type. You can even use BPF to filter.
>> > >> As far as I know, AF_PACKET only works when not binding it to the
>> > >> packet type (otherwise it get stolen by the rx handler).
>> > >
>> > > You can do AF_PACKET and it gets handle before rx_handler.
>> > If I don't bind it to a protocol, it ends up in ptype_all, if I do,
>> > it ends up in &ptype_base. ptype_all is processed before the
>> > rx_handler, ptype_base is processed after the rx handler.
>> > Hooking into ptype_all wastes tons of CPU cycles, hooking into
>> > ptype_base does not solve the problem.
>> >
>> > - Felix
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe
>> > linux-wireless" in the body of a message to
>> > majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at
>> > http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state"

[Stephen Hemminger]

On Thu, 3 Dec 2015 18:29:00 -0800
YanBo <dreamfly281-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Sorry to pick up this thread again,  it looks this issue still existed  in
> the newer 4.3 kernel. (The EAP frames can not be received by wireless
> interface due to the bridge interface,
> http://marc.info/?l=linux-wireless&m=136743495526905&w=2)
> 
> Wonder is anyone know some update for this issue?  Currently the only
> workaround is make the 4-address  AP and STA associated in security mode
> firstly and then create the bridge, the renew key configuration also need
> be disable at the hostapd side to  avoid renew the key at bridge status.
> 
> Thanks
> Yanbo

How does wireless device indicate that is up?  It may just be that
the code is missing the logic to propagate operstate correctly.
This is normally done by netif_stacked_transfer_operstate and linkwatch
event.

Also STP can be disabled if you don't need it.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state"

[Felix Fietkau]

On 2016-01-19 22:48, Stephen Hemminger wrote:
> On Thu, 3 Dec 2015 18:29:00 -0800
> YanBo <dreamfly281-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
>> Sorry to pick up this thread again,  it looks this issue still existed  in
>> the newer 4.3 kernel. (The EAP frames can not be received by wireless
>> interface due to the bridge interface,
>> http://marc.info/?l=linux-wireless&m=136743495526905&w=2)
>> 
>> Wonder is anyone know some update for this issue?  Currently the only
>> workaround is make the 4-address  AP and STA associated in security mode
>> firstly and then create the bridge, the renew key configuration also need
>> be disable at the hostapd side to  avoid renew the key at bridge status.
>> 
>> Thanks
>> Yanbo
> 
> How does wireless device indicate that is up?  It may just be that
> the code is missing the logic to propagate operstate correctly.
> This is normally done by netif_stacked_transfer_operstate and linkwatch
> event.
> 
> Also STP can be disabled if you don't need it.
Wireless only the changes the operstate *after* successful
authentication, for which it needs to communicate through the bridge.

- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html