<xensource.2007@mymail.isbest.biz>
2008-Mar-22 02:40 UTC
[Xen-users] Xen Windows Clients - BSOD with Application Firewall Installs
I have set up both Windows XP and Windows 2000 Server clients on Xen under Centos 5.1 and am unable to install an application firewall. I have tried the latest: 1) Agnitum Outpost Commercial Version 2) Comodo Firewall (ver 2 on Windows 2000) 3) Sunbelt Commercial Version With all of these when the firewall starts up it results in a BSOD. With Windows XP and Agnitum I can go back to a previous system restore point, with Windows 2000 and other firewalls on XP the only option is a backup of the Xen client as even a save mode command prompt startup results in a BSOD. I have tried on the Windows XP install using various HALS and switches for PAE ACPI and multi/single cpu support and have not had any success. Windows 2000 BSOD results from "an attempt was made to write to read only memory" NDIS.SYS Windows XP BSOD message is related to: Agnitum - sandbox.sys Others: "an attempt was made to write to read only memory" NDIS.SYS Has anyone any idea of how to set up Xen Windows clients to allow an application firewall to be installed successfully? Thanks Jesse _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Rudi Ahlers
2008-Mar-22 07:46 UTC
Re: [Xen-users] Xen Windows Clients - BSOD with Application Firewall Installs
xensource.2007@mymail.isbest.biz wrote:> I have set up both Windows XP and Windows 2000 Server clients on Xen under Centos 5.1 and am unable to install an application > firewall. I have tried the latest: > 1) Agnitum Outpost Commercial Version > 2) Comodo Firewall (ver 2 on Windows 2000) > 3) Sunbelt Commercial Version > > With all of these when the firewall starts up it results in a BSOD. With Windows XP and Agnitum I can go back to a previous system > restore point, with Windows 2000 and other firewalls on XP the only option is a backup of the Xen client as even a save mode command > prompt startup results in a BSOD. > > I have tried on the Windows XP install using various HALS and switches for PAE ACPI and multi/single cpu support and have not had > any success. > > Windows 2000 BSOD results from "an attempt was made to write to read only memory" NDIS.SYS > > Windows XP BSOD message is related to: > Agnitum - sandbox.sys > Others: "an attempt was made to write to read only memory" NDIS.SYS > > Has anyone any idea of how to set up Xen Windows clients to allow an application firewall to be installed successfully? > > Thanks > > > Jesse > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > >May I ask, how exactly did you install Windows on Xen, on Centos5.1? -- Kind Regards Rudi Ahlers CEO, SoftDux Web: http://www.SoftDux.com Check out my technical blog, http://blog.softdux.com for Linux or other technical stuff, or visit http://www.WebHostingTalk.co.za for Web Hosting stugg _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
<xensource.2007@mymail.isbest.biz>
2008-Mar-24 04:48 UTC
RE: [Xen-users] Xen Windows Clients - BSOD with Application FirewallInstalls
Certainly Rudi Installation for W2k and XP was the same and seems quite trivial. 1) Initial install done from virt-manager. Installation drive C: is a file 20GB fully allocated. Formatted as NTFS. 2) xen script modified to read also CD drive to finish install 3) A few basic customisations, like adding a user, setting file manager display formats 4) Firewall installation file copied to the new C: drive 5) Respective firewall installation run 6) At firewall startup, BSOD 7) Subsequent restarts result in BSOD as previously stated. I sure hope you can shed some light on it. Thanks Jesse _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
James Harper
2008-Mar-24 09:48 UTC
RE: [Xen-users] Xen Windows Clients - BSOD with ApplicationFirewallInstalls
> 6) At firewall startup, BSOD > 7) Subsequent restarts result in BSOD as previously stated.Xen appears to be sending ''large'' packets onto the bridge, and the tap interface isn''t ''un-large-ing'' them. " 20:40:34.437312 IP (tos 0x0, ttl 128, id 34470, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.207.200.5001 > 192.168.207.254.53981: ., cksum 0x05aa (correct), 1:1(0) ack 14505 win 58295 <nop,nop,timestamp 57828874 1445680997> 20:40:34.437324 IP (tos 0x0, ttl 64, id 51510, offset 0, flags [DF], proto: TCP (6), length: 4396) 192.168.207.254.53981 > 192.168.207.200.5001: . 23193:27537(4344) ack 1 win 46 <nop,nop,timestamp 1445680998 57828874> 20:40:34.439653 IP (tos 0x0, ttl 128, id 34471, offset 0, flags [DF], proto: TCP (6), length: 64) 192.168.207.200.5001 > 192.168.207.254.53981: ., cksum 0x2a79 (correct), 1:1(0) ack 15953 win 56847 <nop,nop,timestamp 57828874 1445680997,nop,nop,sack 1 {17401:18849}> 20:40:34.439670 IP (tos 0x0, ttl 64, id 51513, offset 0, flags [DF], proto: TCP (6), length: 4396) 192.168.207.254.53981 > 192.168.207.200.5001: . 27537:31881(4344) ack 1 win 46 <nop,nop,timestamp 1445680999 57828874> " Note the lengh of 4396 - the hardware interface is supposed to break that up into MSS sized chunks, but there is no hardware interface involved in this case. I''m trying to resolve the problem in the GPL PV drivers. I''ve had wireshark (npf.sys) BSOD when it receives a packet with a size greater than MTU, so I imagine a firewall may well do the same thing. Try turning off large send offload for all interfaces on the bridge (the same bridge as your crashing DomU), eg: " ethtool -K <ifname> gso off " Iperf gives horrible results too when DomU is the ''server'' and Dom0 is the ''client'' because of this. James _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
<xensource.2007@mymail.isbest.biz>
2008-Mar-25 07:35 UTC
RE: [Xen-users] Xen Windows Clients - BSOD withApplicationFirewallInstalls
Thanks James But it makes no dif. Am I applying it to the correct interface (xenbr1)? -----Original Message----- From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of James Harper Sent: Monday, 24 March 2008 6:49 PM To: xensource.2007@mymail.isbest.biz; Rudi Ahlers; xen-users@lists.xensource.com Subject: RE: [Xen-users] Xen Windows Clients - BSOD withApplicationFirewallInstalls> 6) At firewall startup, BSOD > 7) Subsequent restarts result in BSOD as previously stated.Xen appears to be sending ''large'' packets onto the bridge, and the tap interface isn''t ''un-large-ing'' them. " 20:40:34.437312 IP (tos 0x0, ttl 128, id 34470, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.207.200.5001 > 192.168.207.254.53981: ., cksum 0x05aa (correct), 1:1(0) ack 14505 win 58295 <nop,nop,timestamp 57828874 1445680997> 20:40:34.437324 IP (tos 0x0, ttl 64, id 51510, offset 0, flags [DF], proto: TCP (6), length: 4396) 192.168.207.254.53981 > 192.168.207.200.5001: . 23193:27537(4344) ack 1 win 46 <nop,nop,timestamp 1445680998 57828874> 20:40:34.439653 IP (tos 0x0, ttl 128, id 34471, offset 0, flags [DF], proto: TCP (6), length: 64) 192.168.207.200.5001 > 192.168.207.254.53981: ., cksum 0x2a79 (correct), 1:1(0) ack 15953 win 56847 <nop,nop,timestamp 57828874 1445680997,nop,nop,sack 1 {17401:18849}> 20:40:34.439670 IP (tos 0x0, ttl 64, id 51513, offset 0, flags [DF], proto: TCP (6), length: 4396) 192.168.207.254.53981 > 192.168.207.200.5001: . 27537:31881(4344) ack 1 win 46 <nop,nop,timestamp 1445680999 57828874> " Note the lengh of 4396 - the hardware interface is supposed to break that up into MSS sized chunks, but there is no hardware interface involved in this case. I''m trying to resolve the problem in the GPL PV drivers. I''ve had wireshark (npf.sys) BSOD when it receives a packet with a size greater than MTU, so I imagine a firewall may well do the same thing. Try turning off large send offload for all interfaces on the bridge (the same bridge as your crashing DomU), eg: " ethtool -K <ifname> gso off " Iperf gives horrible results too when DomU is the ''server'' and Dom0 is the ''client'' because of this. James _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date: 24/03/2008 3:03 PM No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date: 24/03/2008 3:03 PM _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
James Harper
2008-Mar-25 08:55 UTC
RE: [Xen-users] Xen Windows Clients - BSOD withApplicationFirewallInstalls
I think you''ll need to figure out what interface is launching these packets onto your network, but in the meantime just turn of gso on all interfaces attached to the bridge - do a ''brctl show'' to get a list of them. If you are still getting BSoD''s after doing that, do a tcpdump on the tapX device belonging to your windows HVM domain, and see if a large packet coincides with your BSoD. If it doesn''t, then I''ve probably lead you down the wrong path. It might be easiest to do that second step first: . brctl show . create your domain in a paused state . brctl show . start a tcpdump on your tapX interface (eg the one that wasn''t there in the first brctl show but is in the second). If this is your only hvm domain then you can skip this and just assume tap0 The syntax you want for your tcpdump is probably something like ''tcpdump -i tapX greater 1500'', which should be fired whenever a packet is >1500 bytes. James> -----Original Message----- > From: DoNotReply [mailto:DoNotReply@mymail.isbest.biz] On Behalf Of > xensource.2007@mymail.isbest.biz > Sent: Tuesday, 25 March 2008 18:36 > To: James Harper; xensource.2007@mymail.isbest.biz; xen- > users@lists.xensource.com > Subject: RE: [Xen-users] Xen Windows Clients - BSOD > withApplicationFirewallInstalls > > Thanks James > But it makes no dif. Am I applying it to the correct interface(xenbr1)?> > > -----Original Message----- > From: xen-users-bounces@lists.xensource.com [mailto:xen-users- > bounces@lists.xensource.com] On Behalf Of James Harper > Sent: Monday, 24 March 2008 6:49 PM > To: xensource.2007@mymail.isbest.biz; Rudi Ahlers; xen- > users@lists.xensource.com > Subject: RE: [Xen-users] Xen Windows Clients - BSOD > withApplicationFirewallInstalls > > > > 6) At firewall startup, BSOD > > 7) Subsequent restarts result in BSOD as previously stated. > > Xen appears to be sending ''large'' packets onto the bridge, and the tap > interface isn''t ''un-large-ing'' them. > > " > 20:40:34.437312 IP (tos 0x0, ttl 128, id 34470, offset 0, flags [DF], > proto: TCP (6), length: 52) 192.168.207.200.5001 > > 192.168.207.254.53981: ., cksum 0x05aa (correct), 1:1(0) ack 14505 win > 58295 <nop,nop,timestamp 57828874 1445680997> 20:40:34.437324 > IP (tos 0x0, ttl 64, id 51510, offset 0, flags [DF], > proto: TCP (6), length: 4396) 192.168.207.254.53981 > > 192.168.207.200.5001: . 23193:27537(4344) ack 1 win 46<nop,nop,timestamp> 1445680998 57828874> 20:40:34.439653 IP (tos 0x0, ttl 128, > id 34471, offset 0, flags [DF], > proto: TCP (6), length: 64) 192.168.207.200.5001 > > 192.168.207.254.53981: ., cksum 0x2a79 (correct), 1:1(0) ack 15953 win > 56847 <nop,nop,timestamp 57828874 1445680997,nop,nop,sack 1 > {17401:18849}> 20:40:34.439670 IP (tos 0x0, ttl 64, id 51513, offset0,> flags [DF], > proto: TCP (6), length: 4396) 192.168.207.254.53981 > > 192.168.207.200.5001: . 27537:31881(4344) ack 1 win 46<nop,nop,timestamp> 1445680999 57828874> " > > Note the lengh of 4396 - the hardware interface is supposed to breakthat> up into MSS sized chunks, but there is no hardware > interface involved in this case. > > I''m trying to resolve the problem in the GPL PV drivers. > > I''ve had wireshark (npf.sys) BSOD when it receives a packet with asize> greater than MTU, so I imagine a firewall may well do the > same thing. > > Try turning off large send offload for all interfaces on the bridge(the> same bridge as your crashing DomU), eg: > > " > ethtool -K <ifname> gso off > " > > Iperf gives horrible results too when DomU is the ''server'' and Dom0 isthe> ''client'' because of this. > > James > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com http://lists.xensource.com/xen-users > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date: > 24/03/2008 3:03 PM > > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date: > 24/03/2008 3:03 PM > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
James Harper
2008-Mar-25 08:58 UTC
RE: [Xen-users] Xen Windows Clients - BSODwithApplicationFirewallInstalls
> . brctl show > . create your domain in a paused state > . brctl show > . start a tcpdump on your tapX interface (eg the one that wasn''t there > in the first brctl show but is in the second). If this is your onlyhvm> domain then you can skip this and just assume tap0Oh yeah... unpause your domain here :) James _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
<xensource.2007@mymail.isbest.biz>
2008-Mar-25 12:19 UTC
RE: [Xen-users] Xen Windows Clients - BSOD withApplicationFirewallInstalls
Hi James
Thanks for the detailed instructions.
There are 2 VMs that use this bridge (2000 svr and xp sp2), but it makes no
difference to the bsod if 1 or both are running. With
both running the xp tap is tap1, otherwise it''s tap0.
When I do the tcdump it shows only packets that seem to relate to the ssh
session to DOM0 (The ssh port is 22716, DOM0 is
192.168.20.7 and machine I am ssh from is 192.168.20.30), then it bsods. Before
the bsod there is some double size packets. (Even
though I have disabled gso on all interfaces, bridges and otherwise), but not
directly prior to the bsod. So at this stage I am not
sure if I''m down the garden path or still on the verandah. :-)
The physical interface that the packets run on is eth1. I am a little confused
as to why the ssh packets also show up on the tap1
interface as there is no ssh connection to the DOMU, only DOM0.
Thanks. The dump is below:
---------------------------------------------------------------------------
# tcpdump -i tap0 greater 1500
tcpdump: WARNING: tap0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
20:44:42.183259 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
2964273857:2964275317(1460) ack 3005185253 win 545
20:44:43.626964 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
7296:8756(1460) ack 417 win 545
20:44:43.626980 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
8756:10216(1460) ack 417 win 545
20:44:44.266984 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
12784:15704(2920) ack 449 win 545
20:44:45.225979 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
16912:18372(1460) ack 449 win 545
20:44:46.178139 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
20272:21732(1460) ack 449 win 545
20:44:46.576267 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
23824:25284(1460) ack 529 win 545
20:44:46.577062 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
25888:27348(1460) ack 529 win 545
20:44:46.585779 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
27348:28808(1460) ack 529 win 545
20:44:47.178179 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
30160:33080(2920) ack 609 win 545
20:44:47.885066 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
35712:37172(1460) ack 609 win 545
20:44:47.885997 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
37776:39236(1460) ack 609 win 545
20:44:47.893317 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
39236:40696(1460) ack 609 win 545
20:44:48.182306 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
41520:44440(2920) ack 641 win 545
20:44:48.182329 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: P
44440:45888(1448) ack 641 win 545
20:44:48.191866 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
47248:48708(1460) ack 641 win 545
20:44:48.234170 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
50192:51652(1460) ack 721 win 545
20:44:48.407627 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
52912:54372(1460) ack 721 win 545
20:44:48.408410 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
54960:56420(1460) ack 721 win 545
20:44:48.409493 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
56800:58260(1460) ack 721 win 545
20:44:48.571215 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
58608:60068(1460) ack 753 win 545
20:44:48.600938 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
60496:61956(1460) ack 801 win 545
20:44:48.601814 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
62336:63796(1460) ack 801 win 545
20:44:48.715526 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
64384:65844(1460) ack 801 win 545
20:44:48.716277 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
66416:67876(1460) ack 801 win 545
20:44:48.717355 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
68256:69716(1460) ack 801 win 545
20:44:49.182112 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
70304:73224(2920) ack 833 win 545
20:44:49.182136 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
73224:74684(1460) ack 833 win 545
20:44:50.182639 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
76720:78180(1460) ack 833 win 545
20:44:50.182659 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
78180:79640(1460) ack 833 win 545
20:44:50.188947 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: .
79872:81332(1460) ack 833 win 545
tcpdump: pcap_loop: recvfrom: Network is down
31 packets captured
66 packets received by filter
0 packets dropped by kernel
[root@catss3 vm]# Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/console.py", line 202, in
_vnc_disconnected
self.try_login()
File "/usr/share/virt-manager/virtManager/console.py", line 217, in
try_login
protocol, host, port = self.vm.get_graphics_console()
File "/usr/share/virt-manager/virtManager/domain.py", line 447, in
get_graphics_console
type = self.get_xml_string("/domain/devices/graphics/@type")
File "/usr/share/virt-manager/virtManager/domain.py", line 417, in
get_xml_string
xml = self.get_xml()
File "/usr/share/virt-manager/virtManager/domain.py", line 51, in
get_xml
self.xml = self.vm.XMLDesc(0)
File "/usr/lib64/python2.4/site-packages/libvirt.py", line 196, in
XMLDesc
if ret is None: raise libvirtError (''virDomainGetXMLDesc()
failed'', dom=self)
libvirt.libvirtError: virDomainGetXMLDesc() failed
----------------------------------------------------------------------------------
-----Original Message-----
From: James Harper [mailto:james.harper@bendigoit.com.au]
Sent: Tuesday, 25 March 2008 5:55 PM
To: xensource.2007@mymail.isbest.biz; xen-users@lists.xensource.com
Subject: RE: [Xen-users] Xen Windows Clients - BSOD
withApplicationFirewallInstalls
I think you''ll need to figure out what interface is launching these
packets onto your network, but in the meantime just turn of gso
on all interfaces attached to the bridge - do a ''brctl show''
to get a list of them.
If you are still getting BSoD''s after doing that, do a tcpdump on the
tapX device belonging to your windows HVM domain, and see if a
large packet coincides with your BSoD. If it doesn''t, then
I''ve probably lead you down the wrong path.
It might be easiest to do that second step first:
. brctl show
. create your domain in a paused state
. brctl show
. start a tcpdump on your tapX interface (eg the one that wasn''t there
in the first brctl show but is in the second). If this is
your only hvm domain then you can skip this and just assume tap0
The syntax you want for your tcpdump is probably something like
''tcpdump -i tapX greater 1500'', which should be fired whenever
a
packet is >1500 bytes.
James
> -----Original Message-----
> From: DoNotReply [mailto:DoNotReply@mymail.isbest.biz] On Behalf Of
> xensource.2007@mymail.isbest.biz
> Sent: Tuesday, 25 March 2008 18:36
> To: James Harper; xensource.2007@mymail.isbest.biz; xen-
> users@lists.xensource.com
> Subject: RE: [Xen-users] Xen Windows Clients - BSOD
> withApplicationFirewallInstalls
>
> Thanks James
> But it makes no dif. Am I applying it to the correct interface
(xenbr1)?>
>
> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com [mailto:xen-users-
> bounces@lists.xensource.com] On Behalf Of James Harper
> Sent: Monday, 24 March 2008 6:49 PM
> To: xensource.2007@mymail.isbest.biz; Rudi Ahlers; xen-
> users@lists.xensource.com
> Subject: RE: [Xen-users] Xen Windows Clients - BSOD
> withApplicationFirewallInstalls
>
>
> > 6) At firewall startup, BSOD
> > 7) Subsequent restarts result in BSOD as previously stated.
>
> Xen appears to be sending ''large'' packets onto the
bridge, and the tap
> interface isn''t ''un-large-ing'' them.
>
> "
> 20:40:34.437312 IP (tos 0x0, ttl 128, id 34470, offset 0, flags [DF],
> proto: TCP (6), length: 52) 192.168.207.200.5001 >
> 192.168.207.254.53981: ., cksum 0x05aa (correct), 1:1(0) ack 14505 win
> 58295 <nop,nop,timestamp 57828874 1445680997> 20:40:34.437324 IP (tos
> 0x0, ttl 64, id 51510, offset 0, flags [DF],
> proto: TCP (6), length: 4396) 192.168.207.254.53981 >
> 192.168.207.200.5001: . 23193:27537(4344) ack 1 win 46
<nop,nop,timestamp> 1445680998 57828874> 20:40:34.439653 IP (tos 0x0, ttl 128,
> id 34471, offset 0, flags [DF],
> proto: TCP (6), length: 64) 192.168.207.200.5001 >
> 192.168.207.254.53981: ., cksum 0x2a79 (correct), 1:1(0) ack 15953 win
> 56847 <nop,nop,timestamp 57828874 1445680997,nop,nop,sack 1
> {17401:18849}> 20:40:34.439670 IP (tos 0x0, ttl 64, id 51513, offset
0,> flags [DF],
> proto: TCP (6), length: 4396) 192.168.207.254.53981 >
> 192.168.207.200.5001: . 27537:31881(4344) ack 1 win 46
<nop,nop,timestamp> 1445680999 57828874> "
>
> Note the lengh of 4396 - the hardware interface is supposed to break
that> up into MSS sized chunks, but there is no hardware
> interface involved in this case.
>
> I''m trying to resolve the problem in the GPL PV drivers.
>
> I''ve had wireshark (npf.sys) BSOD when it receives a packet with a
size> greater than MTU, so I imagine a firewall may well do the same thing.
>
> Try turning off large send offload for all interfaces on the bridge
(the> same bridge as your crashing DomU), eg:
>
> "
> ethtool -K <ifname> gso off
> "
>
> Iperf gives horrible results too when DomU is the
''server'' and Dom0 is
the> ''client'' because of this.
>
> James
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date:
> 24/03/2008 3:03 PM
>
> No virus found in this outgoing message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date:
> 24/03/2008 3:03 PM
>
>
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date: 24/03/2008 3:03
PM
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date: 24/03/2008 3:03
PM
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
James Harper
2008-Mar-25 12:27 UTC
RE: [Xen-users] Xen Windows Clients - BSOD withApplicationFirewallInstalls
Well you are definitely still seeing large packets... maybe disable tso too? Also disable rx and tx checksumming. James> Hi James > Thanks for the detailed instructions. > There are 2 VMs that use this bridge (2000 svr and xp sp2), but itmakes> no difference to the bsod if 1 or both are running. With > both running the xp tap is tap1, otherwise it''s tap0. > When I do the tcdump it shows only packets that seem to relate to thessh> session to DOM0 (The ssh port is 22716, DOM0 is > 192.168.20.7 and machine I am ssh from is 192.168.20.30), then itbsods.> Before the bsod there is some double size packets. (Even > though I have disabled gso on all interfaces, bridges and otherwise),but> not directly prior to the bsod. So at this stage I am not > sure if I''m down the garden path or still on the verandah. :-) > The physical interface that the packets run on is eth1. I am a little > confused as to why the ssh packets also show up on the tap1 > interface as there is no ssh connection to the DOMU, only DOM0. > Thanks. The dump is below: >------------------------------------------------------------------------ --> - > # tcpdump -i tap0 greater 1500 > tcpdump: WARNING: tap0: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocoldecode> listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes > 20:44:42.183259 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 2964273857:2964275317(1460) ack 3005185253 win 545 > 20:44:43.626964 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 7296:8756(1460) ack 417 win 545 > 20:44:43.626980 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 8756:10216(1460) ack 417 win 545 > 20:44:44.266984 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 12784:15704(2920) ack 449 win 545 > 20:44:45.225979 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 16912:18372(1460) ack 449 win 545 > 20:44:46.178139 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 20272:21732(1460) ack 449 win 545 > 20:44:46.576267 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 23824:25284(1460) ack 529 win 545 > 20:44:46.577062 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 25888:27348(1460) ack 529 win 545 > 20:44:46.585779 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 27348:28808(1460) ack 529 win 545 > 20:44:47.178179 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 30160:33080(2920) ack 609 win 545 > 20:44:47.885066 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 35712:37172(1460) ack 609 win 545 > 20:44:47.885997 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 37776:39236(1460) ack 609 win 545 > 20:44:47.893317 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 39236:40696(1460) ack 609 win 545 > 20:44:48.182306 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 41520:44440(2920) ack 641 win 545 > 20:44:48.182329 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: P > 44440:45888(1448) ack 641 win 545 > 20:44:48.191866 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 47248:48708(1460) ack 641 win 545 > 20:44:48.234170 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 50192:51652(1460) ack 721 win 545 > 20:44:48.407627 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 52912:54372(1460) ack 721 win 545 > 20:44:48.408410 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 54960:56420(1460) ack 721 win 545 > 20:44:48.409493 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 56800:58260(1460) ack 721 win 545 > 20:44:48.571215 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 58608:60068(1460) ack 753 win 545 > 20:44:48.600938 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 60496:61956(1460) ack 801 win 545 > 20:44:48.601814 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 62336:63796(1460) ack 801 win 545 > 20:44:48.715526 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 64384:65844(1460) ack 801 win 545 > 20:44:48.716277 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 66416:67876(1460) ack 801 win 545 > 20:44:48.717355 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 68256:69716(1460) ack 801 win 545 > 20:44:49.182112 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 70304:73224(2920) ack 833 win 545 > 20:44:49.182136 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 73224:74684(1460) ack 833 win 545 > 20:44:50.182639 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 76720:78180(1460) ack 833 win 545 > 20:44:50.182659 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 78180:79640(1460) ack 833 win 545 > 20:44:50.188947 IP 192.168.20.7.22716 > 192.168.20.30.kofax-svr: . > 79872:81332(1460) ack 833 win 545 > tcpdump: pcap_loop: recvfrom: Network is down > 31 packets captured > 66 packets received by filter > 0 packets dropped by kernel > [root@catss3 vm]# Traceback (most recent call last): > File "/usr/share/virt-manager/virtManager/console.py", line 202, in > _vnc_disconnected > self.try_login() > File "/usr/share/virt-manager/virtManager/console.py", line 217, in > try_login > protocol, host, port = self.vm.get_graphics_console() > File "/usr/share/virt-manager/virtManager/domain.py", line 447, in > get_graphics_console > type = self.get_xml_string("/domain/devices/graphics/@type") > File "/usr/share/virt-manager/virtManager/domain.py", line 417, in > get_xml_string > xml = self.get_xml() > File "/usr/share/virt-manager/virtManager/domain.py", line 51, in > get_xml > self.xml = self.vm.XMLDesc(0) > File "/usr/lib64/python2.4/site-packages/libvirt.py", line 196, in > XMLDesc > if ret is None: raise libvirtError (''virDomainGetXMLDesc()failed'',> dom=self) > libvirt.libvirtError: virDomainGetXMLDesc() failed >------------------------------------------------------------------------ --> -------- > -----Original Message----- > From: James Harper [mailto:james.harper@bendigoit.com.au] > Sent: Tuesday, 25 March 2008 5:55 PM > To: xensource.2007@mymail.isbest.biz; xen-users@lists.xensource.com > Subject: RE: [Xen-users] Xen Windows Clients - BSOD > withApplicationFirewallInstalls > > > I think you''ll need to figure out what interface is launching these > packets onto your network, but in the meantime just turn of gso > on all interfaces attached to the bridge - do a ''brctl show'' to get alist> of them. > > If you are still getting BSoD''s after doing that, do a tcpdump on thetapX> device belonging to your windows HVM domain, and see if a > large packet coincides with your BSoD. If it doesn''t, then I''veprobably> lead you down the wrong path. > > It might be easiest to do that second step first: > . brctl show > . create your domain in a paused state > . brctl show > . start a tcpdump on your tapX interface (eg the one that wasn''t therein> the first brctl show but is in the second). If this is > your only hvm domain then you can skip this and just assume tap0 > > The syntax you want for your tcpdump is probably something like''tcpdump -> i tapX greater 1500'', which should be fired whenever a > packet is >1500 bytes. > > James > > > -----Original Message----- > > From: DoNotReply [mailto:DoNotReply@mymail.isbest.biz] On Behalf Of > > xensource.2007@mymail.isbest.biz > > Sent: Tuesday, 25 March 2008 18:36 > > To: James Harper; xensource.2007@mymail.isbest.biz; xen- > > users@lists.xensource.com > > Subject: RE: [Xen-users] Xen Windows Clients - BSOD > > withApplicationFirewallInstalls > > > > Thanks James > > But it makes no dif. Am I applying it to the correct interface > (xenbr1)? > > > > > > -----Original Message----- > > From: xen-users-bounces@lists.xensource.com [mailto:xen-users- > > bounces@lists.xensource.com] On Behalf Of James Harper > > Sent: Monday, 24 March 2008 6:49 PM > > To: xensource.2007@mymail.isbest.biz; Rudi Ahlers; xen- > > users@lists.xensource.com > > Subject: RE: [Xen-users] Xen Windows Clients - BSOD > > withApplicationFirewallInstalls > > > > > > > 6) At firewall startup, BSOD > > > 7) Subsequent restarts result in BSOD as previously stated. > > > > Xen appears to be sending ''large'' packets onto the bridge, and thetap> > interface isn''t ''un-large-ing'' them. > > > > " > > 20:40:34.437312 IP (tos 0x0, ttl 128, id 34470, offset 0, flags[DF],> > proto: TCP (6), length: 52) 192.168.207.200.5001 > > > 192.168.207.254.53981: ., cksum 0x05aa (correct), 1:1(0) ack 14505win> > 58295 <nop,nop,timestamp 57828874 1445680997> 20:40:34.437324 IP(tos> > 0x0, ttl 64, id 51510, offset 0, flags [DF], > > proto: TCP (6), length: 4396) 192.168.207.254.53981 > > > 192.168.207.200.5001: . 23193:27537(4344) ack 1 win 46 > <nop,nop,timestamp > > 1445680998 57828874> 20:40:34.439653 IP (tos 0x0, ttl 128, > > id 34471, offset 0, flags [DF], > > proto: TCP (6), length: 64) 192.168.207.200.5001 > > > 192.168.207.254.53981: ., cksum 0x2a79 (correct), 1:1(0) ack 15953win> > 56847 <nop,nop,timestamp 57828874 1445680997,nop,nop,sack 1 > > {17401:18849}> 20:40:34.439670 IP (tos 0x0, ttl 64, id 51513,offset> 0, > > flags [DF], > > proto: TCP (6), length: 4396) 192.168.207.254.53981 > > > 192.168.207.200.5001: . 27537:31881(4344) ack 1 win 46 > <nop,nop,timestamp > > 1445680999 57828874> " > > > > Note the lengh of 4396 - the hardware interface is supposed to break > that > > up into MSS sized chunks, but there is no hardware > > interface involved in this case. > > > > I''m trying to resolve the problem in the GPL PV drivers. > > > > I''ve had wireshark (npf.sys) BSOD when it receives a packet with a > size > > greater than MTU, so I imagine a firewall may well do the samething.> > > > Try turning off large send offload for all interfaces on the bridge > (the > > same bridge as your crashing DomU), eg: > > > > " > > ethtool -K <ifname> gso off > > " > > > > Iperf gives horrible results too when DomU is the ''server'' and Dom0is> the > > ''client'' because of this. > > > > James > > > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com http://lists.xensource.com/xen-users > > > > No virus found in this incoming message. > > Checked by AVG. > > Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date: > > 24/03/2008 3:03 PM > > > > No virus found in this outgoing message. > > Checked by AVG. > > Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date: > > 24/03/2008 3:03 PM > > > > > > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date: > 24/03/2008 3:03 PM > > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.519 / Virus Database: 269.22.0/1341 - Release Date: > 24/03/2008 3:03 PM > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
jim burns
2008-Mar-25 23:01 UTC
Re: [Xen-users] Xen Windows Clients - BSOD with ApplicationFirewallInstalls
On Monday 24 March 2008 05:48:54 am James Harper wrote:> Xen appears to be sending ''large'' packets onto the bridge, and the tap > interface isn''t ''un-large-ing'' them.If that''s the case, has either of you tried setting the MTU in the Windows registry, to disable large packets? HKLM/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters/Interfaces/<uuid #> It''s left as an exercise figuring out what your nic''s uuid # is :-) _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
James Harper
2008-Mar-25 23:32 UTC
RE: [Xen-users] Xen Windows Clients - BSOD withApplicationFirewallInstalls
> On Monday 24 March 2008 05:48:54 am James Harper wrote: > > Xen appears to be sending ''large'' packets onto the bridge, and thetap> > interface isn''t ''un-large-ing'' them. > > If that''s the case, has either of you tried setting the MTU in theWindows> registry, to disable large packets? >HKLM/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters/Interfaces/<uuid> #> > It''s left as an exercise figuring out what your nic''s uuid # is :-)The problem is already that Windows doesn''t support large packets, but Dom0 and others are sending them. James _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users