AW: [PATCH] HAL support for HSO modems

[Peter Henn]

Dear Dan and Colin,

some "short" remarks to the HAL patches I did in the udev package.
I saw the the NM just catches the first two serial ports of our WWAN modems. That is done obviously because of a hal patch, which marks these interfaces with some kind of GSM functionality. And unfortunately this patch did not make sure to mark only tty channels, which can really be used for a PPP connection with Option WWAN modems.
So I used the HAL patches, which are currently part of the hso-udev package.


But first I should explain the different interfaces, which will be offered by Option WWAM modem using a hso driver:

a) Network channel:
The hso driver supports an IP network interface, which is similar to an Ethernet interface. Unfortunately this network interface should not be seen as a Wired interfaces, but also not as a WLAN interface. We use that network like interface to increase the WWAN performance and did that specially for the Full Speed USB devices in the past to prevent data throughput bottle necks. But the network configuration and IP address setup can not be done by DHCP! Therefore you we use a AT command channel the:

b) WWAN control channel:
This tty interface can _not_ be used for a PPP modem channel. The Control channel is used to configure and setup the WWAN modem with AT commands. Note that here then the data traffic will be routed by the network interface. These has to do with the USB transmission and the hardware chips, which will be used and the bandwidth of USB channels.

c) Application port:
The Application port is very similar to the WWAN control channel. It can also _not_ be used as a PPP channel, although you can use AT commands according to the GSM specification like on the control channel. The Application port offers a 2nd dedicated interface, e.g. for sending SMS, setting up a voice call for WWAN modems, which support that.

d) Modem channel:
Some WWAN modems also support the modem channels, which can be used for a PPP. But most of them has this feature disabled in the firmware. Note that using PPP needs additional USB bandwidth compared to the transmitted IP data on the network channel.

e) Debug ports:
These tty channels are only used for debugging the WWAN modem firmware or getting debug information of the GSM/UMTS transmission or may used for firmware flashing. Some WWAN modems will also need two debug ports. Naturally a Debug port can not be used setting up a PPP connection.

f) GPS port:
Its also a tty port, which maybe used for GPS data or GPS assistant support, if this is enabled/supported by the hardware/firmware. Also that port can not be used setting up a PPP connection.



So currently the NM can only use a Modem Ports. Trying to use any other tty interface will not work setting up a GSM/UMTS data connection. Here I used the hsotype to identify the correct port, because there is naturally no guarantee, which /dev/ttyHSx is really a serial interface with real modem functionality.
Also I saw that the NM tries to use the network port and tried to do some DHCP, using some older hso drivers. Often the system answers that with system freezes. And because this "hso0" network needs some different support, here it makes no sense to let the system see that as wired interface. Therefore I modified also the network interface.


Another problem I saw in December that the HAL will not setup its internal data base correctly, if the callout is triggered just during system boot. Although the callout is really triggered, the hsotype information will not be updated correct. If a WWAN modem may be later hot-plugged, I have never seen such an effect. So this early callout trigger problem would make things not easy for fixed mounted WWAN modem in e.g. Mobil-Internet-Devices. 


If you have further questions regarding the tty channels, let me know.

Kind Regards,

Peter 

  


-----Ursprüngliche Nachricht-----
Von: Dan Williams [mailto:dcbw at redhat.com]
Gesendet: Mo 12.01.2009 18:50
An: Colin Watson
Cc: hal at lists.freedesktop.org; Peter Henn; Denis Barow
Betreff: Re: [PATCH] HAL support for HSO modems
 
On Mon, 2009-01-12 at 17:23 +0000, Colin Watson wrote:
> This pair of patches adds sufficient support for HSO modems to work out
> of the box with NetworkManager. It's somewhat similar to what's supplied
> by Option in the hso-udev package (under GPLv2+, as far as I can see),
> but I took a slightly different approach since this seemed more suitable
> for direct integration into hal/hal-info.
> 
> (I also needed
> https://lists.one-eyed-alien.net/pipermail/usb-storage/2009-January/004499.html
> to make the device go into modem mode straight away, along similar lines
> to existing quirks for other devices from the same manufacturer.)

There are few problems with this at the moment...

0001-set-info.hsotype-for-ttyHS-devices.patch
----------------------------------------------

- just make the check for ttyHSx additional to the ttyUSBx; I don't
believe there's a need for another section at all.  There's no need to
label the device as an "HSO Serial Port"; it's just a serial port like
any other serial port and doesn't deserve special treatment.  Anything
that cares whether it's an HSO serial port can simply look at the driver
attribute of the devices parent to find that out.

- the 'hsotype' stuff is not standardized and should not be added until
it is.  If you want to add port types, then lets add port types to the
HAL spec for *all* devices.  I've wanted to do this for a while, so lets
kick that discussion off.  Furthermore, the port types should be
standardized in the kernel too and exported via a standard sysfs file if
needed.  Ericsson F3507g apparently can change port types via AT
commands, so maybe we'll need some other mechanism to override this, but
if the device has hardcoded port types and only the driver knows about
them, then the driver should be exposing those.  HAL then translates
them with *standard* mappings to a standard HAL property.


0002-set-capabilities-and-modem-command-sets-for-HSO-mode.patch
---------------------------------------------------------------

- info.hsotype shouldn't be required (see above)

- "wwan" is not a standard hal capability.  Neither is "GPS" or "debug".
We need to standardize TTY port capabilities.  Care to present a
proposal?  We need to find out from Option what exactly these
capabilities are, and what the "debug" port or "Application" ports are
actually used for.


Basically, the correct way to support these things is to make a generic
specification for the things you need, rather than manufacturer-specific
hacks.  There's a need for this generic spec, but that need is also
deeper than HAL and needs to be accessible to udev as well.  Sierra,
Novatel, and Ericsson all have different port types that we need to
identify, and there's no reason to have 4 different standards for this.

Dan