RPI & Android USB modem

Networking
1

I have RPI3B, it was running IPfire 181. And I have small LTE modem from AliExpress, it is just USB dongle. The modem creates WiFi AP and computer can connect to internet over WiFi. It works OK. The LTE modem has USB port, it is used to power the modem. So far, I just plugged the LTE modem to an USB charger and I was able to connect to WiFi that was created by the modem and I was “online”.

My RPI has an external USB WiFi dongle to create blue interface; USB dongle is based on RT3070.

I wanted something more, so I tried to use RPI with IPfire. I can connect RPI to LTE modem over WiFi, like I do with my PC. I tried this in the past and it worked.

I tried something new today, I connected the LTE modem to the USB port of RPI and it worked, a connected over USB port was created. Then I run “setup” and configured new Android device as “red” interface. IP address was assigned from DHCP (dynamic IP).

This is what I see when I run lsusb, this is LTE modem:

Bus 001 Device 007: ID 05c6:90b3 Qualcomm, Inc. Android

RPI was running IPfire 181 and there was update, so I have that bad idea to upgrade IPfire to version 182; this update process was done over LTE, LTE modem was connected as Andorid on red interface.

After reboot, I cannot connect to the internet over USB interface. Modem is detected, interface is renamed from usb0 to red0 but no IP address is assigned to the interface and internet status is just connecting...

This is in dmesg output:

[   43.598088] usb 1-1.1.3: new high-speed USB device number 7 using dwc2
[   43.687798] usb 1-1.1.3: New USB device found, idVendor=05c6, idProduct=90b3, bcdDevice=ff.ff
[   43.687841] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   43.687858] usb 1-1.1.3: Product: Android
[   43.687872] usb 1-1.1.3: Manufacturer: Android
[   43.687885] usb 1-1.1.3: SerialNumber: 27021234
[   43.887534] usbcore: registered new interface driver cdc_ether
[   43.937733] rndis_host 1-1.1.3:1.0 usb0: register 'rndis_host' at usb-3f980000.usb-1.1.3, RNDIS device, 02:04:56:11:22:33
[   43.938134] usbcore: registered new interface driver rndis_host
[   44.171490] rndis_host 1-1.1.3:1.0 red0: renamed from usb0

Other annoying issue is that I have to connect to RPI over ETH cable to use setup command, to reconfigure network/interfaces. When I want to reassign interface, IPfire does reset of networking and when I am connected over WiFi, I cannot proceed; I have to reboot RPI… :frowning: setup is required to reconfigure red interface, from WiFi client, to and USB Ethernet device or Android device". The need to have an extra device that allows me to connect ETH port or to have access to USB keyboard and HDMI screen makes it difficult to use RPI with IPfire as a travel router… :frowning:

2

From my understanding most of these LTE usb modems
use random MAC addresses. So the change there MAC on every reboot…
There is info in the forum about how to fix it.

If you can connect to your “Green or Blue” network.
you should be able to reach your router WUI.
turn on SSH. then connect with putty and run Setup.
this should fix it till next reboot… till you make a permanent fix.

3

That is not a problem. My SSH is enabled, I can connect to the router with ssh. The problem is when I run setup and then “assign interfaces”, IPfire executes network restart; and after that I am disconnected from WiFi and my ssh session is not responsive. I have to reboot RPI, then I can try again, with the same result… To use setup I have to connect over Ethernet to RJ45 port or with console (serial console or USB/HDMI console).

I do not think that changing MAC address is a problem, I have not noticed that. I will keep my eye on it…

I believe that there is a problem with DHCP client in IPfire 182… I tried to use old setup, I tried to connect RPI to LTE modem as WiFi client. I can connect ti WiFi but IP address is not assigned from DHCP server (LTE modem) to red red interface.

I tried force it manually (dhcliencd red0) and it works, I receive IP address on red0 but only for few seconds, less than a minute. After that IP address is removed from the red interface. I tried to debug the issue but dhcpcd is forked to background and I am not able to see the event that triggers disconnection and I cannot find a way to force dhcpcd to stay in the foreground or to create full log file…

I noticed this message in the log but I am not sure if that is an issue or not:

Feb 10 00:50:05 rpifire dhcpcd[3944]: ps_bpf_recvmsg: Invalid argument

SSID of LTE modem is 4G-UFI-E45E, it has IP address 192.168.100.1; this part work but I do not know what happens whet the client forks to the background:

