[PATCH] HAL support for HSO modems
dcbw at redhat.com
Mon Jan 26 10:51:02 PST 2009
On Mon, 2009-01-26 at 19:01 +0100, Peter Henn wrote:
> Hi Dan,
> Dan Williams schrieb:
> > 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?
> Yes it is enabled by default.
> > Are
> > there bugs somewhere that cause it to fail for some cases?
> Oh USB selective suspend is pretty new and only a small couple of
> drivers currently using that feature. So there is a general risk.
> Also there exists some risks with very old WWAN-modem firmware, which
> may show trouble with that feature itself or may freeze your host. So it
> can be helpful to know how that USB selective suspend can be disabled.
> This is currently handled with the osetsuspend script, which is also
> called from udev during the WWAN-modem hotplug or after coldstart.
Ideally the driver turns it on at hardware load time, and there's a
module parameter (and a sysfs file) to turn it off it it stops your
machine from booting. The driver should also be able to detect older
firmware versions and ensure that selective suspend is forced off if the
firmware is too old. Then you can get rid of osetsuspend too.
> >>>> 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?
> Yes, that is my knowledge about that, but should naturally not be done
> in parallel ;-)
> The basic idea/history was having an extra port for extra application
> like SMS daemon. Note that only a small number of WWAN-modems have a 2nd
> application port.
> >>>> 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.
> Yes. But if the hsotype="modem" is shown by the hso driver in sysfs, you
> can also use that tty channel for PPP.
NM isn't handling that case yet since I haven't seen these modems in the
wild, nobody has complained about them, and I assumed that anything
driven by 'hso' would *also* expose the netdevice which I could use for
> >>>> 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.
> Maybe there is a misunderstanding. Flashing means really saving the
> firmware in the NAND/NOR flash of the WWAN-modem. So flashing is only
> needed, if you like to upgrade the firmware.
> But in general a debug port should be seen as binary serial interface
> and should only be used with special debug tools. The tools currently
Thanks for the clarification. I guess I was really just wondering if
there was an AT protocol for flashing the new firmware, or if the
firmware flasher is a binary-only app that uses a proprietary protocol
to do the job. You said "it depends on the modem chipset" which I took
to mean that some might not use a proprietary protocol, and some might.
> look on the USB device/vendor id and on the hsotype="debug" (or using
> the device node links /dev/wdiaga0 or /dev/diagb0, which should be setup
> by a udev rule).
Why change the device name? The software should be smart enough to
figure out which device is which and just use it... you shouldn't need
to do any linking. Device names are *not* stable, and software that
expects them to be is broken.
> >>>> 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.
> Yepp, I too. ;-) But most of that stuff a historical based.
> I recommend better using a central control port and a daemon, which can
> support all that client applications, e.g. by D-BUS. Therefore the
> application port should be reserved for that daemon.
> That means, if the NM likes to setup "only" a data connection by
> OWANCALL, it would be very nice, if NM uses only the hsotype="control"
> channel and keep the other ports just unused OR it uses the
> hsotype="modem" and setup a PPP connection OR do both in parallel, which
> may make sense, if you like to setup two connections to different APNs.
> But the last configuration is another story ...
As long as all the ports allow all the commands, it shouldn't matter
which port which app chooses, as long as two apps don't try to set up
connections or anything. If NM can't open a port (which the SMS program
may have claimed) then NM would just try a different port. I don't
really see why the port types are necessary here.
> >>>> 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.
> Ok. Do I get it correct that you currently working on NetworkManager
> development form RedHat, which naturally also helps other Distros?
That's correct; I maintain NetworkManager and am paid to do so by Red
Hat. Other distros (mainly SUSE) also participate actively in the
development by contributing features and patches, and most distributions
are consumers of NetworkManager as well, even they don't participate
actively in its development.
> >>>> 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.
> Ok, that means the 'event' has arrived, but the hal may not have the
> right view on the sysfs at the coldplug time.
Right, because at coldplug time (ie, when HAL starts up) there are no
events from the kernel, because the hardware is already plugged in. So
HAL has to go read through sysfs and other places to get the information
that would normally have been sent in the uevent. There could be a bug
in the HAL coldplug codepaths that means the end result is different
between coldplug and hotplug.
> > 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
More information about the hal