[LOM]

@Josh

The usb_modeswitch log (now 9 posts up) shows a successful switch even though the pid
is not in the target product list:

Code: Select all

Mode switching was successful, found 2020:4000 (Network Connect: MT6225)

I thought that successful meant a match against the targetproduct/targetproductlist and not
only a change in vid:pid from the default one.
If not then why do we have the targeproduct/targetproductlist ?

[Josh]

@LOM:

I have added the somewhat soft success check variant in 2.2.0. However I'm open to suggestions with regard to the handling there.

Do you think I should make it fail clearly if the target values are not matched?

[Josh]

I thought usb_modeswitch had to automatically fill link_list with proper ids...

Well, it does - but only if the first interface has class 0xff. This was for most of the time the practical standard for plain PPP modems. It seems that I'll have to check more interfaces ...

Stay tuned!

[Josh]

joe,

please try the new script as attached ...

[deleted]

[joe]

Ah, If I well understood, we are in that case: first usb device interface has class "0x02", MBIM interface...
and not 0xff (vendor specific).
Let's take a look one more time to usb-devices output (copied from previous posts...):

Code: Select all

T:  Bus=02 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 11 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=2020 ProdID=4000 Rev=03.00
S:  Manufacturer=Network Connect
S:  Product=MT6225 
C:  #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option
I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I:  If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

So Olicard dongle doesn't report 0xff for its first interface...

As opposite, Huawei dongle has its first interface class setted to 0xff (vendor specified)... Here why gsmmodem link is proper created in that case.... did I well understand your message?

Anyway let's try your new script... stay tuned...

[joe]

Unfortunately no expected changes...
As usual follows log file:

Code: Select all

USB_ModeSwitch log from Mon May  18 23:51:32 CEST 2015

Use global config file: /etc/usb_modeswitch.conf
Raw args from udev: /2-4.1

Use top device dir /sys/bus/usb/devices/2-4.1
Check class of first interface ...
 Interface class is 08.

----------------
USB values from sysfs:
  manufacturer	Network Connect
  product	MT6225
  serial	531598307853860
----------------
ConfigList: /usr/share/usb_modeswitch/2020:0002
SCSI attributes not needed, move on
Check config: /usr/share/usb_modeswitch/2020:0002
! matched. Read config data
config: TargetVendor set to 2020
config: TargetProductList set to 2000,4010,4000
Driver module is "option", ID path is /sys/bus/usb-serial/drivers/option1

Device may have an MBIM configuration, check driver ...
 driver for MBIM devices is available
Find MBIM configuration number ...
 No MBIM configuration found, switch to legacy modem mode
Command to be run:
usb_modeswitch -W -D -s 20  -b 2 -g 21 -v 2020 -p 0002 -f $configBuffer

Verbose debug output of usb_modeswitch and libusb follows
(Note that some USB errors are to be expected in the process)
--------------------------------

Read long config from command line

 * usb_modeswitch: handle USB devices with multiple modes
 * Version 2.2.0 (C) Josua Dietze 2014
 * Based on libusb1/libusbx

 ! PLEASE REPORT NEW CONFIGURATIONS !

DefaultVendor=  0x2020
DefaultProduct= 0x0002
TargetVendor=   0x2020
TargetProductList="2000,4010,4000"
MessageContent="555342430820298900000000000003f0010100000000000000000000000000"
NeedResponse=0
Success check enabled, max. wait time 20 seconds
System integration mode enabled

Use given bus/device number: 002/021 ...
Look for default devices ...
 bus/device number matched
  found USB ID 2020:0002
   vendor ID matched
   product ID matched
 Found devices in default mode (1)
Current configuration number is 1
Use interface number 0
Use endpoints 0x01 (out) and 0x81 (in)

USB description data (for identification)
-------------------------
Manufacturer: Network Connect
     Product: MT6225 
  Serial No.: 531598307853860
-------------------------
Looking for active driver ...
 OK, driver detached
Set up interface 0
Use endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
 OK, message successfully sent
Reset response endpoint 0x81
Reset message endpoint 0x01
Bus/dev search active, refer success check to wrapper. Bye!

ok:busdev
--------------------------------
(end of usb_modeswitch output)

Check success of mode switch for max. 20 seconds ...
 Wait for device file system (1 sec.) ...
 Read attributes ...
 All attributes matched
Mode switching was successful, found 2020:4000 (Network Connect: MT6225)
Logger is /usr/bin/logger
Now check for bound driver ...
 driver has bound, device is known
Check for AVOID_RESET_QUIRK kernel attribute
 AVOID_RESET_QUIRK activated

All done, exit

[Josh]

One thing has changed - the device would have been added to "link_list" automatically now.

Other than that, I am at a loss why you get no logs for the "symlink" run. That works well over here ...

[joe]

Well, I can just confirm there aren't any other log file... As well as I haven't any other line added to link_list file...

Code: Select all

# ls /var/log/usb_*
/var/log/usb_modeswitch_2-4.1

# cat /var/lib/usb_modeswitch/link_list 
12d1:1506

[Josh]

Phew - one more try.

[LOM]

@LOM:

I have added the somewhat soft success check variant in 2.2.0. However I'm open to suggestions with regard to the handling there.

Do you think I should make it fail clearly if the target values are not matched?

No, I can see the advantages of not relying on a target product vid:pid in order to determine a switch success.
I was just not aware of this new behaviour so I found the log very strange.

[joe]

Ok, seems we have a little progress now!

With that new version finally link_list file is filled with 2020:4000 ids...
Although still no gsmmodem is created, nor any logs related to ttyUSB ports inquiring.

