On Wed, Jun 04, 2014 at 01:47:06PM +0200, Johannes Berg wrote: > It seems to me that ebtables should be able to filter on the ports > already, so I'm not really sure what you mean by this. > > The real issue is the internal forwarding. Is that even necessary? Maybe > instead the bridge could forward back to the same port in some cases, > and you could just disable the internal forwarding in mac80211 entirely? I'd assume that for most Hotspot 2.0 use cases, internal forwarding would be disabled completely, but there may very well be cases where one would like to use ProxyARP with forwarding between associated stations. Doing that through the bridge code above mac80211 should be fine, though, i.e., there is no particular reason why the internal forwarding really needs to be internal within mac80211 as long as the implementation outside is doable (forward back to same port). > Beyond that, even the "only reply when you have a response" part could > be done using the nftables framework, it has quick hash/tree data > structures that say the DHCP server could manage (somehow.) Getting DHCP server involved in Proxy ARP management sounds complex and quite impractical for many cases. I'd expect Hotspot 2.0 APs to work with any deployed DHCP setup and there is not really going to be any coordination between the two apart from the AP obviously seeing the DHCP messages flowing through it. Sure, there could be an interface that allows external control, but I think there needs to be capability to learn automatically from ARP (and IPv6 neighbor messages) and DHCP frames flowing through the AP. -- Jouni Malinen PGP id EFC895FA -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
