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

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

SGkgYWxsLA0KDQpBbnkgdXBkYXRlcyBvbiB0aGlzIHBsZWFzZS4gDQoNClRoYW5rcywNCnNoYWZp
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsaW51eC13aXJlbGVzcy1vd25l
ckB2Z2VyLmtlcm5lbC5vcmcgW21haWx0bzpsaW51eC13aXJlbGVzcy1vd25lckB2Z2VyLmtlcm5l
bC5vcmddIE9uIEJlaGFsZiBPZiBZYW5Cbw0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAwNCwgMjAx
NSA4OjAxIEFNDQpUbzogbmJkQG9wZW53cnQub3JnOyBNYWxpbmVuLCBKb3VuaTsga3ZhbG9AY29k
ZWF1cm9yYS5vcmcNCkNjOiBTdGVwaGVuIEhlbW1pbmdlcjsgS3Jpc2huYSBDaGFpdGFueWE7IGxp
bnV4LXdpcmVsZXNzOyBTZWJhc3RpYW4gR290dHNjaGFsbDsgSm9oYW5uZXMgQmVyZzsgbmV0ZGV2
OyBob3N0YXBAbGlzdHMuaW5mcmFkZWFkLm9yZw0KU3ViamVjdDogUmU6IFJlZ3Jlc3Npb24gaW4g
My45IGNhdXNlZCBieSAiYnJpZGdlOiByZXNwZWN0IFJGQzI4NjMgb3BlcmF0aW9uYWwgc3RhdGUi
DQoNCiBTb3JyeSB0byBwaWNrIHVwIHRoaXMgdGhyZWFkIGFnYWluLCAgaXQgbG9va3MgdGhpcyBp
c3N1ZSBzdGlsbCBleGlzdGVkICBpbiB0aGUgbmV3ZXIgNC4zIGtlcm5lbC4gKFRoZSBFQVAgZnJh
bWVzIGNhbiBub3QgYmUgcmVjZWl2ZWQgYnkgd2lyZWxlc3MgaW50ZXJmYWNlIGR1ZSB0byB0aGUg
YnJpZGdlIGludGVyZmFjZSwNCmh0dHA6Ly9tYXJjLmluZm8vP2w9bGludXgtd2lyZWxlc3MmbT0x
MzY3NDM0OTU1MjY5MDUmdz0yKQ0KDQogV29uZGVyIGlzIGFueW9uZSBrbm93IHNvbWUgdXBkYXRl
IGZvciB0aGlzIGlzc3VlPyAgQ3VycmVudGx5IHRoZSBvbmx5IHdvcmthcm91bmQgaXMgbWFrZSB0
aGUgNC1hZGRyZXNzICBBUCBhbmQgU1RBIGFzc29jaWF0ZWQgaW4gc2VjdXJpdHkgbW9kZSBmaXJz
dGx5IGFuZCB0aGVuIGNyZWF0ZSB0aGUgYnJpZGdlLCB0aGUgcmVuZXcga2V5IGNvbmZpZ3VyYXRp
b24gYWxzbyBuZWVkIGJlIGRpc2FibGUgYXQgdGhlIGhvc3RhcGQgc2lkZSB0byAgYXZvaWQgcmVu
ZXcgdGhlIGtleSBhdCBicmlkZ2Ugc3RhdHVzLg0KDQpUaGFua3MNCllhbmJvDQo+IE9uIFdlZCwg
TWF5IDEsIDIwMTMgYXQgNTo1MyBQTSwgRmVsaXggRmlldGthdSA8bmJkQG9wZW53cnQub3JnPiB3
cm90ZToNCj4gPg0KPiA+IE9uIDIwMTMtMDUtMDIgMTI6NDkgQU0sIFN0ZXBoZW4gSGVtbWluZ2Vy
IHdyb3RlOg0KPiA+ID4gT24gV2VkLCAwMSBNYXkgMjAxMyAyMzowNjoxNiArMDIwMCBGZWxpeCBG
aWV0a2F1IDxuYmRAb3BlbndydC5vcmc+IA0KPiA+ID4gd3JvdGU6DQo+ID4gPg0KPiA+ID4+IE9u
IDIwMTMtMDUtMDEgMTA6MjEgUE0sIFN0ZXBoZW4gSGVtbWluZ2VyIHdyb3RlOg0KPiA+ID4+ID4g
V2hhdCBhYm91dCB1c2luZyBBRl9QQUNLRVQgYm91bmQgdG8gdW5kZXJseWluZyB3aXJlbGVzcyBk
ZXZpY2UgDQo+ID4gPj4gPiBhbmQgdGhlIHBhY2tldCB0eXBlLiBZb3UgY2FuIGV2ZW4gdXNlIEJQ
RiB0byBmaWx0ZXIuDQo+ID4gPj4gQXMgZmFyIGFzIEkga25vdywgQUZfUEFDS0VUIG9ubHkgd29y
a3Mgd2hlbiBub3QgYmluZGluZyBpdCB0byB0aGUgDQo+ID4gPj4gcGFja2V0IHR5cGUgKG90aGVy
d2lzZSBpdCBnZXQgc3RvbGVuIGJ5IHRoZSByeCBoYW5kbGVyKS4NCj4gPiA+DQo+ID4gPiBZb3Ug
Y2FuIGRvIEFGX1BBQ0tFVCBhbmQgaXQgZ2V0cyBoYW5kbGUgYmVmb3JlIHJ4X2hhbmRsZXIuDQo+
ID4gSWYgSSBkb24ndCBiaW5kIGl0IHRvIGEgcHJvdG9jb2wsIGl0IGVuZHMgdXAgaW4gcHR5cGVf
YWxsLCBpZiBJIGRvLCANCj4gPiBpdCBlbmRzIHVwIGluICZwdHlwZV9iYXNlLiBwdHlwZV9hbGwg
aXMgcHJvY2Vzc2VkIGJlZm9yZSB0aGUgDQo+ID4gcnhfaGFuZGxlciwgcHR5cGVfYmFzZSBpcyBw
cm9jZXNzZWQgYWZ0ZXIgdGhlIHJ4IGhhbmRsZXIuDQo+ID4gSG9va2luZyBpbnRvIHB0eXBlX2Fs
bCB3YXN0ZXMgdG9ucyBvZiBDUFUgY3ljbGVzLCBob29raW5nIGludG8gDQo+ID4gcHR5cGVfYmFz
ZSBkb2VzIG5vdCBzb2x2ZSB0aGUgcHJvYmxlbS4NCj4gPg0KPiA+IC0gRmVsaXgNCj4gPiAtLQ0K
PiA+IFRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNj
cmliZSANCj4gPiBsaW51eC13aXJlbGVzcyIgaW4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIA0K
PiA+IG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcgTW9yZSBtYWpvcmRvbW8gaW5mbyBhdCAgDQo+
ID4gaHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sDQotLQ0KVG8gdW5z
dWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4
LXdpcmVsZXNzIiBpbiB0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2Vy
bmVsLm9yZyBNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8vdmdlci5rZXJuZWwub3JnL21h
am9yZG9tby1pbmZvLmh0bWwNCg==

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@qti.qualcomm.com> wrote:
> 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@gmail.com> 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.

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@gmail.com> 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

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

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

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

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

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

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

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