Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #201812 > unrolled thread

Mystery interface reported by ip.

Started bypeter@easthope.ca
First post2018-10-28 20:00 +0100
Last post2018-11-09 18:10 +0100
Articles 11 — 3 participants

Back to article view | Back to linux.debian.user

Contents

  Mystery interface reported by ip. peter@easthope.ca - 2018-10-28 20:00 +0100
    Re: Mystery interface reported by ip. Reco <recoverym4n@enotuniq.net> - 2018-10-28 20:10 +0100
    Re: Mystery interface reported by ip. peter@easthope.ca - 2018-10-30 18:30 +0100
      Re: Mystery interface reported by ip. Reco <recoverym4n@enotuniq.net> - 2018-10-30 19:50 +0100
        Re: Mystery interface reported by ip. peter@easthope.ca - 2018-11-02 14:30 +0100
          Re: Mystery interface reported by ip. Reco <recoverym4n@enotuniq.net> - 2018-11-09 18:00 +0100
            Re: Mystery interface reported by ip. peter@easthope.ca - 2018-11-12 22:40 +0100
              Re: Mystery interface reported by ip. Reco <recoverym4n@enotuniq.net> - 2018-11-13 07:10 +0100
              Subject: Re: Mystery interface reported by ip. peter@easthope.ca - 2018-11-13 16:40 +0100
          Re: Mystery interface reported by ip. peter@easthope.ca - 2018-11-09 18:00 +0100
            Re: Mystery interface reported by ip. Greg Wooledge <wooledg@eeg.ccf.org> - 2018-11-09 18:10 +0100

#201812 — Mystery interface reported by ip.

Frompeter@easthope.ca
Date2018-10-28 20:00 +0100
SubjectMystery interface reported by ip.
Message-ID<wNYs2-Sp-11@gated-at.bofh.it>
root@joule:/etc# ip link show | grep rename
4: rename4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000

root@joule:/etc# find . -type f -exec grep "rename4" '{}' \; -print
root@joule:/etc#

So ip reports an interface named rename4 but it doesn't 
appear anywhere in /etc/.  Where does the name originate?

Thanks,           ... Peter E.
 
-- 
Message composed and transmitted by software designed to avoid the 
need, overhead and vulnerability of antivirus software.

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel: +1 360 639 0202                                  +1 
http://easthope.ca/Peter.html              Bcc: peter at easthope. ca

[toc] | [next] | [standalone]

#201814

FromReco <recoverym4n@enotuniq.net>
Date2018-10-28 20:10 +0100
Message-ID<wNYBH-1aU-7@gated-at.bofh.it>
In reply to#201812
	Hi.

On Sun, Oct 28, 2018 at 11:18:09AM -0700, peter@easthope.ca wrote:
> root@joule:/etc# ip link show | grep rename
> 4: rename4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> 
> root@joule:/etc# find . -type f -exec grep "rename4" '{}' \; -print
> root@joule:/etc#
> 
> So ip reports an interface named rename4 but it doesn't 
> appear anywhere in /etc/.  Where does the name originate?

Udev failed to rename this interface to some Predictable™ name.
I'd search dmesg for clues.

Reco

[toc] | [prev] | [next] | [standalone]

#201898

Frompeter@easthope.ca
Date2018-10-30 18:30 +0100
Message-ID<wOG02-1ss-17@gated-at.bofh.it>
In reply to#201812
On Sun, Oct 28, 2018 at 11:18:09AM -0700, peter@easthope.ca wrote:
> > root@joule:/etc# ip link show | grep rename
> > 4: rename4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> > 
> > root@joule:/etc# find . -type f -exec grep "rename4" '{}' \; -print
> > root@joule:/etc#
> > 
> > So ip reports an interface named rename4 but it doesn't 
> > appear anywhere in /etc/.  Where does the name originate?

    From: Reco <recoverym4n@enotuniq.net>
    Date: Sun, 28 Oct 2018 22:07:46 +0300