Code: Select all

# cat /var/lib/usb_modeswitch/link_list
2020:4000

# ls -l /dev/gs*
/bin/ls: impossibile accedere a /dev/gs*: File o directory non esistente

# ls /var/log/usb*
/var/log/usb_modeswitch_1-4.1 

And last but not least follows log file...

Code: Select all

USB_ModeSwitch log from Tue May  19 10:42:23 CEST 2015

Use global config file: /etc/usb_modeswitch.conf
Raw args from udev: /1-4.1

Use top device dir /sys/bus/usb/devices/1-4.1
Check class of first interface ...
 Interface class is 08.

----------------
USB values from sysfs:
  manufacturer	Network Connect
  product	MT6225
  serial	531598307853860
----------------
ConfigList: /usr/share/usb_modeswitch/2020:0002
SCSI attributes not needed, move on
Check config: /usr/share/usb_modeswitch/2020:0002
! matched. Read config data
config: TargetVendor set to 2020
config: TargetProductList set to 2000,4010,4000
Driver module is "option", ID path is /sys/bus/usb-serial/drivers/option1

Device may have an MBIM configuration, check driver ...
 driver for MBIM devices is available
Find MBIM configuration number ...
 No MBIM configuration found, switch to legacy modem mode
Command to be run:
usb_modeswitch -W -D -s 20  -b 1 -g 12 -v 2020 -p 0002 -f $configBuffer

Verbose debug output of usb_modeswitch and libusb follows
(Note that some USB errors are to be expected in the process)
--------------------------------

Read long config from command line

 * usb_modeswitch: handle USB devices with multiple modes
 * Version 2.2.0 (C) Josua Dietze 2014
 * Based on libusb1/libusbx

 ! PLEASE REPORT NEW CONFIGURATIONS !

DefaultVendor=  0x2020
DefaultProduct= 0x0002
TargetVendor=   0x2020
TargetProductList="2000,4010,4000"
MessageContent="555342430820298900000000000003f0010100000000000000000000000000"
NeedResponse=0
Success check enabled, max. wait time 20 seconds
System integration mode enabled

Use given bus/device number: 001/012 ...
Look for default devices ...
 bus/device number matched
  found USB ID 2020:0002
   vendor ID matched
   product ID matched
 Found devices in default mode (1)
Current configuration number is 1
Use interface number 0
Use endpoints 0x01 (out) and 0x81 (in)

USB description data (for identification)
-------------------------
Manufacturer: Network Connect
     Product: MT6225 
  Serial No.: 531598307853860
-------------------------
Looking for active driver ...
 OK, driver detached
Set up interface 0
Use endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
 OK, message successfully sent
Reset response endpoint 0x81
Reset message endpoint 0x01
Bus/dev search active, refer success check to wrapper. Bye!

ok:busdev
--------------------------------
(end of usb_modeswitch output)

Check success of mode switch for max. 20 seconds ...
 Wait for device file system (1 sec.) ...
 Read attributes ...
 All attributes matched
Mode switching was successful, found 2020:4000 (Network Connect: MT6225)
Logger is /usr/bin/logger
Now check for bound driver ...
 driver has bound, device is known
Check for AVOID_RESET_QUIRK kernel attribute
 AVOID_RESET_QUIRK activated

All done, exit

[Josh]

Did you check with your Huawei modem also if you get any "ttyUSB" log file now?

[joe]

Well, no log files referring to my huawei because it was in use (connected to internet on this same PC) when I installed new usb_modeswitch version... I had also removed all log files before reinstall.
Anyway ttyUSB logs related to Huawei dongle were regularly created even before your last version...

Wait... I'll try to re-plugin Huawei dongle so we can see if tty logs are added.

Code: Select all

# ls /var/log/usb*
/var/log/usb_modeswitch_1-4.1

I've just Olicard log now. Let's replug Huawei dongle...

Code: Select all

# ls /var/log/usb*
/var/log/usb_modeswitch_1-4.1        /var/log/usb_modeswitch_ttyUSB_1-4.4.2:1.0  /var/log/usb_modeswitch_ttyUSB_1-4.4.2:1.4
/var/log/usb_modeswitch_1-4.4.2:1.0  /var/log/usb_modeswitch_ttyUSB_1-4.4.2:1.3

Here four new log files are added and three of them are related to ttyUSB ports inquiring. So seems work as expected...
As usual just firs port /dev/ttyUSB0 is recognized as interrupt port and linked to /dev/gsmmodem...
Let take a look to other var/lib files:

Code: Select all

# ls /var/lib/usb_modeswitch/
link_list

# cat /var/lib/usb_modeswitch/link_list 
2020:4000
12d1:1506

And last we have proper link created:

Code: Select all

# ls -l /dev/gsmmodem 
lrwxrwxrwx 1 root root 7 mag 19 16:03 /dev/gsmmodem -> ttyUSB0

So yes, with huawei no problem...

[joe]

Hi all, I write this just as a confirm that no progress has been done with gsm_modem link issue...

PS.
Anyway good news: seems usb-linux developers are ready to merge my/our option.c patch.
I'm not usual at submitting patches at all: this is my first patch... But after reading various documentation about canonical patch format for mailing list submission, I've seen it's possible to include also other names for credit using a "Suggested-by:" tag.

I've just sent a PM to LOM asking if he was interested to appear in kernel changelog, since he had a good idea about function USB_DEVICE_INTERFACE_CLASS involved to bind right interfaces only.

I'll try to submit the pach as soon as LOM answers.

Again, tanks to all helped!