[joe]

I'm trying to better understand why my linux-friendly Huawei-E353 device is recognized without any particular config needed, this aspect could be useful to better understand the "option" driver behaviour on the Olicard-300.

Let's try a very easy test:

- Unload option, cdc_mbim, qmi_wwan

Code: Select all

# modprobe -r option cdc_mbim qmi_wwan
# lsmod |grep option\|cdc_mbim\|qmi_wwan

Code: Select all

T:  Bus=02 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 10 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=(none)
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=(none)
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=(none)
I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I:  If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

Code: Select all

T:  Bus=02 Lev=03 Prnt=05 Port=01 Cnt=01 Dev#=  9 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=12d1 ProdID=1506 Rev=00.00
S:  Manufacturer=Huawei Technologies
S:  Product=HUAWEI Mobile
C:  #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I:  If#= 1 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=09 Driver=(none)
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=(none)
I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=03 Driver=(none)
I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=02 Driver=(none)
I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
I:  If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

- Ok, now load option module only...

Code: Select all

modprobe option

Code: Select all

T:  Bus=02 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 10 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=(none)
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=(none)
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

Code: Select all

T:  Bus=02 Lev=03 Prnt=05 Port=01 Cnt=01 Dev#=  9 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=12d1 ProdID=1506 Rev=00.00
S:  Manufacturer=Huawei Technologies
S:  Product=HUAWEI Mobile
C:  #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=option
I:  If#= 1 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=09 Driver=(none)
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=(none)
I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=03 Driver=option
I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=02 Driver=option
I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
I:  If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

Now the behaviour seem very close between the two dongles.
But now the Olicard is hardcoded in my version of "option.c" driver source (and before this patch this wasn't the default behavoiur), while the Huawei e353 (12d1:1506) isn't mentioned at all.
So my question is:
How Huawei e353 is so finely managed by option module even without be clearly mentioned in its source code?
Where's the magic?

[LOM]

Now the behaviour seem very close between the two dongles.
But now the Olicard is hardcoded in my version of "option.c" driver source (and before this patch this wasn't the default behavoiur), while the Huawei e353 (12d1:1506) isn't mentioned at all.
So my question is:
How Huawei e353 is so finely managed by option module even without be clearly mentioned in its source code?
Where's the magic?

Here it is:

{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x01) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x02) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x03) },

[joe]

Thank you a lot!
I can now better understand how it works....
As I already said, I'm not a programmer, but I've found where is defined that function (or whaterver it is...):
http://lxr.free-electrons.com/source/in ... usb.h#L954

Code: Select all

954 #define USB_VENDOR_AND_INTERFACE_INFO(vend, cl, sc, pr) \
955         .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \
956                 | USB_DEVICE_ID_MATCH_VENDOR, \
957         .idVendor = (vend), \
958         .bInterfaceClass = (cl), \
959         .bInterfaceSubClass = (sc), \
960         .bInterfaceProtocol = (pr)

The syntax seems quite easy so pheraps it works as follows:

- if device vendor id matches 1st argument
- then bind module "option" to device interfaces that have:
1. interface class reported by 2nd argument
2. interface subclass reported by 3th arg
3. interface protocol reported by 4th arg

So, that's why my "usb-devices" output reported:

Code: Select all

I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=option
I:  If#= 1 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=09 Driver=(none)
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=(none)
I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=03 Driver=option
I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=02 Driver=option
I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
I:  If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

Example:

The device E353 has "12d1" vendor id (Huawei).
And its "0" Interface has:
- Class: 0xff (vendor defined)
- SubClass: 0x01
- Protocol: 0x01

Theese mathces the arguments specified by USB_VENDOR_AND_INTERFACE_INFO function... then option is bound to Interface "0".

I had edited option.c not by using the above function... but by adding a blacklist function.
Look at this...

Code: Select all

510 struct option_blacklist_info {
511         /* bitmask of interface numbers blacklisted for send_setup */
512         const unsigned long sendsetup;
513         /* bitmask of interface numbers that are reserved */
514         const unsigned long reserved;
515 };
516 
517 static const struct option_blacklist_info four_g_w14_blacklist = {
518         .sendsetup = BIT(0) | BIT(1),
519 };
520 
521 static const struct option_blacklist_info alcatel_x200_blacklist = {
522         .sendsetup = BIT(0) | BIT(1),
523         .reserved = BIT(4),
524 };

