Re: [Xen-users] Wired Network Bridging

[Simon Hobson <simon@xxxxxxxxxxxxxxxx>]

Ray Joseph <ray3960852@xxxxxxxxx> wrote:

> I am trying to get Xen4.9 up and Debian 9 on a Toshiba laptop with only a 
> wireless connection.  I am trying to use: 
> https://wiki.debian.org/BridgeNetworkConnections#Bridging_with_a_wireless_NIC 
> 
> This laptop will be a personal workstation implementing a variety of vms and 
> OSs.  My internet connection is a wireless connection to a JetPack 4G AP and 
> various public/private wireless APs.  In the future, I expect to have an 
> additional wired connection to a router  that will eventually reach the 
> Internet with a tethered wireless connection to the JetPack (to share the 
> connection with other devices). 

Just bear in mind that I'm not familiar with wireless networking ...

> My /etc/network/interfaces is: 
> # interfaces.r05 
> 
> # The loopback network interface 
> #auto lo xenbr0 
> auto lo 
> iface lo inet loopback 
> 
> #allow-hotplug usb0 
> #iface usb0 inet manual 
> 
> allow-hotplug wlan0 
> iface wlp2s0 inet manual 
>     wireless-power off 
>     wpa-ssid [myssid] 
>     wpa-psk [code] 
> 
> auto xenbr0 
> iface xenbr0 inet dhcp 
>     bridge_ports wlan0 
> #bridge_ports wlan0 usb0 
>     pre-up iwconfig wlan0 essid [myssid] 
>     bridge_hw 95:65:00:38:00:30 
> 
> bridge_stp off                # disable spanning tree protocol 
> bridge_waitport 0        # no delay before a port becomes available 
> bridge_fd 0                # no forwarding delay 
> #bridge_ports none        # if you do not want to bind to any ports 
> #Bridge_ports regex eth* # use a regular expression to define ports 
> 
> # To restart the service after update: 
> # /etc/init.d/procps restart 
> 
> 
> One of my challenges is that bridging to a wireless NIC requires 4addr.  The 
> code is: 
> iw dev wlan0 set 4addr on 
> 
> but I don't know where or how to put this so it gets executed at the correct 
> time. 

The "pre-up" statements in interface declarations are designed for this. I 
would guess that putting "pre-up iw dev wlan0 set 4addr on" in the declaration 
for wlan0 ought to do it - I suspect that the iwconfig statement would probably 
be better in the wlan0 section as well.

> I am not sure how to implement setting the ebtables rules.  Example 1: 
> # ebtables -t nat -A POSTROUTING -o wlan0 -j snat --to-src $MAC_OF_BRIDGE 
> --snat-arp --snat-target ACCEPT 
> 
> Is the bridge MAC supposed to be the wireless NIC MAC?  As it is not a 
> physical device, I'm not sure what this means. 

It IS a physical device, it just has a radio physical layer instead of a cable. 
And yes, it should be the MAC address reported if you ask "ip link show dev 
wlan0" - this rule is changing the source MAC address of all outbound traffic 
to be that of your WLAN interface. It's so that the wireless AP only sees 
traffic from a single MAC address.

I would also try without this. While the article says most APs reject frames 
with a different MAC address, I've had success (we use them from time to time 
at work when we need to get someone connectivity quickly and there isn't time 
to run cables before they need the network operating) with wireless client 
bridges operating transparently (ie the devices behind the client bridge all 
have their own MAC addresses). If it works, then you'd see all the different 
clients with their own MAC addresses if you query the router you are using for 
it's neighbours/DHCP clients - and it'll save all the hassle of mapping the 
traffic back again - see below.
It can be a bit hit and miss. Last time I was setting one up, I found my Mac 
couldn't get an address with DHCP, but the Windows clients the client was using 
had no such problem. It will also depend on the AP settings - more secure 
setups are more likely to fail.

If you are able to, I would suggest setting things up with a wired connection 
first - then you can be sure that your Xen and networking setup is working. 
Then try adding the wireless element. Throwing everything in the mixing pot at 
once means you have a lot to debug if it doesn't work first time.

> I question this because the page goes on to say: 
> The next rules will require you to know the MAC and IP of each of the 
> machines behind your bridge. Replace $MAC and $IP with these. 
>  # ebtables -t nat -A PREROUTING -p IPv4 -i wlan0 --ip-dst $IP -j dnat 
> --to-dst $MAC --dnat-target ACCEPT 
>  # ebtables -t nat -A PREROUTING -p ARP -i wlan0 --arp-ip-dst $IP -j dnat 
> --to-dst $MAC --dnat-target ACCEPT 

This is part of the puzzle if you do MAC address spoofing. What it's doing is 
mapping all the inbound traffic (which due to the rule above, is addressed to 
one MAC address) so it goes to each individual VM. So basically it's picking up 
packets address to a specific IP and remapping the MAC address so the packets 
get picked up by the correct VM - there's 2 rules, the first maps regular 
traffic, the second deals with ARP requests.

> These seem to be the vms since it says 'behind your bridge'.  As I expect to 
> create/bring-up these on the fly, it seems it would be appropriate to use 
> DHCP and won't know the IPs; and I am don't see how to assign the MACs, and I 
> don't see how to invoke DHCP. 

Indeed, the method will only work with static addresses **AND** static MAC 
assignments. You can set a static MAC & IP for the guest in it's config - under 
xm toolset you'd include something like this in your config file :
> vif  = [ 
> 'bridge=xenbr0,vifname=vmname,ip=192.168.xxx.xxx,mac=00:16:3e:xx:xx:xx']

bridge and vifname are optional. On my systems I use different bridge names 
(some have multiple bridges - eg ethfront and ethback for public facing and 
backend networks) and I name the VIFs as it makes it easier to see what's what 
on a host with many guests - imagine a system with 10 guests, each of which has 
multiple VIFs on the different networks ! "mailback" and "mailfront" (for 
example) is easier to follow than just seeing vif7.0 and vif7.1 in the 
interface list !


> The page finishes of with an example of "Link Aggregation (LACP) with VLANs". 
> The example /etc/network/interfaces does not show any of the content in 
> interfaces that was previously described.  Thus I cannot tell how to use it 
> or if it is necessary. 

That's irrelevant to you. There are several other networking scenarios 
described on that page - you are only interested in the wireless section.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users