Date:   Thu, 18 Jun 2020 15:49:43 -0500
From:   Dan Williams <dcbw@...hat.com>
To:     Tanjeff-Nicolai Moos <tmoos@...ec.de>, Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org
Subject: Re: qmi_wwan not using netif_carrier_*()

On Thu, 2020-06-18 at 12:08 +0200, Tanjeff-Nicolai Moos wrote:
> 
> On Wed, 17 Jun 2020 19:24:34 +0200
> Andrew Lunn <andrew@...n.ch> wrote:
> 
> > On Wed, Jun 17, 2020 at 11:59:33AM -0500, Dan Williams wrote:
> > > On Wed, 2020-06-17 at 18:48 +0200, Andrew Lunn wrote:
> > > > On Wed, Jun 17, 2020 at 03:21:53PM +0200, Tanjeff-Nicolai Moos
> > > > wrote:
> > > > > Hi netdevs,
> > > > > 
> > > > > Kernel version:
> > > > > 
> > > > >   I'm working with kernel 4.14.137 (OpenWRT project). But I
> > > > > looked
> > > > > at
> > > > >   the source of kernel 5.7 and found the same situation.
> > > > > 
> > > > > Problem:
> > > > > 
> > > > >   I'm using the qmi_wwan driver for a Sierra Wireless EM7455
> > > > > LTE
> > > > >   modem. This driver does not use
> > > > >   netif_carrier_on()/netif_carrier_off() to update its link
> > > > > status.
> > > > >   This confuses ledtrig_netdev which uses netif_carrier_ok()
> > > > > to
> > > > > obtain
> > > > >   the link status.
> > > > > 
> > > > > My solution:
> > > > > 
> > > > >   As a solution (or workaround?) I would try:
> > > > > 
> > > > >   1) In drivers/net/usb/qmi_wwan.c, lines 904/913: Add the
> > > > > flag
> > > > >      FLAG_LINK_INTR.
> > > > > 
> > > > >   2) In drivers/net/usb/usbnet.c, functions usbnet_open() and
> > > > >      usbnet_stop(): Add a call to netif_carrier_*(),
> > > > >      but only if FLAG_LINK_INTR is set.
> > > > > 
> > > > > Question:
> > > > > 
> > > > >   Is this the intended way to use FLAG_LINK_INTR and
> > > > > netif_carrier_*()?
> > > > >   Or is there another recommended way to obtain the link
> > > > > status of
> > > > >   network devices (I could change ledtrig_netdev)?
> > > > 
> > > > Hi Tanjeff
> > > > 
> > > > With Ethernet, having a carrier means there is a link partner,
> > > > the
> > > > layer 2 of the OSI 7 layer stack model is working. If the
> > > > interface
> > > > is
> > > > not open()ed, it clearly should not have carrier. However, just
> > > > because it is open, does not mean it has carrier. The cable
> > > > could be
> > > > unplugged, etc.
> > > > 
> > > > This is an LTE modem. What does carrier mean here? I don't know
> > > > if it
> > > > is well defined, but i would guess it is connected to a base
> > > > station
> > > > which is offering service. I'm assuming you are interested in
> > > > data
> > > > here, not wanting to make a 911/999/112/$EMERGENCY_SERVICE call
> > > > which
> > > > in theory all base stations should accept.
> > > > 
> > > > Is there a way to get this state information from the hardware?
> > > > That
> > > > would be the correct way to set the carrier.
> > > 
> > > There isn't. All the setup that would result in IFF_LOWER_UP (eg
> > > ability to pass packets to the cellular network) happens over
> > > channels
> > > *other* than the ethernet one. eg CDC-WDM, CDC-ACM, CDC-MBIM, AT
> > > commands, QMI commands, MBIM commands, etc.
> > > 
> > > Something in userspace handles the actual IP-level connection
> > > setup and
> > > once that's done, only then do you really have IFF_LOWER_UP. One
> > > way to
> > > solve this could be to require userspace connection managers to
> > > manage
> > > the carrier state of the device, which is possible for some
> > > drivers
> > > already IIRC.
> > 
> > So Tanjeff, what is you real use case here? I assume you want to
> > control an LED so it is on when the LTE modem is connected? Could
> > you
> > export the LED to user space and have a dhclient-enter/exit script
> > change
> > the state of the LED?
> The LED should show whether the link is up (data transfer is
> possible),
> and it should blink when data is being transferred. This
> functionality
> is provided by the ledtrig_netdev driver. The blinking works already,
> but the indicated link state is wrong, because the netif_carrier_ok()
> function /always/ reports true.
> 
> When I control the LED by userspace software, it would probably not
> blink during xfer. Therefore I would prefer to stick with
> ledtrig_netdev (also, it will give me the same behavior as for WLAN,
> where I also use ledtrig_netdev).
> 
> I observed that sierra.c does call netif_carrier_off(). Since I'm
> using
> a Sierra modem, maybe I'm actually using this driver (sorry for my
> limited knowledge), and things should already work? Then I would have
> some misconfiguration...

The Sierra driver is only for their very old (2000s and early 2010s)
devices that use DirectIP mode. It's very unlikely you're using it.

I don't think you're going to get qmi_wwan to set the carrier state
like you expect. That would require qmi_wwan to snoop on the QMI
control messages passed back and forth from the modem to userspace, and
have some knowledge of the data sessions. That's not something qmi_wwan
should be doing.

Instead, you can have a script that looks for an IP address assigned to
the interface and if so, check its packet counters and if they change,
blink the LED. Doesn't need to be done from kernel space.
Dan

> I also observed that "ip address" shows the flags "UP" and "LOWER_UP"
> when the interface is up. The kernel seems to know whether "the link"
> is up, although I don't know which link is considered. Maybe it is
> possible to get that knowledge from within qmi_wwan or usbnet and to
> set the carrier accordingly.
> 
> Kind regards, tanjeff
> 
> 
> --
> 
> Tanjeff-Nicolai Moos
> Dipl.-Inf. (FH)
> Senior Software Engineer
> 
> ELTEC Elektronik AG, Mainz
> _________________________
> 
> Fon     +49 6131 918 342
> Fax     +49 6131 918 195
> Email   tmoos@...ec.de
> Web     www.eltec.de
> 
> ________________________________
> 
> 
> *********************************************************
> ELTEC Elektronik AG
> Galileo-Galilei-Straße 11
> D-55129 Mainz
> 
> Vorstand: Peter Albert
> Aufsichtsratsvorsitzender: Andreas Kochhäuser
> 
> Registergericht: Amtsgericht Mainz
> Registernummer: HRB 7038
> Ust-ID: DE 149 049 790
> *********************************************************
> Wichtiger Hinweis:
> Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige
> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
> irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts,
> eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich
> untersagt.
> Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-
> Mail. Evtl. Anhänge dieser Nachricht wurden auf Viren überprüft!
> Jede Form von Vervielfältigung, Abänderung, Verbreitung oder
> Veröffentlichung dieser E-Mail Nachricht ist untersagt! Das Verwenden
> von Informationen aus dieser Nachricht für irgendwelche Zwecke ist
> strengstens untersagt.
> Es gelten unsere Allgemeinen Geschäftsbedingungen, zu finden unter 
> www.eltec.de.
> 

Powered by blists - more mailing lists