Search Linux Wireless

Re: [RFC] cfg80211/mac80211: Add support for Proxy ARP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> > 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.

Oh, sure, I agree - and it doesn't really matter where the learning
comes from. I was just trying to say that the filtering part of "drop
frame only when going to reply" should be entirely doable with something
like nftables' set datastructure (or whatever it's called)

johannes

--
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




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux