Daniel Johnson <teknotus@xxxxxxxxx> writes:
>>> Currently 4 ttyUSB devices are detected, but only the second two respond to
>>> AT commands. The first two serial ports may be falsely detected.
>>
>> One of them is likely a QCDM port if this is really a Qualcomm based
>> device. The other might be an inactive NMEA port. Serial doesn't
>> necessarily imply AT commands...
>
> I remember that some tool I tried didn't like the first two serial
> ports for some reason. I thought that might be another clue.
>
>>> Of the two responsive serial devices the first is the source of unsolicited
>>> information such as a SIM insert. The second is always the source of NMEA
>>> messages.
>>>
>>> A have not figured out the correct AT commands to connect to a cell network
>>> so the created network interface is untested.
>>
>> Huawei use subclass+protocol to differentiate their vendor specific
>> functions, so we usually get some idea of what to expect from the USB
>> descriptors.
>>
>> Could you post the output of "lsusb -vd 03f0:9a1d", or the relevant part
>> of /sys/kernel/debug/usb/devices?
>>
>> If this doesn't help, then the Windows drivers (if any?) should give
>> some clue.
>
> It has a windows driver. It is build into the US model of the HP
> Spectre X2 I'm typing on. HP only officially supports the Verizon cell
> phone even though Huawei manuals indicate it supporting many networks.
> It can certainly scan for all the major US carriers. I don't have an
> activated Verizon SIM so I tried the T-Mobile one from my phone. In
> windows it would connect, and get a working internet connection, and
> then reset after about a minute. In Linux the T-Mobile SIM would
> sometimes cause the same behavior where the module seemed to be doing
> a hardware reset.
The reset could of course be by purpose, but I'd say that a firmware
crash is just as likely. Modem firmwares often tend to be unstable
under unexpected conditions...
> Bus 001 Device 028: ID 03f0:9a1d Hewlett-Packard
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 239 Miscellaneous Device
> bDeviceSubClass 2 ?
> bDeviceProtocol 1 Interface Association
> bMaxPacketSize0 64
> idVendor 0x03f0 Hewlett-Packard
> idProduct 0x9a1d
> bcdDevice 0.01
> iManufacturer 6 Hewlett-Packard
> iProduct 5 HP lt4114 LTE 4G Module
> iSerial 0
> bNumConfigurations 3
Good. So you have a few alternative configs here. I forgot to ask, but
I assume you've ended up with cfg #2 by default (because Linux has a
class preference, making it select the first config with a non 0xff
class as the first interface). Anyway, we can go through all three as
they will share most of the functions.
The driver messages in dmesg will tell you which configuration was
selected, or you can read the /sys/bus/usb/devices/x-y/bConfigurationValue
sysfs attribute. Switching configs is as easy as writing to the same
attribute. E.g
echo 3 >/sys/bus/usb/devices/x-y/bConfigurationValue
1st, assumed inactive, config:
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 259
> bNumInterfaces 5
> bConfigurationValue 1
> iConfiguration 2 configuration 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 5
> bInterfaceProtocol 18
This is a serial function of some kind. It would be handled by the
option driver if the modem had a Huawei vendor ID.
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 5
> bInterfaceProtocol 19
Like intf #0. The different protocol numbers probably indicate different
types of serial functions, but I don't know that mapping.
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 0
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 5
> bInterfaceProtocol 16
And another serial function.
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 3
> bAlternateSetting 0
> bNumEndpoints 1
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 5
> bInterfaceProtocol 22
> iInterface 0
> ** UNRECOGNIZED: 05 24 00 10 01
> ** UNRECOGNIZED: 06 24 1a 00 01 1f
> ** UNRECOGNIZED: 0d 24 0f 01 05 00 00 00 ea 05 03 00 01
> ** UNRECOGNIZED: 05 24 06 03 03
There's the network function. I am pretty sure this is a "Huawei type"
NCM device, based on the protocol number. These are usually handled by
the huawei_cdc_ncm driver. But I don't remember if we've ever verified
operation with a firmware using subclass 5. I don't know this for sure,
but I am guessing that Huawei use the subclass number as a firmware
generation and/or source indicator.
If this behaves like other Huawei NCM devices, then it uses AT^NDISDUP
and other Huawei specific AT commands for connection management. Some
firmwares accept these over a serial function, but some insist that the
management channel embedded in the CDC NCM device is used. The
huawei_cdc_ncm driver provides access to this channel via a
/dev/cdc-wdmX character device.
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 4
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 5
> bInterfaceProtocol 20
And there's the last serial function.
2nd, assumed active, config:
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 269
> bNumInterfaces 6
> bConfigurationValue 2
> iConfiguration 4 configuration 1
> bmAttributes 0xa0
> (Bus Powered)
> Remote Wakeup
> MaxPower 500mA
> Interface Association:
> bLength 8
> bDescriptorType 11
> bFirstInterface 0
> bInterfaceCount 2
> bFunctionClass 2 Communications
> bFunctionSubClass 0
> bFunctionProtocol 0
> iFunction 0
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 1
> bInterfaceClass 2 Communications
> bInterfaceSubClass 13
> bInterfaceProtocol 0
> iInterface 0
> CDC Header:
> bcdCDC 1.10
> CDC NCM:
> bcdNcmVersion 1.00
> bmNetworkCapabilities 0x1f
> crc mode
> max datagram size
> encapsulated commands
> net address
> packet filter
> CDC Ethernet:
> iMacAddress 3 022C80139263
> bmEthernetStatistics 0x00000005
> wMaxSegmentSize 1514
> wNumberMCFilters 0x0003
> bNumberPowerFilters 1
> CDC Union:
> bMasterInterface 0
> bSlaveInterface 1
So, there you have a proper standard CDC NCM class function. It is
probably the exact same as the vendor specific NCM function described
above. Only difference is that this will match and work with the
cdc_ncm class driver.
I assume this can be managed with AT^NDISDUP and friends via one of the
AT serial functions. It might still support the inline management
channel, but I cannot imagine that using it is required since that would
make the whole standard class thing pointless.
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 0
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 5
> bInterfaceProtocol 16
Same as in cfg #1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 3
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 5
> bInterfaceProtocol 19
Same as in cfg #1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 4
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 5
> bInterfaceProtocol 18
Same as in cfg #1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 5
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 5
> bInterfaceProtocol 20
Same as in cfg #1
3rd, assumed inactive, config:
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 137
> bNumInterfaces 3
> bConfigurationValue 3
> iConfiguration 0
> bmAttributes 0xa0
> (Bus Powered)
> Remote Wakeup
> MaxPower 500mA
> Interface Association:
> bLength 8
> bDescriptorType 11
> bFirstInterface 0
> bInterfaceCount 2
> bFunctionClass 2 Communications
> bFunctionSubClass 14
> bFunctionProtocol 0
> iFunction 0
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 1
> bInterfaceClass 2 Communications
> bInterfaceSubClass 14
> bInterfaceProtocol 0
A standard CDC MBIM function. Should work out of the box with cdc_mbim
and ModemManager, unless this is one of the Huawei firmwares needing
special packet ordering. If so, then we have a per-device quirk for
that.
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 5
> bInterfaceProtocol 20
Same serial function as in the two other configs. This might be NMEA
since it is present in this configuration (which doesn't need any AT
command functions).
So, what I'd like to have tested is (replace 'x-y' with your actual bus
and port number):
1) echo 3 >/sys/bus/usb/devices/x-y/bConfigurationValue
Does cdc_mbim load? Does mbimcli work? Can ModemManager connect?
Does the netwrok interface work after connecting?
2) echo 2 > >/sys/bus/usb/devices/x-y/bConfigurationValue
Does cdc_ncm load? Can you connect with 'AT^NDISDUP=1,1,"yourapn"'?
Can you get the IP config with DHCP (e.g 'dhclient -d wwan0')? How
about 'AT^DHCP?'? Does the network device work (forwarding traffic)?
3) echo 1 > >/sys/bus/usb/devices/x-y/bConfigurationValue
Well, you'll need to pacth huawei_cdc_ncm for this test. I'm tempted
to assume that the class/subclass/protocol is unique even in the HP
vendor space, so an entry like this should be fine:
{ USB_VENDOR_AND_INTERFACE_INFO(0x03f0, 0xff, 0x05, 0x16),
.driver_info = (unsigned long)&huawei_cdc_ncm_info,
},
Can you connect using the same method as above? Does the
/dev/cdc-wdm0 device respond to AT commands?
No need to test further than you want to of course :)
Personally, I would probably have used this as an MBIM device (assuming
that works) with an udev rule to put it into cfg #3 by default. I'm
pretty sure that is what Windows (8+) does, too.
I'm very interested to know if you can connect in the two first cases,
but are unable to get any IP packets through. That would indicate that
the NCM/MBIM packet "order quirk" is necessary. If you are using Linux
v4.5 or newer (writing for the future :), then you can easily test out
this by toggling the '/sys/class/net/wwanX/cdc_ncm/ndp_to_end' sysfs
attribute.
But please let us know if that quirk is necessary, because we do want it
to work by default.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
