|
Activation Codes and Methods, Hardware Details, Sniffing
-
iaindooley
- Posts: 6
- Joined: 15 Dec 2021, 06:28
Post
by iaindooley » 15 Dec 2021, 06:48
My goal is to be able to issue AT commands in order to send/receive SMS while concurrently using the internet interface. I have seen some instructions for a different ZTE 4G modem in order to switch it into a "serial mode" where it will expose linux devices such as /dev/ttyUSBX but I can't find anything that works for this device. For example:
https://wiki.archlinux.org/title/ZTE_MF ... )_4G_Modem
In dmesg I can see:
Code: Select all [91486.944436] usb-storage 1-1.1.4:1.6: USB Mass Storage device detected
[91486.946343] scsi host0: usb-storage 1-1.1.4:1.6
[91487.951800] scsi 0:0:0:0: Direct-Access DEMO MMC Storage 2.31 PQ: 0 ANSI: 2
[91487.952503] sd 0:0:0:0: Attached scsi generic sg0 type 0
[91487.952879] sd 0:0:0:0: Power-on or device reset occurred
[91487.993230] sd 0:0:0:0: [sda] Attached SCSI removable disk
[92152.604645] rndis_host 1-1.1.4:1.0 eth1: unregister 'rndis_host' usb-0000:01:00.0-1.1.4, RNDIS device
[92153.402729] usb 1-1.1.4: USB disconnect, device number 24
[92168.263087] usb 1-1.1.4: new high-speed USB device number 25 using xhci_hcd
[92168.494553] usb 1-1.1.4: New USB device found, idVendor=19d2, idProduct=0581, bcdDevice= 1.00
[92168.494576] usb 1-1.1.4: New USB device strings: Mfr=2, Product=4, SerialNumber=5
[92168.494594] usb 1-1.1.4: Product: DEMO Mobile Boardband
[92168.494612] usb 1-1.1.4: Manufacturer: DEMO,Incorporated
[92168.494630] usb 1-1.1.4: SerialNumber: 1234567890ABCDEF
[92168.507449] rndis_host 1-1.1.4:1.0 eth1: register 'rndis_host' at usb-0000:01:00.0-1.1.4, RNDIS device, 34:4b:50:00:00:00
[92168.510172] usb-storage 1-1.1.4:1.6: USB Mass Storage device detected
[92168.510860] scsi host0: usb-storage 1-1.1.4:1.6
[92169.564179] scsi 0:0:0:0: Direct-Access DEMO MMC Storage 2.31 PQ: 0 ANSI: 2
[92169.565208] sd 0:0:0:0: Attached scsi generic sg0 type 0
[92169.565969] sd 0:0:0:0: Power-on or device reset occurred
[92169.614724] sd 0:0:0:0: [sda] Attached SCSI removable disk
In lsusb I can see:
Code: Select all Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 025: ID 19d2:0581 ZTE WCDMA Technologies MSM DEMO Mobile Boardband
Bus 001 Device 012: ID 05c6:9000 Qualcomm, Inc. SIMCom SIM5218 modem
Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 003: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Note that the SIM5218 modem is a different device.
The modem successfully connects, and provides eth1 and I can ping using this interface, and have confirmed that it's definitely getting an external IP address from the mobile broadband network. In syslog I see:
Code: Select all Dec 15 04:16:04 hostname kernel: [92168.510172] usb-storage 1-1.1.4:1.6: USB Mass Storage device detected
Dec 15 04:16:04 hostname kernel: [92168.510860] scsi host0: usb-storage 1-1.1.4:1.6
Dec 15 04:16:04 hostname mtp-probe: checking bus 1, device 25: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.1/1-1.1.4"
Dec 15 04:16:04 hostname mtp-probe: bus: 1, device: 25 was not an MTP device
Dec 15 04:16:04 hostname systemd-udevd[18298]: Using default interface naming scheme 'v247'.
Dec 15 04:16:04 hostname dhcpcd[1359]: eth1: waiting for carrier
Dec 15 04:16:04 hostname dhcpcd[1359]: eth1: carrier acquired
Dec 15 04:16:04 hostname dhcpcd[1359]: eth1: IAID 50:00:00:00
Dec 15 04:16:04 hostname dhcpcd[1359]: eth1: adding address fe80::b9e8:2ec4:ca65:5a88
Dec 15 04:16:04 hostname avahi-daemon[378]: Joining mDNS multicast group on interface eth1.IPv6 with address fe80::b9e8:2ec4:ca65:5a88.
Dec 15 04:16:04 hostname avahi-daemon[378]: New relevant interface eth1.IPv6 for mDNS.
Dec 15 04:16:04 hostname avahi-daemon[378]: Registering new address record for fe80::b9e8:2ec4:ca65:5a88 on eth1.*.
Dec 15 04:16:04 hostname mtp-probe: checking bus 1, device 25: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.1/1-1.1.4"
Dec 15 04:16:04 hostname mtp-probe: bus: 1, device: 25 was not an MTP device
Dec 15 04:16:05 hostname dhcpcd[1359]: eth1: soliciting an IPv6 router
Dec 15 04:16:05 hostname dhcpcd[1359]: eth1: rebinding lease of 192.168.8.100
Dec 15 04:16:05 hostname kernel: [92169.564179] scsi 0:0:0:0: Direct-Access DEMO MMC Storage 2.31 PQ: 0 ANSI: 2
Dec 15 04:16:05 hostname kernel: [92169.565208] sd 0:0:0:0: Attached scsi generic sg0 type 0
Dec 15 04:16:05 hostname kernel: [92169.565969] sd 0:0:0:0: Power-on or device reset occurred
Dec 15 04:16:05 hostname kernel: [92169.614724] sd 0:0:0:0: [sda] Attached SCSI removable disk
Dec 15 04:16:10 hostname dhcpcd[1359]: eth1: probing for an IPv4LL address
Dec 15 04:16:10 hostname dhcpcd[1359]: eth1: DHCP lease expired
Dec 15 04:16:10 hostname dhcpcd[1359]: eth1: soliciting a DHCP lease
Dec 15 04:16:15 hostname dhcpcd[1359]: eth1: using IPv4LL address 169.254.219.67
Dec 15 04:16:15 hostname avahi-daemon[378]: Joining mDNS multicast group on interface eth1.IPv4 with address 169.254.219.67.
Dec 15 04:16:15 hostname avahi-daemon[378]: New relevant interface eth1.IPv4 for mDNS.
Dec 15 04:16:15 hostname avahi-daemon[378]: Registering new address record for 169.254.219.67 on eth1.IPv4.
Dec 15 04:16:15 hostname dhcpcd[1359]: eth1: adding route to 169.254.0.0/16
Dec 15 04:16:17 hostname dhcpcd[1359]: eth1: offered 192.168.8.100 from 192.168.8.1
Dec 15 04:16:17 hostname dhcpcd[1359]: eth1: probing address 192.168.8.100/24
Dec 15 04:16:18 hostname dhcpcd[1359]: eth1: no IPv6 Routers available
Dec 15 04:16:22 hostname dhcpcd[1359]: eth1: leased 192.168.8.100 for 86400 seconds
Dec 15 04:16:22 hostname avahi-daemon[378]: Registering new address record for 192.168.8.100 on eth1.IPv4.
Dec 15 04:16:22 hostname dhcpcd[1359]: eth1: adding route to 192.168.8.0/24
Dec 15 04:16:22 hostname dhcpcd[1359]: eth1: adding default route via 192.168.8.1
I have tried copying some files from /usr/share/usb_modeswitch/ into /etc/usb_modeswitch.d/ that had the same vendor ID, and that had either 4G or WCDMA mentioned but this doesn't seem to change anything.
I can see lots of files for the vendor id 19d2 but nothing for product id 0581.
When I disable switching in /etc/usb_modeswitch.conf and remove/reinsert the device, the ethernet interface still works, and the product/vendor ID remain the same in both dmesg and lsusb so I assume this means the device *hasn't* switched already.
Any advice you can provide would be most appreciated!
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 15 Dec 2021, 07:43
iaindooley wrote: ↑15 Dec 2021, 06:48
When I disable switching in /etc/usb_modeswitch.conf and remove/reinsert the device, the ethernet interface still works, and the product/vendor ID remain the same in both dmesg and lsusb so I assume this means the device *hasn't* switched already.
Any advice you can provide would be most appreciated!
It is a device which either switch by itself or a device that doesn't need switching at all.
There is probably 4 serial interfaces on it but the usb Id has not been included in linux serial driver yet so there won't be any ttyUSBx devices created, it could be that one of the possible serial interfaces speaks the AT cmd language and can be used for SMS.
Show me output from lsusb -vd 19d2:0581 so I can see what the other interfaces looks like.
-
iaindooley
- Posts: 6
- Joined: 15 Dec 2021, 06:28
Post
by iaindooley » 15 Dec 2021, 08:39
Hi thanks for such a quick reply. Here is the output of that command:
Code: Select all Bus 001 Device 043: ID 19d2:0581 ZTE WCDMA Technologies MSM DEMO Mobile Boardband
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x19d2 ZTE WCDMA Technologies MSM
idProduct 0x0581
bcdDevice 1.00
iManufacturer 2 DEMO,Incorporated
iProduct 4 DEMO Mobile Boardband
iSerial 5 1234567890ABCDEF
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x00be
bNumInterfaces 7
bConfigurationValue 1
iConfiguration 3 DEMO Configuration
bmAttributes 0xc0
Self Powered
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 224 Wireless
bFunctionSubClass 1 Radio Frequency
bFunctionProtocol 3 RNDIS
iFunction 8 RNDIS
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 255 Vendor Specific (MSFT RNDIS?)
iInterface 6 RNDIS Communications Control
CDC Header:
bcdCDC 2.00
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x00
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 7 RNDIS Ethernet Data
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 2
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 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 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 66
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 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 4
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 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 0x04 EP 4 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 5
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 0x85 EP 5 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
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 6
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 1 Mass Storage
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 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 15 Dec 2021, 16:36
ok, the 4 possible serial interfaces has become 3 since one interface was for ADB (Android Debug).
Interface layout on the dongle:
MI_00, MI_01 RNDIS net device
MI_02
MI_03 ADB
MI_04
MI_05
MI_06 USB Mass Storage Device (TF/SD card in the dongle)
so interfaces 2, 4, and 5 are the possible serial interfaces, one of them is probably a diag interface, another one probably a NMEA interface, and hopefully one is an AT cmd interface.
You can add on-the-fly serial driver support by:
sudo echo 19d2 0581 >/sys/bus/usb-serial/drivers/option1/new_id
but do it after the rndis_host driver has bound to the rndis interface, otherwise the option driver will "steal" those interfaces if no driver has bound to them yet.
You swill get 4 ttyUSBx devices of hich you can test ttyUSB0, ttyUSB2, and ttyUSB3 for AT cmd response.
-
iaindooley
- Posts: 6
- Joined: 15 Dec 2021, 06:28
Post
by iaindooley » 16 Dec 2021, 00:07
That is amazing, it worked thankyou!
I am evaluating a bunch of similar devices for a project. To avoid having to come back and keep asking you how to do this for each one, I just wanted to clarify my understanding.
I received 2 devices from different suppliers yesterday: the first is the ZTE one you already helped me with, the other shows up as:
Bus 001 Device 049: ID 0e8d:2004 MediaTek Inc. uf906_lowram_ttl_20210811
but in dmesg it shows a few different product IDs:
Code: Select all [154548.163414] usb 1-1.1.1.4: new high-speed USB device number 47 using xhci_hcd
[154548.394621] usb 1-1.1.1.4: New USB device found, idVendor=0e8d, idProduct=2000, bcdDevice= 1.00
[154548.394644] usb 1-1.1.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[154548.394663] usb 1-1.1.1.4: Product: MT65xx Preloader
[154548.394680] usb 1-1.1.1.4: Manufacturer: MediaTek
[154548.423615] cdc_acm 1-1.1.1.4:1.0: Zero length descriptor references
[154548.423660] cdc_acm: probe of 1-1.1.1.4:1.0 failed with error -22
[154548.465372] cdc_acm 1-1.1.1.4:1.1: ttyACM0: USB ACM device
[154551.293617] usb 1-1.1.1.4: USB disconnect, device number 47
[154556.353530] usb 1-1.1.1.4: new high-speed USB device number 48 using xhci_hcd
[154556.584818] usb 1-1.1.1.4: New USB device found, idVendor=0e8d, idProduct=2002, bcdDevice=ff.ff
[154556.584841] usb 1-1.1.1.4: New USB device strings: Mfr=2, Product=3, SerialNumber=4
[154556.584860] usb 1-1.1.1.4: Product: uf906_lowram_ttl_20210811
[154556.584877] usb 1-1.1.1.4: Manufacturer: MediaTek
[154556.584894] usb 1-1.1.1.4: SerialNumber: 5150814082130024
[154556.590422] usb-storage 1-1.1.1.4:1.0: USB Mass Storage device detected
[154556.593837] scsi host1: usb-storage 1-1.1.1.4:1.0
[154557.614501] scsi 1:0:0:0: CD-ROM Linux File-CD Gadget 0318 PQ: 0 ANSI: 2
[154557.615410] sr 1:0:0:0: Power-on or device reset occurred
[154557.616329] sr 1:0:0:0: [sr0] scsi-1 drive
[154557.675033] sr 1:0:0:0: Attached scsi CD-ROM sr0
[154557.675570] sr 1:0:0:0: Attached scsi generic sg1 type 5
[154595.839973] usb 1-1.1.1.4: USB disconnect, device number 48
[154596.353687] usb 1-1.1.1.4: new high-speed USB device number 49 using xhci_hcd
[154596.585351] usb 1-1.1.1.4: New USB device found, idVendor=0e8d, idProduct=2004, bcdDevice=ff.ff
[154596.585374] usb 1-1.1.1.4: New USB device strings: Mfr=2, Product=3, SerialNumber=4
[154596.585393] usb 1-1.1.1.4: Product: uf906_lowram_ttl_20210811
[154596.585410] usb 1-1.1.1.4: Manufacturer: MediaTek
[154596.585427] usb 1-1.1.1.4: SerialNumber: 5150814082130024
[154596.595625] rndis_host 1-1.1.1.4:1.0 usb0: register 'rndis_host' at usb-0000:01:00.0-1.1.1.4, RNDIS device, fe:84:0a:cc:9d:2a
[154596.597035] usb-storage 1-1.1.1.4:1.2: USB Mass Storage device detected
[154596.597767] scsi host1: usb-storage 1-1.1.1.4:1.2
[154597.614572] scsi 1:0:0:0: CD-ROM Linux File-CD Gadget 0318 PQ: 0 ANSI: 2
[154597.615495] sr 1:0:0:0: Power-on or device reset occurred
[154597.616716] sr 1:0:0:0: [sr0] scsi-1 drive
[154597.655066] sr 1:0:0:0: Attached scsi CD-ROM sr0
[154597.655560] sr 1:0:0:0: Attached scsi generic sg1 type 5
One of those products is a "USB ACM" device, so I thought maybe I could do:
echo 0e8d 2002 > /sys/bus/usb-serial/drivers/option1/new_id
but this hasn't exposed any additional interfaces. I also tried using the product ID that shows up in lsusb:
echo 0e8d 2004 > /sys/bus/usb-serial/drivers/option1/new_id
The command lsusb -vd 0e8d:2004 produces this output:
Code: Select all Bus 001 Device 049: ID 0e8d:2004 MediaTek Inc. uf906_lowram_ttl_20210811
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0e8d MediaTek Inc.
idProduct 0x2004
bcdDevice ff.ff
iManufacturer 2 MediaTek
iProduct 3 uf906_lowram_ttl_20210811
iSerial 4 5150814082130024
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0062
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 224 Wireless
bFunctionSubClass 1 Radio Frequency
bFunctionProtocol 3 RNDIS
iFunction 19 RNDIS
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 3 RNDIS
iInterface 17 RNDIS Communications Control
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 00 01
** UNRECOGNIZED: 04 24 02 00
** UNRECOGNIZED: 05 24 06 00 01
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 18 RNDIS Ethernet Data
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 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 1 Mass Storage
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 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 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
I can see that it has fewer "Interface Descriptor" entries than the ZTE device and they all seem to be used for stuff.
So I have 2 questions:
1) When I do lsusb -vd is it the "Interface Descriptor" entries that tell me whether or not there is going to be an AT command interface?
2) Is there anything bad that can happen if I experiment by echoing random vendor and product IDs into the serial drivers? Like as I receive each modem to test it, assuming they're all behaving similarly to these two (that is, presenting an ethernet interface that successfully connects to the internet, not responding to usb_modeswitch and not presenting any new ttyUSBX devices) is it safe for me to just try echoing the vendor and product ID into the driver and see what happens? Or is there some info in the lsusb output that I need to be looking for that could warn me that this will break it somehow?
Thanks again for your help, I would have never known where to even start trying to figure that out!!
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 16 Dec 2021, 06:42
You won't break anything by trying to bind the option serial driver to an interface but there is not much use in doing that if the interface is of the wrong type.
The Configuration Descriptor tells how many interfaces there are in a device, the Interface Descriptor tells the interface attributes Class, SubClass, and Protocol.
Those are defined in https://www.usb.org/defined-class-codes and linux has drivers for almost all of them and those drivers bind automatically when a new device appears on the usb bus.
There is however the attribute value ff or decimal 255 which means "Vendor specific" and the serial interfaces for modems are usually in Class 255 so those are the ones one can try and bind the option serial driver to if no driver has bound automatically.
The MediaTek device you asked about is a smartphone or tablet which has a single function on each of its multiple usb Id's, you choose in the phone/tablet menu which function (Media Transfer Protocol, Ethernet Tether, Debug) you want to have on the usb port and the usb Id will change accordingly..
Phones/Tablets do typically not present serial interfaces and they do not have the AT cmd protocol incorporated.
-
iaindooley
- Posts: 6
- Joined: 15 Dec 2021, 06:28
Post
by iaindooley » 16 Dec 2021, 09:52
Amazing thanks again for your help and this information.
-
iaindooley
- Posts: 6
- Joined: 15 Dec 2021, 06:28
Post
by iaindooley » 04 Jan 2022, 23:34
I have a follow up question that is pretty OT for this forum but I thought I'd try anyway just in case someone can help:
The method to add "on the fly" driver support works really well, but seems to behave differently if the device is connected at boot time.
The 3 scenarios are:
1) Device not connected at boot time, no "on the fly" support: in this case there are no /dev/ttyUSBX devices, it just behaves as a modem
2) Device not connected at boot time, "on the fly" driver support added: in this case there are 5 /dev/ttyUSBX devices, and no internet connection
3) Device connected at boot time, "on the fly" driver support added: this is the optimal case, the internet and 4 x ttyUSBX devices are present
However if the carrier is lost on the ethernet connection, the dongle resets and then reconnects in state number 2) above. In this case I can't bring the ethernet interface back up without rebooting the machine.
Any ideas how to make it so that scenario 2) behaves like scenario 3)?
Thanks again for all your help so far.
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 05 Jan 2022, 12:02
You can try adding a ff to the cmd, it may exclude the net interface from being "stolen" by the option driver.
echo 19d2 0581 ff >/sys/bus/usb-serial/drivers/option1/new_id
-
iaindooley
- Posts: 6
- Joined: 15 Dec 2021, 06:28
Post
by iaindooley » 12 Feb 2022, 07:56
I am shocked and delighted to report that adding "ff" appears to have fixed the problem! You're amazing, thank you.
This is even more OT and I'm going to try and find an answer myself (and ask in a more appropriate place) but I thought I would lazily ask you here since you seem so knowledgeable about this stuff, just in case you could save me some more time with your mysterious sorcery.
The file:
/sys/bus/usb-serial/drivers/option1/new_id
doesn't exist unless I have a recognised device connected when the machine boots up. In my case, I have some old 3g modems, and I have one connected to each machine. These modems obviously already have driver support so they create that "option1/new_id" path and show up with /dev/ttyUSBX ports without any further intervention.
However this takes up one of my valuable USB slots so I'm wondering if there is a way to load that usb-serial driver without having one of those devices connected, so that I can echo the "on the fly" driver support code (for want of a better term) without having had a serial device connected at boot time.
Obviously I can disconnect the 3g modem after boot, but that means I would need to be physically present in order to reboot the machine.
Thanks again for all of your invaluable advice, I really appreciate it.
|
|