Author Message

<  Setup Discussion  ~  Huawei ME906s-158 cannot connect

PostPosted: Sun Jun 25, 2017 7:14 am Reply with quote
Posts: 1108Location: Koh Samui, THJoined: Wed Jul 11, 2012 3:14 pm
This is strange, there shouldn't be any difference between usb_modeswitch's selection of config 3 via libusb and your manual selection through the sysfs.

You ran the echo cmd quite late, after 3 minutes according to the dmesg timestamps.
What happens if you instead of echo do the manual usb_modeswitch cmd after 3 minutes?

sudo usb_modeswitch -v 12d1 -p 15c1 -u 3 -W


Offline Profile
PostPosted: Sun Jul 02, 2017 12:22 pm Reply with quote
Posts: 5Joined: Sun Jul 02, 2017 11:03 am
I have a HP lt4132 LTE/HSPA+ 4G Module (03f0:a31d). This is a Huawei ME906s-158 in disguise, and probably behaves exactly the same as aobs's device. After bootup, it it starts out in configuration 2. It is not picked up as a supported device by ModemManager in this configuration.

In order to make it work with ModemManager, it must be switched to configuration 3. In this configuration, it works fine. ModemManager recognises it as follows:

Code:
  -------------------------
  Hardware |   manufacturer: 'Generic'
           |          model: 'MBIM [03F0:A31D]'
           |       revision: '11.617.13.00.00'
           |      supported: 'gsm-umts, lte'
           |        current: 'gsm-umts, lte'
           |   equipment id: '(redacted)'
  -------------------------
  System   |         device: '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3'
           |        drivers: 'cdc_mbim'
           |         plugin: 'Generic'
           |   primary port: 'cdc-wdm0'
           |          ports: 'cdc-wdm0 (mbim), wwp0s20f0u3c3 (net)'
  -------------------------


However, there's a caveat: the modem cannot be switched directly from configuration 2 to configuration 3. It must be deconfigured first (i.e., configuration 0), like so:

Code:
$ cat /sys/bus/usb/devices/1-3/bConfigurationValue
2
$ echo 0 > /sys/bus/usb/devices/1-3/bConfigurationValue
$ echo 3 > /sys/bus/usb/devices/1-3/bConfigurationValue


I couldn't figure out how to make usb_modeswitch perform this two-step switching procedure, unfortunately. Is it possible?


Offline Profile
PostPosted: Sun Jul 02, 2017 1:20 pm Reply with quote
Site AdminPosts: 6280Joined: Sat Nov 03, 2007 12:30 am
Interesting information!

You should be able to use usb_modeswitch for the configuration change:
Code:
# usb_modeswitch -v 0x03f0 -p 0xa31d -u 0
# usb_modeswitch -v 0x03f0 -p 0xa31d -u 3

If that works, I'll think about making it automatic if the initial configuration is not 0 ...


Offline Profile
PostPosted: Sun Jul 02, 2017 1:55 pm Reply with quote
Posts: 5Joined: Sun Jul 02, 2017 11:03 am
That doesn't work, unfortunately.

It appears that usb_modeswitch ignores the -u 0 option:

Code:
$ usb_modeswitch -v 0x03f0 -p 0xa31d -u 0
Look for default devices ...
   product ID matched
 Found devices in default mode (1)
Access device 003 on bus 001
Get the current device configuration ...
Current configuration number is 2
Use interface number 0
 with class 2

USB description data (for identification)
-------------------------
Manufacturer: HP
     Product: HP lt4132 LTE/HSPA+ 4G Module
  Serial No.: 0123456789ABCDEF
-------------------------
Warning: no switching method given. See documentation
-> Run lsusb to note any changes. Bye!


It is also possble to write -1 (instead of 0) to bConfigurationValue in order to deconfigure the device, but usb_modeswitch doesn't appear to be able to do that either. The output changes slightly, though:

Code:
$ usb_modeswitch -v 0x03f0 -p 0xa31d -u -1
Look for default devices ...
   product ID matched
 Found devices in default mode (1)
Access device 003 on bus 001
Get the current device configuration ...
Use interface number 0
 with class 2

USB description data (for identification)
-------------------------
Manufacturer: HP
     Product: HP lt4132 LTE/HSPA+ 4G Module
  Serial No.: 0123456789ABCDEF
-------------------------
-> Run lsusb to note any changes. Bye!

$ cat /sys/bus/usb/devices/1-3/bConfigurationValue
2


Even if the above wasn't a problem, there would still be a problem remaining: usb_modeswitch does not appear to be able to operate on unconfigured devices. After writing 0 or -1 to bConfigurationValue, the file becomes empty, and usb_modeswitch does not understand what that signifies:

Code:
$ echo 0 > /sys/bus/usb/devices/1-3/bConfigurationValue
$ wc /sys/bus/usb/devices/1-3/bConfigurationValue
   0    0    0 /sys/bus/usb/devices/1-3/bConfigurationValue
