USB_ModeSwitch

Hi there,

Got an olivetti olicard100 device. I somewhere found a note/cmd output telling something about Qualcomm:
QUALCOMM INC.
Revision: 090507_GKPEFPMX_M0.05

The modem does only work once every replug cycle. It's virtually impossible using it w/ linux. Win's working ok.

Might it be that win drivers are setting something magically up? But then, there's the option driver precompiled in the deb package on the zerocd..

uname -a
Linux mypole 2.6.33.2 #15 SMP PREEMPT Wed Apr 28 12:53:16 CEST 2010 i686 GNU/Linux

[151917.718098] usb 1-3: new high speed USB device using ehci_hcd and address 62
[151917.846365] usb 1-3: New USB device found, idVendor=0b3c, idProduct=c700
[151917.846374] usb 1-3: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[151917.846381] usb 1-3: Product: DataCard Device
[151917.846387] usb 1-3: SerialNumber: 1234567890ABCDEF
[151917.878634] Initializing USB Mass Storage driver...
[151917.878718] scsi56 : usb-storage 1-3:1.0
[151917.878853] usbcore: registered new interface driver usb-storage
[151917.878855] USB Mass Storage support registered.
[151922.882508] scsi 56:0:0:0: CD-ROM ConnMgr Storage 2.31 PQ: 0 ANSI: 2
[151922.891896] sr0: scsi-1 drive
[151922.892692] sr 56:0:0:0: Attached scsi CD-ROM sr0
[151922.894331] sr 56:0:0:0: Attached scsi generic sg1 type 5
[151924.494332] ISO 9660 Extensions: Microsoft Joliet Level 1
[151924.497323] ISOFS: changing to secondary root

modules loaded so far: usb_storage.

- device led lit: green

eject /dev/sr0

- until successful registration: led blinks: red

- then: device led blinks: green

[152024.779779] usb 1-3: USB disconnect, address 62
[152025.133120] usb 1-3: new high speed USB device using ehci_hcd and address 63
[152025.263613] usb 1-3: device descriptor read/all, error -71
[152025.315330] hub 1-0:1.0: unable to enumerate USB device on port 3
[152031.734099] usb 1-3: new high speed USB device using ehci_hcd and address 65
[152031.862356] usb 1-3: New USB device found, idVendor=0b3c, idProduct=c000
[152031.862365] usb 1-3: New USB device strings: Mfr=4, Product=3, SerialNumber=5
[152031.862371] usb 1-3: Product: DataCard Device
[152031.862377] usb 1-3: SerialNumber: 1234567890ABCDEF
[152031.916249] usbcore: registered new interface driver usbserial
[152031.916522] USB Serial support registered for generic
[152031.916867] usbcore: registered new interface driver usbserial_generic
[152031.916870] usbserial: USB Serial Driver core
[152031.924646] USB Serial support registered for GSM modem (1-port)
[152031.924680] option 1-3:1.0: GSM modem (1-port) converter detected
[152031.924933] usb 1-3: GSM modem (1-port) converter now attached to ttyUSB0
[152031.924956] option 1-3:1.1: GSM modem (1-port) converter detected
[152031.925081] usb 1-3: GSM modem (1-port) converter now attached to ttyUSB1
[152031.925102] option 1-3:1.2: GSM modem (1-port) converter detected
[152031.925848] usb 1-3: GSM modem (1-port) converter now attached to ttyUSB2
[152031.925871] option 1-3:1.3: GSM modem (1-port) converter detected
[152031.926040] usb 1-3: GSM modem (1-port) converter now attached to ttyUSB3
[152031.926063] option 1-3:1.4: GSM modem (1-port) converter detected
[152031.926968] usb 1-3: GSM modem (1-port) converter now attached to ttyUSB4
[152031.927285] usbcore: registered new interface driver option
[152031.927288] option: v0.7.2:USB Driver for GSM modems

Now it's getting interesting:
using wvdialconf ttyUSB0 and ttyUSB2 are identifed being active.

- ttyUSB2 is the modem to dial out with

- ttyUSB0 is used to query field strength data etc. this is partly working. but ATs that are "relevant" are rejected..

- neither of them are useful to switch of zerocd behaviour, they just return ERROR.

- dialing on ttyUSB2 is possible only exactly once. Doing so it's of no interest whether the dialling procedure was successful or not. To use the device again, unplug, replug.

- so far so bad.

- dialling w/ whatever wvdial.conf always fails. EXCEPT: during the trials and errors, there was only one single successful dialin. pppd showed a connection and was happy. Only once. Since then, dialling in only worked using windows. Strange enough.

- calls fail to two different providers. So it's not a SIM fault or anything..

- did a usbsnoop on windows, found some 20 possible MessageContents, only tried a couple, no success but one: as with eject, one of the msg contents switches the device into modem mode, still, the modem connection (calling) is not successful.

