My framework ethernet expansion card is really flaky and unreliable. I’ve tried other USB-C NICs based on the same Realtek chipset and all of them seem to work fine. Did I get a dud?
What is your operating system and version?
This is on Windows 11 22H2. I’ve updated to the latest Realtek driver and it’s had no effect.
Generally the problem occurs when a large, fast transfer is initiated - general browsing usually is fine, but if I kick off a large download, local file transfer, or internet speed test it hangs.
Understood, I’m Linux support and I tagged this as Windows so folks that can help will see it.
Thanks. It seems to happen under linux too, I’ve tried it after booting into Ubuntu 22.04.
Ah, okay. That I can be of help with Are you seeing this behavior from a Live USB of Ubuntu as well? I realize installed Ubuntu is presenting this issue, just to cover all of our bases.
In a terminal, run this command:
journalctl -f
Do you see anything that looks like this:
usb 2-3: USB disconnect, device number 74 xhci_hcd 0000:00:0d.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. cdc_ncm 2-3:2.0 enx9cbf0d000e38: unregister ‘cdc_ncm’ usb-0000:00:0d.0-3, CDC NCM xhci_hcd 0000:00:0d.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
If you do, does this error show itself with it plugged into another port as well?
It wasn’t under installed Linux, I’d booted from a Live USB to test the NIC. I don’t plan to do that again because it turns out the Ubuntu live stick alters some UEFI variables and caused Bitlocker to lock me out of my machine when I did that. I was just pointing out that the issue happened on both operating systems.
1 Like
This is a bit of a necro but since I am experiencing the same issue I figured it might make sense to respond here.
Brief summary:
System is an 11th Gen i7 Mainboard with 32GB RAM running Proxmox 9 (previously running 8.4). OS drive is a Samsung 970 nvme, no wifi card attached, it has an external DAS with spinning rust via USB for mass storage in RAID10 Btrfs. Ethernet is supplied via the Framework expansion card, connected to a 2.5Gbit ubiquity switch of some random model.
What I have observed is that the system sometimes randomly just falls off of the network, but it is relatively easy to trigger it through prolonged data transfers. The system appears to still be on, but until now I had not suspected the Ethernet card, but this behaviour definitely matches.
I ran journalctl -f in a root console but cannot see anything like the example given.
I think but don’t remember for sure that I have already tried swapping port when I initially suspected the power supply currently in use (a 120w USB-C power supply ordinarily supplied with my work-issued Dell but co-opted for this role after I sheepishly figured out that the standard FW brick I had ordered for this isn’t actually intended for battery-less operation. Ooops. 
). I did also try swapping the USB-powered DAS from running a RAIDZ ZFS pool to a Btrfs RAID10 (since running ZFS storage via USB is most definitely off-label use, I figured I’d check if Proxmox itself was just unhappy with things being transferred en-masse).
I’ll try specifically swapping USB port now since why not, but if there’s any ideas on any persistent logs I can look at to confirm the issue is the Ethernet that would be awesome - the unit is headlessly mounted in the Cooler Master case in the electrical cabinet of my house, so it’s a fairly cumbersome operation to get interactive access to it without networking, but if there’s no simpler way - let me know and I’ll try.
Edit: To assist in some troubleshooting, I added an hourly cron that simply does date >> /var/log/checkusb && lsusb >> /var/log/checkusb. My initial suspicion from this (the device does not drop off of the list) is that it’s probably not actually the Ethernet card that’s having issues (even if it does get mighty hot). I’ve ran a Memtest session on the RAM and found no fault, and tried disabling Turbo Boost as well, but I am starting to suspect that the poor mainboard has simply had a long life and some component on the mainboard itself is starting to give in.
I haven’t managed to figure out what, though, and will tinker a bit with some software tests (switching from Proxmox to uCore or FreeBSD, depending on what mood I’m in next time I have a couple hours free), just to eliminate Proxmox from the equation. But it is certainly not at all impossible that it’s just a board that’s starting to flake out, but that it’s not something that would become readily apparent when I was using it for an hour every other evening to play around with some C on OpenBSD - a very lightweight job.