[PATCH] HAL support for HSO modems

[Dan Williams]

On Mon, 2009-01-26 at 17:21 +0100, Peter Henn wrote:
> Dear Dan,
> 
> please find the answers inline ...
> 
> Dan Williams schrieb:
> > On Tue, 2009-01-13 at 01:22 +0100, Peter Henn wrote: 
> >> 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.
> > 
> > I'm putting together a generic proposal for modem port/channel tags, got
> > a few questions below.  Hopefully we can ship these in standard upstream
> > software and then you won't have to maintain hso-udev anymore :)
> > 
> Hmm, hso-udev supports also the selective suspend setting of the driver.

Ok, what are the cases where that shouldn't be enabled by default?  Are
there bugs somewhere that cause it to fail for some cases?

> >> 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:
> > 
> > Right; this will never get exposed to userspace as a TTY since it's
> > handled internally by the driver, but this type is useful for modems
> > that don't work this way.  We'll tag existing ports/channels that *do*
> > use PPP with a "data" type.
> > 
> >> 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.
> > 
> > Can the "Application" port also be used as the WWAN control channel, or
> > does it reject the OWANCALL/OWANDATA commands?
> > 
> Yes, the application port can establish the OWANCALL/OWANDATA commands.

Ok; does this mean that we can basically use the Application,
Application2, Modem, and Control ports interchangeably?

> >> 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.
> > 
> > Ok; I assume these also support the full range of AT commands that the
> > Application and Control ports do, but also support ATDT?  Or do they
> > also reject OWANCALL/OWANDATA?
> > 
> No, it can also be used for OWANCALL/OWANDATA. But keep in mind that
> most of the Option WWAN-modems in the field with "Version 4" interface
> will have the modem channel disabled!

Right; I've assumed in NetworkManager that *any* device driven by HSO
will use the OWANCALL/OWANDATA + netdevice mechanism, not PPP.

> >> 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.
> > 
> > Do these ports use a proprietary protocol?
> > 
> Yes and no. That depends on the modem chipset used and naturally the
> firmware.

Ok; thanks.  It would be good to be able to figure this out in the
driver (or through probing the port) so that we know what devices we can
actually use without additional (possibly) binary-only software.

> >> 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.
> > 
> > Does this port reject GSM commands?  Is there a list somewhere of what
> > AT commands the port supports, or is it also a proprietary protocol?
> > Sierra Wireless devices use (non-standard) AT commands for GPS on some
> > of their devices, for example.
> > 
> I will clarify this for you.

Ok, thanks!  Not a problem if it does filter AT commands, but I'm just
wondering if all the Application/Control/Modem/etc ports can be used for
all the same things, or whether they really do have hardcoded purposes
in the firmware.

> >> 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.
> > 
> > Incorrect, NetworkManager 0.7 handles HSO devices just fine provided
> > that the correct capabilities are tagged onto the ports in HAL via .fdi
> > files.  I'm working on moving the functionality into a udev prober, and
> > that prober should also be able to handle the port types that drivers
> > expose.
> > 
> Oh, which Option WWAN modem did you use for testing?

I have an iCON 225 and a GlobeSurfer iCON 7.2 which I used for adding
this support to NetworkManager.

> >> 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.
> > 
> > Also incorrect; NetworkManager 0.7 will correctly use
> > AT_OWANCALL/AT_OWANDATA to configure hso-driven devices correctly.
> > Ethernet interfaces are not necessarily "wired" interfaces, and weren't
> > before hso came along anyway, so components of the system need to handle
> > it as such.  However, the driver also needs to know what requests are
> > invalid, and return appropriate errors, so as not to do things like hang
> > the system.
> Yepp, I haven't check this. It could be a reason.
> 
> > 
> > Note that some devices like the Ericsson F3507g, *do* require the system
> > to run DHCP on the ethernet/Network channel after doing the GSM setup on
> > the control channel.  So we need to support both methods in software
> > like NetworkManager.
> > 
> >> 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. 
> > 
> > This could also be a problem not with HAL, but with kernel/driver uevent
> > event ordering.  There are a couple races between drivers and userspace
> > (search the HAL list archives) and while HAL needs to be able to handle
> > them, sometimes drivers or the kernel itself also needs to be fixed.
> I wonder about that, because I add in the callout an simple:
> 	 echo "triggered" >>/tmp/callout-test.log
> and saw that the callout _was_ triggered, but the info was not updated
> in the hal database.

you can use '/sbin/udevadm --monitor' to see what actual kernel events
are being pushed out to userspace, and these are the ones that HAL also
listens to.  You can then also use "lshal --monitor" to see what events
HAL emits to userspace.  HAL may need workarounds at coldplug time that
it doesn't need at hotplug time, because coldplug uses direct inspection
of /sys and other things, while hotplug mostly relies on the uevents
coming from the kernel.

Dan

> 
> Kind Regards,
> 
> Peter
> 
> > 
> > Thanks!
> > Dan
> > 
> >>
> >>
> >> -----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