> 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. Plus there would be a lot of new race issues to deal with. >> 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. > > 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. Already fixed in the current -git kernel tree. All packets get pushed up stack but 01:80:c2:00:00:xx addresses are not forwareded. It is actually in one of the 802.1 standards that these should not be forwarded. >> 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 > - 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
