Make sure you have disabled the fast startup option; Windows can hold on to hardware resources while hibernating, including the network card.
Find the “Choose what the power buttons do” menu in Control Panel, and ensure the power button actually shuts down the computer instead of hibernation or something else. You have to enable changing settings that are unavailable to do it.
I’m not sure how up to date this image is, but the options you need to change are like so:
Hello @Matt_Hartley, thank you so much! Apologies for the delay! Wasn’t able to troubleshoot this as the semester got busier. I should have time now and will post the results.
I’m running into this on a Framework 11th gen that’s never seen windows.
Bare Debian (no GUI) with realtek-firmware installed.
ip addr and lshw show the device existing, but ifup can’t find it.
I’m half way to figuring it out.
The ethernet module is using an RTL8156BG.
The firmware for this chip is not available in the bullseye version of the firmware-realtek package.
The firmware for the RTL8156A/B is available in the bullseye-backports, bookworm, sid, and experimental repos. But the kernel does not appear to be loading these for the BG variant.
My continued thanks to Framework for designing for screwdrivers. The ethernet module uses threaded inserts and that gives a lot more confidence to re-assembly.
ok, I think I’ve figured out the situation.
Background, I have two frameworks in question here, one is running Debian Stable (11, bullseye), and the other is running rolling-release Fedora. Debian is running the 5.10.179-1 kernel, Fedora 6.2.14-300.
Some of this information is based on Fixing performance issues with Realtek RTL8156B 2.5GbE USB dongle in Ubuntu - CNX Software and Realtek USB FE / GBE / 2.5G / 5G Ethernet Family Controller Software - REALTEK
As far as I understand it:
I could go and learn how to write modalias strings, but I think it might be smarter at this point to hand it off to someone with more experience in these things.
I think all the important bits are in Linux kernel repos.
And the other RTL8156* chips were contributed directly by Realtek employees.
Which they ostensibly have not yet done for the RTL8156BG.
So I guess someone needs to go ask Realtek what’s up with that.
This is likely going to be the best course of action here for Debian. The Ethernet expansion card works out of the box on Debian based Ubuntu. So following up with Debian may be a good plan.
Probably with the cdc_ncm driver in half-duplex mode.
I just upgraded one of my frameworks to Debian 12 (bookworm) and it’s still not working.
We are only testing with vetted distros at this time. So I am not surprised that Debian isn’t cooperating given their approach to non-FSF-like software/firmware.
I’d definitely want to see this tested on a supported/vetted distro to make sure the card is working at all. If it is failing on Ubuntu, then there may be an issue with the card itself.
Hello. I am glad I finally found this thread. I purchased an 11gen mobo and coolermaster case and attempted to migrate proxmox to it from an old Intel NUC. Spent a few hours trying to figure out why ethernet was not working. I see now why that isn’t going to work, at least not with the framework ethernet accessory until Realtek releases an update driver? I don’t suppose anyone knows how long these things take? I’m mostly a windows guy so I have no clue how long it takes with linux OS’.
Not sure what you mean by Linux OS, are you reffering to Debian or another distro?
I’m referring to a driver release, preferably for Debian, yes. In my specific case, the one Proxmox uses.
Appreciate the clarification. Since we don’t test against Debian at this time, I want to get this in front of other Debian users - merging into the main thread.
Just as follow up, on Debian 12 (13th Intel Framework 13) connecting a 4K external display via HDMI is definitely more stable than USB-C. I also tried some Windows games with Steam Play and HDMI enables higher resolutions on the display (that was not the case with USB-C, I don’t know why).
Finally getting around to this.
Debian 12 (bookworm) is still not able to successfully use the ethernet module in any capacity. It tries to bring it up with the cdc_ncm driver, but fails.
Debian Testing tries to use the r8152 driver instead of the generic one, but it’s still not able to use the module. (When I looked back in June, Realtek had not released a firmware blob to the linux kernel firmware repo. It looks like such a blob has not propagated to Debian Testing.)
Ubuntu 23.04 (live image) is able to use the module without any additional configuration with the cdc_ncm driver–it gets an IP address and such. But it comes up in half-dupllex gigabit. Which isn’t even a mode I realized existed.
Fedora 38 (Live) looks to be identical to Ubuntu: uses the generic driver, gets an IP, comes up in half-duplex.
I’ll have to see if I can file a bug with Debian–I have no expertise in debugging this. But it would be nice if we got the full capabilities of this module on Linux, as opposed to just “it passes packets”. Maybe Framework can bother Realtek about it? They maintain specialized drivers for their other products.
Just got my Intel 13th gen and swapped the hard drive from my old lenovo into the framework (which was a breeze), the only extra thing I had to do was add i915.enable_psr=0 to /etc/grub/default which I had to do on the lenovo too (seems to be a common thing with intel graphics). It stops weird graphical glitches.
This may not be a requirement for a clean install which I may get around to trying at some point.
Another minor tweak which was suggested by support is to enable deep sleep by adding:
mem_sleep_default=deep to /etc/default/grub
Tip: If you use an Android phone, you can switch it to the “USB tethering” connection mode to make it an Ethernet network.
