qmi_wwan not using netif_carrier_*()

qmi_wwan not using netif_carrier_*()

[Tanjeff-Nicolai Moos]

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)?


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@eltec.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.

Re: qmi_wwan not using netif_carrier_*()

[Andrew Lunn]

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.

      Andrew

Re: qmi_wwan not using netif_carrier_*()

[Dan Williams]

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.

Dan

Re: qmi_wwan not using netif_carrier_*()

[Andrew Lunn]

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?

    Andrew

Re: qmi_wwan not using netif_carrier_*()

[Dan Williams]

On Wed, 2020-06-17 at 19:24 +0200, Andrew Lunn 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?

Most of these devices do not use DHCP either, but get the IP through
the control channel (QMI, MBIM, AT commands, etc).  I'd just watch for
an IP address on the interface instead.

Dan

Re: qmi_wwan not using netif_carrier_*()

[Tanjeff-Nicolai Moos]

On Wed, 17 Jun 2020 19:24:34 +0200
Andrew Lunn <andrew@lunn.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...

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@eltec.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.

Re: qmi_wwan not using netif_carrier_*()

[Dan Williams]

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@lunn.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@eltec.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.
>