[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Mystery interface reported by ip.

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

Reply to: