ZeroCD devices (on 3G modems) are not ejected automatically

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

 * Is this reproducible?
 * If so, what specific steps should we take to recreate this bug?

 This will help us to find and resolve the problem.

"* Is this reproducible?
 * If so, what specific steps should we take to recreate this bug?"

Just plug in any 3G USB modem.

On Windows, the first time you plug it, it's detected as an USB flash drive where the modem drivers can be found. Usually, an autorun installs them. Once modem drivers are installed, you restart the computer and the USB 3G modem is not seen as a flash drive anymore but as a 3G USB modem.

On Ubuntu, this doesn't happen unless you switch it manually.

Anyway, 3G USB connection doesn't work for now in Jaunty but that's another matter.

The package usb-modeswitch would automatically switch the modem to the right mode. This package is not installed by default.

Karmic still doesn't switch 3G devices, because udev is missing rules for this.

It is possible to switch Zero-CD devices automatically. For this, udev needs a rule that sends the "eject" command to the device.

For ZTE MF6xx devices (19d2:2000 in CD-ROM mode), the following rule is all that is needed to do mode-switching (tested in Karmic):

SYSFS{idVendor}=="19d2", SYSFS{idProduct}=="2000", RUN+="/usr/bin/eject %k"

Developers: Please add this rule to the standard udev rules.
Users: Please create a file "ZTE.rules" in /etc/udev/rules.d containing the above rule and test it. Don't forget to give feedback :)

Martin, I haven't caught up with the stuff that moved in from udev-extras yet - do you know what we do about this kind of thing?

I don't know how usb-modeswitch is supposed to work, but nm-mode-probe is being used in karmic. Calling "eject" on all interfaces of a USB device doesn't sound like the "correct" solution, though.

I think usb-modeswitch comes with NetworkManager 0.8, but I could be wrong. 0.8 should land in Karmic tomorrow. Subscribing Alex for further input on this.

Nope, there are no "interfaces" at this stage, and nm-modem-probe has nothing to do with CD-ROMs.

A little background:
When ZeroCD devices are plugged in, they are not modems at all. They appear as real CD-ROM drives, with data on them. No interfaces, no modems. USB IDs (e.g. for ZTE MF series) are 19d2:2000.
These CD-ROMs can be ejected with a right click -> Eject, or from the terminal with 'eject sr0'.

Mode-switching is embedded into these devices, this is why usb-modeswitch is not necessary. They switch modes when the CD-ROM is ejected, OR when a special message is sent (e.g. via usb-modeswitch).
The trouble with usb-modeswitch is that each device firmware can have its own "special message" and we never get it done right.

OTOH ejecting the CD works the same for all ZeroCD devices and nobody needs to care about the messages for each single device model/firmware.

After the ZeroCD has been ejected, the device automatically switches to modem mode (19d2:0031 for ZTE MF6xx), and presents 3 interfaces. This is when nm-modem-probe does its job, probing the interfaces for modem capabilities.

The udev rule I have posted is confirmed to work with different ZTE models. I have no other ZeroCD devices to test with, but it has to be the same for all of them.

Right, but I meant that all the other rules use /lib/udev/modem-modeswitch for this, which is the intended program for this operation. Can you please try whether this works, too?

  ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="2000", RUN+="modem-modeswitch -v 0x%s{idVendor} -p 0x%s{idProduct} -t option-zerocd"

Tested on Karmic - it doesn't work. Debug output:

root@dell:/lib/udev# ./modem-modeswitch -v 0x19d2 -p 0x2000 -t option-zerocd -d
D: Found mass storage device:
D: Endpoints: 2
D: Class: 0x8
D: SubClass: 0x6
D: Protocol: 0x50
D: Found modem mass storage device '005'
D: 005: found already attached driver 'usb-storage'
D: 005: REZERO command sent.

It does something to the CD-ROM, causing it to disappear, but nothing else. The modem itself does not switch. Replugging the modem and doing 'eject sr1' Just Works (tm).

