On Fri, Feb 19, 2016 at 2:31 AM, Bjørn Mork <bjorn@xxxxxxx> wrote:
> 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.
Yes confirmed that it was using configuration 2.
> 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.
I remember trying the AT^NDISDUP command at some point. I think I got
an invalid command error.
> 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
[219042.445533] cdc_ncm 1-3:2.0 enx022c80139263: unregister 'cdc_ncm'
usb-0000:00:14.0-3, CDC NCM
[219042.466164] qcserial ttyUSB0: Qualcomm USB modem converter now
disconnected from ttyUSB0
[219042.466224] qcserial 1-3:2.2: device disconnected
[219042.467695] qcserial ttyUSB1: Qualcomm USB modem converter now
disconnected from ttyUSB1
[219042.467753] qcserial 1-3:2.3: device disconnected
[219042.468210] qcserial ttyUSB2: Qualcomm USB modem converter now
disconnected from ttyUSB2
[219042.468252] qcserial 1-3:2.4: device disconnected
[219042.468703] qcserial ttyUSB3: Qualcomm USB modem converter now
disconnected from ttyUSB3
[219042.468747] qcserial 1-3:2.5: device disconnected
[219042.476337] cdc_mbim 1-3:3.0: setting rx_max = 16384
[219042.482837] cdc_mbim 1-3:3.0: setting tx_max = 16384
[219042.483099] cdc_mbim 1-3:3.0: cdc-wdm2: USB WDM device
[219042.483902] cdc_mbim 1-3:3.0 wwan0: register 'cdc_mbim' at
usb-0000:00:14.0-3, CDC MBIM, 62:aa:ce:37:a2:53
[219042.485445] qcserial 1-3:3.2: Qualcomm USB modem converter detected
[219042.485764] usb 1-3: Qualcomm USB modem converter now attached to ttyUSB0
> Does cdc_mbim load? Does mbimcli work?
I'm not sure if I'm using it right.
$ sudo mbimcli -d /dev/cdc-wdm2 --query-device-caps
error: couldn't open the MbimDevice: Transaction timed out
> Can ModemManager connect?
> Does the netwrok interface work after connecting?
ModemManager recognizes it, as it did with config 2. With the
unactivated Verizon SIM the computer came with.
$ mmcli -m 1 --3gpp-scan
Found 4 networks:
311480 - Verizon (lte, forbidden)
310410 - AT&T (lte, available)
310120 - Sprint (lte, available)
310260 - T-Mobile (lte, available)
No luck as far as NMEA
When I inserted my activated T-Mobile SIM it started resetting every
30 seconds or so. It does that in windows too, so it may be an
unhealthy reaction to that particular SIM. In Windows it will actually
get a working network connection before it resets so I might be able
to script this. I should probably get an activated SIM that works in
Windows to test with though.
> 2) echo 2 > >/sys/bus/usb/devices/x-y/bConfigurationValue
[223519.579459] cdc_mbim 1-3:3.0 wwan0: unregister 'cdc_mbim'
usb-0000:00:14.0-3, CDC MBIM
[223519.628860] qcserial ttyUSB0: Qualcomm USB modem converter now
disconnected from ttyUSB0
[223519.628980] qcserial 1-3:3.2: device disconnected
[223519.673883] cdc_ncm 1-3:2.0: MAC-Address: 02:2c:80:13:92:63
[223519.673900] cdc_ncm 1-3:2.0: setting rx_max = 16384
[223519.674543] cdc_ncm 1-3:2.0: setting tx_max = 16384
[223519.677536] cdc_ncm 1-3:2.0 usb0: register 'cdc_ncm' at
usb-0000:00:14.0-3, CDC NCM, 02:2c:80:13:92:63
[223519.682192] qcserial 1-3:2.2: Qualcomm USB modem converter detected
[223519.682417] usb 1-3: Qualcomm USB modem converter now attached to ttyUSB0
[223519.686049] qcserial 1-3:2.3: Qualcomm USB modem converter detected
[223519.686524] usb 1-3: Qualcomm USB modem converter now attached to ttyUSB1
[223519.689555] qcserial 1-3:2.4: Qualcomm USB modem converter detected
[223519.689725] usb 1-3: Qualcomm USB modem converter now attached to ttyUSB2
[223519.690928] qcserial 1-3:2.5: Qualcomm USB modem converter detected
[223519.694418] usb 1-3: Qualcomm USB modem converter now attached to ttyUSB3
[223519.712453] cdc_ncm 1-3:2.0 enx022c80139263: renamed from usb0
[223519.746520] IPv6: ADDRCONF(NETDEV_UP): enx022c80139263: link is not ready
[223519.748424] IPv6: ADDRCONF(NETDEV_UP): enx022c80139263: link is not ready
> 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)?
With the constant resets mentioned above I'm not going to get very far
when trying to connect.
It at least seems to treat that as a valid command.
AT^DHCP?
+CME ERROR: 1
AT^DHCP=?
OK
> 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,
> },
I'm not seeing an obvious place in the code to paste that.
> No need to test further than you want to of course :)
Well considering I didn't know much of anything about cellular modems
before I started it's a drop in the bucket as far as my time spent on
this already.
> 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 could do some USB packet capturing in Windows if that helps.
> 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.
I'm currently testing using a 4.4 kernel. The serial ports didn't work
reliably with a kernel before the one with your November Huawei fix
which is why I cc'd you on this patch.
> But please let us know if that quirk is necessary, because we do want it
> to work by default.
I would like to work by default too. Booting from a USB stick, and
having everything just work is one of my favorite things about Linux.
I first installed Linux on a system around 1997 so I remember when
things weren't so magical. A friend installed it for me in early 1996.
I am just now realizing that I first used Linux 20 years ago.
--
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