$ usb_modeswitch -v 0x03f0 -p 0xa31d -u 3
Look for default devices ...
   product ID matched
Get the current device configuration ...
 Determining the active configuration failed (error -5). Abort


Offline Profile
PostPosted: Sun Jul 02, 2017 2:46 pm Reply with quote
Posts: 1108Location: Koh Samui, THJoined: Wed Jul 11, 2012 3:14 pm
Josh wrote:
Interesting information!

You should be able to use usb_modeswitch for the configuration change:
Code:
# usb_modeswitch -v 0x03f0 -p 0xa31d -u 0
# usb_modeswitch -v 0x03f0 -p 0xa31d -u 3

If that works, I'll think about making it automatic if the initial configuration is not 0 ...


The active configuration can never be 0, 0 is unconfigured so you will never see that config because Linux will set an active configuration for every device appearing on the bus and that is config #1 for most devices since most
devices has only a single configuration.

For devices with multiple configurations Linux will set first found configuration which has an interface with "real" class attribute (ie not vendor specific class).
That is config #2 in ME906-158 which has a cdc_ether interface (attributes 02/06/00).


Offline Profile
PostPosted: Sun Jul 02, 2017 2:53 pm Reply with quote
Posts: 1108Location: Koh Samui, THJoined: Wed Jul 11, 2012 3:14 pm
tore wrote:
That doesn't work, unfortunately.

It appears that usb_modeswitch ignores the -u 0 option:



Yes, config #0 is reserved in usb_modeswitch, it is a dummy a "do nothing" and there is no reason for an end user to be able to select it from the cmdline.

What can be done in usb_modeswitch internally is always select config #0 first before selecting the final config. No need to check for active connection after having selected config #0, just send the final select directly after.


Offline Profile
PostPosted: Sun Jul 02, 2017 4:31 pm Reply with quote
Posts: 5Joined: Sun Jul 02, 2017 11:03 am
LOM wrote:
What can be done in usb_modeswitch internally is always select config #0 first before selecting the final config. No need to check for active connection after having selected config #0, just send the final select directly after.


