Re: RX processing order for packet sockets and bridge
On Wed, Mar 29, 2006 at 01:16:30PM -0800, [EMAIL PROTECTED] wrote: With STP disabled it is still possible to use the same type of packet socket to receive EAPOL frames. However, the frames will now end up being received from the bridge interface (e.g., br0), not Ethernet (eth0). In other words, the supplicant will need to know that it needs to bind to another interface. That is fixed in 2.6.17, STP and other link local frames go up through the stack, but are not forwarded. Thanks! This does indeed fix the issue I was seeing and does it nicely without requiring complex workarounds for being able to process EAPOL frames. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RX processing order for packet sockets and bridge
On Wed, 2006-29-03 at 13:16 -0800, [EMAIL PROTECTED] wrote: On Wed, 2006-29-03 at 11:14 -0800, Jouni Malinen wrote: [..] A digression: One of the problems of the bridge in my opinion is having STP, a control protocol, inside the kernel. I do hope someone with time will rip it out of the kernel some day. I looked into it, but the size of STP is less than the amount of stuff needed to make it have the control hooks in user space. I think thats a fine trade-off. The advantage of putting it in user space is its a lot easier to add newer features. The current STP - by virtue of being in the kernel - is missing a lot of newer developments. Plus there would be a lot of new race issues to deal with. If there are races it only goes further to prove there's a serious problem continuing to keep it in the kernel. The only thing that really oughta stay in the kernel is the state machine - perhaps extended to allow multiple trees per bridge. cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RX processing order for packet sockets and bridge
jamal wrote: On Wed, 2006-29-03 at 13:16 -0800, [EMAIL PROTECTED] wrote: On Wed, 2006-29-03 at 11:14 -0800, Jouni Malinen wrote: [..] A digression: One of the problems of the bridge in my opinion is having STP, a control protocol, inside the kernel. I do hope someone with time will rip it out of the kernel some day. I looked into it, but the size of STP is less than the amount of stuff needed to make it have the control hooks in user space. I think thats a fine trade-off. The advantage of putting it in user space is its a lot easier to add newer features. The current STP - by virtue of being in the kernel - is missing a lot of newer developments. There already exists a version of the new RSTP done on old version of 2.4. It looks easier and better to just fix that and bring it up to date. Plus there would be a lot of new race issues to deal with. If there are races it only goes further to prove there's a serious problem continuing to keep it in the kernel. The only thing that really oughta stay in the kernel is the state machine - perhaps extended to allow multiple trees per bridge. The problem is you can't have a user space application lock the kernel. But you can have a kernel thread grab a lock. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RX processing order for packet sockets and bridge
On Wed, 2006-29-03 at 11:14 -0800, Jouni Malinen wrote: [..] A digression: One of the problems of the bridge in my opinion is having STP, a control protocol, inside the kernel. I do hope someone with time will rip it out of the kernel some day. With STP disabled it is still possible to use the same type of packet socket to receive EAPOL frames. However, the frames will now end up being received from the bridge interface (e.g., br0), not Ethernet (eth0). In other words, the supplicant will need to know that it needs to bind to another interface. It would probably be fine if you are able to tell that the original source of the packet was eth0; are you able to do that? With STP enabled, the EAPOL frames to 01:80:c2:00:00:03 are not received anymore, so IEEE 802.1X authentication does not work with this kind of packet socket use. br_handle_frame() (called via br_handle_frame_hook) has code that processes all 01:80:c2:00:00:0? frames differently. 01:80:c2:00:00:00 will be delivered to NF_BR_LOCAL_IN and consumed internally (I would assume). Packets to other 01:80:c2:00:00:0? addresses get dropped. This is understandable since these are special addresses that bridges are not supposed to forward. However, IEEE 802.1X uses one of these addresses and those frames should be made available to user space programs (but without forwarding them to other ports). yes, that is a nasty assumption. What could be done to make this work better? If the supplicant would not bind to a specific sll_protocol, the packets are received at eth0 and this works. However, lots of other packets would also be received and user space filtering for these is not really a good idea. One could probably use Linux socket filters to do filtering in kernel (if those are processed before packet sockets; I did not yet verify this), this works fine. Need a little libpcap magic. but even that is somewhat complex solution compared to binding a packet socket to sll_protocol=EAPOL. One option would be to move packet socket handlers to be called before handle_bridge() call for both the cases where they are bound to a specific protocol and where they are not. This would allow EAPOL frames to be received from eth0 regardless of whether the device is in a bridge or not. This sounds like the cleanest solution from the user space viewpoint. In the future you should be able to use tc action to redirect to user space packet socket. You can do it today but only redirect to a netdevice. As an example you can redirect to a tuntap and then process in user space - if that is sufficient for you; you just need a 2.6.x kernel (x=8) and i will be willing to spend some time explaining the details to you (its not that complicated actually). Would this be feasible? Can all protocol (ptype_base[type]) handlers be called before handle_bridge() or would there need to be special case for packet sockets? Another option would be to teach bridge code about this special-special case and make br_handle_frame() return 0 if destination address is 01:80:c2:00:00:03. This is also acceptable in my view. The bridge code should have an exception table of what not to swallow. You should be able to add such packet descriptions via the ioctl interface that exists right now. Doing this for the stp_enabled case seemed to resolve the problem I was seeing with wpa_supplicant not receiving the frames when STP was enabled. However, since this was only for stp_enabled, the frames in STP disabled case were received from br0, not eth0. It would be possible to return 0 from br_handle_frame() for both cases with some extra CPU use (i.e., one new memcmp() regardless of whether STP is enabled or not). This should allow EAPOL frames to be received from eth0 in all cases using packet socket with sll_protocol bound to EAPOL, so user space side would be as clean as the first option I mentioned above. However, this would be a specific solution for this particular issue with IEEE 802.1X. Would this be acceptable, if moving packet socket handlers in netif_receive_skb() is consider too expensive? Is anyone aware of a better solution for this issue? Consider the option of redirect packets as an option. cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RX processing order for packet sockets and bridge
The generic solution here is to use ebtables - the broute chain is there to perform exactly this kind of filtering. Set a rule in the broute chain to route these EAPOL frames, rather than bridging them. Then open the packet socket on the original interface. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jouni Malinen Sent: Wednesday, March 29, 2006 11:14 AM To: netdev@vger.kernel.org Subject: RX processing order for packet sockets and bridge The current netif_receive_skb() implementation is delivering packets to all ptype_all handlers before calling handle_bridge() and to all ptype_base[type] handlers after calling handle_bridge(). This causes somewhat unfortunate difference in how packet sockets work based on whether they are bound to a specific sll_protocol or not for the case of special frames that bridge (stp) code processes internally. This does not probably matter much for most cases, but this breaks some applications. I'm looking at an issue where IEEE 802.1X authentication is used on an Ethernet device. In such a case, EAPOL frames are sent to special PAE group address (01:80:c2:00:00:03) with ethertype=EAPOL. At least for me, the most logical way of receiving these frames is to use a packet socket bound to the selected sll_ifndex and sll_protocol=EAPOL. This works fine whenever the network device is not part of a bridge. However, this gets difficult when the interface is added to a bridge. With STP disabled it is still possible to use the same type of packet socket to receive EAPOL frames. However, the frames will now end up being received from the bridge interface (e.g., br0), not Ethernet (eth0). In other words, the supplicant will need to know that it needs to bind to another interface. With STP enabled, the EAPOL frames to 01:80:c2:00:00:03 are not received anymore, so IEEE 802.1X authentication does not work with this kind of packet socket use. br_handle_frame() (called via br_handle_frame_hook) has code that processes all 01:80:c2:00:00:0? frames differently. 01:80:c2:00:00:00 will be delivered to NF_BR_LOCAL_IN and consumed internally (I would assume). Packets to other 01:80:c2:00:00:0? addresses get dropped. This is understandable since these are special addresses that bridges are not supposed to forward. However, IEEE 802.1X uses one of these addresses and those frames should be made available to user space programs (but without forwarding them to other ports). What could be done to make this work better? If the supplicant would not bind to a specific sll_protocol, the packets are received at eth0 and this works. However, lots of other packets would also be received and user space filtering for these is not really a good idea. One could probably use Linux socket filters to do filtering in kernel (if those are processed before packet sockets; I did not yet verify this), but even that is somewhat complex solution compared to binding a packet socket to sll_protocol=EAPOL. One option would be to move packet socket handlers to be called before handle_bridge() call for both the cases where they are bound to a specific protocol and where they are not. This would allow EAPOL frames to be received from eth0 regardless of whether the device is in a bridge or not. This sounds like the cleanest solution from the user space viewpoint. Would this be feasible? Can all protocol (ptype_base[type]) handlers be called before handle_bridge() or would there need to be special case for packet sockets? Another option would be to teach bridge code about this special-special case and make br_handle_frame() return 0 if destination address is 01:80:c2:00:00:03. Doing this for the stp_enabled case seemed to resolve the problem I was seeing with wpa_supplicant not receiving the frames when STP was enabled. However, since this was only for stp_enabled, the frames in STP disabled case were received from br0, not eth0. It would be possible to return 0 from br_handle_frame() for both cases with some extra CPU use (i.e., one new memcmp() regardless of whether STP is enabled or not). This should allow EAPOL frames to be received from eth0 in all cases using packet socket with sll_protocol bound to EAPOL, so user space side would be as clean as the first option I mentioned above. However, this would be a specific solution for this particular issue with IEEE 802.1X. Would this be acceptable, if moving packet socket handlers in netif_receive_skb() is consider too expensive? Is anyone aware of a better solution for this issue? -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
