netdev: operstate UNKNOWN for loopback and other devices?

netdev: operstate UNKNOWN for loopback and other devices?

[Stephen Hemminger]

It looks like loopback and other software devices never get the operstate
set correctly. Not a serious problem, but it is incorrect.

For example:
$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 

tap0             UNKNOWN        ca:ff:ed:bf:96:a0 <BROADCAST,PROMISC,UP,LOWER_UP> 
tap1             UNKNOWN        36:f5:16:d1:4c:15 <BROADCAST,PROMISC,UP,LOWER_UP> 

For wireless and ethernet devices kernel reports UP and DOWN correctly.

Looks like some missing bits in dev_open but not sure exactly where.

Re: netdev: operstate UNKNOWN for loopback and other devices?

[Jakub Kicinski]

On Tue, 19 Nov 2024 15:37:03 -0800 Stephen Hemminger wrote:
> It looks like loopback and other software devices never get the operstate
> set correctly. Not a serious problem, but it is incorrect.
> 
> For example:
> $ ip -br link
> lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
> 
> tap0             UNKNOWN        ca:ff:ed:bf:96:a0 <BROADCAST,PROMISC,UP,LOWER_UP> 
> tap1             UNKNOWN        36:f5:16:d1:4c:15 <BROADCAST,PROMISC,UP,LOWER_UP> 
> 
> For wireless and ethernet devices kernel reports UP and DOWN correctly.
> 
> Looks like some missing bits in dev_open but not sure exactly where.

I thought it means the driver doesn't have any notion of the carrier,
IOW the carrier will never go down. Basically those drivers don't
call netif_carrier_{on,off}() at all, and rely on carrier being on
by default at netdev registration.

Re: netdev: operstate UNKNOWN for loopback and other devices?

[Stephen Hemminger]

On Tue, 19 Nov 2024 19:23:53 -0800
Jakub Kicinski <kuba@kernel.org> wrote:

> On Tue, 19 Nov 2024 15:37:03 -0800 Stephen Hemminger wrote:
> > It looks like loopback and other software devices never get the operstate
> > set correctly. Not a serious problem, but it is incorrect.
> > 
> > For example:
> > $ ip -br link
> > lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
> > 
> > tap0             UNKNOWN        ca:ff:ed:bf:96:a0 <BROADCAST,PROMISC,UP,LOWER_UP> 
> > tap1             UNKNOWN        36:f5:16:d1:4c:15 <BROADCAST,PROMISC,UP,LOWER_UP> 
> > 
> > For wireless and ethernet devices kernel reports UP and DOWN correctly.
> > 
> > Looks like some missing bits in dev_open but not sure exactly where.  
> 
> I thought it means the driver doesn't have any notion of the carrier,
> IOW the carrier will never go down. Basically those drivers don't
> call netif_carrier_{on,off}() at all, and rely on carrier being on
> by default at netdev registration.

Tap device does have concept of pseudo carrier. If application has file descriptor
open it reports carrier, if the device is present but application has not opened
it then carrier is reported down.

Re: netdev: operstate UNKNOWN for loopback and other devices?

[Yong Wang]

On Wed, 20 Nov 2024 09:08:32 -0800
Stephen Hemminger <stephen@networkplumber.org> wrote:


>On Tue, 19 Nov 2024 19:23:53 -0800
>Jakub Kicinski <kuba@kernel.org> wrote:
>
>> On Tue, 19 Nov 2024 15:37:03 -0800 Stephen Hemminger wrote:
>> > It looks like loopback and other software devices never get the operstate
>> > set correctly. Not a serious problem, but it is incorrect.
>> > 
>> > For example:
>> > $ ip -br link
>> > lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
>> > 
>> > tap0             UNKNOWN        ca:ff:ed:bf:96:a0 <BROADCAST,PROMISC,UP,LOWER_UP> 
>> > tap1             UNKNOWN        36:f5:16:d1:4c:15 <BROADCAST,PROMISC,UP,LOWER_UP> 
>> > 
>> > For wireless and ethernet devices kernel reports UP and DOWN correctly.
>> > 
>> > Looks like some missing bits in dev_open but not sure exactly where.  
>> 
>> I thought it means the driver doesn't have any notion of the carrier,
>> IOW the carrier will never go down. Basically those drivers don't
>> call netif_carrier_{on,off}() at all, and rely on carrier being on
>> by default at netdev registration.
>
>Tap device does have concept of pseudo carrier. If application has file descriptor
>open it reports carrier, if the device is present but application has not opened
>it then carrier is reported down.
>

The UNKNOWN operstate sometimes is misleading, for loopback device, the fix seems 
simple, we can just set 'dev->operstate = IF_OPER_UP' in its initialization function
or add ndo_open handler to call netif_carrier_no, as discussed in thread at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754987#89.

Re: netdev: operstate UNKNOWN for loopback and other devices?

[Ido Schimmel]

On Mon, Feb 03, 2025 at 09:17:08PM +0200, Yong Wang wrote:
> 
> On Wed, 20 Nov 2024 09:08:32 -0800
> Stephen Hemminger <stephen@networkplumber.org> wrote:
> 
> 
> >On Tue, 19 Nov 2024 19:23:53 -0800
> >Jakub Kicinski <kuba@kernel.org> wrote:
> >
> >> On Tue, 19 Nov 2024 15:37:03 -0800 Stephen Hemminger wrote:
> >> > It looks like loopback and other software devices never get the operstate
> >> > set correctly. Not a serious problem, but it is incorrect.
> >> > 
> >> > For example:
> >> > $ ip -br link
> >> > lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
> >> > 
> >> > tap0             UNKNOWN        ca:ff:ed:bf:96:a0 <BROADCAST,PROMISC,UP,LOWER_UP> 
> >> > tap1             UNKNOWN        36:f5:16:d1:4c:15 <BROADCAST,PROMISC,UP,LOWER_UP> 
> >> > 
> >> > For wireless and ethernet devices kernel reports UP and DOWN correctly.
> >> > 
> >> > Looks like some missing bits in dev_open but not sure exactly where.  
> >> 
> >> I thought it means the driver doesn't have any notion of the carrier,
> >> IOW the carrier will never go down. Basically those drivers don't
> >> call netif_carrier_{on,off}() at all, and rely on carrier being on
> >> by default at netdev registration.
> >
> >Tap device does have concept of pseudo carrier. If application has file descriptor
> >open it reports carrier, if the device is present but application has not opened
> >it then carrier is reported down.
> >
> 
> The UNKNOWN operstate sometimes is misleading, for loopback device, the fix seems 
> simple, we can just set 'dev->operstate = IF_OPER_UP' in its initialization function

This comes from the VRF driver which is the only driver I found that
does that:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b87ab6b8e517563be372b69bdabd96c672458547

> or add ndo_open handler to call netif_carrier_no, as discussed in thread at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754987#89.

I don't see a lot of value in changing this ancient behavior, but I
don't think the loopback device should be singled out either. Otherwise,
some time from now someone will complain about a different device.