More LiveCD space optimizations

[Josua Dietze]

Am 15.11.2010 08:59, schrieb Martin Pitt:
> Hello Josua,
>
> Josua Dietze [2010-11-13  0:35 +0100]:
>> Am 12.11.2010 23:26, schrieb Martin Pitt:
>>> It currently triggers for any kind of ttyUSB. I think what can be done
>>> is that each of the vendor/product specific rules add a
>>> TAG="usb-modeswitch", and then the dispatcher only fires on that tag.
>>
>> These devices are somewhat elusive in that they return after
>> switching as virtually unrelated to their first appearance.
>
> Right, but is there anything that usb-modeswitch needs to do to those
> devices after they are in proper modem state? Shouldn't modemmanager
> pick them up at that point? My internal 3G card doesn't need any
> usb-modeswitch magic either and just works fine, after all?

It depends on the device configuration. modem-manager often has trouble 
finding the right port for connection.
These modems often provide three or even more vendor-specific 
interfaces, but only one of them is suitable for connecting (the one 
that has an interrupt transfer endpoint). If this port maps to something 
higher than ttyUSB1, modem-manager runs into trouble.

Since there is no way in NetworkManager to set the port manually (e.g. 
to ttyUSB3), the only possibility for people is to use alternative 
software. The helper function of usb_modeswitch checks for the interrupt 
endpoint and adds a symlink to the right ttyUSB port.

This is only to make life easier for users and can actually be skipped 
without affecting the device itself, if you worry about boot drag.

Of course the symlink could be added with annother udev line, but then 
there are devices which provide more than one interrupt port and only 
the lowest one is usable, so there is some logic needed.
Besides, originally I had treated only known devices which was not 
possible with pure udev matching.

> So let's first clarify what that usb-modeswitch rules actually needs
> to match on.
>
> KERNEL=="ttyUSB*", DRIVERS=="option1|usbserial", PROGRAM="/usr/sbin/usb_modeswitch_dispatcher --symlink-name %p", SYMLINK="%c"
>
> Perhaps there is a particular USB device class or protocol which we
> can add, so that this doesn't run on any kind of USB serial converter?

Unfortunally, all interfaces in question have class 0xff. I'm not sure 
about the protocol but I will look it up. In my support forum there are 
plenty of "lsusb -v" listings.

It *is* possible to skip the "usbserial" match though. The 
usb_modeswitch package tries to cater to older and embedded systems too 
where the "option" driver is either not available or does not have the 
ability to add USB IDs on the fly. Only on these systems the "usbserial" 
driver has to be used. This is hardly the case on any future Ubuntu 
distribution, I think.

The "option" driver is explicitly provided for high speed modems.

>> And no matter what, many of those switch-mode modems will not be
>> ready for use when that desktop comes up ...
>> In fact, just delaying the whole switching business would avoid any
>> interference with the boot process alltogether. May be worth a
>> thought.
>
> You need to switch them at some point, though, and if they appear in
> network-manager when your desktop is booted, that's kind of nice,
> isn't it?

Yes, it is, but it will only happen if
a. the device doesn't need longer for switching than the boot time
  and
b. modem-manager will not cause trouble ...

As I mentioned, there are some that will take 10-20 seconds from the 
point where the switching command was issued (on udev startup, that is); 
notable examples are some Huawei, ZTE and the Sony Ericsson models.
BTW, with these the symlink rule will only match if the desktop is 
already up, so there is a forced delay anyway - unless there was a warm 
boot with the device already in modem mode.

See this post (and numerous others) for the NM/MM issue:
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?p=3649#3649


Regards
Josh