No mobile broadband found

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

titan@titan:/etc$ sudo dmesg |grep usb
[sudo] password for titan:
[ 9.225057] usb 1-4: new high-speed USB device number 2 using tegra-xusb
[ 9.378699] usb 1-4: New USB device found, idVendor=2c7c, idProduct=6002, bcdDevice= 3.18
[ 9.378927] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9.379110] usb 1-4: Product: Android
[ 9.379208] usb 1-4: Manufacturer: Android
[ 9.379322] usb 1-4: SerialNumber: 0000
[ 9.389056] cdc_ether 1-4:1.0 usb0: register ‘cdc_ether’ at usb-3610000.xhci-4, CDC Ethernet Device, ae:0c:29:a3:9b:6d
[ 14.284507] usbcore: registered new interface driver option
[ 14.284684] usbserial: USB Serial support registered for GSM modem (1-port)
[ 14.308960] usb 1-4: GSM modem (1-port) converter now attached to ttyUSB0
[ 14.329836] usb 1-4: GSM modem (1-port) converter now attached to ttyUSB1
[ 14.397837] usb 1-4: GSM modem (1-port) converter now attached to ttyUSB2
[ 19.265043] usb1: HOST MAC 6e:a1:40:cf:a7:7a
[ 19.265049] usb1: MAC 6e:a1:40:cf:a7:7b
[ 19.300732] l4tbr0: port 2(usb1) entered blocking state
[ 19.300768] l4tbr0: port 2(usb1) entered disabled state
[ 19.301279] device usb1 entered promiscuous mode

titan@titan:/etc$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2c7c:6002 Quectel Wireless Solutions Co., Ltd. Android
Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
This is the 4g module

image
image1220×800 193 KB

not found mobile broadband

And why does the nmcli command show usb0 instead of ttyUSB2
titan@titan:/etc$ nmcli d
DEVICE TYPE STATE CONNECTION
docker0 bridge connected docker0
eth0 ethernet disconnected –
usb0 ethernet unavailable –
l4tbr0 bridge unmanaged –
can0 can unmanaged –
can1 can unmanaged –
dummy0 dummy unmanaged –
rndis0 ethernet unmanaged –
usb1 ethernet unmanaged –
lo loopback unmanaged –

2

FYI, the USB side succeeded in detecting this device. Could you provide the fully verbose log for just that device? I see it is manufacturer ID 0x2c7c, device ID 0x6002. This would create a log of the command:
sudo lsusb -d 2c7c:6002 -vvv 2>&1 | tee log_quectel.txt

Also, is that Logitech unifying receiver part of this? No need for the following if it is unrelated, but if it is:
sudo lsusb -d 046d:c534 -vvv 2>&1 | tee log_receiver.txt

Indications so far are that the device is detected and available without error, but that no driver took ownership. I don’t know yet what driver would be needed, but the logs might further indicate information on this.

3

hi,linuxdev
thank you reply,this is log
log_quectel.txt (8.4 KB)

5

Several of the devices on that USB cable (one cable supports a more complicated set of devices, not just one device so far as software is concerned) are “standard” classes, but two are vendor specific (meaning they must use a custom driver).

Incidentally, I did not find the specific device in the USB registry. That’s ok, but it makes hunting for a driver more difficult. There are several device models by that company. Can you provide an exact model?

Was the “receiver” something unrelated?

6

thanks，it is EC200N-CN,What is a “receiver”？

7

The “receiver” is from the list of USB devices:

Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver

I’m guessing it is a wireless keyboard or mouse. Sometimes though they’re used for other purposes, including Wi-Fi cameras.

8

Looking for the Linux driver for the EC200N-CN is difficult, with not many English web pages. I found one related web page:
https://forums.quectel.com/t/ec200s-cn-drivers-and-soft/8611

It is quite possible that the driver is available in the kernel source with compile, but I was unable to find out which driver it is. In the case that the manufacturer provides the driver, you might ask the manufacturer for a web URL to find the driver. If the provided driver is not in the form of source code, then it would need to be for arm64/aarch64 architecture, and compatible with your kernel. You can see the version of your current kernel with “uname -r”.

Incidentally, there might also be a firmware download. Firmware won’t care about architecture.

9

yes，This doesn’t matter

10

Hi,liuxdev
Thank you very much for your help.
It was available in jetpakc4.4 and showed mobile broadband as normal. When I upgraded to jetpack5.0.2, networkmanager did not have mobile broadband Settings and was available when I used the AT directive.

11

When I used the nmcli directive to show usb0, in jetpack4.4 the nmcli directive showed ttyUSB2 instead of usb0, so is the problem with netwokmanager

12

titan@titan:~$ nmcli
usb0: connected to Wired connection 2
“Quectel Android”
ethernet (cdc_ether), AE:0C:29:A3:9B:6D, hw, mtu 1500
ip4 default
inet4 192.168.43.100/24
route4 0.0.0.0/0
route4 192.168.43.0/24
inet6 fe80::5c8:349f:9422:5021/64
route6 fe80::/64

eth0: connected to Wired connection 1
“eth0”
ethernet (nvethernet), 48:B0:2D:4D:69:34, hw, mtu 1500
inet4 192.168.1.11/24
route4 192.168.1.0/24
inet6 fe80::4364:f108:af2e:f772/64
route6 fe80::/64

docker0: connected to docker0
“docker0”
bridge, 02:42:C0:0B:5E:E2, sw, mtu 1500
inet4 172.17.0.1/16
route4 172.17.0.0/16

l4tbr0: unmanaged
“l4tbr0”
bridge, 6E:A1:40:CF:A7:79, sw, mtu 1500

can0: unmanaged
“can0”
can (mttcan), hw, mtu 16

This is jetpack5.0.2, it has a usb0 port

This is jetpack4.4， no usb0, and a ttyUSB2 interface is addedtitan@titan:~$ nmcli
docker0: connected to docker0
“docker0”
bridge, 02:42:27:B0:C7:BC, sw, mtu 1500
inet4 172.17.0.1/16
route4 172.17.0.0/16
eth0: disconnected
“eth0”
1 connection available
ethernet (nvethernet), 48:B0:2D:95:10:31, hw, mtu 1466
ttyUSB2: unavailable
“Quectel Android”
gsm (option, cdc_ether), hw
l4tbr0: unmanaged
“l4tbr0”
bridge, C2:D8:6B:4A:7D:49, sw, mtu 1500
can0: unmanaged
“can0”
can (mttcan), hw, mtu 16

13

USB devices change their numbering depending on order of device enumeration. Sometimes the base name is altered by the udev mechanism. One typical example of udev is that many manufacturers will control a device by serial UART, and the UART will be a “standard” device available anywhere, but the “driver” will use a udev trigger to rename that device to something named after the manufacturer (for which the driver might search, and fail should naming not be as expected…despite the standard driver being able to work for this).

I don’t know what init scripts (or systemd scripts) that modem would use, but if for some reason it is looking for the wrong USB device, it is possible to do one of the following:

  • Adjust the script to look for the right device number.
  • Create a udev rule to rename the device.
  • A combination of the above.

The easiest thing to do (not needing udev knowledge) is to simply have the boot content look for the right device.

15

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.