- searching the net, there seem many olicard100 in use, mostly successfully w/ linux. But there are also quite a couple of distressed users not beeing able to use their umts stick.

- tried several recent distros. no luck.

- the option module only recognised the stick w/ echoing the veid:prid to the new_id procfile

hal-get-property --udi /org/freedesktop/Hal/devices/usb_device_b3c_c000_1234567890ABCDEF_if2 --key info.linux.driver
option

- led's blinking: green, always..

- using the same setup (wvdial.conf, SIM) with another stick it is working.

dialling:
wvdial tre-italia2
--> WvDial: Internet dialer version 1.60
[PAUSE]
--> Cannot get information for serial port.
[PAUSE]
--> Initializing modem.
--> Sending: AT+COPS=1,1,"3 ITA"
AT+COPS=1,1,"3 ITA"
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
OK
--> Sending: AT+CGDCONT=1,"ip","tre.it"
AT+CGDCONT=1,"ip","tre.it"
OK
--> Modem initialized.
--> Sending: ATM0L0DT*99#
--> Waiting for carrier.
ATM0L0DT*99#
CONNECT 7200000
--> Carrier detected. Starting PPP immediately.
--> Starting pppd at Fri May 7 17:01:47 2010
--> Pid of pppd: 4453

- sometimes pppd is periodically outputting some non-printable chars, other times not.

- debbugging in pppd shows lcp conf req timeouts. Thanks for the fish, why the hell? Increasing timeouts yield to no other result. And, no, iptables doesn't block lcp. Even w/o iptables, there's no more good.


Any comments, ideas?
Thanks

Can you post a "lsusb -v -d 0b3c:" after switching at "pastebin.com"?

Josh wrote:Can you post a "lsusb -v -d 0b3c:" after switching at "pastebin.com"?

Sure, sorry I forgot.

http://pastebin.com/SytajTci

Actually, there's been this post:

http://permalink.gmane.org/gmane.linux.kernel/982706

There might be some common solution..

Cheers,

Nils

Yes, interface 4 is the port to use; it's - as always - the interrupt port. So ttyUSB4 should work.

I have had several reports of negative impact by the probing of ModemManager. There will be a change in the structure of high speed serial USB drivers in very new kernel versions, but it will take a while for it to migrate into the distributions.

The thing with the interrupt port is known for a while now, and if I'd have to probe/use an unknown modem I'd leave the other ports (bulk type) alone. There are so many new devices popping up all the time that the connect software should not rely on the driver or HAL alone.

The latest version of USB_ModeSwitch adds a link to the correct interrupt ttyUSB port named "gsmmodem". If you use this in wvdial/whatever it should work right away.

Hi Josh,

Josh wrote:Yes, interface 4 is the port to use; it's - as always - the interrupt port. So ttyUSB4 should work.

I'm slightly confused as to your "Yes" statement. Where are your referring to?

Indeed, port 4 hasn't been tested successfully by wvdialconfig's probing and neither so by my stupidly test-accessing probing.

Josh wrote: I have had several reports of negative impact by the probing of ModemManager. There will be a change in the structure of high speed serial USB drivers in very new kernel versions, but it will take a while for it to migrate into the distributions.

