| |
Activation Codes and Methods, Hardware Details, Sniffing
-
joe
- Posts: 31
- Joined: 14 Apr 2015, 14:43
Post
by joe » 14 Apr 2015, 15:07
Hi all!
I'm trying to make an internet usb dongle work.
The device is an Olivetti Olicard 300, which doesn't seems supported for using on Linux, as describes by specs reported on the Olivetti site:
http://www.olivetti.it/Tool/Product/Pan ... 639&idp=60
On this siteThere are some more infos about vendor etc... seems that "2020" vendor id is referred to Visiontek... Look for 2020:0002 and olicard 300 on that page...
Looking for a solution, I've exeprimented a "rude" empirical procedure that is working (even if with some issues with modem-manager: solved by killing its process):
- inserting usbkey it's recognized as 2020:0002 device: "Product MT6225", but it is seen as a "Zero-CD" "/dev/sr?"
- running "eject /dev/sr?" solves the switching problem and appear a new usbdevice recognized as 2020:4000
- at this point there aren't any kernel modules that automagically handle this device so searching on the web I've tried to manually load "usbserial"
- modprobe usbserial vendor=0x2020 product=0x4000
- serial device files /dev/ttyUSB0, USB1 and USB2 appears! And I was able to use /dev/ttyUSB0 as 3G modem, sending various AT commands to it and reading its answers (for example using minicom).
- at the end I'm able also to use a pppd/chat script (but I think also wvdial or other program like that work fine) to "call" my ISP and obtain a "ppp0" internet interface.
- end
But I'cant successfully automate all that procedure using udev rule and a bash script... something goes wrong and It's not a so clean solution.
So I've done a closer look to usb_modeswitch README to learn something more about its way to work.
I've also found a "Mass Message" that seems to work well also for my usb dongle switch as reported there:
http://www.draisberghof.de/usb_modeswit ... f=3&t=1487
So I've tried to automate the switching by using the "clean way": usb_modeswitch! 
I've add an entry in /lib/udev/40-usb_modeswich.rules, as well describes usbmodeswitch README and create a custom config file "/etc/usb_modeswitch.d/2020:0002".
Code: Select all $ grep -A10 Olicard_300 /lib/udev/rules.d/40-usb_modeswitch.rules
# Olivetti Olicard_300 - Tim-21.1 (made by MediaTek MT6225)
ATTRS{idVendor}=="2020", ATTRS{idProduct}=="0002", RUN+="usb_modeswitch '%b/%k'"
# the file is created automatically, PLEASE DO NOT MODIFY IT!!!
LABEL="modeswitch_rules_end"
Code: Select all $ cat /etc/usb_modeswitch.d/2020\:0002
# Olicard_300
DefaultVendor= 0x2020
DefaultProduct= 0x0002
MessageContent="555342430820298900000000000003f0010100000000000000000000000000"
After that, I've edited usb_modeswitch config to enable the logs...
Ok, now seems to work fine all the switch: the default device 2020:0002 is switched to 2020:4000. And I notice no need to stop modem-manager process as before.
I report /var/log/messages records appearing by plug the dongle in.
Code: Select all pr 14 11:14:39 darkstar kernel: [ 8699.339039] usb 1-4.1: new high-speed USB device number 19 using ehci_hcd
Apr 14 11:14:39 darkstar kernel: [ 8699.431654] usb 1-4.1: New USB device found, idVendor=2020, idProduct=0002
Apr 14 11:14:39 darkstar kernel: [ 8699.431658] usb 1-4.1: New USB device strings: Mfr=2, Product=3, SerialNumber=4
Apr 14 11:14:39 darkstar kernel: [ 8699.431661] usb 1-4.1: Product: MT6225
Apr 14 11:14:39 darkstar kernel: [ 8699.431663] usb 1-4.1: Manufacturer: Network Connect
Apr 14 11:14:39 darkstar kernel: [ 8699.431665] usb 1-4.1: SerialNumber: 531598307853860
Apr 14 11:14:39 darkstar kernel: [ 8699.432341] scsi19 : usb-storage 1-4.1:1.0
Apr 14 11:14:39 darkstar mtp-probe: checking bus 1, device 19: "/sys/devices/pci0000:00/0000:00:04.1/usb1/1-4/1-4.1"
Apr 14 11:14:39 darkstar mtp-probe: bus: 1, device: 19 was not an MTP device
Apr 14 11:14:39 darkstar logger: usb_modeswitch: using overriding config file /etc/usb_modeswitch.d/2020:0002; make sure this is intended
Apr 14 11:14:39 darkstar logger: usb_modeswitch: please report any new or corrected settings; otherwise, check for outdated files
Apr 14 11:14:39 darkstar usb_modeswitch: switching device 2020:0002 on 001/019
Apr 14 11:14:40 darkstar kernel: [ 8700.447156] usb 1-4.1: USB disconnect, device number 19
Apr 14 11:14:41 darkstar kernel: [ 8701.131039] usb 1-4.1: new high-speed USB device number 20 using ehci_hcd
Apr 14 11:14:41 darkstar kernel: [ 8701.225530] usb 1-4.1: New USB device found, idVendor=2020, idProduct=4000
Apr 14 11:14:41 darkstar kernel: [ 8701.225533] usb 1-4.1: New USB device strings: Mfr=9, Product=10, SerialNumber=0
Apr 14 11:14:41 darkstar kernel: [ 8701.225536] usb 1-4.1: Product: MT6225
Apr 14 11:14:41 darkstar kernel: [ 8701.225539] usb 1-4.1: Manufacturer: Network Connect
Apr 14 11:14:41 darkstar kernel: [ 8701.229784] scsi20 : usb-storage 1-4.1:1.6
Apr 14 11:14:41 darkstar mtp-probe: checking bus 1, device 20: "/sys/devices/pci0000:00/0000:00:04.1/usb1/1-4/1-4.1"
Apr 14 11:14:41 darkstar mtp-probe: bus: 1, device: 20 was not an MTP device
Apr 14 11:14:42 darkstar kernel: [ 8702.235177] scsi 20:0:0:0: Direct-Access UsbModem Storage Disk 6225 PQ: 0 ANSI: 0 CCS
Apr 14 11:14:42 darkstar kernel: [ 8702.252661] sd 20:0:0:0: [sdc] Attached SCSI removable disk
And now let's see what usb_modeswitch log reports...
Code: Select all
USB_ModeSwitch log from Tue Apr 14 11:06:14 CEST 2015
Raw args from udev: /1-4.4.2:1.0
Using global config file: /etc/usb_modeswitch.conf
Using top device dir /sys/bus/usb/devices/1-4.4.2
----------------
USB values from sysfs:
manufacturer Network Connect
product MT6225
serial 531598307853860
----------------
SCSI attributes not needed, moving on
checking config: /etc/usb_modeswitch.d/2020:0002
! matched. Reading config data
Using config file from override folder /etc/usb_modeswitch.d
Logger is /usr/bin/logger
Driver module is "option", ID path is /sys/bus/usb-serial/drivers/option1
Command to be run:
usb_modeswitch -I -W -D -s 20 -b 1 -g 17 -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)
--------------------------------
Reading long config from command line
* usb_modeswitch: handle USB devices with multiple modes
* Version 1.2.4 (C) Josua Dietze 2012
* Based on libusb0 (0.1.12 and above)
! PLEASE REPORT NEW CONFIGURATIONS !
DefaultVendor= 0x2020
DefaultProduct= 0x0002
TargetVendor= not set
TargetProduct= not set
TargetClass= not set
TargetProductList=""
DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
QisdaMode=0
GCTMode=0
KobilMode=0
SequansMode=0
MobileActionMode=0
CiscoMode=0
MessageEndpoint= not set
MessageContent="555342430820298900000000000003f0010100000000000000000000000000"
NeedResponse=0
ResponseEndpoint= not set
InquireDevice disabled
Success check enabled, max. wait time 20 seconds
System integration mode enabled
Use given bus/device number: 001/017 ...
Note: target parameter missing; success check limited
Looking for default devices ...
bus/device number matched
searching devices, found USB ID 2020:0002
found matching vendor ID
found matching product ID
adding device
Found device in default mode, class or configuration (1)
Getting the current device configuration ...
OK, got current device configuration (1)
Using interface number 0
Using 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 found; name unknown, limitation of libusb1
OK, driver "unkown" detached
Setting up communication with interface 0
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
OK, message successfully sent
Resetting response endpoint 0x81
Resetting message endpoint 0x01
Bus/dev search active, referring success check to wrapper. Bye.
ok:busdev
--------------------------------
(end of usb_modeswitch output)
Checking success of mode switch for max. 20 seconds ...
Waiting for device file system (1 sec.) ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Target config not matching - current values are
1-4.4.2:1.0/bInterfaceClass: 02
bConfigurationValue: 1
bNumConfigurations: 1
busnum: 1
devnum: 18
idProduct: 4000
idVendor: 2020
manufacturer: Network Connect
product: MT6225
serial:
Mode switching may have failed. Exiting
Ok, I don't know usb_modeswitch so well to understand what exactly happens, but I can easly report a missing on my system:
there aren't any serial device files named /dev/ttyUSB* as expected.
Seems the right kernel module the dongle IDs are to to be added was "option":
Code: Select all Driver module is "option", ID path is /sys/bus/usb-serial/drivers/option1
But peraphs at the end the device is not recognized as a "pure option compatible" one... and it is not automatically managed by the same "option" module.
We could "force" option module to manage olicard "2020:4000" device by running the following command:
Code: Select all Apr 14 12:20:19 darkstar kernel: [12639.790101] option 1-4.1:1.0: GSM modem (1-port) converter detected
Apr 14 12:20:19 darkstar kernel: [12639.790230] usb 1-4.1: GSM modem (1-port) converter now attached to ttyUSB0
Apr 14 12:20:19 darkstar kernel: [12639.790589] option 1-4.1:1.1: GSM modem (1-port) converter detected
Apr 14 12:20:19 darkstar kernel: [12639.790649] usb 1-4.1: GSM modem (1-port) converter now attached to ttyUSB1
Apr 14 12:20:19 darkstar kernel: [12639.791095] option 1-4.1:1.2: GSM modem (1-port) converter detected
Apr 14 12:20:19 darkstar kernel: [12639.791295] usb 1-4.1: GSM modem (1-port) converter now attached to ttyUSB2
Apr 14 12:20:19 darkstar kernel: [12639.791969] option 1-4.1:1.3: GSM modem (1-port) converter detected
Apr 14 12:20:19 darkstar kernel: [12639.792083] usb 1-4.1: GSM modem (1-port) converter now attached to ttyUSB3
Apr 14 12:20:19 darkstar kernel: [12639.792841] option 1-4.1:1.4: GSM modem (1-port) converter detected
Apr 14 12:20:19 darkstar kernel: [12639.792905] usb 1-4.1: GSM modem (1-port) converter now attached to ttyUSB4
Apr 14 12:20:19 darkstar kernel: [12639.793343] option 1-4.1:1.5: GSM modem (1-port) converter detected
Apr 14 12:20:19 darkstar kernel: [12639.793404] usb 1-4.1: GSM modem (1-port) converter now attached to ttyUSB5
Now, on my actual system this action creates (as reported above) all those /dev/ttyUSB* device files, but when I try to communicate for example with /dev/ttyUSB0 using minicom my shell crashes. Trying to send an AT "function" command to turn on all dongle functions, I obtain a write error, after a ctrl-c to reobtain my shell prompt:
Code: Select all # echo "AT+CFUN=1" >/dev/ttyUSB0
^C-su: echo: write error: Chiamata di sistema interrotta
Then I've tried to get back to usbserial generic driver and it seems to work better:
Code: Select all # lsmod|grep option
option 17551 0
usb_wwan 7662 1 option
usbserial 26300 2 usb_wwan,option
# modprobe -r option
# modprobe usbserial vendor=0x2020 product=0x4000
On /var/log/messages appears:
Code: Select all Apr 14 13:22:26 darkstar kernel: [16366.800353] option1 ttyUSB4: GSM modem (1-port) converter now disconnected from ttyUSB4
Apr 14 13:22:26 darkstar kernel: [16366.800369] option 1-4.1:1.4: device disconnected
Apr 14 13:22:26 darkstar kernel: [16366.800426] option1 ttyUSB3: GSM modem (1-port) converter now disconnected from ttyUSB3
Apr 14 13:22:26 darkstar kernel: [16366.800441] option 1-4.1:1.3: device disconnected
Apr 14 13:22:26 darkstar kernel: [16366.800562] option1 ttyUSB2: GSM modem (1-port) converter now disconnected from ttyUSB2
Apr 14 13:22:26 darkstar kernel: [16366.800577] option 1-4.1:1.2: device disconnected
Apr 14 13:22:26 darkstar kernel: [16366.800628] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
Apr 14 13:22:26 darkstar kernel: [16366.800642] option 1-4.1:1.1: device disconnected
Apr 14 13:22:26 darkstar kernel: [16366.800755] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
Apr 14 13:22:26 darkstar kernel: [16366.800769] option 1-4.1:1.0: device disconnected
Apr 14 13:22:26 darkstar kernel: [16366.800780] USB Serial deregistering driver GSM modem (1-port)
Apr 14 13:22:26 darkstar kernel: [16366.809006] usbcore: deregistering interface driver usbserial_generic
Apr 14 13:22:26 darkstar kernel: [16366.809019] USB Serial deregistering driver generic
Apr 14 13:22:26 darkstar kernel: [16366.809030] usbcore: deregistering interface driver usbserial
Apr 14 13:22:59 darkstar kernel: [16400.069555] usbcore: registered new interface driver usbserial
Apr 14 13:22:59 darkstar kernel: [16400.069569] USB Serial support registered for generic
Apr 14 13:22:59 darkstar kernel: [16400.069615] usbserial_generic 1-4.1:1.2: generic converter detected
Apr 14 13:22:59 darkstar kernel: [16400.069684] usb 1-4.1: generic converter now attached to ttyUSB0
Apr 14 13:22:59 darkstar kernel: [16400.069693] usbserial_generic 1-4.1:1.3: generic converter detected
Apr 14 13:22:59 darkstar kernel: [16400.069745] usb 1-4.1: generic converter now attached to ttyUSB1
Apr 14 13:22:59 darkstar kernel: [16400.069754] usbserial_generic 1-4.1:1.4: generic converter detected
Apr 14 13:22:59 darkstar kernel: [16400.069806] usb 1-4.1: generic converter now attached to ttyUSB2
Apr 14 13:22:59 darkstar kernel: [16400.069815] usbserial_generic 1-4.1:1.5: generic converter detected
Apr 14 13:22:59 darkstar kernel: [16400.069867] usb 1-4.1: generic converter now attached to ttyUSB3
Apr 14 13:22:59 darkstar kernel: [16400.069882] usbcore: registered new interface driver usbserial_generic
Apr 14 13:22:59 darkstar kernel: [16400.069884] usbserial: USB Serial Driver core
Ok, now /dev/ttyUSB0 seems to be usable as a modem, it regularly responds to AT commands and I'm able to use it for internet connection (I've tried with "pppd call olikey", where olikey is the name of pppd script I've put in /etc/ppp/peers).
As I said, the above reported behaviour is related to my actual system:
Code: Select all OS: Slackware-14.0
Kernel: 3.2.45-smp
usb_modeswitch version:
-----------------------
# usb_modeswitch --version
* usb_modeswitch: handle USB devices with multiple modes
* Version 1.2.4 (C) Josua Dietze 2012
* Based on libusb0 (0.1.12 and above)
! PLEASE REPORT NEW CONFIGURATIONS !
As you can see my system is a little too old, so I've tried to see what happens on a new, updated, Debian Jessie. I haven't now the kernel and usb_modeswitch version in use, cause I'm writing from the Slack, anyway reading from debian site:
seems that they using: 2.2.0 usb-modeswitch
and 3.16 linux kernel
Anyway on that new system after installation of modem-manager and usb_modeswitch:
- usb_modeswitch has new config entries and one reports my dongle vendor:product, so the switch is done out of the box, without any config editing needs.
- option module doesn't seems to be able to automatically take and manage the device.
- but if I manually load it and force it to mange the dongle (echo "2020 4000" > /sys/.../new_id), the "option" module of that kernel version seems to be able to manage fine the olicard-300: it makes /dev/ttyUSB* devices and I'm able to use /dev/ttyUSB0 as modem to connect to internet.
Now, I've a couple of questions to you.
Is there a way as cleaner as possible to automate the last step of that specific dongle managment?
usb_modeswitch does the switch, but I need also the modem device /dev/ttyUSB0 to be automatically created by the right kernel module.
I've done a look inside the "option.c" source. An idea could be to insert olicard300 IDs and rebuild/reinstall that module....
... But are we sure there isn't a better driver linux compatible to manage that olicard?
Pharaps also a third party driver to add as a firmware...
Or calling option (or usbserial) module from a udev rule would be the better choice?
Sorry for my very long post!!!
Anyway, hope you can help me...
Thanks in advance!
Last edited by joe on 15 Apr 2015, 12:08, edited 1 time in total.
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 14 Apr 2015, 16:00
joe wrote:
Now, I've a couple of questions to you.
Is there a way as cleaner as possible to automate the last step of that specific dongle managment?
usb_modeswitch does the switch, but I need also the modem device /dev/ttyUSB0 to be automatically created by the right kernel module.
I've done a look inside the "option.c" source. An idea could be to insert olicard300 IDs and rebuild/reinstall that module....
... But are we sure there isn't a better driver linux compatible to manage that olicard?
Pharaps also a third party driver to add as a firmware...
Or calling option (or usbserial) module from a udev rule would be the better choice?
usb_modeswitch will load the option driver (which is the right driver for ppp serial coms)
if it is able to detect a successful modeswitch.
If the usb id is not in option then usb_modeswitch will see that no driver bound to the interfaces and will instead load option driver using the new_id function.
For this to work you need to specify a TargetVendor and a TargetProduct in the device config file for 2020:0002 so that usb_modeswitch get to know what a successful switch is.
ttyUSB0 is probably not the correct modem device even if it works.
I don't have an interface listing for 2020:4000 but I have interface info from Windows driver pack which specifies the two first interfaces being for a direct ethernet connection.
Please give me the output from lsusb -v -d 2020:4000 so I can verify the interface usage.
-
joe
- Posts: 31
- Joined: 14 Apr 2015, 14:43
Post
by joe » 14 Apr 2015, 18:15
Thanks a lot for your quick answer!
Just a note:
now I'm connected to internet using the olicard300 with "usbserial" module and I'm writing from the old slackware system, so I'm not using "option" module, because the key did'nt work with that... as I explained in my post above.
I report the output of "lsusb -v" command:
Code: Select all Bus 001 Device 030: ID 2020:4000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x2020
idProduct 0x4000
bcdDevice 3.00
iManufacturer 9 Network Connect
iProduct 10 MT6225
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 228
bNumInterfaces 7
bConfigurationValue 1
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 1 COM(comm_if)
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 14
bInterfaceProtocol 0
iInterface 1 COM(comm_if)
CDC Header:
bcdCDC 1.10
CDC Union:
bMasterInterface 0
bSlaveInterface 1
UNRECOGNIZED CDC: 0c 24 1b 00 01 00 02 10 40 dc 05 20
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 2
iInterface 2 COM(data_if)
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 2
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 2
bInterfaceProtocol 1
iInterface 3 COM(comm_if)
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 04 24 02 0f
** UNRECOGNIZED: 05 24 06 02 03
** UNRECOGNIZED: 05 24 01 03 03
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 3
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 5 COM(data_if)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 6 COM(data_if)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 7 COM(data_if)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 6
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 8 6225--Storage
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0002
(Bus Powered)
Remote Wakeup Enabled
Hope this help!
Please I'm glad if you could explain which are the interesting parts of this output...
PS: direct ethernet connection? how it works? Is this specific dongle support that feature?
If the usb id is not in option then usb_modeswitch will see that no driver bound to the interfaces and will instead load option driver using the new_id function.
For this to work you need to specify a TargetVendor and a TargetProduct in the device config file for 2020:0002 so that usb_modeswitch get to know what a successful switch is.
As regards the usb_modeswitch config file that I written for 2020:4000, well, you has been very clear, I'll add two new lines suggested and let you know how it works.
Many thanks again!
See you!
-
joe
- Posts: 31
- Joined: 14 Apr 2015, 14:43
Post
by joe » 14 Apr 2015, 18:47
Ok, this is the new config file followed by usb_modeswitch log:
Code: Select all # Olicard_300
DefaultVendor = 0x2020
DefaultProduct = 0x0002
TargetVendor = 0x2020
TargetProduct = 0x4000
MessageContent = "555342430820298900000000000003f0010100000000000000000000000000"
Code: Select all
USB_ModeSwitch log from Tue Apr 14 18:30:45 CEST 2015
Raw args from udev: /1-4.1:1.0
Using global config file: /etc/usb_modeswitch.conf
Using top device dir /sys/bus/usb/devices/1-4.1
----------------
USB values from sysfs:
manufacturer Network Connect
product MT6225
serial 531598307853860
----------------
SCSI attributes not needed, moving on
checking config: /etc/usb_modeswitch.d/2020:0002
! matched. Reading config data
Using config file from override folder /etc/usb_modeswitch.d
Logger is /usr/bin/logger
config: TargetVendor set to 2020
config: TargetProduct set to 4000
Driver module is "option", ID path is /sys/bus/usb-serial/drivers/option1
Command to be run:
usb_modeswitch -I -W -D -s 20 -b 1 -g 33 -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)
--------------------------------
Reading long config from command line
* usb_modeswitch: handle USB devices with multiple modes
* Version 1.2.4 (C) Josua Dietze 2012
* Based on libusb0 (0.1.12 and above)
! PLEASE REPORT NEW CONFIGURATIONS !
DefaultVendor= 0x2020
DefaultProduct= 0x0002
TargetVendor= 0x2020
TargetProduct= 0x4000
TargetClass= not set
TargetProductList=""
DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
QisdaMode=0
GCTMode=0
KobilMode=0
SequansMode=0
MobileActionMode=0
CiscoMode=0
MessageEndpoint= not set
MessageContent="555342430820298900000000000003f0010100000000000000000000000000"
NeedResponse=0
ResponseEndpoint= not set
InquireDevice disabled
Success check enabled, max. wait time 20 seconds
System integration mode enabled
Use given bus/device number: 001/033 ...
Looking for default devices ...
bus/device number matched
searching devices, found USB ID 2020:0002
found matching vendor ID
found matching product ID
adding device
Found device in default mode, class or configuration (1)
Getting the current device configuration ...
OK, got current device configuration (1)
Using interface number 0
Using 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 found; name unknown, limitation of libusb1
OK, driver "unkown" detached
Setting up communication with interface 0
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
OK, message successfully sent
Resetting response endpoint 0x81
Resetting message endpoint 0x01
Bus/dev search active, referring success check to wrapper. Bye.
ok:busdev
--------------------------------
(end of usb_modeswitch output)
Checking success of mode switch for max. 20 seconds ...
Waiting for device file system (1 sec.) ...
Reading attributes ...
All attributes matched
Mode switching was successful, found 2020:4000 (Network Connect: MT6225)
No vendor-specific class found, skip driver checking
Checking for AVOID_RESET_QUIRK kernel attribute
AVOID_RESET_QUIRK activated
All done, exiting
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 15 Apr 2015, 03:02
You should really avoid using the usbserial driver, it is a driver intended for experimental use on low-speed devices and it will, when forced to bind, bind to all interfaces of a device - not only the serial interfaces.
You will then get ttyUSB devices in linux for interfaces which does not speak a serial protocol.
The option driver has provision for white or black listing device interfaces when the usb id is included in the driver but this white/black listing is lost if one uses the new_id function for adding temporary option driver support for a device.
option will in such case bind to any interface except those with storage class attributes.
joe wrote:
Please I'm glad if you could explain which are the interesting parts of this output...
PS: direct ethernet connection? how it works? Is this specific dongle support that feature?
Here is the info I had before for this dongle:
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
It indicates that interface #0 (MI_00) could be a direct ethernet interface.
Your lsusb listing shows the Class, Subclass, and Protocol attributes of interface #0 to be 2,14,0 which are the attributes for cdc_mbim, interface #0 is used for the cmd protocol and interface #1 is the data interface.
Direct ethernet means that there is no dialup, the cdc_mbim driver (present in linux kernel 3.6 and higher) will create an eth type device in the system.
Your dmesg log shows that interface 0-5 creates ttyUSB0..ttyUSB5 when you loaded the option driver and you ought to get the same number of ttyUSB devices if you use the usbserial driver.
ttyUSB2 should therefore be the right device to use for ppp dialup with ttyUSB3 being the extra user interface for AT cmds after a ppp connection is established, I am a bit surprised that you were able to establish a dialup ppp connection on an interface not intended for dialup.
The shell crash you mentioned may have been caused by you using wrong ttyUSB device..
I see from your latest post that usb_modeswitch failed to load the option driver, that happened because interface #0 did not have attributes indicating a serial protocol.
You can easily add a udev rule for 2020:4000 to load it.
-
joe
- Posts: 31
- Joined: 14 Apr 2015, 14:43
Post
by joe » 15 Apr 2015, 12:51
Hi!
First of all, after re-testing serial device /dev/ttyUSB* with AT commands, I can confirm what you said about the five "interfaces" generated at option module loading.
For modem use I can regularly communicate with "ttyUSB2" and use it for PPP dial-up connection.
In my first post I've said:
As you can see my system is a little too old, so I've tried to see what happens on a new, updated, Debian Jessie. I haven't now the kernel and usb_modeswitch version in use, cause I'm writing from the Slack, anyway reading from debian site:
seems that they using: 2.2.0 usb-modeswitch
and 3.16 linux kernel
Anyway on that new system after installation of modem-manager and usb_modeswitch:
- usb_modeswitch has new config entries and one reports my dongle vendor:product, so the switch is done out of the box, without any config editing needs.
- option module doesn't seems to be able to automatically take and manage the device.
- but if I manually load it and force it to mange the dongle (echo "2020 4000" > /sys/.../new_id), the "option" module of that kernel version seems to be able to manage fine the olicard-300: it makes /dev/ttyUSB* devices and I'm able to use /dev/ttyUSB0 as modem to connect to internet.
Well the last sentence isn't true: /dev/ttyUSB0 is not a modem!!!
I was my mistake... I've counfused "usbserial" module with "option" one. I'll try to re-test the behaviour on Debian Jessie, but pheraps (if I well remember) on that system, adding "2020 4000" to "new_id" don't generate ttyUSB0 and USB1 at all... So I've probably configured ppp script to use the first ttyUSB I found, that is /dev/ttyUSB2..
And It worked fine...
In conclusion:
- option module can manage the Olicard-300 forcing add of IDs to /sys/bus/usb-serial/.../new_id.
- the right "port" for modem use (PPP dial-up) is the third interface: /dev/ttyUSB2
Ok, in a next post I'll ask something more about your infos and how to take advantage of other features of this dongle.
For now, thanks a lot!
Your support is very useful to understand how theese devices work!
See you!
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 15 Apr 2015, 13:54
joe wrote: Debian Jessie, but pheraps (if I well remember) on that system, adding "2020 4000" to "new_id" don't generate ttyUSB0 and USB1 at all...
option driver must be loaded before you can use its new_id function, ie
modprobe option
echo "2020 4000" > /sys/bus/usb-serial/drivers/option1/new_id.
-
joe
- Posts: 31
- Joined: 14 Apr 2015, 14:43
Post
by joe » 15 Apr 2015, 17:29
Yes that is clear!
I'll do an other test on Jessie as soon as possible and report what exactly happens and how many "ttyUSB*" (and which exactly) are created.
Anyway I'm interseted in learning something more by your infos.
1) Can you explain me where did you obtain this report?
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
2) Direct Ethernet Interface (interesting approach to internet connection on mobile broadband)
Direct ethernet means that there is no dialup, the cdc_mbim driver (present in linux kernel 3.6 and higher) will create an eth device in the system.
Ok, I've yet tried to make this dongle works with libmbim under Debian Jessie (recente kernel) for test this feature... But without success.
I have an other USB dongle (more linux friendly), a Huawei E353... That should be working also with "libqmi" (cdc-qmi).
On that recent system when I plug theese dongles appear a new interface called "wwan0".
But with mbimcli or qmicli tools I wasn't able to establish a succesfull communication... returned error If I well remember was
But for Huawei dongle there is one more chance, it support ^NDIS at command:
Code: Select all echo 'AT^NDISDUP=1,1,"my.isp.apn\r\n' > /dev/ttyUSB0
At that point just launch:
...and a few "ip route" commands to use that interface to internet without dial up PPP connection.
Unfortunately on my slack I'm using a too old kernel version now, so I can't test that feature... I could try to build up a new kernel... But before that I have to look around for any issues using a so new kernel on an "old" system like mine.
I see from your latest post that usb_modeswitch failed to load the option driver, that happened because interface #0 did not have attributes indicating a serial protocol.
You can easily add a udev rule for 2020:4000 to load it.
Uhmmm...
So there's no way to avoid to call udev help...
Can you suggest a udev rule example working for this dongle?
Your dmesg log shows that interface 0-5 creates ttyUSB0..ttyUSB5 when you loaded the option driver and you ought to get the same number of ttyUSB devices if you use the usbserial driver.
Using usbserial driver I've less ttyUSB files. And I'm also able to comunicate over USB0 as modem... Take a look:
Code: Select all [root@darkstar ~]# ppp-off
PPP link to [ppp0] terminated.
Demand Dialing Stoped.
[root@darkstar ~]# modprobe -r option
[root@darkstar ~]# ls /dev/ttyU*
/bin/ls: impossibile accedere a /dev/ttyU*: File o directory non esistente
[root@darkstar ~]# modprobe usbserial vendor=0x2020 product=0x4000
[root@darkstar ~]# ls /dev/ttyU*
/dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2 /dev/ttyUSB3
[root@darkstar ~]# screen /dev/ttyUSB0
OK
MTK2
MOLY.WR8.W1244.DNR.WG.MP.V7
OK
+CGDCONT: 1, "IP", "ibox.tim.it", "0.0.0.0", 0, 0, 0
+CGDCONT: 2, "IP", "internet", "0.0.0.0", 0, 0, 0
+CGDCONT: 3, "IP", "internet", "0.0.0.0", 0, 0, 0
+CGDCONT: 4, "IP", "internet", "0.0.0.0", 0, 0, 0
+CGDCONT: 5, "IP", "internet", "0.0.0.0", 0, 0, 0
+CGDCONT: 6, "IP", "internet", "0.0.0.0", 0, 0, 0
OK
OK
+CGDCONT: 1, "IP", "ibox.tim.it", "0.0.0.0", 0, 0, 0
+CGDCONT: 2, "IPV6", "ibox.tim.it", "0.0.0.0", 0, 0, 0
+CGDCONT: 3, "IP", "internet", "0.0.0.0", 0, 0, 0
+CGDCONT: 4, "IP", "internet", "0.0.0.0", 0, 0, 0
+CGDCONT: 5, "IP", "internet", "0.0.0.0", 0, 0, 0
+CGDCONT: 6, "IP", "internet", "0.0.0.0", 0, 0, 0
OK
CONNECT 21000000
~�}#�!}!}!} }2}"}&} }*} } }#}$�#}'}"}(}"U�~~�}#�!}!}!} }2}"}&} }*} } }#}$�#}'}"}(}"U�~~�}#�!}!}!} }2}"}&} }*} } }#}$�#}'}"}(}"U�~~�}#�!}!}!} }2}"}&} }*} } }#}$�#}'}"}(}"U�~~�}#�!}!}!} }2}"}&} }*} } }#}$�#}'}"}(}"U�~~�}#�!}!}!} }2}"}&} }*} } }#}$�#}'}"}(}"U�~~�}#�!}!}!} }2}"}&} }*} } }#}$�#}'}"}(}"U�~~�}#�!}!}!} }2}"}&} }*} } }#}$�#}'}"}(}"U�~~�}#�!}!}!} }2}"}&} }*} } }#}$�#}'}"}(}"U�~
[detached]
[root@darkstar ~]# pppd /dev/ttyUSB0
[root@darkstar ~]# tailf /var/log/messages
Apr 15 17:00:13 darkstar modem-manager[2393]: <info> (ttyUSB3) closing serial port...
Apr 15 17:00:13 darkstar modem-manager[2393]: <info> (ttyUSB3) serial port closed
Apr 15 17:00:13 darkstar modem-manager[2393]: <info> (ttyUSB1) closing serial port...
Apr 15 17:00:13 darkstar modem-manager[2393]: <info> (ttyUSB1) serial port closed
Apr 15 17:02:47 darkstar pppd[21712]: pppd 2.4.5 started by root, uid 0
Apr 15 17:02:47 darkstar pppd[21712]: Using interface ppp0
Apr 15 17:02:47 darkstar pppd[21712]: Connect: ppp0 <--> /dev/ttyUSB0
Apr 15 17:02:48 darkstar pppd[21712]: PAP authentication succeeded
Apr 15 17:02:51 darkstar pppd[21712]: local IP address 10.187.xxx.xxx
Apr 15 17:02:51 darkstar pppd[21712]: remote IP address 10.64.64.64
Ok, my seems AT sended commands are not visible... on screen but you can view "USB0" responses.
And the PPP session successfully estabilished with mi ISP.
So USB4 and USB5 are missed...
Or pheraps usbserial can't manage direct ethernet devices so its USB0 is the same of the "old" USB2 when I was using option module...
Pheraps that's why usbserial-USB0 works as a modem while option-USB0 not... I' dont' know...
-
joe
- Posts: 31
- Joined: 14 Apr 2015, 14:43
Post
by joe » 16 Apr 2015, 15:16
Just a quick update about a UDEV rule I written:
Code: Select all # cat 89-olicard-option-driver.rules
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2020", ATTRS{idProduct}=="4000", ATTRS{manufacturer}=="Network Connect", ATTRS{product}=="MT6225 ", RUN+="/bin/sh -c '/sbin/modprobe option && /usr/bin/echo 2020\ 4000 > /sys/bus/usb-serial/drivers/option1/new_id'"
With that solution, invoking /bin/sh within the rule, we don't need any script located in /usr/local/bin or somwhere else... I think this is a better choice.
I' had some trouble with the space between vendor and product IDs: "echo" wasn't agree to print them on "new_id" file!!!
After tried many variants like:
Code: Select all /bin/sh -c '/sbin/modprobe option && /usr/bin/echo \'2020\ 4000\\' > /sys/bus/usb-serial/drivers/option1/new_id'
Code: Select all /bin/sh -c '/sbin/modprobe option && /usr/bin/echo "2020 4000" > /sys/bus/usb-serial/drivers/option1/new_id'
And so on...
Finally I've found the above string that appears to be working well.
Hope this could help anyone looking for info about this "not so linux-friendly" device...
I'll stay tune to read yours other answers about my prevoius post questions..
(expecially about using direct ethernet interfaces, I've downloaded yet a "brend new" kernel)
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 17 Apr 2015, 15:06
joe wrote:
1) Can you explain me where did you obtain this report?
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
It is Windows verbose description of the interfaces and is taken from the windows driver pack for the dongle.
joe wrote:
2) Direct Ethernet Interface (interesting approach to internet connection on mobile broadband)
Direct ethernet means that there is no dialup, the cdc_mbim driver (present in linux kernel 3.6 and higher) will create an eth device in the system.
Ok, I've yet tried to make this dongle works with libmbim under Debian Jessie (recente kernel) for test this feature... But without success.
I have an other USB dongle (more linux friendly), a Huawei E353... That should be working also with "libqmi" (cdc-qmi).
On that recent system when I plug theese dongles appear a new interface called "wwan0".
But with mbimcli or qmicli tools I wasn't able to establish a succesfull communication... returned error If I well remember was
wwan0 is an eth type of device and that is what you will get with cdc_mbim as well.
The transport protocol of mbim is ncm so you'll need the usbnet driver and cdc_ncm being loaded before cdc_mbim and you also need the cdc-wdm driver which cdc_mbim needs for the cmd channel.
Your dmsg log should show something like:
[ 3484.414442] usbcore: registered new interface driver cdc_ncm
[ 3484.425132] usbcore: registered new interface driver cdc_wdm
[ 3484.448356] cdc_mbim 3-5:2.0: cdc-wdm0: USB WDM device
[ 3484.448479] cdc_mbim 3-5:2.0 wwan0: register 'cdc_mbim' at usb-0000:00:14.0-5, CDC MBIM, f2:67:ba:10:01:f6
libmbim + NetWorkManager are the final parts for establishing a connection or you can do it from the cmd line with mbimcli.
joe wrote:
Using usbserial driver I've less ttyUSB files. And I'm also able to comunicate over USB0 as modem... Take a look:
Seems that usbserial doesn't bind to the 2 first non-serial interfaces, you can easily find out that by consulting your dmsg log.
The part below shows interface #2 creating ttyUSB0.
Apr 14 13:22:59 darkstar kernel: [16400.069615] usbserial_generic 1-4.1:1.2: generic converter detected
Apr 14 13:22:59 darkstar kernel: [16400.069684] usb 1-4.1: generic converter now attached to ttyUSB0
-
joe
- Posts: 31
- Joined: 14 Apr 2015, 14:43
Post
by joe » 20 Apr 2015, 18:50
I've tried an other solution for testing purposes of all Olicard features, included direct ethernet broadband connection.
As I explained above, my actual system is too old and doesn't support thees new features: we need cdc-mbim module to manage the dongle...
So I've decided to upgrade my kernel to a newer version "linux-3.19.4": I configured, compiled from sources and installed it on my system.
My old usb_modeswitch (version 1.2.4) didn't seem to be able in manage the dongle, and the switch hasn't succeded anymore at plugin time.
Why...??
I didn't exactly understand why... but I can read strange lines from the log:
Code: Select all *** glibc detected *** usb_modeswitch_dispatcher: double free or corruption (!prev): 0x09389860 ***
======= Backtrace: =========
/lib/libc.so.6(+0x78027)[0xb7625027]
usb_modeswitch_dispatcher[0x805df89]
[...]
I think this is a issue related in some way to the new kernel, while usb-modeswitch in use was compiled against a very older kernel version.
But I really don't know if could be right or not...
So I've decided to upgrade also my usb-modeswitch package to 2.2.1.
Some instructions for Slackware users:
- I've downloaded all neede files from the usb_modeswich site... this site!
Code: Select all device_reference.txt
usb-modeswitch-2.2.1.tar.bz2
usb-modeswitch-data-20150115.tar.bz2
- Downloaded also the "build" directory from slackawre-current tree:
lftp -c 'open http://mirrors.slackware.com/slackware/ ... /source/a/; mirror usb_modeswitch'
Then substitute the corresponding files with the above new ones.
Code: Select all # ls /root/build/usb_modeswitch/
device_reference.txt.gz doinst.sh.gz slack-desc usb-modeswitch-2.2.1.tar.bz2 usb-modeswitch-data-20150115.tar.bz2 usb_modeswitch.SlackBuild*
"device_reference" file has to be gzipped cause SlackBuild is written to use the file name "device_reference.txt.gz".
Now, we need to edit the Pat. Volkerding "SlackBuild", I've just edited the version top lines:
Code: Select all PKGNAM=usb_modeswitch
VERSION=${VERSION:-2.2.1}
DATAVER=${DATAVER:-20150115}
And finally, enter in the build directory and launch:
Code: Select all # chmod +x *SlackBuild
# ./usb_modeswitch.Slackbuild
We'll find a brand new slackware package in "/tmp" to install (after remove the old one... or using "upgradepkg")
Code: Select all installpkg /tmp/usb_modeswitch-2.2.1-i486-1.txz
I've also removed my config file /etc/usb/modeswitch.d/2020:0002, because this device is now part of /usr/share/usb_modeswitch database...
Code: Select all # cat /usr/share/usb_modeswitch/2020\:0002
# Mediatek MT6225, MT6229, Micromax MMX 377G
TargetVendor=0x2020
TargetProductList="2000,4010,4000"
MessageContent="555342430820298900000000000003f0010100000000000000000000000000"
I've edited the commented line above, adding "MT6225" Mediatek product.
And add the "4000" product ID to the "TargetProductList" entry.
The same commented line editing for the follow usb_modeswitch udev rules:
Code: Select all # grep -B1 "2020.*0002" /lib/udev/rules.d/40-usb_modeswitch.rules
# Mediatek MT6225, MT6229, Micromax MMX 377G
ATTR{idVendor}=="2020", ATTR{idProduct}=="0002", RUN+="usb_modeswitch '%b/%k'"
I've also renamed my udev rule to 89-olicard-option-driver.rules.disabled (and then run "udevadm control --reload") to test if the switch and the module load is now automatic out of the box.
Code: Select all # cat /etc/udev/rules.d/89-olicard-option-driver.rules.disabled
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2020", ATTRS{idProduct}=="4000", ATTRS{manufacturer}=="Network Connect", ATTRS{product}=="MT6225 ", RUN+="/bin/sh -c '/sbin/modprobe option && /usr/bin/echo 2020\ 4000 > /sys/bus/usb-serial/drivers/option1/new_id'"
Now let's take a look at the next post... This one is already too long... and see what happens when I plug the dongle in....
-
joe
- Posts: 31
- Joined: 14 Apr 2015, 14:43
Post
by joe » 20 Apr 2015, 19:02
1- If neither option nor cdc-mbim module are already loaded:
Code: Select all [root@darkstar ~]# lsmod |grep "option\|cdc"
[root@darkstar ~]#
Let's plug the dongle in....
a) /var/log/messages:
Code: Select all Apr 20 18:03:52 darkstar kernel: [28162.221000] usb 2-4.1: new high-speed USB device number 32 using ehci-pci
Apr 20 18:03:52 darkstar kernel: [28162.312623] usb 2-4.1: New USB device found, idVendor=2020, idProduct=0002
Apr 20 18:03:52 darkstar kernel: [28162.312627] usb 2-4.1: New USB device strings: Mfr=2, Product=3, SerialNumber=4
Apr 20 18:03:52 darkstar kernel: [28162.312630] usb 2-4.1: Product: MT6225
Apr 20 18:03:52 darkstar kernel: [28162.312633] usb 2-4.1: Manufacturer: Network Connect
Apr 20 18:03:52 darkstar kernel: [28162.312635] usb 2-4.1: SerialNumber: 531598307853860
Apr 20 18:03:52 darkstar kernel: [28162.313363] usb-storage 2-4.1:1.0: USB Mass Storage device detected
Apr 20 18:03:52 darkstar kernel: [28162.317058] scsi host35: usb-storage 2-4.1:1.0
Apr 20 18:03:52 darkstar mtp-probe: checking bus 2, device 32: "/sys/devices/pci0000:00/0000:00:04.1/usb2/2-4/2-4.1"
Apr 20 18:03:52 darkstar mtp-probe: bus: 2, device: 32 was not an MTP device
Apr 20 18:03:52 darkstar usb_modeswitch: switch device 2020:0002 on 002/032
Apr 20 18:03:53 darkstar kernel: [28163.321127] usb 2-4.1: USB disconnect, device number 32
Apr 20 18:03:53 darkstar kernel: [28164.012007] usb 2-4.1: new high-speed USB device number 33 using ehci-pci
Apr 20 18:03:53 darkstar kernel: [28164.105500] usb 2-4.1: New USB device found, idVendor=2020, idProduct=4000
Apr 20 18:03:53 darkstar kernel: [28164.105506] usb 2-4.1: New USB device strings: Mfr=9, Product=10, SerialNumber=0
Apr 20 18:03:53 darkstar kernel: [28164.105509] usb 2-4.1: Product: MT6225
Apr 20 18:03:53 darkstar kernel: [28164.105512] usb 2-4.1: Manufacturer: Network Connect
Apr 20 18:03:53 darkstar kernel: [28164.109777] usb-storage 2-4.1:1.6: USB Mass Storage device detected
Apr 20 18:03:53 darkstar kernel: [28164.109844] scsi host36: usb-storage 2-4.1:1.6
Apr 20 18:03:53 darkstar mtp-probe: checking bus 2, device 33: "/sys/devices/pci0000:00/0000:00:04.1/usb2/2-4/2-4.1"
Apr 20 18:03:53 darkstar mtp-probe: bus: 2, device: 33 was not an MTP device
Apr 20 18:03:53 darkstar kernel: [28164.119482] usbcore: registered new interface driver cdc_ncm
Apr 20 18:03:53 darkstar kernel: [28164.119704] usbcore: registered new interface driver cdc_wdm
Apr 20 18:03:53 darkstar kernel: [28164.123349] cdc_mbim 2-4.1:1.0: cdc-wdm0: USB WDM device
Apr 20 18:03:53 darkstar kernel: [28164.123603] cdc_mbim 2-4.1:1.0 wwan0: register 'cdc_mbim' at usb-0000:00:04.1-4.1, CDC MBIM, e6:77:fd:86:dc:d1
Apr 20 18:03:53 darkstar kernel: [28164.123631] usbcore: registered new interface driver cdc_mbim
Apr 20 18:03:54 darkstar logger: usb_modeswitch: switched to 2020:4000 on 002/033
Apr 20 18:03:54 darkstar kernel: [28165.115147] scsi 36:0:0:0: Direct-Access UsbModem Storage Disk 6225 PQ: 0 ANSI: 0 CCS
Apr 20 18:03:54 darkstar kernel: [28165.133761] sd 36:0:0:0: [sdc] Attached SCSI removable disk
b) dmesg
Code: Select all [28162.221000] usb 2-4.1: new high-speed USB device number 32 using ehci-pci
[28162.312623] usb 2-4.1: New USB device found, idVendor=2020, idProduct=0002
[28162.312627] usb 2-4.1: New USB device strings: Mfr=2, Product=3, SerialNumber=4
[28162.312630] usb 2-4.1: Product: MT6225
[28162.312633] usb 2-4.1: Manufacturer: Network Connect
[28162.312635] usb 2-4.1: SerialNumber: 531598307853860
[28162.313363] usb-storage 2-4.1:1.0: USB Mass Storage device detected
[28162.317058] scsi host35: usb-storage 2-4.1:1.0
[28163.321127] usb 2-4.1: USB disconnect, device number 32
[28164.012007] usb 2-4.1: new high-speed USB device number 33 using ehci-pci
[28164.105500] usb 2-4.1: New USB device found, idVendor=2020, idProduct=4000
[28164.105506] usb 2-4.1: New USB device strings: Mfr=9, Product=10, SerialNumber=0
[28164.105509] usb 2-4.1: Product: MT6225
[28164.105512] usb 2-4.1: Manufacturer: Network Connect
[28164.109777] usb-storage 2-4.1:1.6: USB Mass Storage device detected
[28164.109844] scsi host36: usb-storage 2-4.1:1.6
[28164.119482] usbcore: registered new interface driver cdc_ncm
[28164.119704] usbcore: registered new interface driver cdc_wdm
[28164.123349] cdc_mbim 2-4.1:1.0: cdc-wdm0: USB WDM device
[28164.123603] cdc_mbim 2-4.1:1.0 wwan0: register 'cdc_mbim' at usb-0000:00:04.1-4.1, CDC MBIM, e6:77:fd:86:dc:d1
[28164.123631] usbcore: registered new interface driver cdc_mbim
[28165.115147] scsi 36:0:0:0: Direct-Access UsbModem Storage Disk 6225 PQ: 0 ANSI: 0 CCS
[28165.130380] sd 36:0:0:0: [sdc] Test WP failed, assume Write Enabled
[28165.132380] sd 36:0:0:0: [sdc] Asking for cache data failed
[28165.132383] sd 36:0:0:0: [sdc] Assuming drive cache: write through
[28165.133761] sd 36:0:0:0: [sdc] Attached SCSI removable disk
c) usb-devices (I've found the following usefull usb-devices command that returns which module is managing each interface) we have:
Code: Select all T: Bus=02 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 33 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=(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
d) lsmod
Code: Select all # lsmod |grep "option\|cdc"
cdc_mbim 4261 0
cdc_wdm 8395 1 cdc_mbim
cdc_ncm 13229 1 cdc_mbim
usbnet 17727 2 cdc_mbim,cdc_ncm
No "option" module is been atuomatically loaded, just cdc_mbim.
So the goal is to find a way to load option module and link it only to specific interfaces (but the right ones: "If #2", #3, #4, #5).
I've tried to activate my udev rule to load option, but with that activated, option takes all interfaces, also the first two... and cdc_mbim is not loaded at all... likely because #0 and #1 are already under "option" control:
Code: Select all T: Bus=02 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 25 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=option
I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=option
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
Finally I've tried to manually load option module after cdc_mbim was linked to the first two interface of the device:
Code: Select all T: Bus=02 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 21 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
This last one is our goal I think...
If the dongle is recognized in that way, we are able to use it as a serial modem or a serial device to sent/receive SMS.. also a storage device and a Direct Ethernet Broadband device.
As I said, I need to automate the above procedure:
- manual plugin
- load cdc_mbim
- link it to first two interface of dongle device
- load option
- link it to the 3d, 4th, 5, 6 interfaces
I report also the same "usb-device" output after plugin my other dongle the Huawei E353:
Code: Select all T: Bus=02 Lev=02 Prnt=04 Port=00 Cnt=01 Dev#= 35 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=qmi_wwan
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=qmi_wwan
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
No other actions are needed. "option" takes care of the right "interfaces", for the rest qmi_wwan and usb_storage are automatically loaded..
Any suggestions to obtain the same for the Olicard-300?
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 21 Apr 2015, 04:23
joe wrote:
No other actions are needed. "option" takes care of the right "interfaces", for the rest qmi_wwan and usb_storage are automatically loaded..
This is due to white listing in the option driver, based on usb vendor id and interface attributes.
You will only be able to use options white/black listing of interfaces if the device is supported in the option driver, the new_id function with on-the-fly support has no info about which interfaces it should and should not bind to.
joe wrote:
Any suggestions to obtain the same for the Olicard-300?
Add it to the option driver source, re-compile option.
Submit the patch to linux usb maintainers so that other users don't have to struggle with it.
or
give cdc_mbim time to bind before you load option with new_id.
option will not be able to bind to interfaces which already are taken by another driver.
-
joe
- Posts: 31
- Joined: 14 Apr 2015, 14:43
Post
by joe » 21 Apr 2015, 11:48
This is due to white listing in the option driver, based on usb vendor id and interface attributes.
You will only be able to use options white/black listing of interfaces if the device is supported in the option driver, the new_id function with on-the-fly support has no info about which interfaces it should and should not bind to.
I understand... but if it works in that way...
...Why the Huawei E353 dongle (12d1:1446 before the switch - 12d1:1506 after the switch) is well managed out of the box?
It doen't seem to be present in option.c source code....
Look at this part of the option source code, there are few Huawei devices, and there's no sign of "1506" id nor "1446"...
Code: Select all * Vendor and product IDs */
#define OPTION_VENDOR_ID 0x0AF0
#define OPTION_PRODUCT_COLT 0x5000
[...]
#define HUAWEI_VENDOR_ID 0x12D1
#define HUAWEI_PRODUCT_E173 0x140C
#define HUAWEI_PRODUCT_E1750 0x1406
#define HUAWEI_PRODUCT_K4505 0x1464
#define HUAWEI_PRODUCT_K3765 0x1465
#define HUAWEI_PRODUCT_K4605 0x14C6
#define HUAWEI_PRODUCT_E173S6 0x1C07
#define QUANTA_VENDOR_ID 0x0408
[...]
Add it to the option driver source, re-compile option.
I'd like to do it... Even if I'm not an expert nor kernel hacking guru 
Can you explain how to recompile only the option module? Also a link to a quick doc that explains that procedure could be enought...I never done it before, so I need to read a quick tutorial.
Thanks again for your support!
-
joe
- Posts: 31
- Joined: 14 Apr 2015, 14:43
Post
by joe » 22 Apr 2015, 10:22
I've done...
I've modify the option.c module source.
Then I've rebuild kernel modules and finally reinstall.
Now, when I plug Olicard-300 in, all interfaces are managed by proper driver. Here what usb-devices returns:
Code: Select all T: Bus=02 Lev=02 Prnt=04 Port=00 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=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
I'll post all details of procedure I've followed as soon as possible...
Stay tune!
|
|
