netdev - rtl8168e-vl dropping tftp ack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <516EB23B.3080504@canonical.com>
Date:	Wed, 17 Apr 2013 16:31:23 +0200
From:	Stefan Bader <stefan.bader@...onical.com>
To:	netdev@...r.kernel.org
CC:	Realtek linux nic maintainers <nic_swsd@...ltek.com>,
	Francois Romieu <romieu@...zoreil.com>
Subject: rtl8168e-vl dropping tftp ack

There seems to be a subtle problem in handling the tftp part of
pxe booting a vm guest that is related to the specific hw /
driver.

I could observe this when using the r8169 driver from kernels
3.2, 3.5 and 3.8. It does not seem to happen when I replaced
the driver with r8168-8.035.00.tar.bz2 from the realtek site
(this I only did for kernel 3.2 for now).
It also seems to be worked-around by changing the tftp sequence
(see below).

The setup is as follows:

+-------------+
| TFTP server |
|      +------+
|      | eth0 +---+
+------+------+   |
                  |
+-------------+   |
| Xen host    |   |
|             |   |
| +-----------+   |
| | br0       |   |
| |    +------+   |   +-----------+
| |    | eth0 +---+   | Xen guest |
| |    +------+       +------+    |
| |    | vif0 +-------+ eth0 |    |
+-+----+------+       +------+----+

The Xen host has the Realtek NIC:

2:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
       RTL8111/8168B PCI Express Gigabit Ethernet controller
       [10ec:8168] (rev 06)
       Subsystem: Micro-Star International Co., Ltd. Device [1462:7798]

This is configured to be the external port of a transparent bridge.
Normal networking is working without any apparent issues.
The problem arises when a xen guest tries to pxe boot. I had tcpdump
processes running on eth0 of the Xen host and on eth0 of the TFTP
server.

- DHCP of the Xen guest is successful (and can be pinged from then on)
- Transfer of pxelinux.0 via tftp works
- The guest then tries to load a config file named like the UUID of
  the virtual adapter. This does not exist and tftp returns "file not
  found"
  - Read Request, File: pxelinux.cfg/df80012c-a855-d44b-3fb2-4ef4932fdf83,
    Transfer type: octet, tsize\000=0\000, blksize\000=1408\000
  - Error Code, Code: File not found, Message: File not found
- Next the guest tries to transfer a config file which is named like
  the MAC address of the guest. This file exists.
  - Read Request, File: pxelinux.cfg/01-00-16-3e-cd-a2-82,
    Transfer type: octet, tsize\000=0\000, blksize\000=1408\000
- The tftp server returns an ACK together with the size of the file.
  - Option Acknowledgement, tsize\000=103\000, blksize\000=1408\000
- The guest would ACK with
  - Acknowledgement, Block: 0

However, that last package only shows up on the Xen host side tcpdump.
It never seems to make it out. The server retries its ack a few times
but without any reaction from the vm guest side.
Avoiding the "file not found" situation by creating a properly named
soft link on the tftp servers side seems to avoid this problem, too.
Also there are a few occations (but I cannot tell why those happen)
when the tftp sequence works even with the first file not found. But
in the majority of cases the transfer fails due to that ack of block 0
not reaching the tftp server.

I am not sure this is enough to find out what goes wrong but I can
add debugging code to the kernel driver or gather other info if
someone can hint me which things would be of interest.

Thanks,
-Stefan

Download attachment "signature.asc" of type "application/pgp-signature" (900 bytes)