> Udev failed to rename this interface to some Predictable™ name.
> I'd search dmesg for clues.

root@joule:/etc# dmesg | grep rename
[    1.547879] e100 0000:02:08.0 LocLCS218301788: renamed from eth0
[   20.974490] asix 1-6:1.0 LocLCS1788: renamed from eth1
[   20.997121] asix 1-3:1.0 rename3: renamed from eth0

So eth0 was renamed to LocLCS218301788.  

root@joule:/etc/udev# find . -type f -exec grep "eth0" '{}' \; -print
#ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
./rules.d/70-persistent-net.rules

eth0 is defined in 70-persistent-net.rules.
Why rename it?

LocLCS218301788 existed previously in 
/etc/udev/rules.d/70-persistent-net.rules but I shortened the name to 
LocLCS1788; as evident here.

root@joule:/etc# grep 1788 /etc/udev/rules.d/70-persistent-net.rules
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="LocLCS1788"

The old name "LocLCS218301788" was dredged up from somewhere 
outside /etc/.  Where?  Old NIC names are cached? 

Thanks,             ... Peter E.



-- 
Message composed and transmitted by software designed to avoid the 
need, overhead and vulnerability of antivirus software.

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel: +1 360 639 0202                                  +1 
http://easthope.ca/Peter.html              Bcc: peter at easthope. ca

[toc] | [prev] | [next] | [standalone]

#201902

FromReco <recoverym4n@enotuniq.net>
Date2018-10-30 19:50 +0100
Message-ID<wOHfr-285-5@gated-at.bofh.it>
In reply to#201898
	Hi.

On Tue, Oct 30, 2018 at 09:39:13AM -0700, peter@easthope.ca wrote:
> On Sun, Oct 28, 2018 at 11:18:09AM -0700, peter@easthope.ca wrote:
> > > root@joule:/etc# ip link show | grep rename
> > > 4: rename4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
> > > 
> > > root@joule:/etc# find . -type f -exec grep "rename4" '{}' \; -print
> > > root@joule:/etc#
> > > 
> > > So ip reports an interface named rename4 but it doesn't 
> > > appear anywhere in /etc/.  Where does the name originate?
>
> > Udev failed to rename this interface to some Predictable™ name.
> > I'd search dmesg for clues.
> 
> root@joule:/etc# dmesg | grep rename
> [    1.547879] e100 0000:02:08.0 LocLCS218301788: renamed from eth0
> [   20.974490] asix 1-6:1.0 LocLCS1788: renamed from eth1
> [   20.997121] asix 1-3:1.0 rename3: renamed from eth0
> 
> So eth0 was renamed to LocLCS218301788.  

It's funnier.
Your onboard 100Mbit card (judging from e100) was renamed to LocLCS218301788.
Next USB NIC (asix) was discovered, and renamed to LocLCS1788.
And yet another USB interface (asix) was discovered, which got 'kernel'
name eth0, and it should have been renamed to the same LocLCS218301788.
Since you had an interface called LocLCS218301788 by then, third rename
failed, and you was left with intermediate 'renameN' name.


> 
> root@joule:/etc/udev# find . -type f -exec grep "eth0" '{}' \; -print
> #ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
> ./rules.d/70-persistent-net.rules
> 
> eth0 is defined in 70-persistent-net.rules.
> Why rename it?

Because it's commented out? I see '#ATTR' in the beginning of the line.


> LocLCS218301788 existed previously in 
> /etc/udev/rules.d/70-persistent-net.rules but I shortened the name to 
> LocLCS1788; as evident here.
> 
> root@joule:/etc# grep 1788 /etc/udev/rules.d/70-persistent-net.rules
> ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="LocLCS1788"

So you try to rename anything that's named 'eth*' to a single name
LocLCS1788? I suspect that this rule's broken.

> 
> The old name "LocLCS218301788" was dredged up from somewhere 
> outside /etc/.  Where?  Old NIC names are cached? 

Have you rebuilt initrd after the last udev rule changes?