[root@rpifire log]# dhcpcd -d red0
dhcpcd-10.0.4 starting
chrooting as dhcpcd to /run/dhcpcd/chroot
sandbox: seccomp
spawned manager process on PID 8930
spawned privileged proxy on PID 8931
spawned controller proxy on PID 8932
DUID 00:01:00:01:2c:3f:0c:eb:00:e0:4c:36:00:92
red0: executing: /var/ipfire/dhcpc/dhcpcd-run-hooks PREINIT
red0: connected to Access Point: 4G-UFI-E45E
red0: executing: /var/ipfire/dhcpc/dhcpcd-run-hooks CARRIER
red0: IAID eb:57:bd:af
red0: delaying IPv4 for 1.9 seconds
red0: reading lease: /var/ipfire/dhcpc/red0-4G-UFI-E45E.lease
red0: discarding expired lease
red0: soliciting a DHCP lease
red0: sending DISCOVER (xid 0xb4c3546f), next in 3.5 seconds
red0: spawned BPF BOOTP on PID 8969
red0: offered 192.168.100.137 from 192.168.100.1
red0: sending REQUEST (xid 0xb4c3546f), next in 4.4 seconds
red0: process BPF BOOTP already started on pid 8969
red0: acknowledged 192.168.100.137 from 192.168.100.1
red0: probing address 192.168.100.137/24
red0: spawned BPF ARP 192.168.100.137 on PID 8972
red0: probing for 192.168.100.137
red0: ARP probing 192.168.100.137 (1 of 3), next in 1.9 seconds
red0: ARP probing 192.168.100.137 (2 of 3), next in 2.0 seconds
red0: ARP probing 192.168.100.137 (3 of 3), next in 2.0 seconds
red0: DAD completed for 192.168.100.137
red0: leased 192.168.100.137 for 120 seconds
red0: renew in 60 seconds, rebind in 105 seconds
red0: writing lease: /var/ipfire/dhcpc/red0-4G-UFI-E45E.lease
red0: adding IP address 192.168.100.137/24 broadcast 192.168.100.255
red0: adding route to 192.168.100.0/24
red0: adding default route via 192.168.100.1
red0: ARP announcing 192.168.100.137 (1 of 2), next in 2.0 seconds
red0: executing: /var/ipfire/dhcpc/dhcpcd-run-hooks BOUND
[  OK  ]tatic routes...
[  OK  ]g firewall
[  OK  ] Squid Proxy Server (this may take up to a few minutes).....
[  OK  ] Squid swap directories...
[  OK  ] Squid Proxy Server...
forked to background, child pid 8930
dhcpcd_fork_cb: truncated read 0 (expected 4)

BTW, note “corrupted” entries in the output, this is 100% repeatable, it looks like a bug:

[  OK  ]tatic routes...
[  OK  ]g firewall
4

It might be that you are affected by a bug in dhcpcd-10.0.4 that is mentioned in this post thread.

https://community.ipfire.org/t/core-update-182-aarch64-red0-interface-stops/10827

This bug tends to affect aarch64 systems much more than it does x86_64 based systems.
If your problem is caused by that bug, then it was fixed in dhcpcd-10.0.6 which will be in Core Update 184 which will likely go to Testing stage before very long.

You could either try evaluating Core Update 184 which is currently in Unstable or if you want to wait for it to be in Stable or Testing then you will need to re-install Core Update 181 and restore a backup and wait for Core Update 184 to be released.

5

Looks like this nic has a random mac address. (the kernel name it usb0 instead of eth0)
In this case setup cannot permanent assign the device. Assign it once in the setup and then edit in /var/ethernet/settings the line RED_DEV=red0 to RED_DEV=usb0 to use such device after next boot.

2 Likes
6

IPfire 183 was released but I do not see any note about DHCP in the release notes. Was “dhcpcd” issue fixed in 183?

DHCP was not updated in 183:

[root@rpifire ~]# pakfire status
Core-Version: 2.29-aarch64
Core-Update-Level: 183
Last update: 17m 18s ago
Last core-list update: 5m 17s ago
Last server-list update: 5m 30s ago
Last packages-list update: 5m 28s ago
Core-Update available: no
Package-Updates available: 5
Reboot required: no

[root@rpifire ~]# dhcpcd --version
dhcpcd 10.0.4
Copyright (c) 2006-2023 Roy Marples
Compiled in features: INET ARP ARPing IPv4LL INET6 DHCPv6 AUTH PRIVSEP

I changed red0 from DHCP to STATIC configuration and it works; I was able to upgrade from 182 to 183 in this way. This workaround was noted in other post about dhcp issue. I use LTE modem in the way that RPI (IPfire) is connected to LTE modem as WiFi client (red0 is WiFi client to LTE modem, IP assignment is static)

I tried to switch red0 interface from static to dynamic (dhcp). I see the issue is still there, red0 has no IP address. Interesting point is that status page at WUI reports that internet is connected and IP address is assigned. That is not true, command ifconfig shows that there is no IP address assigned to red0; and IPfire cannot connect to the internet, as expected… Status page at WUI cannot detect this issue and reports false information…

7

Adolf has mentioned that the dhcp update is in core184:

You have to switch pakfire from stable to testing if you want to install this prior stable release.

8

Have you rebootet after this change? Switching from static to dhcp alter the ip displays only if it successfull get a lease.

9

Yes, I changed configuration and rebooted. Status page showed connected but I was not able to connect to internet. Once I connected with ssh, I run ifconfig… It works in the way that DHCP client receives IP address but it release that IP address in few seconds later. Status page shows status when it received IP address (and it was connected to the internet for few seconds) but status page is not updated when the IP address on red0 is “lost”.

10

Looks like dhcpcd hung at closing the connection and not run the network down scriptlets properly. Maybee this is the mentioned bug above.