[lxc-users] Is it possible to create a wireless bridge with proxy_arp
Michael H. Warfield
mhw at WittsEnd.com
Mon Apr 21 16:33:34 UTC 2014
On Sat, 2014-04-19 at 21:24 +0200, phep wrote:
> Hi,
> Le 19/04/2014 19:50, Michael H. Warfield a écrit :
> > 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
> As I mentioned, I do this with KVM guests with few efforts. Don't have any
> inclination for suffering indeed!
> > 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.
> While I'm not an expert wrt networking, this is exactly how I understand
> what I'm doing.
> > I really need to read that referenced article to comment further on
> Sorry. I noticed the site was down only after sending my message. Actually,
> I made a short notice for myself about that blog entry some time ago,
> keeping the original URL. This is my summary (the title is misleading since
> there is no bridge involved, actually) in case it helps:
Ok... I've taken a little time to think this over and I might try and
experiment with some things to test out some ideas. Now that I've read
some of what's below, I understand much better what it is that is trying
to being done and, yeah, the title and your original subject are rather
misleading. The idea of using proxy arp with a "bridge" is confusing.
This is not creating a "bridge" at all. I'm actually at a bit of a loss
to understand why the original author chose to create a tap interface,
since it doesn't appear that he's using the tap bridging characteristics
but just seems like he's using it as a placeholder interface that could
just as easily be an internal bridge like virbr0 or lxcbr0 or some such.
Maybe it has something more to do with KVM.
I've used proxy arp in numerous circumstances and never with a tap
interface. That almost seems oximoronic since proxy arp is used with
routed subnetting and tap interfaces are used with mac layer bridging.
I've rarely used tap interfaces and then only in connection with
OpenVPN, and then only when I wanted to propagate network local
broadcast datagrams, but I don't see where a tunnel is being constructed
for a tap bridge to the other side of the wireless connection. But the
proxy arp alone should do the job, anyways for most traffic.
With proxy arp, you would extrude a subnet of a larger net, and then use
proxy arp to respond to the larger net for addresses within the smaller
subnet. That would appear to be what you're doing here.
I've done something similar to this:
192.168.0.0/22 -> (eth0) gateway (eth1) -> 192.168.3.0/24
Gateway is set to forward IPv4 and is configured to proxy arp on eth0.
Note that network 1 (192.168.3.0/24) is a subnet of network 0
(192.168.0.0/22). Machines on network 1 naturally route over to the
default route and out to the outer net. Machines on the outer net don't
know about routing to the smaller net and send arp requests for those
machines. The proxy arp on gateway responses for the machines that it
knows how to route to, so the machines in the outer net get the MAC
address of the gateway and packets get routed to it.
So all machines can communicate as if they were bridged but they're not
really bridged from parent net to subnet (which could be individual IP
addresses). The only thing that doesn't work in this configuration is
services which depend on broadcast packets like netbios name service,
broadcast ntp, etc, etc.
That certainly should be doable, and it looks like it should be what
you're after. I'll test a couple things out and get back. It's been a
few years since I last dabbled in proxy arp.
Regards,
Mike
> ********************************************
> Bridging with a wireless link with proxy_arp
> ********************************************
>
> This is a ultra-short version of
> http://blog.ericwhite.ca/articles/2011/04/creating-a-wireless-bridge/
>
> This installation requires setting static IP for both host and guest.
> We'll assume that:
>
> - host has 192.168.0.153
> - guest has 192.168.0.203
>
> Keep the host's `/etc/network/interfaces` in a basic state::
>
> auto wlan0
> iface wlan0 inet static
> wpa-driver wext
> wpa-ssid SOMESSID
> wpa-psk blahblahblah
> address 192.168.0.153
> netmask 255.255.255.0
> broadcast 192.168.0.255
> gateway 192.168.0.1
>
> Then add the a tap interface::
>
> # ip tuntap add dev tap0 mode tap
>
> Enable proxy_arp on both devices::
>
> # echo 1 > /proc/sys/net/ipv4/conf/wlan0/proxy_arp
> # echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp
>
> Add the host IP address to the tap interface::
>
> # ip addr add 192.168.0.153 dev tap0
>
> Finish configuring the tap interface::
>
> # ip link set tap0 up
> # ip link set tap0 promisc on
>
> Then add a route from the host to the guest::
>
> # ip route add 192.168.0.203 dev tap0
>
> There just need to start the guest now.
>
> > what they were doing but, regardless, that's not an LXC issue. That's
> > an outer host issue to be set up.
>
> Yes, it is also an LXC issue. What is not described in my summary is that
> the KVM guest is started with something like (yes, I avoid libvirt and
> superfluous layers):
>
> # kvm -net nic,model=virtio -net tap,script=no,downscript=no,ifname=tap0
> .... blah blah blah
>
> And this is how the guest interface is associated with the tap interface.
> And this is precisely the step I'm missing wrt LXC! ;-).
>
> > 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.
>
> I don't play with NM. I use Debian's ifupdown. Moreover, I have a set of
> personal / ad hoc scripts that let me set up my network configuration (hosts
> and guests) with 2 or 3 commands according to where I am. Setting it up in a
> new place is generally nothing more than copying and adapting a set of
> configuration files.
>
> > Where it comes to WiFi, you're better off going with a NAT'ed
> > connection.
>
> To be honest, 99% I'd be fine with a NAT'ed setup (wrt what I need to do
> with my KVM or LXC guests), but well, you know how it goes....
>
> Regards,
>
> Patrice
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
--
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/20140421/c0624bac/attachment.sig>
More information about the lxc-users
mailing list