Got the Ethernet card and the DisplayPort card today. I’ll test the Ethernet when I’m not on my college’s network, but so far the DisplayPort works well. 
2 Likes
I added the Expansion cards to my two Framework laptops.
I did a slight issue when I have the two Framework laptops using these ethernet cards with a 5 port switch (Netgear GS105E): I cannot toggle the card on or off via the POP!_OS Network GUI. The card is working – I have the amber and green light displayed.
Using the switch, I was creating a small static network between the two laptops to allow me to transfer files between the two laptop (and to use x2go).
When I check the network adapters via “ip a” this is the line of text for the Framework ethernet card:
enx9cbf0d000496: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
When I plug the same ethernet cable into the larger network (with servers/switches/live internet), the ethernet device is active and I can toggle it on or off via the Network GUI.
To me this does not seem to be an OS issue, but an issue how the Network hardware is recognizing ethernet connects to the switch. I don’t have this issue with docking stations that have ethernet ports.
Good results from the Ethernet IO card in terms of speed.
However, it doesn’t seem to be hot-swapable (requiring a reboot every time I plug it in). 
I’ll have to do some trouble-shooting tomorrow. 
Running: Manjaro KDE, Kernal 5.19.7-1, last update: 20SEP 2022.
No blinking indicator lights (or whatever they’re called)
Good speeds from Fios… after rebooting to get it to connect.
Framework stuffed inside my backpack’s laptop sleeve.
FYI: Hot plugs/hot swappable fine for me under Pop!_OS 22.04; which includes kernel 5.19.0-76051900-generic #202207312230~1660780566~22.04~9d60db1 SMP PREEMPT_DYNAMIC Thu A x86_64 x86_64 x86_64 GNU/Linux
1 Like
@Robert_Emery - are you able to have the card detect the ethernet cable when connected to a simple Network switch? I can only get the card to be working with my larger network (that has DHCP servers and a live internet). I have the same Kernel as you (my earlier post shared that I have both Framework 11th and Framework 12th gen models - both DYI with the faster processor for each model.
I wanted to create a second network using my two framework laptops connected to a small desktop switch.
I had only tested it from the perspective of: plug in the card into the USB-C, plug-in the network cable, works. Unpug the USB-C Card, plug it back-in (and the network cable). Unplug the USB-C card and plug into into a different USB-C port, works etc.
You’re talking about unplugging only the network cable correct? You’re also implying that it doesn’t work if you unplug and replug the network cable when plugged into an isolate network without DHCP? I assume you want to statically configure IP’s in that situation and you want network manager to remember which IP’s have been assigned between different “sessions” as it were (i.e. each duration that you plugged in the network cable)?
Is that correct?
Yes I was going to use static address such as 10.40.0.1 thru 10.40.0.5 for the two laptops, the switch, etc.
I have done the tests that you have stated:
- Plug the card into the Framework laptop
- If the card is not detected, reboot the laptop
- Plug in the ethernet cable - say to my larger network with DHCP servers and live internet - watch the network connection is detected
- I did check that all the packages are updated on both laptops
Leaving the card in the same slot, I unplug the current ethernet cable from the laptop to use another ethernet cable that is connected to a desktop switch (Netgear GS105e).
When I use the GS105e switch between the two laptops, I am not getting the card to recognize the active ethernet cable – even after a reboot.
So I’ve just tested it plugged into just a switch. ip link shows the link up when the cable is plugged in and down when the cable isn’t. So from a link detection perspective it seems totally fine.
I’ve assigned a static IP through network manager and ignoring the “network manager lag” (i.e. it takes like 5 seconds for it to take links fully down or up etc) it looks like when I unplug and re-plug the cable I get the same static IP assigned each time. Also works fine if I change USB-C port as well (i.e. the settings move with it). So I’m not seeing anything weird or different from what I would expect.
Hmm, it could be something specific about the Netgear GS105e maybe? I’m using a 5-port DLink DGS-1005D that’s laying around. I don’t think I’ve got any Netgears to test with anywhere unfortunately.
The router is part of their commerical line – a lifetime warranty. Everything else works great if I use USB - C gigabit dongles and the same switch.
I am noticing that the Ethernet expansion card on the Framework 11th Gen is taking itself offline and online about every 10 minutes.
I am wondering if one of my cards are faulty. I have tried 2 different USB - C ports for the cards. The problem only happens with the new ethernet card.
Is there something different due to the motherboard/processors?
No issue with any of the docs and the same switch or other Netgear switches GS116F or JGS524PE.
I can see show what syslog is reporting from the Framework laptop that has the Intel 11th Gen processor. x.x.x were values I added not disclose the CIDR of the local network.
Sep 23 12:43:31 framework NetworkManager[1055]: <info> [1663955011.9960] device (enx9cbf0d00049a): state change: activated -> unavailable (reason 'carrier-changed', sys-if
ace-state: 'managed')
Sep 23 12:43:32 framework NetworkManager[1055]: <info> [1663955012.0089] dhcp4 (enx9cbf0d00049a): canceled DHCP transaction
Sep 23 12:43:32 framework NetworkManager[1055]: <info> [1663955012.0089] dhcp4 (enx9cbf0d00049a): activation: beginning transaction (timeout in 45 seconds)
Sep 23 12:43:32 framework NetworkManager[1055]: <info> [1663955012.0090] dhcp4 (enx9cbf0d00049a): state changed no lease
Sep 23 12:43:32 framework systemd-resolved[895]: enx9cbf0d00049a: Bus client reset search domain list.
Sep 23 12:43:32 framework avahi-daemon[1059]: Withdrawing address record for x.x.x.22 on enx9cbf0d00049a.
Sep 23 12:43:32 framework systemd-resolved[895]: enx9cbf0d00049a: Bus client set default route setting: no
Sep 23 12:43:32 framework avahi-daemon[1059]: Leaving mDNS multicast group on interface enx9cbf0d00049a.IPv4 with address x.x.x.22.
Sep 23 12:43:32 framework avahi-daemon[1059]: Interface enx9cbf0d00049a.IPv4 no longer relevant for mDNS.
Sep 23 12:43:32 framework systemd-resolved[895]: enx9cbf0d00049a: Bus client reset DNS server list.
Sep 23 12:43:32 framework avahi-daemon[1059]: Withdrawing address record for fe80::3c05:b937:2bba:7b03 on enx9cbf0d00049a.
Sep 23 12:43:32 framework avahi-daemon[1059]: Leaving mDNS multicast group on interface enx9cbf0d00049a.IPv6 with address fe80::3c05:b937:2bba:7b03.
Sep 23 12:43:32 framework avahi-daemon[1059]: Interface enx9cbf0d00049a.IPv6 no longer relevant for mDNS.
Sep 23 12:43:32 framework systemd[1]: Starting Network Manager Script Dispatcher Service...
Sep 23 12:43:32 framework systemd[1]: Started Network Manager Script Dispatcher Service.
Sep 23 12:43:42 framework systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Sep 23 12:45:48 framework NetworkManager[1055]: <info> [1663955148.5821] device (enx9cbf0d00049a): carrier: link connected
Sep 23 12:45:48 framework NetworkManager[1055]: <info> [1663955148.5826] device (enx9cbf0d00049a): state change: unavailable -> disconnected (reason 'carrier-changed', sys
-iface-state: 'managed')
Sep 23 12:45:48 framework NetworkManager[1055]: <info> [1663955148.5843] policy: auto-activating connection 'Wired connection 2' (e702663f-53b7-3989-b2c2-3ffcbe7bc260)
Sep 23 12:45:48 framework NetworkManager[1055]: <info> [1663955148.5849] device (enx9cbf0d00049a): Activation: starting connection 'Wired connection 2' (e702663f-53b7-3989
-b2c2-3ffcbe7bc260)
Sep 23 12:45:48 framework NetworkManager[1055]: <info> [1663955148.5851] device (enx9cbf0d00049a): state change: disconnected -> prepare (reason 'none', sys-iface-state: '
managed')
Sep 23 12:45:48 framework NetworkManager[1055]: <info> [1663955148.5856] device (enx9cbf0d00049a): state change: prepare -> config (reason 'none', sys-iface-state: 'manage
d')
Sep 23 12:45:48 framework NetworkManager[1055]: <info> [1663955148.7377] device (enx9cbf0d00049a): state change: config -> ip-config (reason 'none', sys-iface-state: 'mana
ged')
Sep 23 12:45:48 framework NetworkManager[1055]: <info> [1663955148.7386] dhcp4 (enx9cbf0d00049a): activation: beginning transaction (timeout in 45 seconds)
Sep 23 12:45:48 framework avahi-daemon[1059]: Joining mDNS multicast group on interface enx9cbf0d00049a.IPv6 with address fe80::3c05:b937:2bba:7b03.
Sep 23 12:45:48 framework avahi-daemon[1059]: New relevant interface enx9cbf0d00049a.IPv6 for mDNS.
Sep 23 12:45:48 framework avahi-daemon[1059]: Registering new address record for fe80::3c05:b937:2bba:7b03 on enx9cbf0d00049a.*.
Sep 23 12:45:51 framework NetworkManager[1055]: <info> [1663955151.5260] device (enx9cbf0d00049a): carrier: link connected
Sep 23 12:45:54 framework NetworkManager[1055]: <info> [1663955154.2140] device (enx9cbf0d00049a): carrier: link connected
Sep 23 12:45:56 framework NetworkManager[1055]: <info> [1663955156.9022] device (enx9cbf0d00049a): carrier: link connected
Sep 23 12:45:59 framework NetworkManager[1055]: <info> [1663955159.5899] device (enx9cbf0d00049a): carrier: link connected
Sep 23 12:46:08 framework systemd[1]: Started Session 6 of User pcorey.
Sep 23 12:46:09 framework NetworkManager[1055]: <info> [1663955169.1766] device (enx9cbf0d00049a): state change: ip-config -> unavailable (reason 'carrier-changed', sys-iface-state: 'managed')
Sep 23 12:46:09 framework NetworkManager[1055]: <info> [1663955169.1969] dhcp4 (enx9cbf0d00049a): canceled DHCP transaction
Sep 23 12:46:09 framework avahi-daemon[1059]: Withdrawing address record for fe80::3c05:b937:2bba:7b03 on enx9cbf0d00049a.
Sep 23 12:46:09 framework avahi-daemon[1059]: Leaving mDNS multicast group on interface enx9cbf0d00049a.IPv6 with address fe80::3c05:b937:2bba:7b03.
Sep 23 12:46:09 framework avahi-daemon[1059]: Interface enx9cbf0d00049a.IPv6 no longer relevant for mDNS.
Sep 23 12:46:14 framework NetworkManager[1055]: <info> [1663955174.1820] device (enx9cbf0d00049a): carrier: link connected
Sep 23 12:46:14 framework NetworkManager[1055]: <info> [1663955174.1824] device (enx9cbf0d00049a): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
Sep 23 12:46:14 framework NetworkManager[1055]: <info> [1663955174.1837] policy: auto-activating connection 'Wired connection 2' (e702663f-53b7-3989-b2c2-3ffcbe7bc260)
Sep 23 12:46:14 framework NetworkManager[1055]: <info> [1663955174.1845] device (enx9cbf0d00049a): Activation: starting connection 'Wired connection 2' (e702663f-53b7-3989-b2c2-3ffcbe7bc260)
Sep 23 12:46:14 framework NetworkManager[1055]: <info> [1663955174.1847] device (enx9cbf0d00049a): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Sep 23 12:46:14 framework NetworkManager[1055]: <info> [1663955174.1852] device (enx9cbf0d00049a): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Sep 23 12:46:14 framework NetworkManager[1055]: <info> [1663955174.1858] device (enx9cbf0d00049a): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Sep 23 12:46:14 framework NetworkManager[1055]: <info> [1663955174.1871] dhcp4 (enx9cbf0d00049a): activation: beginning transaction (timeout in 45 seconds)
Sep 23 12:46:14 framework avahi-daemon[1059]: Joining mDNS multicast group on interface enx9cbf0d00049a.IPv6 with address fe80::3c05:b937:2bba:7b03.
Sep 23 12:46:14 framework avahi-daemon[1059]: New relevant interface enx9cbf0d00049a.IPv6 for mDNS.
Sep 23 12:46:14 framework avahi-daemon[1059]: Registering new address record for fe80::3c05:b937:2bba:7b03 on enx9cbf0d00049a.*.
Sep 23 12:46:14 framework NetworkManager[1055]: <info> [1663955174.1941] dhcp4 (enx9cbf0d00049a): state changed new lease, address=x.x.x.22
Sep 23 12:46:14 framework avahi-daemon[1059]: Joining mDNS multicast group on interface enx9cbf0d00049a.IPv4 with address x.x.x.22.
Sep 23 12:46:14 framework avahi-daemon[1059]: New relevant interface enx9cbf0d00049a.IPv4 for mDNS.
Sep 23 12:46:14 framework avahi-daemon[1059]: Registering new address record for x.x.x.22 on enx9cbf0d00049a.IPv4.
Sep 23 12:46:14 framework NetworkManager[1055]: <info> [1663955174.1967] device (enx9cbf0d00049a): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Sep 23 12:46:14 framework systemd[1]: Starting Network Manager Script Dispatcher Service...
Sep 23 12:46:14 framework systemd[1]: Started Network Manager Script Dispatcher Service.
Sep 23 12:46:14 framework NetworkManager[1055]: <info> [1663955174.2084] device (enx9cbf0d00049a): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Sep 23 12:46:14 framework NetworkManager[1055]: <info> [1663955174.2087] device (enx9cbf0d00049a): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Sep 23 12:46:14 framework NetworkManager[1055]: <info> [1663955174.2107] device (enx9cbf0d00049a): Activation: successful, device activated.
Sep 23 12:46:14 framework systemd-resolved[895]: enx9cbf0d00049a: Bus client set search domain list to: mydnshq.one, mydnshq.dev, mydnshq.net, mydnshq.org, mydnshq.work
Sep 23 12:46:14 framework systemd-resolved[895]: enx9cbf0d00049a: Bus client set default route setting: yes
Sep 23 12:46:14 framework systemd-resolved[895]: enx9cbf0d00049a: Bus client set DNS server list to: x.x.x.1
Sep 23 12:46:14 framework nm-dispatcher[19737]: /etc/network/if-up.d/resolved: 12: mystatedir: not found
Sep 23 12:46:14 framework nm-dispatcher[19774]: /etc/network/if-up.d/resolved: 12: mystatedir: not found
Sep 23 12:46:14 framework chronyd[1226]: Could not add source 129.6.15.28
Sep 23 12:46:14 framework chronyd[1226]: Could not add source 129.6.15.29
Sep 23 12:46:24 framework systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
2' (e702663f-53b7-3989
What I mean is that if there’s a specific problem between the framework USB-C adapter and that switch, it could be a firmware problem with the two together? I’ve had instances before where specific models of X don’t work with switch Y but others do etc; it is pretty rare though.
Is there something different due to the motherboard/processors?
Yeah possible I’ve only got an 11th gen; so I can’t test a newer one. If you swap the USB-C cards between the 11th and 12th gen, does the problem move with the card? (I assume the two cards are both Framework USB-C cards?)
Everything is working without issue on the Framework with the 12th Gen CPU.
The above log is from the 11th Gen only (the first model of the Framework laptop batch 6 shipped in December 2021).
I corrected the post as I mistyped the batch numbers between the two laptops.
Some early Framework batches have some problem with the shielding of the internal USB connectors. Have you looked at that?
Just a quick note for any Windows users here. If your Ethernet card doesn’t work, you might need to update your drivers. Head to 11th gen drivers or 12th gen drivers and run the appropriate driver installer.
I also updated my BIOS while I was at it, but I’m not sure if that’s necessary.
I am not seeing this issue any of the other Expansion Cards:
- USB C
- USB Port Type A
- Display Port
- HDMI Port
- MicroSD card
- 1 TB Hard Drive
The log messages I shared was when I had the Ethernet Card on the right side ports. When I swap the card to USB C one and connect it with a docking station or another devices, I do not see any issue.
I will do some more testing this weekend.
Ethernet IO card problems
Expected behavior
Plug IO card into laptop, plug Ethernet cord into IO card (or any variation of that order) and connect to the internet.
Observed behavior
Lights briefly flash on IO card but laptop refuses to connect. Laptop requires full system reboot to recognize the card.
Notes
- No-name Amazon Ethernet-to-USB-C adapter has been working for over 10 months, no issues
- All other IO cards work, no issues (USB-A, USB-C, 256GB, DisplayPort, HDMI, Micro SD)
- Software: Manjaro KDE, Kernel 5.19.7-1
- Hardware: 11th Gen i5-1135G7 (Batch 4)
- Last system update: 20SEP 2022
Seems like I’m not alone with this issue. Was there a flaw in design/ manufacturing? Is this something that requires a firmware update?
2 Likes
I’ve noticed that mine drops in and out when doing large uploads
Running on Fedora 36
Just noticed that the card is no longer for sale. Took this screen-shot just now (26SEP 2022).
Are the issues with the card known by Framework yet? Did they pull it from sale, run out, or incorrectly configure their website?
Been hype for this card for a while. It’s… a little disappointing to have it not be fully functional or very practical. 
So just to chime-in again in with a differing opinion.
I have no issues at all with the network dongle, hot plugging works (both the USB card and the cable).
Just to confirm that there isn’t a problem when under load, I’ve just left it running iperf3 for 5 minutes concurrently as both client and server (so both sending and receiving), pulling a shade over 900 MBit/sec; and the link didn’t drop once. There’s a total of between 1400 and 3000 retries over the 5 minutes, which is totally reasonable, none of that is really making me concerned. I did watch it as well, so I would have spotted any prolonged dropouts.
Just for completeness:
sending:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-300.00 sec 32.8 GBytes 938 Mbits/sec 1429 sender
[ 5] 0.00-300.01 sec 32.8 GBytes 938 Mbits/sec receiver
receiving:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-300.00 sec 32.3 GBytes 925 Mbits/sec 3112 sender
[ 5] 0.00-300.04 sec 32.3 GBytes 925 Mbits/sec receiver
That’s on an 11th gen i5-1135G7; batch 8 running Pop_OS! 22.04; Linux fa 5.19.0-76051900-generic #202207312230~1663791054~22.04~28340d4 SMP PREEMPT_DYNAMIC Wed S x86_64 x86_64 x86_64 GNU/Linux. I’m completely up to date on firmware etc
Plugged into a Force 10 S50-01-GE-48T-AC switch running iperf3 (5.19.0-76051900-generic).
So, I don’t think there’s a systemic problem with the dongle necessarily, it could be there’s a problem with some people’s specific ones, or possibly an issue with specific Linux builds perhaps?
2 Likes
that’s characteristic of realtek ethernet chips in my experience.
2 Likes
They ran out of stock, per their Twitter
4 Likes