So I've added:

Code: Select all

/* VisionTek Mediatek Olivetti */
#define VISIONTEK_VENDOR_ID                     0x2020
#define OLIVETTI_PRODUCT_OLICARD300             0x4000

Code: Select all

static const struct option_blacklist_info olicard_300_blacklist = {
        .reserved = BIT(0) | BIT(1) | BIT(6),
};

Code: Select all

{ USB_DEVICE(VISIONTEK_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD300), /* Olivetti Olicard 300 - MT6225 */
                .driver_info = (kernel_ulong_t)&olicard_300_blacklist },

My solution works only for my specific device due to the product id recalled by the last line.
Pheraps it was a better choice by adding USB_VENDOR_AND_INTERFACE_INFO... because it is based just on the VendorId and class/subcl/prot specs.... And If we plugin an other "2020" vendor device, well it should bind option to the right interface out the box even if it has a different ProductId....
....But it's just a rough guess

What do you think about?
It would be a better solution?

PS.
I'm not sure about who really owns "2020" id vendor...
I've searched over various usb vendors databases but no trace of this one...
The only who talks about VisionTek is:
http://www.dd-wrt.com/wiki/index.php/3G ... #Visiontek

If you could help me to find any more reliable infos about this "2020" VendorId It would be much appreciated.

[LOM]

My solution works only for my specific device due to the product id recalled by the last line.
Pheraps it was a better choice by adding USB_VENDOR_AND_INTERFACE_INFO... because it is based just on the VendorId and class/subcl/prot specs.... And If we plugin an other "2020" vendor device, well it should bind option to the right interface out the box even if it has a different ProductId....
....But it's just a rough guess

What do you think about?
It would be a better solution?

The only correct solution is to make a rule that matches the device you have, you should definitely not make assumptions that other devices from the same vendor has the same kind of interface attributes.
There are a bunch of macro definitions in usb.h for matching a device and its interfaces, in your case a whitelisting of the serial interfaces based on their Class seems to be optimal so
use the same macro as has been used for some Bandrich dongles:

{ USB_DEVICE_INTERFACE_CLASS(BANDRICH_VENDOR_ID, BANDRICH_PRODUCT_C100_1, 0xff) }

Blacklisting by interface number is only needed if net interfaces should happen to match the whitelisting rule for the serial interfaces, you don't need to do that since your net interfaces have quite different attributes from what the serial interfaces have.

PS.
I'm not sure about who really owns "2020" id vendor...
I've searched over various usb vendors databases but no trace of this one...
The only who talks about VisionTek is:
http://www.dd-wrt.com/wiki/index.php/3G ... #Visiontek

If you could help me to find any more reliable infos about this "2020" VendorId It would be much appreciated.

I am really not the right guy to comment on the quality/exactness of the dd-wrt wiki page and assume that you have contradictory info about the owner of the vid since you ask about it.
I can imagine that the vid belongs to MediaTek and is used for their OEM's, I can say for sure though that it does not belong to Olivetti.

[joe]

Ok, I've edited option.c as follows (I've just added 4 new lines: a comment, two define lines for Vid an Pid and a line for binding based on interface class):

Code: Select all

   393  #define OLIVETTI_PRODUCT_OLICARD500             0xc00b
   394
   395  /* Olicard300 MT6225 */
   396  #define OLICARD300_VENDOR_ID                    0x2020 <-------
   397  #define OLICARD300_PRODUCT_ID                   0x4000 <-------
--
  1691                  .driver_info = (kernel_ulong_t)&net_intf6_blacklist },
  1692          { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD500),
  1693                  .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
  1694          { USB_DEVICE_INTERFACE_CLASS(OLICARD300_VENDOR_ID, OLICARD300_PRODUCT_ID, 0xff) }, <-------

After module rebuilding it seems to work as expected: option just binds interfaces with "0xff" class.