Reco

[toc] | [prev] | [next] | [standalone]

#201996

Frompeter@easthope.ca
Date2018-11-02 14:30 +0100
Message-ID<wPHGq-5Km-21@gated-at.bofh.it>
In reply to#201902
> > root@joule:/etc/udev# find . -type f -exec grep "eth0" '{}' \; -print
> > #ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
> > ./rules.d/70-persistent-net.rules
> > 
> > eth0 is defined in 70-persistent-net.rules.
> > Why rename it?
    
   From: Reco <recoverym4n@enotuniq.net>
    Date: Tue, 30 Oct 2018 21:47:15 +0300
> Because it's commented out? I see '#ATTR' in the beginning of the line.

My reply was composed poorly.  udev rules are too long for one line and 
I break them in two with \ at the end of the first line.  Consequently 
"find . -type f -exec grep "eth0" '{}' \; -print" gives only the 2nd section 
of the rule.  When I'm home again in a week or so, will have another look 
at this and make a better report.

> So you try to rename anything that's named 'eth*' to a single name
> LocLCS1788? I suspect that this rule's broken.

That isn't the intention. To simplify and rationalize configuration of 
shorewall, interfaces used for the local network are given names 
prefixed with Loc.  That is the Loc zone of shorewall.  Interfaces in 
the DMZ are prefixed with Dmz.  The second part of the name, such as 
ACS29H400713 is taken directly from the label on the USB adapter.  
That would make a name LocACS29H400713.  One other complication is 
that shorewall or openvpn didn't recognize an interface name correctly 
when the length exceeded about a dozen characters.  To work around 
that and still have unique names I removed some of the characters 
following ACS.  Eg. LocACS29H400713 => LocACS0713.  All worked 
perfectly until I switched the internet connection from cable to LTE. 

> Have you rebuilt initrd after the last udev rule changes?

Almost certain that the last initrd rebuild was prior to the last 
udev rule change.  For sure the system has been rebooted since 
the last rule change.  Therefore udev reloaded rules after the 
initrd rebuild and prior to the info in my previous message. 

When I have access to the machine again, will review this dodgy 
picture and make a better reply.  About a week hence.

Thanks,                 ... P.

-- 
Message composed and transmitted by software designed to avoid the 
need, overhead and vulnerability of antivirus software.

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel: +1 360 639 0202                                  +1 
http://easthope.ca/Peter.html              Bcc: peter at easthope. ca

[toc] | [prev] | [next] | [standalone]

#202293

FromReco <recoverym4n@enotuniq.net>
Date2018-11-09 18:00 +0100
Message-ID<wSiit-30Y-1@gated-at.bofh.it>
In reply to#201996
	Hi.

