On Wed, Jun 4, 2014 at 6:46 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2014-06-04 at 16:42 +0300, Jouni Malinen wrote: >> 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). > > Right - I think currently the forward back to the same port part would > be missing. We should probably have a wider discussion with > bridging/nftables/etc. folks. I have some virtualization interests on this topic as well. The same problem and need is present if one wants to implement a clean solution to use 802.11 on the backend dom0 to share given we can't bridge 802.11, additionally there is a bit of overhead I see with existing virtualization strategies on relying on full backend device drivers in *addition* to the TAP interfaces created by qemu, what I hope for is doing away with the backend device drivers completely. There are issues with this architecturally though and although I'm not yet a fan of the existing code the DPDK [0] code is one example strategy. The way I was thinking about this was having APIs for userspace to deal with the a proxy arp requirements which are currently not handled in the kernel. [0] http://dpdk.org/ Luis -- 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