At this point pheraps we can talk about patch submitting...
I'll try to have some more info about who owns that vendor id, I haven't any exact idea where to ask at now, but I'll look around for the right place to obtain that vendor name...

Anyway, let's see what ahppens at dongle plugin and verify if usb_modeswitch does all actions to manage it as best.

Code: Select all

USB_ModeSwitch log from Sat May  02 16:42:07 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 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: 001/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
 No vendor-specific class found, skip driver check
Check for AVOID_RESET_QUIRK kernel attribute
 AVOID_RESET_QUIRK activated

All done, exit

Ok, now I'd like to answer the following two questions, comparing Olicard behaviour with Huawei one:
1- There isn't any sym. link related to /dev/ttyUSB device (I refer to /dev/gsmmodem* which is created instead when I plugin my other Huawei dongle.
2- Device /dev/sr* (Zero CD funtion when device is recognized as 2020:0002 before the switch) disappears at all after switching this Olicard300. On the other hand after Huawei is switched to modem is still present and usable its /dev/sr ZeroCD function.

Any chance to obtain the same for the Olicard300?

Thanks again for your very usefull support and suggestions!

[LOM]

Ok, I've edited option.c as follows (I've just added 4 new lines: a comment, two define lines for Vid an Pid and a line for binding based on interface class):

Code: Select all

   393  #define OLIVETTI_PRODUCT_OLICARD500             0xc00b
   394
   395  /* Olicard300 MT6225 */
   396  #define OLICARD300_VENDOR_ID                    0x2020 <-------
   397  #define OLICARD300_PRODUCT_ID                   0x4000 <-------
--
  1691                  .driver_info = (kernel_ulong_t)&net_intf6_blacklist },
  1692          { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD500),
  1693                  .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
  1694          { USB_DEVICE_INTERFACE_CLASS(OLICARD300_VENDOR_ID, OLICARD300_PRODUCT_ID, 0xff) }, <-------

After module rebuilding it seems to work as expected: option just binds interfaces with "0xff" class.

You don't need to invent a vendor name or a product name, you are allowed to use the vid and pid numbers in the list without defining them by name, see the 07d1 and 2001 vid's near the end of the MODULE_DEVICE_TABLE.
The define section is completely useless if you ask me - the whole option driver is based on numbers and not on names.

Ok, now I'd like to answer the following two questions, comparing Olicard behaviour with Huawei one:
1- There isn't any sym. link related to /dev/ttyUSB device (I refer to /dev/gsmmodem* which is created instead when I plugin my other Huawei dongle.

I have no idea why it isn't created. Josh??

2- Device /dev/sr* (Zero CD funtion when device is recognized as 2020:0002 before the switch) disappears at all after switching this Olicard300. On the other hand after Huawei is switched to modem is still present and usable its /dev/sr ZeroCD function.

Any chance to obtain the same for the Olicard300?

Why?
The virtual cd-rom contains Windows drivers and Connection Manager, none of which linux can use.
The interface layout after switching is decided by the dongles firmwares and Huawei do sometimes include not only the SD/TF-card interface but also the virtual cd-rom interface.
Only sometimes, not always!
It is not common among other mfgr to do so and the reason is most likely that there is no value at all in including it.

[joe]

Ok, I cutted away entries in define section, just added a comment at the end of USB_DEVICE_INTERFACE_CLASS line. I think could be useful to find what device refers that IDs...

Code: Select all

  1686                  .driver_info = (kernel_ulong_t)&net_intf6_blacklist },
  1687          { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD500),
  1688                  .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
  1689          { USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff) },  /* OLICARD300 - MT6225 */     <--------  <------- !!!

Do you think I could try to submit this "patch" to kernel developers?
---




As regards /dev/sr lost device after switching you are right... it'is not usefull at all on a linux system..

As regards "gsmmodem" link... seems we have to wait for Josh to let we know how it works and why in my case it doesn't work as expected.
I'll try to send him a PM...

It could be a good chioce to create a more explicative name instead of just "gsmmodem".
If the link was named for example:

Code: Select all

gsmmodem_20204000

or

Code: Select all

gsmmodem_MT6225

