Xen project Mailing List

Simon,

Thank you for providing the details. I have a couple questions:

1) The POSTROUTING command gets the dom0 wireless interface name wlan0 and the $MAC_OF_BRIDGE which is the same as the MAC of the dom0 wireless MAC?

2) The PREROUTING commands reference the dom0 wireless interface name and the domU IP address and MAC?

3) In domUs, can the interface be defined as an Ethernet? As such, be given the MAC address of the dom0 wireless interface? Is there a good way to keep track of what IP addresses the vms are allocated?

4) In the interfaces file, is there a need to assure the ordering of these two lines:

pre-up iwconfig wlan0 essid [myessid] # 1

pre-up iw dev wlan0 set 4addr on # 2

On Sun, Jun 18, 2017 at 3:53 AM, Simon Hobson <simon@xxxxxxxxxxxxxxxx> wrote:

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

Re: [Xen-users] Wired Network Bridging