I suppose it'd be easier to use the simple and tested 'eject' command instead of debugging 'modem-modeswitch' and trying to figure out other alternative ways of ejecting a CD :)

I committed the eject rule upstream to the existing 61-mobile-action.rules file. I hope it still works like that, testing appreciated.

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=3c47b388eef138cab2d931b73019650914305799

Hi :)

It's great to seee action taking place about this. Martin, your upstream bug-report only mentions 1 type of modem but i think this is a more widespread problem affecting a lot of different usb wireless dongles and other stuff too? Anyway, it's good to see the report out there :) Nicely done :)

Does "fix committed" mean that soem update from the repos will suddenly automate this task and magically fix things for most people?

There seems to be a lot of questions in the Answers Section about wireless issues right now. Anyone that could help with just wireless issues would be appreciated
https://answers.launchpad.net/ubuntu/+source/nautilus/+question/80712

Thanks and regards from
Tom :)

Tom [2009-08-24 11:56 -0000]:
> It's great to seee action taking place about this. Martin, your
> upstream bug-report

That wasn't a bug report, but a code change to the upstream code.

> only mentions 1 type of modem but i think this is a
> more widespread problem affecting a lot of different usb wireless
> dongles and other stuff too?

Sure, but many others are covered by the existing modem-modeswitch
rules. If any particular device isn't working, please open a new bug
report about it.

> Does "fix committed" mean that soem update from the repos will suddenly
> automate this task and magically fix things for most people?

Somewhat. As soon as upstream does a new release and we'll upload it
to Ubuntu, this will be available for all Ubuntu users.

Great, all sounds good then :)
Thanks Martin :)
Regards from
Tom :)

I have a ZTE ZeroCD device, with the same vendor and product id 19d2:2000, but the above rule doesn't work for me in karmic.

The device is branded by Vodafone It as K3565-Z. Plugging the device result in the cd-rom being displayed, when manually ejected it switchs to a modem as usual. The prod and vendor id after switching are: 19d2:0063.

Neither the rule posted by Sergiu,

SYSFS{idVendor}=="19d2", SYSFS{idProduct}=="2000", RUN+="/usr/bin/eject %k"

nor the one commited by Martin, works for me.

The former is recognized for the device to apply by udevadm test, the latter doesn't.

It seems my device has a value of "00" for the attributes bDeviceClass and bDeviceSubClass, instead of "ff", as in the rule by Martin.

Changing the rule this way:

SUBSYSTEM=="usb", ATTR{bDeviceClass}=="00", ATTR{bDeviceSubClass}=="00", ENV{DEVTYPE}=="usb_device", GOTO="mobile_action_switch"

results in udevadm test recognizing it, but still it doesn't work. After plugging, the fake cd is still there.

I tried with modem-modeswitch but it didn't succeed, too.

I am sorry but i made a mistake, i am a newbie as regards udev stuff.

In fact, the rules are correct and in my karmic box both work as expected, provided that they are outside the "mobile_action_switch" block.

I couldn't get the SUBSYSTEM rule to work for my device, though.

Giuseppe,

I updated the upstream rules accordingly in commit bfde03a, to also match on class/subclass "00". Thanks!

This bug was fixed in the package udev - 147~-1

---------------
udev (147~-1) karmic; urgency=low

  FFE LP: #427356.

  * Update to GIT HEAD (pre 147 release):
    - worker signal mask corrected. LP: #407428.
    - database format change to avoid path length issues. LP: #377121.
    - multiple devices may not claim the same /dev names, except with
      symlinks
    - NAME="%k" produces a warning
    - symlinks to udevadm no longer resolve to the original command
    - rules updates. LP: #281335, LP: #407940, #420015, #426647.

  * Build-depend on gawk, since build fails with mawk.

  * Replace init scripts with Upstart jobs.
  * debian/control:
    - Add missing ${misc:Depends}
    - Bump build-dependency on debhelper for Upstart-aware dh_installinit

 -- Scott James Remnant <email address hidden> Tue, 15 Sep 2009 03:22:11 +0100

No, it has not been fixed.

