Hi, I have a setup as follows: xen 4.0.1 [debian 6.0.1] libxenstore3.0 4.0.1-2 linux-image-2.6.32-5-xen-amd64 2.6.32-31 xen-hypervisor-4.0-amd64 4.0.1-2 xen-tools 4.2-1 xen-utils-4.0 4.0.1-2 xen-utils-common 4.0.0-1 xenstore-utils 4.0.1-2 - ssh directly to Dom0 works fine. - ssh from Dom0 to DomU works fine. - ssh [directly] to DomU via bridged eth0 refuses connection. Dom0 is set with some restrictions in /etc/hosts.allow / etc/hosts.deny and that seems to be working fine. There are no such restrictions on DomU. Removing the restrictions on Dom0 don''t help either. DomU doesn''t have any iptables rules active and it is listening on port 22 0.0.0.0 .... Attempts to ssh directly to DomU are not showing anything in logs on either Dom0 or DomU. Dom0 and DomU share 2 physical Ethernet ports (both bridged), Dom0 ssh to either DomU IP works fine. Pinging DomU works fine from outside Dom0 and DomU is serving a website fine -- the issues are only with direct access to the DomU machine via ssh. Putty doesn''t even get as far as creating a log file. Any ideas as to what is going wrong? -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP Current Land Line No: 03 9912 0504 Mobile: 04 2574 1827 Fax: 03 9012 2178 National No: 1300 85 3804 Affinity Vision Australia Pty Ltd http://www.affinityvision.com.au http://adsl2choice.net.au In Case of Emergency -- http://www.affinityvision.com.au/ice.html _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, On Thu, Mar 31, Andrew McGlashan wrote:> - ssh directly to Dom0 works fine. > > - ssh from Dom0 to DomU works fine. > > - ssh [directly] to DomU via bridged eth0 refuses connection.what does refuses connection mean ? what does a tcpdump on DomU show about the packets to port 22 ? -- best regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won''t use my address in the>From field._______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, Dieter Bloms wrote:> On Thu, Mar 31, Andrew McGlashan wrote: > >> - ssh directly to Dom0 works fine. >> - ssh from Dom0 to DomU works fine. >> - ssh [directly] to DomU via bridged eth0 refuses connection. > > what does refuses connection mean ? > what does a tcpdump on DomU show about the packets to port 22 ?putty quits almost immediately, nothing in logs at DomU or Dom0 putty responds with: Network error: Connection refused Then looking at putty event log: 2011-03-31 20:43:20 Looking up host "192.168.1.xxx" (IPv4) 2011-03-31 20:43:20 Connecting to 192.168.1.xxx port 22 2011-03-31 20:43:23 Failed to connect to 192.168.1.xxx: Network error: Connection refused 2011-03-31 20:43:23 Network error: Connection refused [On DomU] tcpdump -nS only sees ARP requests / replies when restricted to the putty client machine. The following two lines look the most interesting on the Dom0 machine: 21:21:48.585443 ARP, Request who-has 192.168.1.xxx tell 192.168.1.xx, length 46 21:21:48.585686 IP 192.168.1.xx.50847 > 192.168.1.xxx.22: Flags [S], seq 600018374, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 I''ve also tried the following [and it''s reciprocal] tcpdump src 192.168.1.xxx and dst 192.168.1.xx and port ssh Any options that you think I should use to see the "right" detail? Thanks. -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, On Thu, Mar 31, Andrew McGlashan wrote:> 21:21:48.585686 IP 192.168.1.xx.50847 > 192.168.1.xxx.22: Flags [S], > seq 600018374, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0ok, the syn packet reached the domU. What are the next packets from tcpdump ? Maybe you want start sshd with following option from console (xm console domU) /usr/sbin/sshd -Dd and watch the output on the console of domU -- Gruß Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won''t use my address in the From field. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, Dieter Bloms wrote:> On Thu, Mar 31, Andrew McGlashan wrote: > >> 21:21:48.585686 IP 192.168.1.xx.50847 > 192.168.1.xxx.22: Flags [S], >> seq 600018374, win 8192, options [mss 1460,nop,wscale >> 8,nop,nop,sackOK], length 0 > > ok, the syn packet reached the domU. > What are the next packets from tcpdump ?Nothing else of interest.> Maybe you want start sshd with following option from console (xm console domU) > /usr/sbin/sshd -Dd > and watch the output on the console of domUI only see output when I ssh from Dom0 -- nothing when trying from putty client. -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Andrew McGlashan wrote:>I only see output when I ssh from Dom0 -- nothing when trying from >putty client.Do you have any firewall in place that might be dropping connections ? -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, Simon Hobson wrote:> Andrew McGlashan wrote: > >> I only see output when I ssh from Dom0 -- nothing when trying from >> putty client. > > Do you have any firewall in place that might be dropping connections ?No, the closest thing would be the standard iptables rules on Dom0 ... but it looks "okay" to me. The same problems arise from other boxen on the same network too. Target eth0 network is 192.168.1.0/24 with eth1 network being 192.168.10.0/24 In the interest of solving this and not making any changes to the output which _may_ cause confusion, I''ve included some extra info here. If anyone needs any more information, please let me know what to provide. [Dom0] # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED PHYSDEV match --physdev-out vif3.1 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-in vif3.1 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED PHYSDEV match --physdev-out vif3.0 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-in vif3.0 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-in peth1 Chain OUTPUT (policy ACCEPT) target prot opt source destination # netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.222.0 192.168.1.1 255.255.255.0 UG 0 0 0 eth0 0.0.0.0 192.168.10.254 0.0.0.0 UG 0 0 0 eth1 # cat /etc/resolv.conf nameserver 192.168.10.254 # ifconfig -a eth0 Link encap:Ethernet HWaddr 00:11:25:8e:35:5e inet addr:192.168.1.33 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::211:25ff:fe8e:355e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:488448 errors:0 dropped:0 overruns:0 frame:0 TX packets:24333 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:38658147 (36.8 MiB) TX bytes:5180786 (4.9 MiB) eth1 Link encap:Ethernet HWaddr 00:11:25:8e:35:5f inet addr:192.168.10.33 Bcast:192.168.10.255 Mask:255.255.255.0 inet6 addr: fe80::211:25ff:fe8e:355f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:128731 errors:0 dropped:0 overruns:0 frame:0 TX packets:108605 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:16447271 (15.6 MiB) TX bytes:119938992 (114.3 MiB) eth2 Link encap:Ethernet HWaddr 00:0e:0c:76:4a:08 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:11 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:841 (841.0 B) TX bytes:841 (841.0 B) peth0 Link encap:Ethernet HWaddr 00:11:25:8e:35:5e inet6 addr: fe80::211:25ff:fe8e:355e/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:524126 errors:0 dropped:0 overruns:0 frame:0 TX packets:11900 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:46978477 (44.8 MiB) TX bytes:4145178 (3.9 MiB) Interrupt:16 peth1 Link encap:Ethernet HWaddr 00:11:25:8e:35:5f inet6 addr: fe80::211:25ff:fe8e:355f/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:278848 errors:0 dropped:0 overruns:0 frame:0 TX packets:332433 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:43404930 (41.3 MiB) TX bytes:331005275 (315.6 MiB) Interrupt:16 vif3.0 Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:34 errors:0 dropped:0 overruns:0 frame:0 TX packets:35913 errors:0 dropped:7 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:4920 (4.8 KiB) TX bytes:2322684 (2.2 MiB) vif3.1 Link encap:Ethernet HWaddr fe:ff:ff:ff:ff:ff inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:10181 errors:0 dropped:0 overruns:0 frame:0 TX packets:13043 errors:0 dropped:4 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:11165923 (10.6 MiB) TX bytes:1562808 (1.4 MiB) [DomU] Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination # netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.222.0 192.168.1.1 255.255.255.0 UG 0 0 0 eth0 0.0.0.0 192.168.10.254 0.0.0.0 UG 0 0 0 eth1 # cat /etc/resolv.conf nameserver 192.168.10.254 # ifconfig -a eth0 Link encap:Ethernet HWaddr 00:16:3e:24:79:d6 inet addr:192.168.1.201 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::216:3eff:fe24:79d6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:36006 errors:0 dropped:0 overruns:0 frame:0 TX packets:34 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1824540 (1.7 MiB) TX bytes:5396 (5.2 KiB) Interrupt:246 eth1 Link encap:Ethernet HWaddr 00:16:3e:24:79:d7 inet addr:192.168.10.201 Bcast:192.168.10.255 Mask:255.255.255.0 inet6 addr: fe80::216:3eff:fe24:79d7/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13098 errors:0 dropped:0 overruns:0 frame:0 TX packets:10217 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1383487 (1.3 MiB) TX bytes:11388793 (10.8 MiB) Interrupt:245 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:104 errors:0 dropped:0 overruns:0 frame:0 TX packets:104 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:10634 (10.3 KiB) TX bytes:10634 (10.3 KiB) Thanks. -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Am 01.04.2011 15:41, schrieb Andrew McGlashan:> Hi, > > Simon Hobson wrote: >> Andrew McGlashan wrote: >> >>> I only see output when I ssh from Dom0 -- nothing when trying from >>> putty client. >> >> Do you have any firewall in place that might be dropping connections ? > > No, the closest thing would be the standard iptables rules on Dom0 ... > but it looks "okay" to me.It isn''t.> Chain FORWARD (policy DROP) > target prot opt source destination > ACCEPT all -- anywhere anywhere state > RELATED,ESTABLISHED PHYSDEV match --physdev-out vif3.1 > ACCEPT all -- anywhere anywhere PHYSDEV > match --physdev-in vif3.1 > ACCEPT all -- anywhere anywhere state > RELATED,ESTABLISHED PHYSDEV match --physdev-out vif3.0 > ACCEPT all -- anywhere anywhere PHYSDEV > match --physdev-in vif3.0 > ACCEPT all -- anywhere anywhere PHYSDEV > match --physdev-in peth1These rules basically say that any traffic coming in from anywhgere (the outside) and being directed towards your DomU is only valid if it is part of an existing connection (see the state RELATED,ESTABLISHED on the physdev-out matches, which are driven by the stateful xtables match of the Dom0 kernel), whereas the DomU is allowed to do any traffic (see the physdev-in match). The Dom0 is allowed to do traffic to all DomUs, because the packets the Dom0 generates go through INPUT and OUTPUT, but not through FORWARD. You might want to check the iptables generation on your Dom0. -- --- Heiko. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, Heiko Wundram wrote:>>> Do you have any firewall in place that might be dropping connections ? >> No, the closest thing would be the standard iptables rules on Dom0 ... >> but it looks "okay" to me. > > It isn''t. > >> Chain FORWARD (policy DROP) >> target prot opt source destination >> ACCEPT all -- anywhere anywhere state >> RELATED,ESTABLISHED PHYSDEV match --physdev-out vif3.1 >> ACCEPT all -- anywhere anywhere PHYSDEV >> match --physdev-in vif3.1 >> ACCEPT all -- anywhere anywhere state >> RELATED,ESTABLISHED PHYSDEV match --physdev-out vif3.0 >> ACCEPT all -- anywhere anywhere PHYSDEV >> match --physdev-in vif3.0 >> ACCEPT all -- anywhere anywhere PHYSDEV >> match --physdev-in peth1 > > These rules basically say that any traffic coming in from anywhgere (the > outside) and being directed towards your DomU is only valid if it is > part of an existing connection (see the state RELATED,ESTABLISHED on the > physdev-out matches, which are driven by the stateful xtables match of > the Dom0 kernel), whereas the DomU is allowed to do any traffic (see the > physdev-in match).The DomU machine can host a website, no problem. It can reply to pings sent to it by another machine on the 192.168.1.0 network just fine. ssh works fine for the 192.168.10.201 going through Dom0 in the same manner as http [modem / forwarding -- modem is on 192.168.10.0 network]. So, ssh is different from _other_ traffic types for some reason.> The Dom0 is allowed to do traffic to all DomUs, because the packets the > Dom0 generates go through INPUT and OUTPUT, but not through FORWARD. You > might want to check the iptables generation on your Dom0.I didn''t craft the iptables rules on Dom0, it is standard installation with bridged networking setup -- okay, I had to mod the network script for xen, but I didn''t fiddle with any iptables rules. -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Le 01/04/2011 18:20, Andrew McGlashan a écrit :> > Hi, > > Heiko Wundram wrote: >>>> Do you have any firewall in place that might be dropping connections ? >>> No, the closest thing would be the standard iptables rules on Dom0 ... >>> but it looks "okay" to me. >> >> It isn''t. >> >>> Chain FORWARD (policy DROP) >>> target prot opt source destination >>> ACCEPT all -- anywhere anywhere state >>> RELATED,ESTABLISHED PHYSDEV match --physdev-out vif3.1 >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-in vif3.1 >>> ACCEPT all -- anywhere anywhere state >>> RELATED,ESTABLISHED PHYSDEV match --physdev-out vif3.0 >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-in vif3.0 >>> ACCEPT all -- anywhere anywhere PHYSDEV >>> match --physdev-in peth1 >> >> These rules basically say that any traffic coming in from anywhgere (the >> outside) and being directed towards your DomU is only valid if it is >> part of an existing connection (see the state RELATED,ESTABLISHED on the >> physdev-out matches, which are driven by the stateful xtables match of >> the Dom0 kernel), whereas the DomU is allowed to do any traffic (see the >> physdev-in match). > > The DomU machine can host a website, no problem. It can reply to > pings sent to it by another machine on the 192.168.1.0 network just fine.does your cards eth0 and eth1 are on the same LAN ( on the same switch ), do you ping 192.168.1.201 or 192.168.10.201 ?> ssh works fine for the 192.168.10.201 going through Dom0 in the same > manner as http [modem / forwarding -- modem is on 192.168.10.0 network].because it pass through eth1> So, ssh is different from _other_ traffic types for some reason. > >> The Dom0 is allowed to do traffic to all DomUs, because the packets the >> Dom0 generates go through INPUT and OUTPUT, but not through FORWARD. You >> might want to check the iptables generation on your Dom0. > > I didn''t craft the iptables rules on Dom0, it is standard installation > with bridged networking setup -- okay, I had to mod the network script > for xen, but I didn''t fiddle with any iptables rules. >Your first post mention that you can''t connect via ssh through eth0 bridge, There''s no rules to accept incoming packet via this interface in FORWARD table, allthought it might work via eth1. I suggest you to test by issuing this command on Dom0 : iptables -P FORWARD ACCEPT retry ssh and then revert back : iptables -P FORWARD DROP if it don''t work can you post the output of "brctl show" on Dom0 ? And the output of : netstat -an |grep ''LISTEN'' on DomU. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, Andrew McGlashan wrote:>> These rules basically say that any traffic coming in from anywhgere (the >> outside) and being directed towards your DomU is only valid if it is >> part of an existing connection (see the state RELATED,ESTABLISHED on the >> physdev-out matches, which are driven by the stateful xtables match of >> the Dom0 kernel), whereas the DomU is allowed to do any traffic (see the >> physdev-in match).Okay, I turned off anti spoofing in the xen network bridge setup; now it works -- however, sometimes I need to try a few times before it connects. Anti spoofing set the default FORWARD policy to DROP. Thanks. -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
-- re-sending, I''ve still got this problem of connections sometimes working and sometimes not. I can try repeatedly without changing any settings and sometimes it will finally work. Extra info added. ----------------------------------------------------------- Hi, Andrew McGlashan wrote:>> These rules basically say that any traffic coming in from anywhgere (the >> outside) and being directed towards your DomU is only valid if it is >> part of an existing connection (see the state RELATED,ESTABLISHED on the >> physdev-out matches, which are driven by the stateful xtables match of >> the Dom0 kernel), whereas the DomU is allowed to do any traffic (see the >> physdev-in match).Okay, I turned off anti spoofing in the xen network bridge setup; now it works -- however, sometimes I need to try a few times before it connects. Anti spoofing set the default FORWARD policy to DROP. -- extra info below this line -- Dom0 === [Output edited for readability] # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED PHYSDEV match --physdev-out vif2.1 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-in vif2.1 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED PHYSDEV match --physdev-out vif2.0 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-in vif2.0 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED PHYSDEV match --physdev-out vif1.0 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-in vif1.0 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED PHYSDEV match --physdev-out vif1.1 ACCEPT all -- anywhere anywhere PHYSDEV match --physdev-in vif1.1 Chain OUTPUT (policy ACCEPT) target prot opt source destination # brctl show bridge name bridge id STP enabled interfaces eth0 8000.0011258e355e no peth0 vif1.0 vif2.0 eth1 8000.0011258e355f no peth1 vif1.1 vif2.1 DomU ===# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination # netstat -an|grep 22|grep LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp6 0 0 :::22 :::* LISTEN No IPV6 is configured on these machines at this time fwiw. Connecting via a modem with port forwarding works 100% of the time without troubles (from allowed IP addresses). I am using /etc/hosts.allow and /etc/hosts.deny to restrict access, but the intermittent connections don''t show this as an issue. Relevant /etc/hosts.allow from the "other" network, the one that can connect intermittently. sshd: 192.168. NB: there are other allowed hosts, but they are not having any problems [coming in via the modem and with port forwards directly to DomU] /etc/hosts.deny relevant entry: sshd: ALL Thanks. -- Kind Regards AndrewM Andrew McGlashan Broadband Solutions now including VoIP _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users