Xen users - Oct 2013 - GPLPV signed network drivers cause TCP connection resets on some HTTPS endpoints on Windows Server 2012 R2 guest

Config:
- 64-bit Ubuntu 13.10 host on Hetzner dedicated server
- Xen 4.3
- Windows Server 2012 R2 guest
- GPLPV signed drivers downloaded from <
http://wiki.univention.de/index.php?title=Installing-signed-GPLPV-drivers>
(gplpv_Vista2008x64_0.11.0.372.msi)
- Problem reproduced with both bridged and routed networking setup
- The server is new, has nothing setup or running on it apart from Xen and
this single VM (since getting started with Xen on Hetzner was more
challenging than expected, I wrote up a guide that includes the detailled
config I''m using here if this helps: <
http://blog.tickmeet.com/2013/10/setting-up-windows-server-2012-r2-on-xen.html
>)
With the config above, the connection fails when trying to access specific
HTTPS endpoints. It seems that the TCP connection gets reset.

Example 1:
Trying to load <https://login.live.com> in a web browser on the Windows
guest results in:

Firefox: "The connection to the server was reset while the page was
loading."
Chrome: "No data received - Error code: ERR_EMPTY_RESPONSE"
IE 10: can''t load page (don''t have the exact error message)

Loading the http version of that page works just fine.

Loading HTTPS version from PowerShell using Invoke-WebRequest works fine
too. I can only reproduce it consistently when loading the page in a web
browser. I''m guessing that PowerShell must send request headers that
cause
the Microsoft''s servers to serve a different page than what is served
to
browers.

Example 2:
Accessing the meetup.com API over HTTPS from a .NET 4.5 application results
in the following exception for two specific endpoints of the API (but all
the other endpoints work fine):

"System.IO.IOException : Received an unexpected EOF or 0 bytes from the
transport stream"

General points:
- Networking in general works fine on the guest.
- All HTTP connections works 100% fine.
- The immense majority of HTTPS requests also work fine.
- The problem only occurs for a few very specific HTTPS requests and
it''s
reproducible at least 99% of the time for those particular requests
(occasionally, one of those requests will go through before failing again
the next time).

This problem has been driving me nuts for a good two days now. I tried
everything I could think of to fix this to no avail. Eventually, last
night, I remembered about the GPLPV drivers and wondered if they could be
the culprit. So I uninstalled them and, lo and behold, everything works
perfectly now.

For those who want to uninstall the drivers, uninstalling the package via
Add / Remove programs will most likely nuke your VM. If this happens,
Windows should let you still boot using the last know good configuration,
which will bring it back up again but it will still be using the GPLPV
drivers. The .bat script for the 0.10 version at the bottom of <
http://wiki.univention.de/index.php?title=Installing-signed-GPLPV-drivers>
will take care of uninstalling them properly. A reboot and you should be
good to go.

Cheers,
Mehdi


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

On Sun, Nov 3, 2013 at 11:58 PM, James Harper
<james.harper@bendigoit.com.au
> wrote:
>
> I can''t reproduce this on 2008R2. Are you able to confirm if this
problem
> only exists under 2012R2?
>
> I have 2012R2 downloaded and ready to install but haven''t had time
yet. If
> you have found that this is a problem that is new to 2012R2 I''ll
try and
> hurry up and install it.
>
>
That 2012 R2 VM is the only one I''ve setup with Xen. But setting up a
2008
R2 machine should just be a matter of a few minutes so I''ll do that and
let
you know if it''s 2012-specific or not.

Mehdi


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

On Mon, Nov 4, 2013 at 11:03 AM, Mehdi El Gueddari
<mehdi@tickmeet.com>wrote:
> On Sun, Nov 3, 2013 at 11:58 PM, James Harper <
> james.harper@bendigoit.com.au> wrote:
>
>>
>> I can''t reproduce this on 2008R2. Are you able to confirm if
this problem
>> only exists under 2012R2?
>>
>> I have 2012R2 downloaded and ready to install but haven''t had
time yet.
>> If you have found that this is a problem that is new to 2012R2
I''ll try and
>> hurry up and install it.
>>
>>
> That 2012 R2 VM is the only one I''ve setup with Xen. But setting
up a 2008
> R2 machine should just be a matter of a few minutes so I''ll do
that and let
> you know if it''s 2012-specific or not.
>
So I''ve setup a new VM on that same machine with a 64-bit install of
Windows Server 2008 R2 Standard Edition with SP1. And I''m getting the
exact
same problem.

Before installing the GPLPV drivers, I could load
https://login.live.comjust fine in Firefox (haven''t tried other
browsers but I''m assuming that,
just like with 2012 R2, it''s not browser-specific). After installing
the
drivers, the page fails to load with a "The connection was reset"
error
message from Firefox.

This is weird. I could give you access to the VM if you wanted although
I''m
not sure if you''d like to spend time troublshooting an issue that
appears
to be isolated to a single machine. I haven''t come accross any other
mentions of the issue anywhere.

Cheers,
Mehdi


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

> Before installing the GPLPV drivers, I could load https://login.live.com
just
> fine in Firefox (haven''t tried other browsers but I''m
assuming that, just like
> with 2012 R2, it''s not browser-specific). After installing the
drivers, the page
> fails to load with a "The connection was reset" error message
from Firefox.
> 
> This is weird. I could give you access to the VM if you wanted although
I''m
> not sure if you''d like to spend time troublshooting an issue that
appears to
> be isolated to a single machine. I haven''t come accross any other
mentions of
> the issue anywhere.
> 
Can you get a tcpdump of what is going on? You''d need to do it in dom0
I think, and using the ''-s0'' option to capture full packets.

Also can you confirm that there is only the one Ethernet interface active in the
DomU?

After you''ve done the tcpdump, can you mess around with turning off
some of the offload options (adapter settings in windows) and see if that makes
a difference.

There should be nothing strange about https though as compared to any other
protocol.

Thanks

James