We will able to better distinguish it from any other dongles connected to our PC.
An example: I could configure a pppd script, "/etc/ppp/peers/olicard300" containing "/dev/gsmmodem-20204000" as device to use for connection...
If we have more than one dongle plugged in at the same time, it could be usefull..

Thanks again for all your suggests!

[Josh]

To see what's going on with the symbolic link feature of usb_modeswitch, enable logging in /etc/usb_modeswitch.conf.

Note that this feature is based on separate udev calls to usb_modeswitch for each port named "ttyUSB*" (see 'rules' file in data package).

Also note that not any ttyUSB port is treated, only those that belong to devices that were mode-switched and are 'known' to usb_modeswitch.
In "usb_modeswitch.sh", the USB ID of the triggering port's device is checked against a whitelist that is appended by the usb_modeswitch_dispatcher script when it meets a previously unregistered device.

As for the names of the symlinks, at the moment they are just numbered up to 256. It's easy to modify the usb_modeswitch_dispatcher script and append all sorts of additional attributes to the names created. See procedure "SymLinkName".

[bmork]

Pheraps it was a better choice by adding USB_VENDOR_AND_INTERFACE_INFO... because it is based just on the VendorId and class/subcl/prot specs.... And If we plugin an other "2020" vendor device, well it should bind option to the right interface out the box even if it has a different ProductId....

No, this doesn't work for most vendors using the ff (vendor specific class). It works for Huawei because they have implemented there own subclass+protocol scheme to indicate different functions, similar to how the generic USB classes work. Most vendors don't to this. Instead they rely on drivers knowing which interface number to bind to and which to leave for other drivers. Modern LTE or 3G modems are always composite devices, mixing serial and network functions (and often storage too) . The storage functions always use the proper USB class, so those are not a problem. But the serial and network functions are often both vendor specific, but requiring distinctly different drivers. So the drivers have to know the interface number to function mapping. And this is usually device specific, requiring an entry per device ID. You cannot make any assumptions about other devices from the same vendor. Just look at all the different ZTE entries in the option driver, for example.

Yes, this is all stupid. But that's what we've got. It's mainly because Micosoft failed to understand (or wanting to understand) about USB device classes until Windows 8. So every device comes with their own drivers, and device specifc *.inf file describing the mapping of the vendor specific functions.

[joe]

Pheraps it was a better choice by adding USB_VENDOR_AND_INTERFACE_INFO... because it is based just on the VendorId and class/subcl/prot specs.... And If we plugin an other "2020" vendor device, well it should bind option to the right interface out the box even if it has a different ProductId....

[...]
You cannot make any assumptions about other devices from the same vendor. Just look at all the different ZTE entries in the option driver, for example.

Yes, this is all stupid. But that's what we've got. It's mainly because Micosoft failed to understand (or wanting to understand) about USB device classes until Windows 8. So every device comes with their own drivers, and device specifc *.inf file describing the mapping of the vendor specific functions.

Thank you for reply!
And thank sfor your further explaination. I modified my patch attempt as also suggesteed by LOM in an above post, so my final version is made up of the only following line added (I report also number of line of "option.c"):

Code: Select all

1689          { USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff) },  /* OLICARD300 - MT6225 */

As you can see USB_DEVICE_INTERTFACE_CLASS function is invovled insetad of USB_VENDOR_AND_INTERFACE_INFO.
In that way we should match the specific VId AND PId at same time: we shouldn't have any problem with other devices having the same vendor id.
Am I wrong? Or I well understood your explanation?

Thank you again for the rest of your interesting answer!!!

An ask: there is a way to look in to *inf windows files of a dongle?
And there's a way to do it working under a linux system?

PS.
Are you the same Bjorn Mork of libmbim-devel mailing list?

[bmork]

And thank sfor your further explaination. I modified my patch attempt as also suggesteed by LOM in an above post, so my final version is made up of the only following line added (I report also number of line of "option.c"):

Code: Select all

1689          { USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff) },  /* OLICARD300 - MT6225 */

