On Sat, 21 Feb 2009, Julien Valroff wrote:
> Le vendredi 20 février 2009 à 21:54 -0300, Henrique de Moraes Holschuh a
> écrit :
> > On Fri, 20 Feb 2009, Julien Valroff wrote:
> > > The new USB Option WWAN modem device support a CDROM device, which holds
> > > the needed Windows driver to use the WWAN modem.
> > > 
> > > Therefore the firmware of the WWAN modem announce during the USB 
> > > enumeration
> > > process to work as a virtual CDROM device with its vendor name "ZOPTION".
> > >  
> > > This device is now called ZERO-CD.
> > > 
> > > ozerocdoff is a solution to switch off the ZERO-CD and allow the modem to
> > > be a modem.
> > 
> > Why is it needed?  Are there devices that malfunction as modems while the
> > emulated cdrom is active?
> 
> Yes.
> 
> > I ask because I have tested a bunch of Huawei E226, which do have this
> > stupid cdrom emulation hack from hell to bypass Windows security policies.
> > While option does allow it to register the mass storage device with
> > usb-storage, it also works as a GSM modem just fine at the same time...
> 
> That is not the case of (at least) Option WWAN modems.

Fair enough.

> > If there is a pressing need to disable that stupid emulated cdrom, maybe a
> > bug should be filled to fix it right in the kernel, so that the emulated
> > device is never bound to usb-storage to begin with?
> 
> I attach the original README file shipped with ozerocdoff, which
> explains much better than I could.

[...  ozerocdoff readme below ...]

> The Linux OS does currently not use this ZERO-CD, because the image can
> not hold all the needed binary kernel drivers, which 

And it never will, it is just plain impossible.  Source it could hold, but
that's useless from a normal user perspective, so it is a completely useless
feature for Linux, and it can be unconditionally disabled on all WWAN modems
(not just "Option WWAN"), IMO.

That makes it the kernel's business.  I am not against Debian adding these
userspace utilities, mind you (so I am not against your ITP), they will be
needed for at least one year...

> it off. Once you send this switch off command to the WWAN modem, another
> new USB enumeration will be requested by the WWAN modem firmware.
> Afterwards the real WWAN modem interface is available on the USB bus.

That's the clinch, then.  It only becomes usable after the cdrom emulator is
disabled, so the kernel driver is incomplete if it doesn't do it (again,
IMO).

> Looking on the Linux USB core system, it has another restriction. If there
> are more than one possible drivers, which can work successfully with that
> USB WWAN modem, the USB core system will allow probing the WWAN modem by
> these drivers in a special order.  First the already loaded driver will be
> allowed to do the probe. If then this driver do a successful probe,
> another potential driver will never become a chance to do also a probing
> with that hardware. Therefore it is (currently) impossible to use the
> final WWAN modem driver to send the ZERO-CD switch off command, because
> often the USB mass storge driver will be already loaded and is working in
> your Linux system.  If the probing of an already loaded module is not
> successful or no module is loaded, the udev system will trigger a
> modeprobe to load the needed driver(s). But the loading order of the
> drivers is not clear specified, although is may depends on the order of
> the appearance in the modules dependency files created by depmod.

This is a kernel deficiency, and it can and should be fixed (if it isn't
already by adding quirks to the option module or whatever).

> But this probe order is also important to know for some old Option WWAN
> modems, which could be handled by the mainstream 'option' kernel driver.
> Unfortunately this is a bug, because the mainstream 'option' driver looks
> on the wrong USB device ID.

This should also be fixed in the kernel, and appears to be a consequence of
the stuff above.

> The ZERO-CD switch off command is simple a SCSI 'rezero' command. The
> easiest way to send this command to the WWAN modem is by using the
> standard Linux USB mass storage driver. Because the WWAN modem will
> initiate a hard disconnect from the SCSI bus connection after receiving
> that rezero command and the USB mass storage driver is not prepared for
> such a situation, we risk a possible system freeze.  Therefore we use a

This is ALSO a kernel bug that needs to be fixed, unless "a hard disconnect"
is something that violates some spec, which I very much doubt, since SCSI is
supposed to support target-initiated disconnection.

[...]

> Solution use the correct HSO Option driver:
> 
> Because we have now two drivers for some Option WWAN-modems, we simply
> blacklist the mainstream 'option' kernel module driver, which we do not
> like to use. Note that this 'option' driver does support only Option WWAN
> modem with Version 3 Interface, which support only virtual serial modem
> ports. The new 'hso' driver supports the newer Version 4 Interface. Here
> also an IP network device is available, which allow high speed
> communication also by using the slow USB 1.1 bus system. Note also that
> this network interface is not identical to a virtual ethernet, because it
> "speaks" only IP. So e.g. running a dhcpclient is here not possible,
> because this would require the support of the simple ether transport
> package frames.  The 'option' mainstream driver can be prevent to be
> automatically loaded be adding a line like: blacklist option

Again, stuff that needs to be fixed in the kernel properly.

You can file a bug on bugzilla.kernel.org, mentioning this mailinglist
thread, AND attaching the ozerocdoff README (make it clear that it explains
the hoops that are being done to get that hardware to work).

You need two bugs: one for the "usb-storage might freeze on a SCSI hard
disconnect from an "Option WWAN Modem with an emulated CDROM mass-storage
device",  and the other for the rest of the stuff dealing with the "option"
module not doing the right thing to *select* the proper module to drive the
"Option WWAN modem".

Or you can file the two bugs against the Debian kernel, tag them upstream,
and ask the Debian kernel maintainers to forward it upstream (write THAT on
the top of the bug reports, or someone might thing by mistake that the
upstream tag means you have already forwarded it upstream, etc).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to