* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" [not found] <CAFuUQkhHsRZMnNYBbVZU0=BcAKMEktzYgPv6oc=CMFd7MFDi6g@mail.gmail.com> @ 2015-12-04 2:31 ` YanBo 2016-01-19 15:45 ` Shajakhan, Mohammed Shafi (Mohammed Shafi) 2016-01-19 21:48 ` Stephen Hemminger 1 sibling, 1 reply; 18+ messages in thread From: YanBo @ 2015-12-04 2:31 UTC (permalink / raw) To: Felix Fietkau, jouni, kvalo Cc: Stephen Hemminger, Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev, hostap 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2016-01-19 15:45 ` Shajakhan, Mohammed Shafi (Mohammed Shafi) 0 siblings, 0 replies; 18+ messages in thread From: Shajakhan, Mohammed Shafi (Mohammed Shafi) @ 2016-01-19 15:45 UTC (permalink / raw) To: YanBo, nbd, Malinen, Jouni, kvalo Cc: Stephen Hemminger, Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev, hostap 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== ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2016-01-19 15:45 ` Shajakhan, Mohammed Shafi (Mohammed Shafi) 0 siblings, 0 replies; 18+ messages in thread From: Shajakhan, Mohammed Shafi (Mohammed Shafi) @ 2016-01-19 15:45 UTC (permalink / raw) To: YanBo, nbd-p3rKhJxN3npAfugRpC6u6w, Malinen, Jouni, kvalo-sgV2jX0FEOL9JmXXK+q4OQ Cc: Stephen Hemminger, Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev, hostap-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2016-01-19 21:10 ` YanBo 0 siblings, 0 replies; 18+ messages in thread From: YanBo @ 2016-01-19 21:10 UTC (permalink / raw) To: Shajakhan, Mohammed Shafi (Mohammed Shafi) Cc: nbd, Malinen, Jouni, kvalo, Stephen Hemminger, Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev, hostap 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2016-01-19 21:10 ` YanBo 0 siblings, 0 replies; 18+ messages in thread From: YanBo @ 2016-01-19 21:10 UTC (permalink / raw) To: Shajakhan, Mohammed Shafi (Mohammed Shafi) Cc: nbd-p3rKhJxN3npAfugRpC6u6w, Malinen, Jouni, kvalo-sgV2jX0FEOL9JmXXK+q4OQ, Stephen Hemminger, Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev, hostap-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2016-01-19 21:48 ` Stephen Hemminger 0 siblings, 0 replies; 18+ messages in thread From: Stephen Hemminger @ 2016-01-19 21:48 UTC (permalink / raw) To: YanBo Cc: Felix Fietkau, jouni, kvalo, Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev, hostap 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2016-01-19 21:48 ` Stephen Hemminger 0 siblings, 0 replies; 18+ messages in thread From: Stephen Hemminger @ 2016-01-19 21:48 UTC (permalink / raw) To: YanBo Cc: Felix Fietkau, jouni-A+ZNKFmMK5xy9aJCnZT0Uw, kvalo-sgV2jX0FEOL9JmXXK+q4OQ, Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev, hostap-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" 2016-01-19 21:48 ` Stephen Hemminger @ 2016-01-19 21:55 ` Felix Fietkau -1 siblings, 0 replies; 18+ messages in thread From: Felix Fietkau @ 2016-01-19 21:55 UTC (permalink / raw) To: Stephen Hemminger, YanBo Cc: jouni, kvalo, Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev, hostap 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2016-01-19 21:55 ` Felix Fietkau 0 siblings, 0 replies; 18+ messages in thread From: Felix Fietkau @ 2016-01-19 21:55 UTC (permalink / raw) To: Stephen Hemminger, YanBo Cc: jouni-A+ZNKFmMK5xy9aJCnZT0Uw, kvalo-sgV2jX0FEOL9JmXXK+q4OQ, Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev, hostap-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2013-05-01 19:02 Felix Fietkau 2013-05-01 19:49 ` Krishna Chaitanya 0 siblings, 1 reply; 18+ messages in thread From: Felix Fietkau @ 2013-05-01 19:02 UTC (permalink / raw) To: netdev, linux-wireless Cc: Stephen Hemminger, Johannes Berg, Sebastian Gottschall 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2013-05-01 19:49 ` Krishna Chaitanya 0 siblings, 0 replies; 18+ messages in thread From: Krishna Chaitanya @ 2013-05-01 19:49 UTC (permalink / raw) To: Felix Fietkau Cc: netdev, linux-wireless, Stephen Hemminger, Johannes Berg, Sebastian Gottschall 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2013-05-01 19:49 ` Krishna Chaitanya 0 siblings, 0 replies; 18+ messages in thread From: Krishna Chaitanya @ 2013-05-01 19:49 UTC (permalink / raw) To: Felix Fietkau Cc: netdev, linux-wireless, Stephen Hemminger, Johannes Berg, Sebastian Gottschall 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <CAOaVG179Rx_JfV99mbjWhwQTALb5gh+2_WVFWDSbngA0qkzoGw@mail.gmail.com>]
* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2013-05-01 21:06 ` Felix Fietkau 0 siblings, 0 replies; 18+ messages in thread From: Felix Fietkau @ 2013-05-01 21:06 UTC (permalink / raw) To: Stephen Hemminger Cc: Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2013-05-01 21:06 ` Felix Fietkau 0 siblings, 0 replies; 18+ messages in thread From: Felix Fietkau @ 2013-05-01 21:06 UTC (permalink / raw) To: Stephen Hemminger Cc: Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2013-05-01 22:49 ` Stephen Hemminger 0 siblings, 0 replies; 18+ messages in thread From: Stephen Hemminger @ 2013-05-01 22:49 UTC (permalink / raw) To: Felix Fietkau Cc: Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev 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 > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2013-05-01 22:49 ` Stephen Hemminger 0 siblings, 0 replies; 18+ messages in thread From: Stephen Hemminger @ 2013-05-01 22:49 UTC (permalink / raw) To: Felix Fietkau Cc: Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2013-05-02 0:53 ` Felix Fietkau 0 siblings, 0 replies; 18+ messages in thread From: Felix Fietkau @ 2013-05-02 0:53 UTC (permalink / raw) To: Stephen Hemminger Cc: Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Regression in 3.9 caused by "bridge: respect RFC2863 operational state" @ 2013-05-02 0:53 ` Felix Fietkau 0 siblings, 0 replies; 18+ messages in thread From: Felix Fietkau @ 2013-05-02 0:53 UTC (permalink / raw) To: Stephen Hemminger Cc: Krishna Chaitanya, linux-wireless, Sebastian Gottschall, Johannes Berg, netdev 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2016-01-19 21:55 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAFuUQkhHsRZMnNYBbVZU0=BcAKMEktzYgPv6oc=CMFd7MFDi6g@mail.gmail.com> 2015-12-04 2:31 ` Regression in 3.9 caused by "bridge: respect RFC2863 operational state" YanBo 2016-01-19 15:45 ` Shajakhan, Mohammed Shafi (Mohammed Shafi) 2016-01-19 15:45 ` Shajakhan, Mohammed Shafi (Mohammed Shafi) 2016-01-19 21:10 ` YanBo 2016-01-19 21:10 ` YanBo 2016-01-19 21:48 ` Stephen Hemminger 2016-01-19 21:48 ` Stephen Hemminger 2016-01-19 21:55 ` Felix Fietkau 2016-01-19 21:55 ` Felix Fietkau 2013-05-01 19:02 Felix Fietkau 2013-05-01 19:49 ` Krishna Chaitanya 2013-05-01 19:49 ` Krishna Chaitanya [not found] ` <CAOaVG179Rx_JfV99mbjWhwQTALb5gh+2_WVFWDSbngA0qkzoGw@mail.gmail.com> 2013-05-01 21:06 ` Felix Fietkau 2013-05-01 21:06 ` Felix Fietkau 2013-05-01 22:49 ` Stephen Hemminger 2013-05-01 22:49 ` Stephen Hemminger 2013-05-02 0:53 ` Felix Fietkau 2013-05-02 0:53 ` Felix Fietkau
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.