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