Environment woes

Environment woes

[Josua Dietze]

Hi everyone,

I am in need of a friendly hint regarding a delicate matter ...

I maintain a Linux tool to put USB devices from one mode (or state) to 
the other. Many wireless sticks support that "feature", showing up as 
a storage device and providing their Windows drivers onboard. To be 
used as modems they are switched by these drivers (once they are 
installed) to their second mode.

This can be handled in Linux and is properly tested.

Usually there is more than one interface exposed after the mode 
switch, but only one is suitable for a wireless connection; binding 
the GSM driver ("option") or the generic serial driver will add 
multiple ports though (ttyUSB).

Up to now I have used a rule to add a symlink to the "right" port; the 
check is done by a script via "PROGRAM". If the port is not right, the 
result of the script is empty, thus no symlink:

ACTION="add", KERNEL="ttyUSB*", PROGRAM="<script> %p", SYMLINK="%c"

To handle *only* the device that was switched by my other rules, I 
stored the bus and device number during the switching process in a 
temporary file which is then used by the <script>. I had tried to work 
with ENV first but failed.

You might already guess what I'm going to ask ...

I was reprimanded - and rightly so - for using the temp file, which is 
said to be insecure and not working at boot time.
But I am at a loss how I should signal from one enumeration event to 
annother without using a file; neither ENV nor IMPORT are working, 
probably because the different modes behave like two unrelated 
devices, storage and serial. Quite often the USB ID changes with the 
mode switch.

Is there really no environment that can be accessed from both 
scripts/events?
Or is there a third way maybe?
The order of events is guaranteed in my case ...


Thanks,
Josua Dietze

Re: Environment woes

[Kay Sievers]

On Tue, Aug 10, 2010 at 00:37, Josua Dietze <digidietze@draisberghof.de> wrote:
> Up to now I have used a rule to add a symlink to the "right" port; the check
> is done by a script via "PROGRAM". If the port is not right, the result of
> the script is empty, thus no symlink:
>
> ACTION="add", KERNEL="ttyUSB*", PROGRAM="<script> %p", SYMLINK="%c"

Who needs these custom links? Why don't you just use the stuff in
/dev/serial/ which should already work?

Kay

Re: Environment woes

[Josua Dietze]

Am 10.08.2010 06:37, schrieb Kay Sievers:

> On Tue, Aug 10, 2010 at 00:37, Josua Dietze<digidietze@draisberghof.de>  wrote:
>> Up to now I have used a rule to add a symlink to the "right" port; the check
>> is done by a script via "PROGRAM". If the port is not right, the result of
>> the script is empty, thus no symlink:
>>
>> ACTION="add", KERNEL="ttyUSB*", PROGRAM="<script>  %p", SYMLINK="%c"
>
> Who needs these custom links? Why don't you just use the stuff in
> /dev/serial/ which should already work?


There is a symlink to *every* port in the /dev/serial folders. Again, 
only *one* of them is usable for connecting through 
wvdial/umtsmon/networkmanager. The latter often auto-selects a wrong 
port, BTW.

I add *one* symlink called "gsmmodem[x]" to make life easier for users.

Examples:
Huawei E160	ttyUSB0,1,2	gsmmodem -> ttyUSB0
ZTE MF110	ttyUSB0,1,2	gsmmodem -> ttyUSB2

These interfaces all have a class of 0xff. Some are even accepting AT 
commands, but are only intended for diagnostic purposes, misleading 
users and probers.


Thanks,
Josua Dietze

Re: Environment woes

[Greg KH]

On Tue, Aug 10, 2010 at 12:37:23AM +0200, Josua Dietze wrote:
> Hi everyone,
> 
> I am in need of a friendly hint regarding a delicate matter ...
> 
> I maintain a Linux tool to put USB devices from one mode (or state)
> to the other.

What program, usb-modeswitch?

> Usually there is more than one interface exposed after the mode
> switch, but only one is suitable for a wireless connection; binding
> the GSM driver ("option") or the generic serial driver will add
> multiple ports though (ttyUSB).

Let the modem-manager program handle knowing which tty device to use,
that type of logic can usually only be detected after talking to the
device.

And what happens with your tool when in the near future, we want to talk
to those other device nodes because modem-manager knows what thoes ports
do and how to get the data out of them?

In short, you shouldn't have to do any of this.

thanks,

greg k-h

Re: Environment woes

[Josua Dietze]

Am 10.08.2010 21:30, schrieb Greg KH:

> On Tue, Aug 10, 2010 at 12:37:23AM +0200, Josua Dietze wrote:
>> I maintain a Linux tool to put USB devices from one mode (or state)
>> to the other.
>
> What program, usb-modeswitch?


That's the one, yes.

>> Usually there is more than one interface exposed after the mode
>> switch, but only one is suitable for a wireless connection; binding
>> the GSM driver ("option") or the generic serial driver will add
>> multiple ports though (ttyUSB).
>
> Let the modem-manager program handle knowing which tty device to use,
> that type of logic can usually only be detected after talking to the
> device.


Unfortunately, I keep receiving reports that modem-manager picks the 
wrong port after probing, and there is no way of setting the port 
manually in NetworkManager. This happens mostly with devices where the 
interrupt port has a number > 0. I have yet to meet a GSM modem device 
where the "interrupt rule" does *not* apply.

I usually recommend using wvdial (autoprobing problems too) and edit 
the port directly in the config file. And just entering "gsmmodem" 
spares users the testing of all ports, some of which may seem to work 
at first but then build up a very unreliable connection.

> And what happens with your tool when in the near future, we want to talk
> to those other device nodes because modem-manager knows what thoes ports
> do and how to get the data out of them?


The usb_modeswitch helper in the post-switch rule only picks ttyUSB 
ports and looks only for their transfer type. It doesn't do anything 
to the ports if they are bulk.
Note that this is unrelated to the preceding switching process and 
doesn't change anything at all except that one symlink.

And yes, it can be scrapped anytime without further consequences when 
there are other solutions. It is a temporary workaround to make user's 
life a little easier.

> In short, you shouldn't have to do any of this.


I couldn't agree more! :-)


Regards,

Josua Dietze

Re: Environment woes

[Greg KH]

On Tue, Aug 10, 2010 at 10:02:10PM +0200, Josua Dietze wrote:
> Am 10.08.2010 21:30, schrieb Greg KH:
> >Let the modem-manager program handle knowing which tty device to use,
> >that type of logic can usually only be detected after talking to the
> >device.
> 
> 
> Unfortunately, I keep receiving reports that modem-manager picks the
> wrong port after probing, and there is no way of setting the port
> manually in NetworkManager. This happens mostly with devices where
> the interrupt port has a number > 0. I have yet to meet a GSM modem
> device where the "interrupt rule" does *not* apply.

Then point people at the modem-manager developers :)

> I usually recommend using wvdial (autoprobing problems too) and edit
> the port directly in the config file. And just entering "gsmmodem"
> spares users the testing of all ports, some of which may seem to
> work at first but then build up a very unreliable connection.

It sounds like this is information that the modem-manager developers
would like to know about, so that they can pick the correct ports.  Or
is it networkmanager that does that these days, I can't remember, sorry.

Either way, I don't see this a function of the modeswitch program at
all.

good luck,

greg k-h