The rule inserted in "61-mobile-action.rules" is correct, but doesn't do anything, probably because it's misplaced.
Placing that same rule in any file located under /etc/udev/rules.d (i.e. ZTE.rules) makes it work, so it's definitely a problem of precedence.

Then I guess one of these checks fails:

SUBSYSTEM=="usb", ATTR{bDeviceClass}=="00|ff", ATTR{bDeviceSubClass}=="00|ff", ENV{DEVTYPE}=="usb_device"

Sergio, please do

  udevadm monitor --udev -e

then plug in the device, and copy&paste the output. Thanks!

Ok, did it twice:
1. The rule is located in file /etc/udev/rules.d/ZTE.rules
   - the ZeroCD has been ejected, modem detected
   - output attached as "etc_udev.txt"

2. The rule is located in file /lib/udev/rules.d/61-mobile-action.rules
   - the ZeroCD has not been ejected, no modem
   - output attached as "lib_udev.txt"

Good, thanks. Now plug it into the same port you used before, and afterwards copy&paste the output of

  udevadm info --attribute-walk --path=/devices/pci0000:00/0000:00:1d.7/usb2/2-4

Thanks!

Here it is, with the device being already switched and connected to the Internet:

  looking at device '/devices/pci0000:00/0000:00:1d.7/usb2/2-4':
    KERNEL=="2-4"
    SUBSYSTEM=="usb"
    DRIVER=="usb"
    ATTR{configuration}=="ZTE Configuration"
    ATTR{bNumInterfaces}==" 4"
    ATTR{bConfigurationValue}=="1"
    ATTR{bmAttributes}=="e0"
    ATTR{bMaxPower}=="500mA"
    ATTR{urbnum}=="4362"
    ATTR{idVendor}=="19d2"
    ATTR{idProduct}=="0031"
    ATTR{bcdDevice}=="0000"
    ATTR{bDeviceClass}=="00"
    ATTR{bDeviceSubClass}=="00"
    ATTR{bDeviceProtocol}=="00"
    ATTR{bNumConfigurations}=="1"
    ATTR{bMaxPacketSize0}=="64"
    ATTR{speed}=="480"
    ATTR{busnum}=="2"
    ATTR{devnum}=="28"
    ATTR{version}==" 2.00"
    ATTR{maxchild}=="0"
    ATTR{quirks}=="0x0"
    ATTR{authorized}=="1"
    ATTR{manufacturer}=="ZTE,Incorporated"
    ATTR{product}=="ZTE CDMA Technologies MSM"
    ATTR{serial}=="1234567890ABCDEF"

  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb2':
    KERNELS=="usb2"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bMaxPower}==" 0mA"
    ATTRS{urbnum}=="555"
    ATTRS{idVendor}=="1d6b"
    ATTRS{idProduct}=="0002"
    ATTRS{bcdDevice}=="0206"
    ATTRS{bDeviceClass}=="09"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{speed}=="480"
    ...

And the same command, but this time with the rule located under /lib/udev/rules.d (not working). The device is in CD-ROM mode:

  looking at device '/devices/pci0000:00/0000:00:1d.7/usb2/2-4':
    KERNEL=="2-4"
    SUBSYSTEM=="usb"
    DRIVER=="usb"
    ATTR{configuration}=="ZTE Configuration"
    ATTR{bNumInterfaces}==" 1"
    ATTR{bConfigurationValue}=="1"
    ATTR{bmAttributes}=="e0"
    ATTR{bMaxPower}=="500mA"
    ATTR{urbnum}=="827"
    ATTR{idVendor}=="19d2"
    ATTR{idProduct}=="2000"
    ATTR{bcdDevice}=="0000"
    ATTR{bDeviceClass}=="00"
    ATTR{bDeviceSubClass}=="00"
    ATTR{bDeviceProtocol}=="00"
    ATTR{bNumConfigurations}=="1"
    ATTR{bMaxPacketSize0}=="64"
    ATTR{speed}=="480"
    ATTR{busnum}=="2"
    ATTR{devnum}=="29"
    ATTR{version}==" 2.00"
    ATTR{maxchild}=="0"
    ATTR{quirks}=="0x0"
    ATTR{authorized}=="1"
    ATTR{manufacturer}=="ZTE,Incorporated"
    ATTR{product}=="ZTE CDMA Technologies MSM"
    ATTR{serial}=="MDAP673A3CDROMMS"

  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb2':
    KERNELS=="usb2"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bMaxPower}==" 0mA"
    ATTRS{urbnum}=="578"
    ATTRS{idVendor}=="1d6b"
    ATTRS{idProduct}=="0002"
    ATTRS{bcdDevice}=="0206"
    ATTRS{bDeviceClass}=="09"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{speed}=="480" ...

