This morning I connected my L5 to the laptop, but no link came up. I restarted the DHCP server, no change. Then I rebooted the L5 and saw about the connection in /var/log/syslog only the following lines:
Apr 5 07:10:28 pureos systemd-networkd[471]: usb0: Gained carrier
Apr 5 07:10:28 pureos NetworkManager[117889]: <info> [1680671428.6424] device (usb0): carrier: link connected
Apr 5 07:12:33 pureos sm.puri.OSK0.desktop[1680]: Debug: Tried file "/home/purism/.local/share/squeekboard/keyboards/us.yaml", but it's missing: No such file or directory (os error 2)
...
The line at 07:12:33, i.e 2 minutes after the connect, is already caused by starting the terminal app to look with ifconfig usb0 what the state of the interface was, nothing to see as IP.
Normally in the same second of the connection the NetworkManager logs a lot of messages about the new interface usb0:. This time nothing more after 07:10:28. Why?
link connected then nothing more normally means that the interface is up but there is no configuration, maybe the interface is not running a dhcp client, maybe NetworkManager’s connection config has become corrupt or rendered unreadable for some other reason.
ifconfig is not a good choice of tool/utility for networks managed by NetworkManager. nmcli is the tool that should be used, to get some basic information on state…
nmcli dev
Will list devices and their basic state, while…
nmcli conn show
will list connections and their basic general state, while…
nmcli conn show <connecion-name>
will show the configuration of the named connection in detail.
ip can also be used to determine assigned/configured IP addresses and routing etc.
From your recent thread on tethering with MacOS…
Did this setting/configuration persist? By default NetworkManger handles config/setup of all network devices/interfaces, however, if the interface has been configured elsewhere outside of NetworkManager, NetwrokManger won’t takeover. I suspect that your use of ifconfig may have caused NetworkManager to ignore the usb0 interface.
Using ifconfig to configure the IP address or any other parameter of an interface handled by NetwrokManager is a bad idea and is likely to introduce problems.
Read later posts from me in this thread. I now have on the Mac a DHCP server which gives the L5 an IP addr 192.168.33.2 and the Mac has 192.168.33.1. This works just by plug-in the cable on both ends, only that single time it did not. With ifconfig I only wanted to see if usb0 got an IP addr assigned.
From the other thread to this one, it wasn’t clear to me whether or not you had rebooted the phone or reinitialised the usb0 interface since setting the IP with ipconfig hence asking if the IP set with ifconfig persisted.
Either way, I would use nmcli to check the device and connection state and also double check the connection configuration. I’d also check the NetworkManger logs (journal) as it may be more verbose than dmesg.
I would also directly check that there is no mention of the interface in /etc/network/interfaces
So the issue is that one time this morning when you connect the Librem 5 to your Mac NetwrokManager on the Lbrem 5 did not establish a connection/link and get it’s IP address? But subsequent connections since do get an IP and connections can be established?
Since March 30, I do use USB tethering with a DHCP server in the Mac very often (mostly because at work my laptop and the L5 are on different Wifi AP) and until now it failed only once. I was surprised and 1st thought that the DHCP on the Mac was not running, but it was, and even a restart of the DHCP didn’t changed the situation.
Sorry, I had thought the system was in a permanent failed state, I didn’t initially realise that this issue you were describing was at this time a ‘one off’ or non-reproducible state/issue.
I will not continue to try to remote troubleshoot a one off issue after the fact.
When it is in it’s failed state, what is the output of nmcli dev ?
Also when it’s in it’s failed state, is the interface showing up within the Network settings pane of MacOS?
What, if any, additions (drivers, config, etc,.) have been added for MacOS to recognise the Librem 5? The Librem 5 uses Linux Gadget in multifunction/composite mode for it’s USB Ethernet functionality and as far as I’m aware, MacOS has no native support for Gadget in composite mode (more specifically, it has no native support for RNDIS which would be required). I have one older Intel MacBook Pro running v10.15 and a newer Apple Silicon MacBook Pro running v13.2 and neither of these machines recognise the Librem 5 as a network device when attached via USB.
When I plug the USB-C in, the MacOS recognises this as a networkinterface, even with the name “Librem 5” (see screen). I was highly suprised, whe I saw this the first time. Note also, to make it work, I must reboot the L5 and no change in the Mac. It’s version is 12.6.
The other information I will gather on next fault. Thanks for your hints in any case.
Ah, yes, I don’t know if it’s a misconfiguration or a quirk of the system (I have never looked into it in any detail), I would guess that CDC ECM (MacOS supports CDC ECM (g_ether mode)) is exposed during boot of the Librem 5. Whether CDC ECM is always there or whether it gets stomped on by RNDIS I do not know. It may be that most times CDC comes up first and MacOS recognises/registers it but perhaps on occasion RNDIS comes up first and CDC gets stomped, all this is merely speculative guessing on my part, I could be way off the mark.
This is probably the root of your issue as even though it’s seen during (most) boot and remains connected (of sorts) it’s not entirely correct in MacOS from what I have observed peviously. I’ve used this approach myself a few times to share the internet connection of MacOS with the Librem 5 and although data/traffic flowed correctly, the status and details of the connection on the MacOS side were completely wrong.
I suspect that when it’s in it’s failed state you won’t see the interface in the Network settings pane of MacOS.
I also have some debugging hints for the next time of the issue:
in MacOS:
sudo log stream --process bootpd --info --debug
man bootpd
man bootptab
sudo tcpdump -i en7 # works only if USB is connected
in L5:
sudo tcpdump -i usb0 # works also if USB is not connected
Today I catched again the situation that the usb0 interface did not “received” an IP addr. I pulled out the USB-C from the L5, started in the termina a tcpdump and plug’ed in the cable again. I have here two tcpdump outputs on my server:
