I am on Ubuntu 19.10 with a RTL8153 USB-C ethernet adapter built into a DA200 (dock/cable) adapter connected via Thunderbolt 3 to a Dell Latitute 7300 machine (with UEFI secure boot if that matters).
My current approach is to get an 802.1X wired connection to run via NetworkManager (which, I assume, uses dhclient behind the curtains). However, the settings I use currently fail in obtaining an IP address robustly.
uname -r: 5.3.0-26-generic
/
linux-firmware: 1.183.3
lsusb: Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
ip link: myif: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether <mac> brd ...
Because NetworkManager is not properly working for me out of the "19.10" box, I started using dhclient
directly, with mediocre success. However,
now I am getting these strange errors (copied from journalctl -f
) when trying to establish a connection with sudo dhclient -v myif
:
dhclient: DHCPDISCOVER on myif to 255.255.255.255 port 67 interval 17 (xid=0xfeee5e2c)
dhclient: send_packet: No such device or address
dhclient: dhclient.c:2569: Failed to send 300 byte long packet over myif interface.
kernel: r8152 4-1.1:1.0 myif: Tx status -71
I can also see
kernel: r8152 4-1.1:1.0 xxx: Tx status -71
systemd-resolved: Failed to send hostname reply: Invalid argument
kernel: r8152 4-1.1:1.0 xxx: Tx status -71
and tons of repetitions.
First, I got it to work but only for until next login or for a couple of minutes. I have spent a few hours in reading forums and issue reports, and tried around. Also switching NetworkManager.conf from managed=false
to true
doesn't change anything.
Update 1: When first asking this question, I thought only the wired interface was affected and only in a particular setting. But then I realized that the speed varies and both interfaces wireless and wired are affected. When I found that fairly recent issue report, suggesting that the Kernel 5 (also used in 18.04.3) might be the problem, I stopped trying around with NM. Has anybody an idea whether I can get around installing Kernel 4 and risking not being able to use other recent HW features?
Update 2:
I have now tested the described hardware setting under Windows 10 (Oct'19) with the result that both wifi/ethernet work out of the box with both the genuine W10 driver and the latest Realtek GBE Ethernet driver available from Dell (Dec'19). It appears as if there is something strange going on with the Realtek linux kernel module r8152
operating the DA200 USB-C dock/dongle via the Thunderbolt 3 (TB3) socket. My machine is currently running on the TB3 firmware v40.3. My attempt to update the TB3 firmware to Dell's latest (v44) under W10 was unsuccessful. After updating to the newest BIOS (1.6.1, as indicated here), switching to BIOS factory settings, updating to Dell's newest TB3 Application and TB3 Driver, Dell's Firmware installer (Dec'19, Intel_TBT3_FW_UPDATE_NVM44_Y9HXJ_A02_4.44.118.001
) keeps freezing Windows, forcing a hard reboot. I tried to find corresponding instructions/issue reports with no success, except for a note that for certain firmware versions one has to have a TB device plugged in, and I don't have one (DA200 is afaik not a TB but a USB-C device). Anyway, that leaves me unable to check whether the latest TB3 firmware fixes the issue with Kernel 5 and r8152 module respectively. Sidenote: Switching back to Kernel 4.17 didn't change anything either.
Update 3: Good news, switching off SMM Security Mitigation
in the BIOS allowed me to update to TB3 firmware v44. Bad news, it doesn't seem to change anything with the Realtek networking issue. So, it must be something different.
I found that switching off Bluetooth and suspend/resume made the DA200 work a couple of times but highly unreliably. My solution was to buy a generic docking adapter. The fact that this adapter (and many others one can find) has the same chipset (Realtek 8153) makes me believe that the DA200 hardware is intricate to handle by drivers or simply unreliable. For any DA200 users' interest, my observation sadly confirms to what is reported by several others. The W10 drivers seem to be able to circumvent these issues. I've filed an issue report with the hope to help getting a potential kernel bug fixed.