Thanks for the attribute-walk outputs, they showed that all attribute checks in

  SUBSYSTEM=="usb", ATTR{bDeviceClass}=="00|ff", ATTR{bDeviceSubClass}=="00|ff", ENV{DEVTYPE}=="usb_device"

*should* match.

Now I still don't understand why the rule doesn't work in the mobile_action_switch block. The problem with your separate one is that it is called several times, which we want to avoid.

With the rule in /lib and in the switch block (as currently in Karmic), could you please give me the output of

  udevadm test --action=add /devices/pci0000:00/0000:00:1d.7/usb2/2-4

after plugging in the device (but not ejecting it yet).

Also, let's eliminate what clause is responsible for breaking the rule: Can you please comment the

   SUBSYSTEM=="usb", ATTR{bDeviceClass}=="00|ff", ATTR{bDeviceSubClass}=="00|ff", ENV{DEVTYPE}=="usb_device"
   GOTO="mobile_action_end"

lines in /lib/udev/rules.d/61-mobile-action.rules entirely by prepending a "#", replug the device, and check if it works?

If that works, can you please restore the two lines, and then drop each test in succession and see which one breaks? (i. e. delete everything after a comma until and including to the next comma).

Thanks!

Well, maybe they should match, but they don't. Actually, *none* of them matches.
Instead, this works:

SUBSYSTEMS=="usb", ATTRS{bDeviceClass}=="00|ff", ATTRS{bDeviceSubClass}=="00|ff", GOTO="mobile_action_switch"

All of the above checks match, and the ZeroCD is being ejected. Please note that I used "SUBSYSTEMS" and "ATTRS" instead of the default "SUBSYSTEM" and "ATTR".

Unfortunately, I have no idea how to fix the fourth check, ENV{DEVTYPE}=="usb_device", so I have removed it.

Ah, I think I figured it out. The previous rules could never match the fake CD-ROM device, which is what we need to match on and eject.

Can you please remove your rule in /etc/ again, install this one with

  sudo cp 61-mobile-action.rules /ilb/udev/rules.d/

and test again?

Thanks!

I really think it should work now. I committed this to trunk now (commit 6badb06).

This bug was fixed in the package udev - 147-1

---------------
udev (147-1) lucid; urgency=low

  * Update to 147 release:
    - Includes previous GIT updates.
    - udev-acl now requires ConsoleKit 0.4.1
    - gudev API no longer marked as experimental
    - rules updates. LP: #281335, #215035, #438114.

  * Added Build-Depends on gobject-introspection, libgirepository1.0-dev
    and gir1.0-glib-2.0.
  * Add gir1.0-gudev-1.0 package with introspection data.
  * Added Breaks on consolekit << 0.4.1
  * Add missing copyright files for the libudev and libgudev packages
    which are LGPL 2.1+ and LGPL 2+ respectively, not GPL 2+.

  * Include symbols files and update shlibs to 147. LP: #427672.
 -- Scott James Remnant <email address hidden> Mon, 30 Nov 2009 22:37:34 +0000

2009/12/1 Launchpad Bug Tracker <email address hidden>:
> This bug was fixed in the package udev - 147-1
>
> ---------------
> udev (147-1) lucid; urgency=low
>
>  * Update to 147 release:
>    - Includes previous GIT updates.
>    - udev-acl now requires ConsoleKit 0.4.1
>    - gudev API no longer marked as experimental
>    - rules updates.  LP: #281335, #215035, #438114.