Yes, having the option to deconfigure the device before switching to the final config would be very helpful to support the Huawei ME906s-158 / HP lt4132. If such functionality is added, it might be wise to also make it possible to insert a configurable delay between deconfiguring it (selecting config #0) and entering the final configuration. I have a suspicion that the lt4132 might sometimes need a little bit of time to settle.


Offline Profile
PostPosted: Mon Jul 03, 2017 5:32 am Reply with quote
Posts: 1108Location: Koh Samui, THJoined: Wed Jul 11, 2012 3:14 pm
tore wrote:
LOM wrote:
What can be done in usb_modeswitch internally is always select config #0 first before selecting the final config. No need to check for active connection after having selected config #0, just send the final select directly after.


Yes, having the option to deconfigure the device before switching to the final config would be very helpful to support the Huawei ME906s-158 / HP lt4132. If such functionality is added, it might be wise to also make it possible to insert a configurable delay between deconfiguring it (selecting config #0) and entering the final configuration. I have a suspicion that the lt4132 might sometimes need a little bit of time to settle.


A user configurable delay might not be needed, just make it long enough.
Half a second for instance, it's not like a user would notice that as a longer startup time and it is a one-time-only thingy.

There is a modemmanager mailing list thread about this problem and I'm linking to the post where Björn Mork explains that Windows always goes via config #0 when selecting a new config.

https://lists.freedesktop.org/archives/ ... 02840.html

Josh?


Offline Profile
PostPosted: Mon Jul 03, 2017 6:50 pm Reply with quote
Site AdminPosts: 6280Joined: Sat Nov 03, 2007 12:30 am
I'll check it out. My main problem is that to test with, I have only one single modem that provides multiple configurations ...


Offline Profile
PostPosted: Sun Jul 30, 2017 1:56 pm Reply with quote
Site AdminPosts: 6280Joined: Sat Nov 03, 2007 12:30 am
Yes, I know, it did take long ...

Anyway, here is a test version of the usb_modeswitch core program. Just drop it into the source folder of the current release and re-make.

Two issues are addressed in this version:

- Driver detachment is now much more thorough, for every interface of the current configuration

- The device is set to initial configuration before applying the actual target configuration.

It runs quite well with my Alcatel X602d. I can switch configurations back and forth, without any complaints by the kernel about claimed interfaces. Note that " -u 0 " will still be ignored.
Attachments:
usb-modeswitch.test.tgz [16.77 KiB]
Downloaded 23 times

Offline Profile
PostPosted: Mon Jul 31, 2017 2:12 am Reply with quote
Posts: 5Joined: Sun Jul 02, 2017 11:03 am
Hi Josh,

I tested with your updated files plus the attached patch to add support for the HP lt4132. I tried rebooting my laptop approx. a dozen times, and it worked all but once. The one time it didn't work, the config had been switched to #3, but the modem was still inoperable (as if it had been switched directly from #2 to #3).

I can't be sure but I have a suspicion that it might be because you didn't add any delay between the libusb_set_configuration(devh, -1); and libusb_set_configuration(devh, Configuration); calls.

Tore
Attachments:
File comment: Patch to add HP lt4132 to usb_modeswitch-data-20170205.
hp-lt4132.patch [1001 Bytes]
Downloaded 23 times

Offline Profile
PostPosted: Mon Jul 31, 2017 8:06 am Reply with quote
Site AdminPosts: 6280Joined: Sat Nov 03, 2007 12:30 am
tore wrote:
delay between the libusb_set_configuration(devh, -1); and libusb_set_configuration(devh, Configuration);

I had thought about that but the testing with my modem didn't show any problems so I left it out.

If you want to try for yourself, just insert a wait in between:
Code:
    usleep(100000);

The waiting time is entered as microseconds, so here you have 100 milliseconds.

You should also be able to change the configuration cleanly on the command line now:
Code:
# usb_modeswitch -v 0x03f0 -p 0xa31d -W -u 2

If all goes according to plan (as it does here), usb_modeswitch should be triggered again immediately and set config #3 automatically. Repeat as often as you like - in theory the modem should be operative all the time.


Offline Profile
PostPosted: Mon Jul 31, 2017 8:55 am Reply with quote
Posts: 1108Location: Koh Samui, THJoined: Wed Jul 11, 2012 3:14 pm
tore wrote:
Hi Josh,

I tested with your updated files plus the attached patch to add support for the HP lt4132. I tried rebooting my laptop approx. a dozen times, and it worked all but once. The one time it didn't work, the config had been switched to #3, but the modem was still inoperable (as if it had been switched directly from #2 to #3).

I can't be sure but I have a suspicion that it might be because you didn't add any delay between the libusb_set_configuration(devh, -1); and libusb_set_configuration(devh, Configuration); calls.

Tore


If it works 11 times out of 12 then you should not need much of delay so I retract my earlier suggestion of 500mS, I think you'll find that Josh suggestion of 100mS (or even less) is enough.
It is so far only this Huawei card of all devices needing a configuration change that has the problem.

@Josh
If you are about to release a new build then also consider a Android switch message under HuaweiNewMode with a switch between them in the global config file.


Offline Profile
PostPosted: Mon Jul 31, 2017 2:56 pm Reply with quote
Posts: 5Joined: Sun Jul 02, 2017 11:03 am
It doesn't automatically switch back after selecting config #2, because changing the config doesn't trigger any udev events for the parent device, which in turn means usb_modeswitch doesn't get invoked.

Instead, I cooked up the following simple script to do some repetitive testing:

Code:
#!/bin/sh -e
echo -ne "\rSuccessful iterations: 0";
for i in {1..1000}; do
        echo 0 > /sys/bus/usb/devices/1-3/bConfigurationValue
        sleep 1
        echo 2 > /sys/bus/usb/devices/1-3/bConfigurationValue
        sleep 1
        udevadm trigger /sys/bus/usb/devices/1-3
        timeout 35 sh -c 'until mmcli -L | grep -q MBIM; do sleep 0.1; done'
        sleep 1
        echo -ne "\rSuccessful iterations: $i";
done


Using an usb_modeswitch without any added delay, I got the following reference results:

Code:
$ for i in {1..20}; do sudo ./test.sh; echo; done
Successful iterations: 3
Successful iterations: 2
Successful iterations: 0
Successful iterations: 2
Successful iterations: 26
Successful iterations: 3
Successful iterations: 11
Successful iterations: 10
Successful iterations: 2
Successful iterations: 40
Successful iterations: 2
Successful iterations: 6
Successful iterations: 2
Successful iterations: 11
Successful iterations: 3
Successful iterations: 1
Successful iterations: 11
Successful iterations: 2
Successful iterations: 7
Successful iterations: 6


I then added usleep(100000); immediately after ret = libusb_set_configuration(devh, -1);, recompiled usb_modeswitch, and tried again. The first round has now passed 250 successful iterations, and it's still going strong.

The conclusion is clear as day: a delay is obviously necessary for reliable switching, and 100ms seems sufficient.


Offline Profile
PostPosted: Mon Jul 31, 2017 3:25 pm Reply with quote
Posts: 1Joined: Mon Jul 31, 2017 2:30 pm
tore wrote:
I then added usleep(100000); immediately after ret = libusb_set_configuration(devh, -1);, recompiled usb_modeswitch, and tried again. The first round has now passed 250 successful iterations, and it's still going strong.

The conclusion is clear as day: a delay is obviously necessary for reliable switching, and 100ms seems sufficient.

I agree. Tried with a test version of usb_modeswitch without any delay. Only on 6th reboot modem started to work.
Added 100ms delay, recompiled. Now it works every time.


Offline Profile

Display posts from previous:  Sort by:

All times are UTC + 1 hour [ DST ]
Page 2 of 2
30 posts
Go to page Previous  1, 2
Users browsing this forum: Bing [Bot] and 1 guest
Search for:
Post new topic  Reply to topic
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum