[lxc-users] Is it possible to create a wireless bridge with proxy_arp

[Michael H. Warfield]

On Sat, 2014-04-19 at 16:57 +0200, phep wrote:
> Hi,

> While it is easy to have the containers in the same net as the host using 
> veth interfaces and a bridge on the host, this does not work when the host 
> is connected to the network through a wireless device.

> Using KVM guests, one may overcome the difficulties creating a tap device 
> for the guest, enabling proxy_arp on both the tap and wireless devices then 
> adding the host IP address to the tap interface then a route from the host 
> to the guest (see e.g. 
> http://blog.ericwhite.ca/articles/2011/04/creating-a-wireless-bridge/).

I can not reach this site.  Do you have another URL?  I would like to
review that article.

> I've googled around for some time tonight to find if this would be possible 
> to set up with LXC containers but it does not seem to. Am I wrong ?

> If not are there any plan about something like this ?

> This would be very handy on laptop.

No.  Well, maybe.  And maybe looks pretty grim.  How much of a masochist
are you?  I looked into this off and on over several years and just
recently several months ago.

It seems the kernel itself prohibits most WiFi devices from being joined
to a bridge and there are some very good reasons for this.  There's
several modes the WiFi device can be in.  As a client, one is adhoc and
another is managed.  It can also be placed in AP mode to act as an
access point and then are some bridging modes that allow a WiFi
interface to act as a WiFi extender or client adapter.  It can also be
put into a promiscuous mode ala Kismit for WiFi sniffing.

The fundamental issue with WiFi is that in adhoc or managed modes (the
basic client modes) the client is not allowed, by the standard, to
support multiple mac addresses.  Ergo, you can not allow bridging as
that would place multiple mac addresses from that client adapter and the
access point would not know how to handle it.  The client associations
would be broken at the wireless mac layer.  IOW...  The access point
would have no way to route the bridged macs back because it has no
association with them.

I understand that the kernel use to allow this to be done but they put
the restrictions in place for recent kernels.  I don't know what rev
this was done or why it suddenly became an issue but it did.  Looks like
that article is 3 years old.  It may have been written before those
kernel restrictions.  OTOH...  I find the references to the tap device
interesting.  Mostly, in the past, I've seen tap used with OpenVPN to
set up tunneled bridging.  Is that what they were advocating?  That
should work as well.  You could manually set up a tap tunnel at each
end, even without OpenVPN, and manually tunnel it.  If you set up tap
devices between the host and access point, you're then tunneling
everything under WiFi client connection and the AP only sees the client
MAC address but the tap devices and tunnel deal with the other devices.
I really need to read that referenced article to  comment further on
what they were doing but, regardless, that's not an LXC issue.  That's
an outer host issue to be set up.

There is a way to do it but it's very complicated.  I haven't tried this
at all.  The way is to get the WiFi interface into "wireless repeater"
or "wireless extender" or "wireless bridge" mode where it can act like a
mini-access point and communicate access-point to access-point.  I've
tried doing this in the past running Linksys to Linksys routers with
mixed success both with stock firmware and DD-WRT firmware.  The setup
alone is not for the faint of heart.

You'll notice, none of this has a thing to do with LXC.  Everything has
to do with the WiFi communications and how you get it set up in the
kernel.  If you can get a wlan interface connected to a bridge using
whatever options and black magic you can bring to bare, you can use LXC
with it.  But...  NetworkManagler (err NetworkManger) doesn't support
most of those client bridge and repeater options and it does not play
nicey nicey with bridges in general.  That means you're going to have to
manually deal with wpa_supplicant and iwconfig yourself before building
the bridge and adding the interface to it.  That's all before you can
even come close to LXC.

Where it comes to WiFi, you're better off going with a NAT'ed
connection.

I would love to be proven wrong here...  I could also use it.

> Cheers,

> Patrice

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140419/c3fc1d70/attachment.sig>