Would it be possible to backport these rules to Karmic?

--
## Przemysław Kulczycki >><< Azrael Nightwalker ##
# jabber: azrael[na]jabster.pl | tlen: azrael29a #
### www: http://reksio.ftj.agh.edu.pl/~azrael/ ###

Przemysław Kulczycki [2009-12-01 14:04 -0000]:
> Would it be possible to backport these rules to Karmic?

Yes, you can just grab the ones from lucid.

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

2009/12/1 Martin Pitt <email address hidden>:
> Przemysław Kulczycki [2009-12-01 14:04 -0000]:
>> Would it be possible to backport these rules to Karmic?
>
> Yes, you can just grab the ones from lucid.

I meant an official update in the repositories, to make the hardware
detection better also in older releases.
Would it be possible to do such thing regularly as a matter of policy?

--
## Przemysław Kulczycki >><< Azrael Nightwalker ##
# jabber: azrael[na]jabster.pl | tlen: azrael29a #
### www: http://reksio.ftj.agh.edu.pl/~azrael/ ###

Przemysław Kulczycki [2009-12-01 16:46 -0000]:
> I meant an official update in the repositories, to make the hardware
> detection better also in older releases.
> Would it be possible to do such thing regularly as a matter of policy?

They need to be tested individually, though. E. g. for new key
mappings it can happen that a laptop which previously had non-working
keys suddenly freaks out because it additionall needs a
"force-release" kernel quirk. Or a modem doesn't work with the
previous kernel, etc.

So someone would need to pick out some, confirm that they work in a
previous release, and mark the bug as applicable to
karmic/jaunty/whatever.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

I encountered this problem in Ubuntu Karmic.

After trying all suggestions in many pages with no result, I tried this :

rename /lib/udev/rules.d/61-mobile-action.rules,
to /lib/udev/rules.d/51-mobile-action.rules

Then plugging in the modem works as it was in Jaunty (yes, my ZTE MF622 was working staright away, flawlessly, in Jaunty)

Don't ask me WHY it works though, I'm no expert on udev :-)
But if I may guess - renaming that file into a smaller number (from 61 to 51) make udev processes it in a more timely fashion.

Anyway, hope it helps others.

Works for me with Martin's /lib/udev/rules.d/61-mobile-action.rules, though I'm confused as why the same thing in /etc/udev/rules.d won't work. I debugged it with logger it, and it logs _after_ I unplug the usb stick:

/etc/udev/rules.d/49-ZTE.rules:

ENV{ID_CDROM}=="1", ENV{ID_VENDOR_ID}=="19d2", ENV{ID_MODEL_ID}=="2000", RUN+="/usr/bin/logger /usr/bin/eject %k"

tail -f /var/log/messages:

Mar 11 18:25:23 Tellervo kernel: [21277.948097] usb 1-1: new high speed USB device using ehci_hcd and address 53
Mar 11 18:25:23 Tellervo kernel: [21278.093654] usb 1-1: configuration #1 chosen from 1 choice
Mar 11 18:25:23 Tellervo kernel: [21278.113217] scsi55 : SCSI emulation for USB Mass Storage devices
Mar 11 18:25:28 Tellervo kernel: [21283.119408] scsi 55:0:0:0: CD-ROM ZTE USB SCSI CD-ROM 2.31 PQ: 0 ANSI: 2
Mar 11 18:25:28 Tellervo kernel: [21283.145377] sr1: scsi-1 drive
Mar 11 18:25:28 Tellervo kernel: [21283.145908] sr 55:0:0:0: Attached scsi generic sg1 type 5
Mar 11 18:25:44 Tellervo kernel: [21299.086685] usb 1-1: USB disconnect, address 53
Mar 11 18:25:44 Tellervo logger: /usr/bin/eject sr1

But, the one in /lib/udev/rules.d now works, and I'm happy to announce that udev works strangely, and I'll just give up trying to understand it ^____^