As you can see USB_DEVICE_INTERTFACE_CLASS function is invovled insetad of USB_VENDOR_AND_INTERFACE_INFO.
In that way we should match the specific VId AND PId at same time: we shouldn't have any problem with other devices having the same vendor id.
Am I wrong? Or I well understood your explanation?

Yes, that's fine as long as there aren't any non-serial vendor specific functions (like e.g QMI or similar). If there are, then those interfaces have to be blacklisted. There are plenty of such examples in the option driver.

An ask: there is a way to look in to *inf windows files of a dongle?
And there's a way to do it working under a linux system?

It's a plain text file, so that's of course possible. It's often wrapped in some automatic installer, though, and unpacking these on Linux is more hassle than I can handle It's easier to borrow a Windows PC, let the modem install its drivers there, and then look at the files it installed.

Are you the same Bjorn Mork of libmbim-devel mailing list?

Yup

[joe]

Yes, I did'nt black list any vendor specific interfaces in this case because we know (thanks to LOM) how windows driver defines each device interface, look at the following post:
http://www.draisberghof.de/usb_modeswit ... 733#p14733

Code: Select all

MI_00 Network Connect Mobile Broadband Device
MI_01 Network Connect Mobile Broadband Device 
MI_02 Network Connect HSPA Plus Modem
MI_03 Network Connect HSPA Plus Application Interface
MI_04 Network Connect HSPA Plus Speech Port
MI_05 Network Connect HSPA Plus Debug Port
MI_06 USB Mass Storage Device

And from usb-device launched on my system with option module rebuilt, we have:

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, option module now automatically binds all "0xff" Class interfaces that are all related to "HSPA+ Modem" features.
What do you think about?
Do we need to exclude some above Interfaces (Cls=0xff) to be buond by option module?
Or that features could be well managed by it?



PS. @Josh

Thanks for your explanation, I'll try to learn how all mechanism works...
I'll reply to your post as I understood.
Thanks again!

[Josh]

Thanks for your explanation, I'll try to learn how all mechanism works...

Just an additional clarification: the usb_modeswitch wrapper does not create the symlinks. All the wrapper does in this separate udev rule is to return either an empty string or a new name like "gsmmodemX" for the first port with an interrupt endpoint of a newly connected modem.

The link itself is then created by udevd if the usb_modeswitch wrapper call returns a non-empty name, using the PROGRAM/SYMLINK combo rule. See udev rule documentation like this one.

The good bit about the symlink being managed by udevd is that it will be automatically removed if the modem is disconnected.

Some background: there is a rule of thumb that of several serial ports provided by a wireless USB modems, the lowest one which includes an interrupt endpoint is the best bet to actually connect through. This is only useful when tools other than Network Manager are to be used for the connection, like wvdial or kppp.

There is no guarantee whatsoever that the port is indeed useable!

[joe]

usb_modeswitch.sh wrapper recalls usb_modeswitch dispatcher as follows:

Code: Select all

--symlink-name)
                device_in "link_list" $v_id $p_id
                if [ "$?" = "1" ]; then
                        if [ -e "/usr/sbin/usb_modeswitch_dispatcher" ]; then
                                exec usb_modeswitch_dispatcher $1 $2 2>>/dev/null
                        fi
                fi
                exit 0
                ;;

Could you explain the meaning of "usb_modeswitch_dispatcher $1 $2"

$1 seems to be "--symlink-name"
$2 seems to be our device path /dev/ttyUSB*

Is it right?

And an other question, what does dispatcher with those two arguments (I don't know where to find this info... pheraps dispatcher.c, but my C knowledge doesn't help at all... ) ???

Thanks in advance!
See you

[Josh]

$1 seems to be "--symlink-name"
$2 seems to be our device path /dev/ttyUSB*

Correct. Again, enable logging in "/etc/usb_modeswitch.conf" and you will see more clearly.

And an other question, what does dispatcher with those two arguments (I don't know where to find this info... pheraps dispatcher.c

No. If you look at /usr/sbin/usb_modeswitch_dispatcher, it's actually the Tcl script "usb_modeswitch.tcl", renamed.

You can open it in your favourite editor right away and jump to "proc {SymLinkName}". The name-finding part starts from the line that says:

Code: Select all

set symlinkName "gsmmodem"