Xen project Mailing List

Oliver,

That’s interesting. It suggests a bug in the guest tx side checksum calculation. This is normally done by netback setting up metadata in skb and having either the kernel or the h/w driver do the calculation. Disabling the option in the guest means the calculation will be done in-guest by XENVIF before the segment is passed to netback. Hence, it sounds like your problem may actually be in your dom0 or NIC (possibly failing to handle some quirk of the RDP packets).

Cheers,

Paul

From: Oliver Linden <oliver_linden@xxxxxxxxxxx>
Sent: 07 May 2020 12:34
To: paul@xxxxxxx; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: Likely bug in the PV driver v9.0

Hi Paul,

that was a perfect hint!

Disabling all features in the advanced properties pane allowed to reconnect via RDP.

I subsequently activated the features and was able to nail it down to the two "TCP Checksum Offload (IPv[46])" entries. For those two you need to set them to either "Disabled" or "RX enabled". TX and RX&TX enabled are breaking RDP connectivity.

Many thanks for your support, it's highly appreciated.

Best, Oliver

Am 06.05.20 um 09:26 schrieb Paul Durrant:

Hi Oliver,

Xen 4.9 and Ubuntu 18.04 are clearly both a little old. I guess it is possible that changes in netback have caused problems. I think the next step is probably to disable all offloads (checksum and LSO) in advanced properties pane for the PV network frontend and see if the problem still exists. If that doesn’t have any effect then next would be to collect wireshark traces and look for oddities around RDP login.

Cheers,

Paul

From: Oliver Linden <oliver_linden@xxxxxxxxxxx>
Sent: 05 May 2020 18:38
To: paul@xxxxxxx; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: Likely bug in the PV driver v9.0

Hello Paul,
thanks a lot for your reply. I already reached out to the Xen IRC channels but didn't get a response besides the email address I've used for my initial email.
The Windows firewall settings don't have any influence on the behavior. I tested that already. But as far as I can recall I had the drivers installed on a Windows 10 1909 DomU on my old server running an upgraded ubuntu 18.04 with Xen 4.9 and xend still being active (originally server install date was Dec 2012 with ubuntu 12.04 and their Xen version).
With this setup the v9 drivers were working with RDP. Does this give you any hint/idea?
Best, Oliver
Am 05.05.20 um 15:56 schrieb Paul Durrant:
Hi Oliver,

I can only think this is a checksumming issue. I can’t see how else a network driver operating no higher than L4 (for checksum/LSO) would be able to affect a very specific part of a higher level protocol. Although, one thing to watch out for… in the past I have seen Windows do things like re-enabling firewall rules when there is a change in the network stack so you might want to check that.

Cheers,

Paul

From: win-pv-devel <win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Oliver Linden
Sent: 04 May 2020 18:06
To: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Likely bug in the PV driver v9.0

Dear all,
I'm observing an annoying bug with the v9 Windows PV drivers. It's easy reproducible here on my side:
Dom0:
ubuntu 20.04 freshly installed around Easter with there version of Xen (4.11) and only using the xl tool-stack.
DomU:
With every fresh installation of Windows 10 v1909 German the following can be reproduced:
Everything is working but slow as expected
Installation of the v9 drivers works well without any issues and results in significantly improved speed
but
RDP connections to such a machine aren't possible anymore. The RDP service always asks for a user/PW but never accepts it. To be precise, the RDP connections are working
with the plain vanilla installation
with the v9 drivers being installed except the network class & driver
Since I'm using my Windows machines predominately with RDP clients it would be great if this can be solved. Please let me know if you need any kind of details from my side.
Best, Oliver

RE: Likely bug in the PV driver v9.0