On Fri, Nov 09, 2018 at 08:11:06AM -0800, peter@easthope.ca wrote:
>     From: peter@easthope.ca
>     Date: Fri, 02 Nov 2018 06:03:42 -0700
> > ... will have another look at this and make a better report.
> 
> So here is the effective content of /etc/udev/rules.d/70-persistent-net.rules.  
> (The definition of collect follows and is in http://easthope.ca/DebianPage.html .)
> 
> peter@joule:~$ collect /etc/udev/rules.d/70*
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1d:7e:00:ee:9f", \
> ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="LocLCS1788"
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e8:94:f6:24:83:52", \
> ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a0:f3:c1:0a:28:f7", \
> ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan1"
> 
> LocLCS1788 is present and LocLCS218301788 is absent.  Nevertheless, LocLCS218301788 
> surfaces here.

Ok, let's do it the hard way.

udevadm info /sys/class/net/LocLCS218301788
udevadm trigger /sys/class/net/LocLCS218301788

and, while we're at it,

udevadm info /sys/class/net/rename4
udevadm trigger /sys/class/net/rename4

Reco

[toc] | [prev] | [next] | [standalone]

#202344

Frompeter@easthope.ca
Date2018-11-12 22:40 +0100
Message-ID<wTs65-6Zt-7@gated-at.bofh.it>
In reply to#202293
*	From: Reco <recoverym4n@enotuniq.net>
*	Date: Fri, 9 Nov 2018 19:56:24 +0300
> Ok, let's do it the hard way.
> 
> udevadm info /sys/class/net/LocLCS218301788

peter@joule:~$ udevadm info /sys/class/net/LocLCS218301788
P: /devices/pci0000:00/0000:00:1e.0/0000:02:08.0/net/LocLCS218301788
E: DEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:02:08.0/net/LocLCS218301788
E: ID_BUS=pci
E: ID_MODEL_FROM_DATABASE=82562EZ 10/100 Ethernet Controller
E: ID_MODEL_ID=0x1050
E: ID_NET_DRIVER=e100
E: ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
E: ID_NET_NAME_MAC=enx0007e978a8b0
E: ID_NET_NAME_PATH=enp2s8
E: ID_OUI_FROM_DATABASE=Intel Corporation
E: ID_PATH=pci-0000:02:08.0
E: ID_PATH_TAG=pci-0000_02_08_0
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: ID_VENDOR_ID=0x8086
E: IFINDEX=2
E: INTERFACE=LocLCS218301788
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/LocLCS218301788
E: TAGS=:systemd:
E: USEC_INITIALIZED=1550444

> udevadm trigger /sys/class/net/LocLCS218301788

peter@joule:~$ udevadm trigger /sys/class/net/LocLCS218301788
[no output]

> udevadm info /sys/class/net/rename4

peter@joule:~$ udevadm info /sys/class/net/rename4
Unknown device, --name=, --path=, or absolute path in /dev/ or /sys expected.

> udevadm trigger /sys/class/net/rename4

peter@joule:~$ udevadm trigger /sys/class/net/rename4
unable to open the device '/sys/class/net/rename4'

Thanks,                       ... Peter E.

-- 
Message composed and transmitted by software designed to avoid the 
need, overhead and vulnerability of antivirus software.

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel: +1 360 639 0202                                  +1 
http://easthope.ca/Peter.html              Bcc: peter at easthope. ca

[toc] | [prev] | [next] | [standalone]

#202351

FromReco <recoverym4n@enotuniq.net>
Date2018-11-13 07:10 +0100
Message-ID<wTA3D-3Vk-1@gated-at.bofh.it>
In reply to#202344
	Hi.

On Mon, Nov 12, 2018 at 12:54:11PM -0800, peter@easthope.ca wrote:
> *	From: Reco <recoverym4n@enotuniq.net>
> *	Date: Fri, 9 Nov 2018 19:56:24 +0300
> > Ok, let's do it the hard way.
> > 
> > udevadm info /sys/class/net/LocLCS218301788
> 
> peter@joule:~$ udevadm info /sys/class/net/LocLCS218301788
> P: /devices/pci0000:00/0000:00:1e.0/0000:02:08.0/net/LocLCS218301788
> E: DEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:02:08.0/net/LocLCS218301788
> E: ID_BUS=pci
> E: ID_MODEL_FROM_DATABASE=82562EZ 10/100 Ethernet Controller
> E: ID_MODEL_ID=0x1050
> E: ID_NET_DRIVER=e100
> E: ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
> E: ID_NET_NAME_MAC=enx0007e978a8b0
> E: ID_NET_NAME_PATH=enp2s8
> E: ID_OUI_FROM_DATABASE=Intel Corporation
> E: ID_PATH=pci-0000:02:08.0
> E: ID_PATH_TAG=pci-0000_02_08_0
> E: ID_PCI_CLASS_FROM_DATABASE=Network controller
> E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
> E: ID_VENDOR_FROM_DATABASE=Intel Corporation
> E: ID_VENDOR_ID=0x8086
> E: IFINDEX=2
> E: INTERFACE=LocLCS218301788
> E: SUBSYSTEM=net
> E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/LocLCS218301788
> E: TAGS=:systemd:
> E: USEC_INITIALIZED=1550444
> 
> > udevadm trigger /sys/class/net/LocLCS218301788
> 
> peter@joule:~$ udevadm trigger /sys/class/net/LocLCS218301788
> [no output]

That's unusual, to say the least. And what about this:

udevadm test /sys/class/net/LocLCS218301788

Reco

[toc] | [prev] | [next] | [standalone]

#202360 — Subject: Re: Mystery interface reported by ip.

Frompeter@easthope.ca
Date2018-11-13 16:40 +0100
SubjectSubject: Re: Mystery interface reported by ip.
Message-ID<wTIXf-17j-3@gated-at.bofh.it>
In reply to#202344
> That's unusual, to say the least.

Definitely beyond my experience.

> And what about this:
> udevadm test /sys/class/net/LocLCS218301788

Will report on that when at the site again November 
20 or so.  

Thanks,             ... Peter E.



-- 
Message composed and transmitted by software designed to avoid the 
complication, overhead and vulnerability of antivirus software.

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel: +1 360 639 0202                                  +1 
http://easthope.ca/Peter.html              Bcc: peter at easthope. ca

[toc] | [prev] | [next] | [standalone]

#202294

Frompeter@easthope.ca
Date2018-11-09 18:00 +0100
Message-ID<wSiit-30Y-3@gated-at.bofh.it>
In reply to#201996
    From: peter@easthope.ca
    Date: Fri, 02 Nov 2018 06:03:42 -0700
> ... will have another look at this and make a better report.

So here is the effective content of /etc/udev/rules.d/70-persistent-net.rules.  
(The definition of collect follows and is in http://easthope.ca/DebianPage.html .)

peter@joule:~$ collect /etc/udev/rules.d/70*
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1d:7e:00:ee:9f", \
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="LocLCS1788"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e8:94:f6:24:83:52", \
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a0:f3:c1:0a:28:f7", \
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan1"

LocLCS1788 is present and LocLCS218301788 is absent.  Nevertheless, LocLCS218301788 
surfaces here.

peter@joule:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
 group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: LocLCS218301788: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DE
FAULT group default qlen 1000
    link/ether 00:07:e9:78:a8:b0 brd ff:ff:ff:ff:ff:ff
3: LocLCS1788: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast sta
te DOWN mode DEFAULT group default qlen 1000
    link/ether 00:1d:7e:00:ee:9f brd ff:ff:ff:ff:ff:ff
4: rename4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT gr
oup default qlen 1000
    link/ether 00:1d:7e:01:3d:c2 brd ff:ff:ff:ff:ff:ff
5: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORM
ANT group default qlen 1000
    link/ether e8:94:f6:24:83:52 brd ff:ff:ff:ff:ff:ff

How does the system dredge up LocLCS218301788?  A cache?  Haven't seen 
a mention of wicd caching old device names.  Other ideas?

Thanks,                ... Peter E.

=======================================
peter@joule:~$ declare -f collect
collect ()
{
    case $# in
        0)
            echo "collect  <filename>"
        ;;
        1)
            egrep -v '(^ *#)|(^ *$)' $1
        ;;
        *)
            echo "Too many arguments."
        ;;
    esac
}

-- 
Message composed and transmitted by software designed to avoid the 
need, overhead and vulnerability of antivirus software.

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel: +1 360 639 0202                                  +1 
http://easthope.ca/Peter.html              Bcc: peter at easthope. ca

[toc] | [prev] | [next] | [standalone]

#202295

FromGreg Wooledge <wooledg@eeg.ccf.org>
Date2018-11-09 18:10 +0100
Message-ID<wSisa-3jQ-11@gated-at.bofh.it>
In reply to#202294
On Fri, Nov 09, 2018 at 08:11:06AM -0800, peter@easthope.ca wrote:
>         1)
>             egrep -v '(^ *#)|(^ *$)' $1
>         ;;

https://mywiki.wooledge.org/Quotes

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web