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