Hm, did I mention modemmanager? If at all I fired it up out of desperation, last resort (it's not really working here).

In fact, I'm using vanilla kernels, never distribution kernels.. too laggy and patchy to be comparable or reportable when bug-hunting.

Josh wrote: The latest version of USB_ModeSwitch adds a link to the correct interrupt ttyUSB port named "gsmmodem". If you use this in wvdial/whatever it should work right away.

Ok, last time I checked for the gsmmodem link w/ the olicard100 plugged in, there was none. Not surprisingly, as the olicard100 wasn't
recognised at all by usb_modeswitch. But I couldn't fake an olicard100 config file either as I had no correct MessageContent yet. At least I think IRC.

Cheers,

Nils

My first statements somewhat referred to the link you posted about the MF636, where lower ports were not working and ModemManager caused hangs.

You can easily add your device to the usb_modeswitch config base.

The MessageContent should be the EJECT command:
"5553424312345678000000000000061b000000030000000000000000000000"

What I find amazing is that the "option" driver obviously bound to the switched device - the ID is not in the driver yet (in 2.6.33.3). So - unless usb_modeswitch did anything automatically - someone else has bound the device to the driver.

Josh wrote: The MessageContent should be the EJECT command:
"5553424312345678000000000000061b000000030000000000000000000000"

Ok, thanks. Wasn't clear to me that there's something such as a generic MessageContent. Thought the MessageContent is individual as per every device and that's why one has to deploy usbsnoop. Thx anyway for the hint.

Maybe it is a good idea to state this fact clearly in a place where it can't be overlooked (did I overlook it?).

Josh wrote: What I find amazing is that the "option" driver obviously bound to the switched device - the ID is not in the driver yet (in 2.6.33.3). So - unless usb_modeswitch did anything automatically - someone else has bound the device to the driver.

Erm.. I patched some version of option.c (.33.2/.33.3) to include that ID but reverted it again for other versions. Could easily be that while running the lsusb cmd I had booted the .33.3 which had it enabled. I sort of lost track where it's on and off right now. But since the lsusb there hasn't been a reboot and modinfo option doesn't know about the 0b3c device. Sometimes I add the ID via echo > option1/new_id so this might have been the path. OTH, the option module was rmmoded before plugging the stick for the lsusb cmd.. Does the kernel keep IDs added via echo > option1/new_id across rmmod/modprobe cycles?

So far so interesting. Peter from the lkml thread wrote back and it seems that these option.c code changes happened right in .34. Looks like I got to use this one.

Thanks

Josh wrote:The MessageContent should be the EJECT command:
"5553424312345678000000000000061b000000030000000000000000000000"

Tried the above msg content: Device didn't switch. Reverting back to: Cheers,

Nils

Please remove the "MessageEndpoint" line. It will be determined automatically. Your entry is probably wrong.

Josh wrote:Please remove the "MessageEndpoint" line. It will be determined automatically. Your entry is probably wrong.

Even w/o the MessageEndpoint the device doesn't switch.

BTW, it seems that the device switches itself after 20 minutes..

There isn't even a log written by usb-modeswitch for this device.
Other devices get their log share.. Strange..

Any hint?

Hmm ... I suppose you checked the rules entry and the config file, and you have "tcl" installed ...

But even with a wrong config file there should be a short log. So it might be something in the "rules".

The entry there should read:After each rules file update I recommend to run
"udevadm control --reload-rules".

Josh wrote:

Code: Select all

ATTRS{idVendor}=="0b3c", ATTRS{idProduct}=="c700", RUN+="usb_modeswitch '%b/%k'"

After each rules file update I recommend to run
"udevadm control --reload-rules".

Ah, sorry, didn't remember /lib/udev/rules.d/40-usb_modeswitch.rules
and thought therefore that modeswitch would parse /etc/usb_modeswitch.d/* for appropriate entries.

Ok, so now, there's a log:

http://pastebin.com/dGAgUYVt

What's about this inappropriate ioctl, the quirk and the device not found?

So, device switched. Great.

/dev/gsmmodem is a link to ttyUSB4. Great.

wvdial.conf: Still no luck dialling in.
Thank you.

Cheers

I can think of two causes at the moment.

1. Something else is interfering with the modem ports after switching. "dmesg" may show reports of "probing", probably along with hangs or problems. Suspect: ModemManager.
2. The modem doesn't get along well with the "option" driver. For testing purposes, you could try the generic "usbserial". Remove the "option" module and add in your config file:

Josh wrote:I can think of two causes at the moment.

1. Something else is interfering with the modem ports after switching. "dmesg" may show reports of "probing", probably along with hangs or problems. Suspect: ModemManager.

modemmanager isn't installed any longer..

Josh wrote: [*]The modem doesn't get along well with the "option" driver. For testing purposes, you could try the generic "usbserial". Remove the "option" module and add in your config file:[/list]

Code: Select all

DriverModule="usbserial"
DriverIDPath=/sys/bus/usb-serial/drivers/generic/new_id

Thanks for the config. Tried. Failed. I had to load usbserial via else usb-modeswitch complained in the log about missing /sys/bus/usb-serial/drivers/generic/new_id. usbserial didn't get loaded on
switching..

Blacklisting/setting to /bin/true of option wasn't enough. Maybe due to option including the olicard100 device IDs (patched src). But OTOH the option module wasn't loaded any more, so there's could be no way for the kernel - in theory - to know that any longer. Strangely option got loaded every time, though. blacklist+/bin/true for option _and_ specifying vendor/product ID during modprobe fixed it. But the device is yet unresponsive.

Thank you for your support, Josh.

Cheers

olia wrote:

Josh wrote:I can think of two causes at the moment.

1. Something else is interfering with the modem ports after switching. "dmesg" may show reports of "probing", probably along with hangs or problems. Suspect: ModemManager.

modemmanager isn't installed any longer..

Holy cow. I did test it all along _before_ purging modemmanager.
Now, I tested it once again.

It works.

What is this modemmanager crap worth it when it's breaking other pieces and you can't get a chance of knowing that. There was no
sign of modemmanager interfering in any log. Bad thing, that is.

BTW, w/o that piece of binary chunk on the system: /dev/gsmmodem -> ttyUSB2

I think this xp is worth a big warning note (if not already available and me not remembering it..)

DO REMOVE modemmanager BEFORE PLUGGING.

Thank you again very much for your support, Josh, well done.

Cheers