raspberry-pi-pcie-devices
raspberry-pi-pcie-devices copied to clipboard
geerlingguy
Test Quectel EC25-A LTE Cat 4 mini PCIe module
I just bought a Quectel EC25-A LTE mini PCIe module. I have some plans for it—assuming I can get it to work!
From the spec sheet:
Quectel EC25 Mini PCIe is a series of LTE category 4 module adopting standard PCI Express® Mini Card form factor (Mini PCIe). It is optimized specially for M2M and IoT applications, and delivers 150 Mbps downlink and 50 Mbps uplink data rates.
Supposedly it has "USB serial drivers for Windows 7/8/8.1/10, Linux, Android" and some other Pi users have reported success with these models (the EU version).
There's a tutorial for using cellular modems with the Pi 4 that I think should apply equally well for the CM4. We'll see. There's a more generic tutorial with qmi_wwan here.
I also have a SIM from SixFab, but I will try to see if I can also get an AT&T SIM working later, since I may have a bead on an unlimited data plan for a 'decent-ish' price, which might be nice for a project I want to do.
Subscribing to this issue, I'd love to have RPi with backup connection over LTE/5G modem and UPS, that'd be crazy useful! Especially when your ISP is lying 😉 I've found this 5G hat with Snapdragon X55 modem, but it has quite a price tag attached
@TeoTN - Note that the data plans for 4G/5G are pretty expensive if your Pi does anything more than a trickle of data... that's something I'm trying to figure out before I get deeper into this project!
Plan prices are getting better, depending on where you live, I suppose. In Ireland we have 3 providers claiming to have unlimited 5G plans for €45/month. If you look at their terms a bit closer, two have fair use policies of 750GB and 1TB per month and the third claims to be fully unlimited but reserves the right to restrict based on network conditions. I'm not sure how the latter works in practice, the wired ISPs I've been with haven't even enforced the stated fair use limits so far. :) A fourth provider has an unlimited 4G for €25 per month with no fair use policy limit, but also reserves the right to restrict. So yeah, it's still not a perfect situation, but I'd say 4G/5G are starting to become a viable alternative even for primary access here.
It's similar in Poland with 500GB over 5G available for €26/mo ($29), and since for me this would be only as a backup for short periods of time, I'd be happy even with 50GB :)
Step 1: Try to use the card on the Turing Pi. Inserted SixFab SIM and card in Mini PCIe slot for node 1 and booted. Neither lspci nor lsusb return anything. Hmm...
Added overlay to enable the built-in USB 2.0 port on the CM4, rebooted, lsusb is still empty.
pi@turing-node-1:~ $ ls /dev/tty*
/dev/tty /dev/tty15 /dev/tty22 /dev/tty3 /dev/tty37 /dev/tty44 /dev/tty51 /dev/tty59 /dev/tty9
/dev/tty0 /dev/tty16 /dev/tty23 /dev/tty30 /dev/tty38 /dev/tty45 /dev/tty52 /dev/tty6 /dev/ttyAMA0
/dev/tty1 /dev/tty17 /dev/tty24 /dev/tty31 /dev/tty39 /dev/tty46 /dev/tty53 /dev/tty60 /dev/ttyprintk
/dev/tty10 /dev/tty18 /dev/tty25 /dev/tty32 /dev/tty4 /dev/tty47 /dev/tty54 /dev/tty61
/dev/tty11 /dev/tty19 /dev/tty26 /dev/tty33 /dev/tty40 /dev/tty48 /dev/tty55 /dev/tty62
/dev/tty12 /dev/tty2 /dev/tty27 /dev/tty34 /dev/tty41 /dev/tty49 /dev/tty56 /dev/tty63
/dev/tty13 /dev/tty20 /dev/tty28 /dev/tty35 /dev/tty42 /dev/tty5 /dev/tty57 /dev/tty7
/dev/tty14 /dev/tty21 /dev/tty29 /dev/tty36 /dev/tty43 /dev/tty50 /dev/tty58 /dev/tty8
Nothing in there either.
Wondering if this may be of any assistance? Sixfab seems to have a ZIP in their repo here for their Base Shield. Obviously not using that, but wondering if it may still help out on discovery.
https://github.com/sixfab/Sixfab_RPi_3G-4G-LTE_Base_Shield/blob/master/tutorials/QMI_tutorial/src/quectel-CM.zip
@danmanners - It seems like that presumes a device is appearing in /dev/tty* already, which is not happening at least on my board. I wonder if maybe the Turing Pi 2's USB connections to the first PCIe slot might not be correct? I will be ordering a USB to Mini PCIe WWAN adapter and I'll see if it shows up connected through there. I hope I don't have a broken LTE modem!
Some more debugging steps:
- Tried the card in the mPCIe slot for node 2 on the Turing Pi, nothing in
lspci,lsusb, or in/dev/tty*either. - Tried installing modem manager (
sudo apt install modemmanager) on node 1, then runningmmcli -m 0, but that gives:
pi@turing-node-1:~ $ mmcli -m 0
error: couldn't find modem
(One can always hope...)
I've ordered both a USB to mini PCIe WWAN/LTE adapter with SIM tray, and an Ableconn PEX-MP117 Mini PCI-E to PCI-E Adapter Card and will test with both to see if I can get the card recognized via USB or PCIe on another Pi.
Also, someone else had some issues with the EC25 on the Raspberry Pi but it looks like that was just a fluke, needed to recreate the connection.
On a Pi 4 model B with the USB to mini PCIe adapter, I get the following:
pi@lte:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 2c7c:0125 Quectel Wireless Solutions Co., Ltd. EC25 LTE modem
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@lte:~ $ ls /dev/ttyUSB*
/dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2 /dev/ttyUSB3
pi@lte:~ $ sudo apt install -y modemmanager
...
pi@lte:~ $ mmcli -L
No modems were found
pi@lte:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether e4:5f:01:45:fe:b2 brd ff:ff:ff:ff:ff:ff
3: wwan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 1a:22:69:21:7e:5a brd ff:ff:ff:ff:ff:ff
inet 169.254.105.23/16 brd 169.254.255.255 scope global noprefixroute wwan0
valid_lft forever preferred_lft forever
inet6 fe80::5c22:265d:59af:2337/64 scope link
valid_lft forever preferred_lft forever
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether e4:5f:01:45:fe:b4 brd ff:ff:ff:ff:ff:ff
inet 10.0.100.159/24 brd 10.0.100.255 scope global dynamic noprefixroute wlan0
valid_lft 86193sec preferred_lft 75393sec
inet6 fe80::4a4c:fd06:5dd4:52e9/64 scope link
valid_lft forever preferred_lft forever
Following SixFab's instructions, I communicated with the modem via minicom -D /dev/ttyUSB2 -b 115200 (after installing minicom), and here's the transaction history (the last command triggered a modem reboot, then it came back with AT / OK:
And after all that, I see the modem with mmcli:
pi@lte:~ $ mmcli -L
/org/freedesktop/ModemManager1/Modem/0 [Quectel] EC25
pi@lte:~ $ mmcli -m 0
--------------------------------
General | dbus path: /org/freedesktop/ModemManager1/Modem/0
| device id: bfded8fabaedf6e1facc0edd1041f99c4f9feb2f
--------------------------------
Hardware | manufacturer: Quectel
| model: EC25
| firmware revision: EC25AFAR05A07M4G
| supported: gsm-umts, lte
| current: gsm-umts, lte
| equipment id: 861641043666287
--------------------------------
System | device: /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3
| drivers: option1, cdc_ether
| plugin: quectel
| primary port: ttyUSB3
| ports: ttyUSB0 (qcdm), ttyUSB1 (gps), ttyUSB3 (at), usb0 (net)
--------------------------------
Status | unlock retries: sim-pin (3), sim-puk (10), sim-pin2 (10), sim-puk2 (10)
| state: disabled
| power state: on
| signal quality: 0% (cached)
--------------------------------
Modes | supported: allowed: 2g, 3g, 4g; preferred: none
| current: allowed: 2g, 3g, 4g; preferred: none
--------------------------------
IP | supported: ipv4, ipv6, ipv4v6
--------------------------------
3GPP | imei: 861641043666287
--------------------------------
3GPP EPS | ue mode of operation: csps-2
--------------------------------
SIM | dbus path: /org/freedesktop/ModemManager1/SIM/0
pi@lte:~ $ dmesg
...
[ 546.722909] cdc_ether 1-1.3:1.4 usb0: register 'cdc_ether' at usb-0000:01:00.0-1.3, CDC Ethernet Device, c2:a2:8a:5b:3d:f9
pi@lte:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether e4:5f:01:45:fe:b2 brd ff:ff:ff:ff:ff:ff
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether e4:5f:01:45:fe:b4 brd ff:ff:ff:ff:ff:ff
inet 10.0.100.159/24 brd 10.0.100.255 scope global dynamic noprefixroute wlan0
valid_lft 85700sec preferred_lft 74900sec
inet6 fe80::4a4c:fd06:5dd4:52e9/64 scope link
valid_lft forever preferred_lft forever
5: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether c2:a2:8a:5b:3d:f9 brd ff:ff:ff:ff:ff:ff
inet 192.168.225.23/24 brd 192.168.225.255 scope global dynamic noprefixroute usb0
valid_lft 43028sec preferred_lft 37628sec
inet6 fe80::7ffa:e040:7995:99d8/64 scope link
valid_lft forever preferred_lft forever
pi@lte:~ $ ping -I usb0 sixfab.com -c 5
PING sixfab.com (172.66.40.115) from 192.168.225.23 usb0: 56(84) bytes of data.
64 bytes from 172.66.40.115 (172.66.40.115): icmp_seq=1 ttl=49 time=153 ms
64 bytes from 172.66.40.115 (172.66.40.115): icmp_seq=2 ttl=49 time=193 ms
64 bytes from 172.66.40.115 (172.66.40.115): icmp_seq=3 ttl=49 time=152 ms
64 bytes from 172.66.40.115 (172.66.40.115): icmp_seq=4 ttl=49 time=192 ms
64 bytes from 172.66.40.115 (172.66.40.115): icmp_seq=5 ttl=49 time=148 ms
--- sixfab.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 148.419/167.943/193.195/20.305 ms
Testing the speed; first with all interfaces going:
pi@lte:~ $ sudo apt-get install speedtest-cli
...
pi@lte:~ $ speedtest-cli --source 192.168.225.23
Retrieving speedtest.net configuration...
Testing from Amazon.com (3.239.194.27)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by eero (Ashburn, VA) [0.81 km]: 173.036 ms
Testing download speed................................................................................
Download: 8.17 Mbit/s
Testing upload speed......................................................................................................
Upload: 0.57 Mbit/s
This was in suboptimal conditions, with a tiny cheap antenna located in my basement :P
Monitored the traffic through the interface (to confirm it was going out over LTE and not the LAN) with sudo apt install -y iftop then sudo iftop -i usb0:
Interesting aside: for some reason if I used --source [IP of WiFi connection on Pi], it would just hang, and I could see it was trying to ping that IP through the LTE connection.
A few other notes concerning routing—SixFab seems to use a mobile network that's CG-NAT'ed behind AWS, as the public IP address in front of the LTE connection is:
pi@lte:~ $ curl icanhazip.com
3.239.194.27
And my private IP on the LTE modem is 192.168.225.23.
If I had a SIM with a public IP, it looks like this is the process for getting that working (or, in other comments in that thread, there are suggestions for port forwarding, though I think using a reverse SSH tunnel might be my best bet).
Learning more about interacting with the modem via minicom:
# Signal strength: https://m2msupport.net/m2msupport/atcsq-signal-quality/
AT+CSQ
+CSQ: 15,99
# Network information: https://m2msupport.net/m2msupport/network-information-automaticmanual-selection/
AT+COPS?
+COPS: 0,0,"AT&T Twilio",7
# Get clock: https://m2msupport.net/m2msupport/m2m-module-diagnostics/
AT+CCLK?
+CCLK: "22/01/07,05:19:00-24"
More exploration: I tried swapping out a separate AT&T SIM from a cradlepoint unit to see what would happen. Even after 10 minutes or so I'm seeing in the logs via minicom:
+QLWURC: "pdp active","failed","attm2mglobal"
+QLWURC: "deregister",0
+QLWURC: "pdp active","failed","attm2mglobal"
+QLWURC: "deregister",0
+QLWURC: "pdp active","failed","nxtgenphone"
+QLWURC: "deregister",0
+QLWURC: "pdp active","failed","nxtgenphone"
+QLWURC: "deregister",0
+QLWURC: "pdp active","failed","nxtgenphone"
+QLWURC: "deregister",0
Seems like it's not able to connect to LTE towers in my basement on this SIM, not sure if it's the data plan, the signal, or what... but the other SIM said it was on ATT / Twilio, and my cell phone plan is AT&T (and I get 2-3 bars in my basement), so...
Just as a comparison, testing through a Cradlepoint router in the same location with AT&T (though it has a nicer antenna configuration):
pi@lte:~ $ speedtest-cli
Retrieving speedtest.net configuration...
Testing from AT&T Wireless (107.77.206.52)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Xiber LLC (Indianapolis, IN) [262.61 km]: 58.766 ms
Testing download speed................................................................................
Download: 11.70 Mbit/s
Testing upload speed......................................................................................................
Upload: 3.55 Mbit/s
Testing upstairs (instead of downstairs) also using LAN port on the cradlepoint:
pi@lte:~ $ speedtest-cli
Retrieving speedtest.net configuration...
Testing from AT&T Wireless (107.77.208.18)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Consolidated Cooperative (Mount Gilead, OH) [426.59 km]: 47.725 ms
Testing download speed................................................................................
Download: 12.07 Mbit/s
Testing upload speed......................................................................................................
Upload: 12.05 Mbit/s
According to my Dad (thanks, Dad!) the SIM plan the cradlepoint is using is limited to 12 Mbps so that's as good as it gets.
Tested the Quectel with the SixFab SIM upstairs too:
pi@lte:~ $ speedtest-cli
Retrieving speedtest.net configuration...
Testing from Amazon.com (3.239.194.21)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Rackdog (Ashburn, VA) [0.81 km]: 146.569 ms
Testing download speed................................................................................
Download: 9.15 Mbit/s
Testing upload speed......................................................................................................
Upload: 10.88 Mbit/s
And signal strength (logged in via minicom -D /dev/ttyUSB2 -b 115200):
# Signal strength: https://m2msupport.net/m2msupport/atcsq-signal-quality/
AT+CSQ
+CSQ: 22,99
I swapped in my own iPhone AT&T SIM (though on a limited data plan), and it seems to have connected immediately, no fuss. With a different antenna, I'm getting signal of 16-19, with speedtest result:
# Network information: https://m2msupport.net/m2msupport/network-information-automaticmanual-selection/
AT+COPS?
+COPS: 0,0,"AT&T",7
pi@lte:~ $ speedtest-cli
Retrieving speedtest.net configuration...
Testing from AT&T Wireless (107.77.207.227)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Misaka Network, Inc. (Kansas City, MO) [664.74 km]: 58.119 ms
Testing download speed................................................................................
Download: 11.63 Mbit/s
Testing upload speed......................................................................................................
Upload: 5.10 Mbit/s
Wish I had a T-Mobile SIM to compare the two.
Doing a speed test with my Mac tethered directly to my phone, with the same SIM, I get:
$ speedtest-cli
Retrieving speedtest.net configuration...
Testing from AT&T Wireless (107.77.207.5)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Pavlov Media (Champaign, IL) [203.48 km]: 44.745 ms
Testing download speed................................................................................
Download: 69.11 Mbit/s
Testing upload speed......................................................................................................
Upload: 3.30 Mbit/s
Over multiple tests I see anywhere from 45-70 Mbps down, 3-5 Mbps up. So it's interesting the Quectel seems to be able to more consistently put up better upload numbers (and the Cradlepoint blows them both away, getting its 12 Mbps up pretty much every test!).
I currently don't have another CM4 board available to test the SIM tray and 4G card in a mini PCIe slot, but I think it's safe to say the card will work fine with a Pi CM4, assuming the USB data lines in the mini PCIe slot are wired in correctly.
I do want to make sure it works in that configuration on some board, though, before I close out this issue.
Since we know the mPCIe lanes work for other devices (at least on my board), is it worth looking at picking up something like this and trying it on slot two? More than happy to send you one if you'd like :)
https://www.amazon.com/dp/B07T33NQPF?th=1
@danmanners - My guess is the USB D+/- lanes on slot two are also wired into the BMC's USB hub, therefore I'd hit the same issue on that slot :/
The Turing Pi 2's slot is now working, thanks to the removal of this tiny resistor: https://twitter.com/geerlingguy/status/1481027568052711425
I also just received another CM4 board with a mini PCIe slot and SIM card tray... so I might test it in there too at some point.
So new question / problem:
- I have
eth0andusb0both providing Internet access on different subnets/networks. - I would like to have things like
speedtest-cliroute only through theusb0interface. - I try things like
speedtest-cli --source 192.168.225.57to forceusb0, but that doesn't work.
Do I really have to mess with routing tables in Linux to basically 'set a service priority order' like I can do on macOS in the Network system preference pane?
I want to temporarily switch usb0 to be the primary network interface (but not disable eth0, since that's the interface through which I'm locally interacting with the machine).
pi@turing-node-1:~ $ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.100.1 0.0.0.0 UG 202 0 0 eth0
0.0.0.0 192.168.225.1 0.0.0.0 UG 203 0 0 usb0
10.0.100.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
192.168.225.0 0.0.0.0 255.255.255.0 U 203 0 0 usb0
Ah... trying out ifmetric as suggested in this answer:
pi@turing-node-1:~ $ sudo apt install ifmetric
pi@turing-node-1:~ $ sudo ifmetric eth0 220
pi@turing-node-1:~ $ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.100.1 0.0.0.0 UG 202 0 0 eth0
0.0.0.0 192.168.225.1 0.0.0.0 UG 203 0 0 usb0
10.0.100.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
192.168.225.0 0.0.0.0 255.255.255.0 U 203 0 0 usb0
That... didn't work.
So, looks like I may need to do my own route table modifications...
pi@turing-node-1:~ $ ip route list
default via 10.0.100.1 dev eth0 proto dhcp src 10.0.100.250 metric 202
default via 192.168.225.1 dev usb0 proto dhcp src 192.168.225.57 metric 203 mtu 1360
10.0.100.0/24 dev eth0 proto dhcp scope link src 10.0.100.250 metric 202
192.168.225.0/24 dev usb0 proto dhcp scope link src 192.168.225.57 metric 203 mtu 1360
Both connections are set as default. Might futz around with https://serverfault.com/a/836708/15673 if I can hack together some other way of controlling things.
AHA! I found it... after reading through , I found the key—since Raspberry Pi OS uses dhcpcd, I had to set the metric in that configuration.
So, basically:
# Edit dhcpcd's configuration.
pi@turing-node-1:~ $ sudo nano /etc/dhcpcd.conf
# Add the following to the end of the file and save it:
interface usb0
metric 0
# Restart dhcpcd.
pi@turing-node-1:~ $ sudo systemctl restart dhcpcd
# Et voila!
pi@turing-node-1:~ $ ip route list
default via 192.168.225.1 dev usb0 proto dhcp src 192.168.225.57 mtu 1360
default via 10.0.100.1 dev eth0 proto dhcp src 10.0.100.250 metric 202
10.0.100.0/24 dev eth0 proto dhcp scope link src 10.0.100.250 metric 202
192.168.225.0/24 dev usb0 proto dhcp scope link src 192.168.225.57 mtu 1360
Reverting the changes to dhcpcd and restarting the service got the order back to how it was before.
The rule for dhcpcd seems to be:
- Metrics are used to prefer an interface over another one, lowest wins.
- dhcpcd will supply a default metric of 200 + if_nametoindex(3).
- An extra 100 will be added for wireless interfaces.
Therefore, it seems that since usb0 comes after eth0 alphabetically, it loses and becomes the 203 to eth0's 202.
And testing through the Turing Pi 2 with an external antenna that's attached to an air duct in my basement (still not ideal, signal-wise, but giving 20,99:
pi@turing-node-1:~ $ speedtest-cli
Retrieving speedtest.net configuration...
Testing from Amazon.com (3.239.194.16)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Xiber LLC (Kansas City, MO) [1472.95 km]: 172.994 ms
Testing download speed................................................................................
Download: 8.91 Mbit/s
Testing upload speed......................................................................................................
Upload: 2.78 Mbit/s
Blog post based on findings with routing metric priority: Network interface routing priority on a Raspberry Pi.
Reopening for a bit—I am wondering if I can eke out more performance. I know I won't hit the 150/50 Mbps performance that's theoretically possible, but I've heard from others (example) who are getting more like 75/25.
Never getting more than 10-12 Mbps makes it seem like maybe something is getting stuck in USB 1.x speeds (which are limited to 12 Mbps).
But looking at the modem with lsusb it seems to be in 480M mode (USB 2.0) at least on a hardware level:
pi@turing-node-1:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2c7c:0125 Quectel Wireless Solutions Co., Ltd. EC25 LTE modem
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@turing-node-1:~ $ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/0p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 2, If 1, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 2, If 2, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 2, If 3, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 2, If 4, Class=Communications, Driver=cdc_ether, 480M
|__ Port 1: Dev 2, If 5, Class=CDC Data, Driver=cdc_ether, 480M
Full USB device details:
Click to show `sudo lsusb -v` output
pi@turing-node-1:~ $ sudo lsusb -v
Bus 001 Device 002: ID 2c7c:0125 Quectel Wireless Solutions Co., Ltd. EC25 LTE modem
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x2c7c Quectel Wireless Solutions Co., Ltd.
idProduct 0x0125 EC25 LTE modem
bcdDevice 3.18
iManufacturer 1 Android
iProduct 2 Android
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0102
bNumInterfaces 6
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 00 00
** UNRECOGNIZED: 04 24 02 02
** UNRECOGNIZED: 05 24 06 00 00
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 9
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 00 00
** UNRECOGNIZED: 04 24 02 02
** UNRECOGNIZED: 05 24 06 00 00
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 9
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 00 00
** UNRECOGNIZED: 04 24 02 02
** UNRECOGNIZED: 05 24 06 00 00
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 9
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 4
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 6 Ethernet Networking
bFunctionProtocol 0
iFunction 9 CDC ECM
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 6 Ethernet Networking
bInterfaceProtocol 0
iInterface 6 CDC Ethernet Control Model (ECM)
CDC Header:
bcdCDC 1.10
CDC Union:
bMasterInterface 4
bSlaveInterface 5
CDC Ethernet:
iMacAddress 7 12016d374b3a
bmEthernetStatistics 0x00000000
wMaxSegmentSize 1514
wNumberMCFilters 0x0000
bNumberPowerFilters 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x89 EP 9 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 8 CDC Ethernet Data
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
bNumConfigurations 1
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
And ethtool just shows:
pi@turing-node-1:~ $ sudo ethtool usb0
Settings for usb0:
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
For the driver:
pi@turing-node-1:~ $ sudo ethtool -i usb0
driver: cdc_ether
version: 5.10.63-v8+
firmware-version: CDC Ethernet Device
expansion-rom-version:
bus-info: usb-fe9c0000.xhci-1
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
pi@turing-node-1:~ $ dmesg | grep cdc_ether
[ 5.664883] cdc_ether 1-1:1.4 usb0: register 'cdc_ether' at usb-fe9c0000.xhci-1, CDC Ethernet Device, 12:01:6d:37:4b:3a
[ 5.670281] usbcore: registered new interface driver cdc_ether
SixFab has a couple guides for QMI mode, notably:
- QMI Interface Internet Connection Setup Using Sixfab Shield/HAT
- Setting up a data connection over QMI interface using libqmi
The latter is more useful to me, since I already have the modem in USB mode and just need to turn that off to hopefully get to QMI/wwan mode. We'll see if it's any faster.
Since lsusb -t returns cdc_ether, I need to reset the modem in QMI mode:
$ minicom -D /dev/ttyUSB2 -b 115200
AT+QCFG="usbnet" # returns 1
AT+QCFG="usbnet",0 # disables USB mode
AT+CFUN=1,1 # reset the modem (takes a minute or so)
Install necessary utilities:
$ sudo apt install libqmi-utils udhcpc
# Make sure operating mode is 'online':
$ sudo qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
error: couldn't create client for the 'dms' service: CID allocation failed in the CTL client: Transaction timed out
Hmm...
[341579.723073] usb 1-1: USB disconnect, device number 2
[341579.723720] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
[341579.723892] option 1-1:1.0: device disconnected
[341579.724969] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
[341579.725132] option 1-1:1.1: device disconnected
[341579.727098] option1 ttyUSB2: GSM modem (1-port) converter now disconnected from ttyUSB2
[341579.727185] option 1-1:1.2: device disconnected
[341579.727713] option1 ttyUSB3: GSM modem (1-port) converter now disconnected from ttyUSB3
[341579.727797] option 1-1:1.3: device disconnected
[341579.728020] cdc_ether 1-1:1.4 usb0: unregister 'cdc_ether' usb-fe9c0000.xhci-1, CDC Ethernet Device
[341592.372496] usb 1-1: new high-speed USB device number 3 using xhci-hcd
[341592.530514] usb 1-1: New USB device found, idVendor=2c7c, idProduct=0125, bcdDevice= 3.18
[341592.530526] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[341592.530532] usb 1-1: Product: Android
[341592.530537] usb 1-1: Manufacturer: Android
[341592.684213] option 1-1:1.0: GSM modem (1-port) converter detected
[341592.684481] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
[341592.684794] option 1-1:1.1: GSM modem (1-port) converter detected
[341592.684997] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1
[341592.685259] option 1-1:1.2: GSM modem (1-port) converter detected
[341592.685450] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB2
[341592.685707] option 1-1:1.3: GSM modem (1-port) converter detected
[341592.685892] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB3
[341592.716070] qmi_wwan 1-1:1.4: cdc-wdm0: USB WDM device
[341592.717256] qmi_wwan 1-1:1.4 wwan0: register 'qmi_wwan' at usb-fe9c0000.xhci-1, WWAN/QMI device, ee:22:25:db:79:b1
[341598.445820] qmi_wwan 1-1:1.4 wwan0: Cannot change a running device