Hi all,
I''m running xen 2.0.6 with linux 2.6.8 in dom0 and domU. The machine
has
two NICs - WiFi on network 192.168.157.0/25 and "wired" on
192.168.157.128/25. Dom0 uses .21 (dev wifi0) and .221 (dev wire0) and
can access router on over both channels on .1/.129. However when I start
up domU and assign addresses .41 to the interface bridged on wifi and
.241 to the other, only the wired network works. No luck with wifi.
For my tests I have manually created both bridges and set them in the
config file:
[/etc/xen/x1]
nics = 2
vif = [''mac=00:60:00:00:00:01, bridge=xbr0'',
''mac=00:60:00:00:00:02, bridge=xbr1'']
dom0:~# brctl show
bridge name bridge id STP enabled interfaces
xbr0 8000.004063d3d632 no wire0
vif6.0
xbr1 8000.0060b3656596 no wifi0
vif6.1
Addresses and routes are set the same way on both subnets (relevant parts):
dom0:~# ip addr show
2: wifi0: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast
link/ether 00:60:b3:65:65:96 brd ff:ff:ff:ff:ff:ff
inet 192.168.157.21/25 brd 192.168.157.127 scope global eth0
22: wire0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
link/ether 00:40:63:d3:d6:32 brd ff:ff:ff:ff:ff:ff
inet 192.168.157.221/25 brd 192.168.157.255 scope global wire
23: xbr0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 00:40:63:d3:d6:32 brd ff:ff:ff:ff:ff:ff
inet 192.168.157.221/25 scope global xbr0
24: xbr1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 00:60:b3:65:65:96 brd ff:ff:ff:ff:ff:ff
inet 192.168.157.21/25 scope global xbr1
27: vif6.0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
28: vif6.1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
dom0:~# ip route show
192.168.157.128/25 dev xbr0 proto kernel scope link src 192.168.157.221
192.168.157.0/25 dev xbr1 proto kernel scope link src 192.168.157.21
domU:~# ip addr show
# ip addr show
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:60:00:00:00:01 brd ff:ff:ff:ff:ff:ff
inet 192.168.157.241/25 brd 192.168.157.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:60:00:00:00:02 brd ff:ff:ff:ff:ff:ff
inet 192.168.157.41/25 brd 192.168.157.127 scope global eth1
domU:~# ip route show
192.168.157.128/25 dev eth0 proto kernel scope link src 192.168.157.241
192.168.157.0/25 dev eth1 proto kernel scope link src 192.168.157.41
No firewall or MAC filtering is set up on any node.
When pinging from domU to the router on the wired subnet it just works.
OTOH when pinging on the wifi subnet I can observe the arp packets
"who-has 192.168.157.1 tell 192.168.157.41" going out on both xbr1 and
wifi0 but they don''t arrive at the router, i.e. they are either sent
out
malformed or not sent at all (I don''t know). When pinging from the
router the arp request for .41 arrives to domU, but the response
doesn''t
reach the router. I.e. no outgoing traffic from domU over WiFi. Incoming
seems to work, dom0 works both ways.
FWIW the WiFi card on xen machine is Prism2.5/PCI with orinoco_pci
driver, tried both with and without WEP.
Does anyone have an idea on what could be wrong, workarounds, etc.?
Thanks!
Michal Ludvig
--
* Personal homepage: http://www.logix.cz/michal
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
A misuse of this list, but important for all of us! The Software Patents Directive, as approved by the European Council of Ministers, would codify US-style Software Patents in the European Union. If that happens, software developers will no longer own what they write and can be sued for selling or distributing their own software. If you don''t inform your parliament, mega-corporations are doing the job for you: "The European Parliament is filled with lobbyists of Microsoft, Eicta, CompTIA and so on. There are 30 to 40 lobbyists permanently roaming the halls." (in Eweek, 21 June (http://www.eweek.com/article2/0,1759,1829955,00.asp)) http://noepatents.eu.org/index.php/NO_Software_Patents ~~ STOP Software Patents! Use the Webdemo on your page! ~~ http://www.ffii.org/~zoobab/demopage/index-en.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Michal Ludvig wrote:> I''m running xen 2.0.6 with linux 2.6.8 in dom0 and domU. The machine has > two NICs - WiFi on network 192.168.157.0/25 and "wired" on > 192.168.157.128/25. Dom0 uses .21 (dev wifi0) and .221 (dev wire0) and > can access router on over both channels on .1/.129. However when I start > up domU and assign addresses .41 to the interface bridged on wifi and > .241 to the other, only the wired network works. No luck with wifi.I guess other people may face this problem as well so just for the record here is some discussion and solution. * The culprit is not Xen but the wireless card which refuses to send out packets with different MAC address than its own. But as Xen deploys ethernet bridge to provide network for domU kernels the outgoing packets have a virtual source MAC address different from the real one of the WiFi card. You don''t need Xen to observe this problem - simple ethernet bridge constructed with brctl between wired and wireless segments will not work with many wifi cards either. See "It doesn''t work with my Wireless card" at [1]. * The solution obviously is to change the source MAC address to the real one on all outgoing packets. At first I tried to set it in vif=[''mac=...''] config option for domU host, but it didn''t work. Better solution turned out to be deployment of ''ebtables'' [2] - netfilter infrastructure similar to ''iptables'' but working with MAC addresses instead of IP addresses. Given that domU MAC address is 00:60:00:00:00:01 and wifi card MAC address is 00:60:aa:bb:cc:dd the simplest ebfilter rule that made it work is: ebtables -t nat -A POSTROUTING -s 00:60:00:00:00:01 \ -j snat --to-source 00:60:aa:bb:cc:dd You may want to add some more checks, e.g. for source interface name or alike. This is the bare minimum. * Surprisingly enough there doesn''t have to be a corresponding reversed ''dnat'' rule like. Ping from outside to domU triggers this packet sequence (00:02:11:22:33:44 is my workstation MAC address): 01:56:03.972501 00:02:11:22:33:44 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.157.41 tell 192.168.157.20 01:56:03.975205 00:60:aa:bb:cc:dd > 00:02:11:22:33:44, ethertype ARP (0x0806), length 60: arp reply 192.168.157.41 is-at 00:60:00:00:00:01 Interesting point is the ARP reply. Although it comes from wifi real MAC address, inside in the packet it carries the domU virtual MAC. Subsequently my workstation created an entry in its ARP table with the virtual(!) address of domU and started sending all further communication to that MAC: 01:56:03.975231 00:02:11:22:33:44 > 00:60:00:00:00:01, ethertype IPv4 (0x0800), length 98: IP 192.168.157.20 > 192.168.157.41: icmp 64: echo request seq 1 01:56:03.982348 00:60:aa:bb:cc:dd > 00:02:11:22:33:44, ethertype IPv4 (0x0800), length 98: IP 192.168.157.41 > 192.168.157.20: icmp 64: echo reply seq 1 As I said in my first posting the packets destined to the virtual MAC are successfully delivered to domU, just the outgoing ones are blocked. That''s why it all works like a charm with just a single ebtables snat rule. Q.O.D. BTW I wonder if there are any caveats in this setup. Linux kernel seems to always update its ARP table from the non-snat''ed contents of the ARP packet, not from the snat''ed ethernet headers and it all looks just fine... [1] - http://bridge.sourceforge.net/faq.html [2] - http://ebtables.sourceforge.net/ Enjoy! Michal Ludvig -- * Personal homepage: http://www.logix.cz/michal * Novy Zeland: http://kiwi.logix.cz _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users