Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
Steve Litt wrote: > The vast majority of documents I've read tell me that once you make the > bridge, the hardware NIC must be robbed of its IP addresses. So that's > what I did. That is the correct way to do it - though from memory it does seem to still work for host-LAN communications if you use an IP address on the physical NIC. By putting IP address(es) on the bridge, it's functionally identical to having a host virtual NIC which connects to that bridge and hence via another NIC to the LAN. To a certain extent I think the relationship between a host physical NIC and a virtual bridge it's connected to can be a bit schizophrenic as I notice that my bridge has the same MAC address as the physical NIC it's connected to - possibly it just gets the MAC address of the first NIC to be connected to it though I've never tested that. There is one thing I'm unclear about in your document, and that's the object you refer to as mybridge0. My experience is with Xen, which is configured almost identically to how you show it, and I believe uses QEMU for some functions. What you call mybridge0 and describe as a bridge, in the Xen world is (by default) called vifn.m‡ and is a virtual NIC. I'm suspecting that what you call mybridge0 is in fact a virtual NIC which connects to the bridge br0. Thus what you have is the bridge (analogous to a network switch), with a virtual NIC (mybridge0) connected to it - then there's a virtual point-point network link between that and eth0 in the guest. I'm guessing that "brctl show" will probably show something like this : bridge name bridge id STP enabled interfaces br0 8000.2cf05d7a5c1d no enp40s0 mybridge0 ‡ Where n is the id (number) of the guest, and m is the interface number starting with 0 for the first and incrementing if multiple VIFs are created. I forget how many I've got to with one guest, I don't think it was double digits although it must have been close ! I don't actually use the vifm.n format - I prefer to manually specify "meaningful" names (specified in the network section for creating a Xen guest) that make it easier to see what's connected to what. If you do see that, then it would avoid a lot of confusion to do a global find & replace to rename mybridge0 to something more like a NIC. https://wiki.xenproject.org/wiki/Xen_Networking#Paravirtualised_Network_Devices may help Oh yes, and use a different name for each guest - having two guests configured to use the same name for the host end of their virtual link produces "interesting" results. Lastly, there is a definite point of correction to be made. A bridge/switch is **NOT** "kinda-sorta like a network router in that it connects two distinct IP address ranges into one network", and nor is it a hub (though it does behave at the most basic level in the same way). A switch is IP address, and even protocol, agnostic - unless you apply filtering (e.g. ebtables on Linux) then it simply forwards packets without caring what is in them. In this respect, it is mostly definitely in no way "kinda-sorta like a network router" ! The difference between a bridge/switch and a hub is that a switch is clever about which ports it sends traffic out on. It keeps track of what MAC addresses are connected to each port, and will only send a packet out of the appropriate port. Thus point-point traffic does not appear on other links - which means that (e.g.) A can talk at full wire speed to B, while C can talk to D at full wire speed assuming that A-D are connected to different switch ports. A hub is "dumb" - every packet it receives is simply repeated out of every other port with no buffering or delay. Thus every node in the network sees all traffic, and the entire network is one flat collision domain. With a switch, it will queue packets destined for a port that is already carrying a packet - and thus splits the collision domain up. https://en.wikipedia.org/wiki/Network_switch On Linux, you can see the MAC forwarding table (for bridge br0) with "brctl showmacs br0" which should produce output like : port no mac addris local? ageing timer 1 00:16:3e:xx:xx:xx no24.96 4 00:16:3e:xx:xx:xx no 0.13 1 00:1e:0b:xx:xx:xx yes0.00 ... 00:16:3e is the OUI prefix used by Xen - so those first two lines are virtual machines Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
>Le 02/03/2021 à 12:48, Steve Litt a écrit : >> Hi all, >> >> As you know, I was asking many Qemu LAN-peer questions on this list a >> week ago. My documentation on the subject has finally achieved >> first-draft status. If you'd like to see it, go to: >> >> http://troubleshooters.com/linux/qemu/nobs.htm >> > Thanks Steve for this document. I have a question though and a >remark that tomething is missing in your block diagram. From the >response to the command "[slitt@mydesk qemu]$ ip -4 addr", it is >visible that enp40s0, the physical Ethernet adapter has no address. >This means that the host's network configuration must be modified to >operate through br0 instead of enp40s0. I mean /both/ guest and host >use the bridge. Do I understand correctly? > >-- Didier Hi Didier, The vast majority of documents I've read tell me that once you make the bridge, the hardware NIC must be robbed of its IP addresses. So that's what I did. By the time I finally got a LAN-peer setup working, after about a year on and off of trying, and 2.5 weeks of full-on work to create the LAN-peer configuration, I was so happy just to have something work that I didn't go back and do the obvious experiment of adding the addresses to enp40s0 and seeing what difference that makes. My itch was scratched :-) Right now my long term TODO list includes writing two books and creating a playlist creation system, so it will be several months before I have time to run the experiment. If you remind me in September, I just might run the experiment then. Thanks, SteveT Steve Litt Spring 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
Le 02/03/2021 à 12:48, Steve Litt a écrit : > Hi all, > > As you know, I was asking many Qemu LAN-peer questions on this list a > week ago. My documentation on the subject has finally achieved > first-draft status. If you'd like to see it, go to: > > http://troubleshooters.com/linux/qemu/nobs.htm > Thanks Steve for this document. I have a question though and a remark that tomething is missing in your block diagram. From the response to the command "[slitt@mydesk qemu]$ ip -4 addr", it is visible that enp40s0, the physical Ethernet adapter has no address. This means that the host's network configuration must be modified to operate through br0 instead of enp40s0. I mean /both/ guest and host use the bridge. Do I understand correctly? -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
Fri, 5 Mar 2021 18:56:25 + - Simon Hobson : > Florian Zieboll via Dng wrote: > > > For the sake of completeness and y'all's convenience, here a link to > > the related info in the Debianwiki: > > > > https://wiki.debian.org/NetworkInterfaceNames [quote] * UNPREDICTABILITY it turns out even after all this there are still reported cases of interfaces changing their name on a reboot. All that needs to happen is that some buggy BIOS (or some new, less buggy version of a driver module, or systemd's naming policy) changes its mind about some detail like whether or not your hardware counts as the kind that should have an ONBOARD name. There are even reports of devices changing their PCI-port numbering due to other hardware being installed. [\quote] > Did anyone else read that and think it could be summarised along the > lines of : "We thought X was badly broken, so we developed Y which will > require you to reconfigure lots of stuff - but even we have to admit > that Y is actually more broken and here's the complicated ways to get > sane behaviour" "... and if even so it remains broken, even then it's not our fault: or it is a non-compliant device (with us), or it's a hardware problem." al3xu5 -- Say NO to copyright, patents, trademarks and industrial design restrictions! Public GPG/PGP key: 8FC2 3121 2803 86E9 F7D8 B624 DA50 835B 2624 A36B pgpUbROVu7Bes.pgp Description: Firma digitale OpenPGP ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
>On Fri, 5 Mar 2021 18:56:25 + >Simon Hobson wrote: > >> Florian Zieboll via Dng wrote: >> >> > For the sake of completeness and y'all's convenience, here a link >> > to the related info in the Debianwiki: >> > >> > https://wiki.debian.org/NetworkInterfaceNames >> >> Did anyone else read that and think it could be summarised along the >> lines of : "We thought X was badly broken, so we developed Y which >> will require you to reconfigure lots of stuff - but even we have to >> admit that Y is actually more broken and here's the complicated ways >> to get sane behaviour" >> >> Simon >> > >I wonder why instead of predictable names they didn't choose >prefix+mac_address at least for initial setup of names and leave it >to user to name the interfaces they way he likes. Because Freedesktop.Org. SteveT Steve Litt Spring 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Fri, 5 Mar 2021 18:56:25 + Simon Hobson wrote: > Florian Zieboll via Dng wrote: > > > For the sake of completeness and y'all's convenience, here a link > > to the related info in the Debianwiki: > > > > https://wiki.debian.org/NetworkInterfaceNames > > Did anyone else read that and think it could be summarised along the > lines of : "We thought X was badly broken, so we developed Y which > will require you to reconfigure lots of stuff - but even we have to > admit that Y is actually more broken and here's the complicated ways > to get sane behaviour" > > Simon > I wonder why instead of predictable names they didn't choose prefix+mac_address at least for initial setup of names and leave it to user to name the interfaces they way he likes. This would have guaranteed (almost) unique persistent names and by using standard prefixes would have identified easily the class of network device. Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
Florian Zieboll via Dng wrote: > For the sake of completeness and y'all's convenience, here a link to the > related info in the Debianwiki: > > https://wiki.debian.org/NetworkInterfaceNames Did anyone else read that and think it could be summarised along the lines of : "We thought X was badly broken, so we developed Y which will require you to reconfigure lots of stuff - but even we have to admit that Y is actually more broken and here's the complicated ways to get sane behaviour" Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
Le 05/03/2021 à 07:48, tito via Dng a écrit : > On Thu, 4 Mar 2021 19:38:49 -0500 > Steve Litt wrote: > >>> On Wed, 03 Mar 2021 21:44:30 + >>> g4sra via Dng wrote: >>> In my young years I used to tinker with linux distros on floppy >>> disks and there still where eth0, eth1 and so on but no udev, >>> so where did the names came from? >> Ya know, mknod wasn't so bad. The moment inotify was invented, I could >> have created software to create devices with mknod. > Hi, > network interfaces cannot be found in /dev so I would be surprised > if they could be created with mknod. > > C Here is my interpretation: Historically, there is a property of device special files which is represented by a single bit: these special files represent either a character device or a block device. Devices which do not belong to one of these classes cannot be created by mknod, and do not show up in /dev. -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Thu, 4 Mar 2021 19:38:49 -0500 Steve Litt wrote: > > >On Wed, 03 Mar 2021 21:44:30 + > >g4sra via Dng wrote: > > >In my young years I used to tinker with linux distros on floppy > >disks and there still where eth0, eth1 and so on but no udev, > >so where did the names came from? > > Ya know, mknod wasn't so bad. The moment inotify was invented, I could > have created software to create devices with mknod. Hi, network interfaces cannot be found in /dev so I would be surprised if they could be created with mknod. Ciao, Tito > SteveT > > Steve Litt > Spring 2020 featured book: Thriving in Tough Times > http://www.troubleshooters.com/thrive > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
>On Wed, 03 Mar 2021 21:44:30 + >g4sra via Dng wrote: >In my young years I used to tinker with linux distros on floppy >disks and there still where eth0, eth1 and so on but no udev, >so where did the names came from? Ya know, mknod wasn't so bad. The moment inotify was invented, I could have created software to create devices with mknod. SteveT Steve Litt Spring 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Thu, 4 Mar 2021 11:02:08 +0100 Didier Kryn wrote: > Le 04/03/2021 à 07:46, tito via Dng a écrit : > > How Linux assigns network interface names > > The default name for Ethernet interfaces is based upon how Linux > > initializes them during device discovery. As Linux finds the network > > devices it will start numbering them starting with 0 and increasing > > sequentially. > > But what if, say, eth0 is renamed by the hotplugger before the > kernel discovers the second ethernet device? I guess the kernel > restarts with 0 which is the smallest free number. Because eth0 may > well have been renamed eth1 by the hotplugger. I didn't dig in the > kernel code to verify. > > -- Didier > > > hi, I bet the counter is increased until a free number is found for the law of laziness and least effort. Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
Quoting Steve Litt (sl...@troubleshooters.com): > As you know, I was asking many Qemu LAN-peer questions on this list a > week ago. My documentation on the subject has finally achieved > first-draft status. If you'd like to see it, go to: > > http://troubleshooters.com/linux/qemu/nobs.htm This is a very nice piece of work, Steve, and will be endlessly useful. Thank you. -- Cheers,My pid is Inigo Montoya. You kill -9 Rick Moen my parent process. Prepare to vi. r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Thu, 4 Mar 2021 07:24:50 +0100 aitor wrote: > Hi tito, > > On 4/3/21 0:47, tito via Dng wrote: > > In my young years I used to tinker with linux distros on floppy > > disks and there still where eth0, eth1 and so on but no udev, > > so where did the names came from? > > They were assigned by the kernel, i think. > > Aitor. > > Exactly, therefore udev only can modify the kernel assigned names, How Linux assigns network interface names The default name for Ethernet interfaces is based upon how Linux initializes them during device discovery. As Linux finds the network devices it will start numbering them starting with 0 and increasing sequentially. Device discovery is dependent on the device driver load order, PCI bus topology and the device driver code. On RHEL4, the device driver load order is determined by the /etc/modprobe.conf file. Device drivers assigned lower interface numbers in that file are loaded first. On RHEL5 device drivers are loaded by thehotplug subsystem, i.e. by udev, in parallel and it affects the assignment of names. When Linux loads a single device driver it will initialize and find all devices supported by that single driver first. On SLES, device drivers are loaded based on the PCI bus topology as discovered by the kernel. The PCI bus topology is composed of buses, bridges and devices. PCI devices must be connected to a PCI bus. The PCI buses are connected by PCI bridges to either other buses or to the system. The topology of the system can be viewed as a tree. Using this analogy, the devices are leaves, the system is the trunk, buses are branches and bridges exist where branches meet each other or the trunk. Searching for PCI devices in a system is accomplished by "walking the tree". The method of walking the tree was modified in the 2.6 and later kernels, thus changing the order in which devices are found. And last, each device driver will search the PCI tree for all the devices it supports. Some drivers have a list of different devices it will support and search the tree for each device in the list. Other drivers will scan the tree and, for each device, see if it is in its list of supported devices. This will also change order of how devices are found and thus its interface name. Changes in system configuration will also result in a different enumeration order. If a new network card is inserted into a PCI slot, its new position could be between two previous network devices. This may result in the new card taking over the name of a previous card in the system. The root cause of NIC enumeration mismatches is that there is currently no industry standard to enable the OS to determine the physical labeling of Ethernet ports on the motherboard. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
Hi tito, On 4/3/21 0:47, tito via Dng wrote: In my young years I used to tinker with linux distros on floppy disks and there still where eth0, eth1 and so on but no udev, so where did the names came from? They were assigned by the kernel, i think. Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 03 Mar 2021 21:44:30 + g4sra via Dng wrote: > ‐‐‐ Original Message ‐‐‐ > On Wednesday, March 3, 2021 7:54 PM, tito via Dng > wrote: > > > On Wed, 03 Mar 2021 16:15:10 + > > g4sra via Dng dng@lists.dyne.org wrote: > > > > > > > > > > > Your 'predictable' names name are being assigned by what ? > > > > > By the kernel, I suppose as you can pass a kernel command line > > parameter with grub (net.ifnames=0 or net.ifnames=1) > > to switch between eth* and en* names. > > > > > Search under /lib/udev, you will find rules that post-boot process > the kernel command line. It is very common to pass configuration > options to userspace via the kernel command line at boot. The kernel > simply ignores anything it doesn't understand. > In my young years I used to tinker with linux distros on floppy disks and there still where eth0, eth1 and so on but no udev, so where did the names came from? > > > > > I was there, I did try hard, but I was not able to make ifrename > > work reliably in the case you want to rename and reorder > > the interfaces (that is change the name and the number) > > because you change it one by one but the names you want > > are already in use by other interfaces that are up. > > > > > The key is to be imaginative with the naming, using standard network > device names is not recommended an will cause issues if anything is > hotplugged. And to demonstrate how imaginative I am and always > practise what I preach, in one router I use the following. > > wan0 // this should actually be man0 for metropolitan area network, > but I didn't like 'man' and it reaches the wide area network > eventually anyway. lan0 // local area network interface wlan0 // > wireless local area network access point interface > > In another I prefixed 'mb' for devices on the motherboard and 'ex' > for an external USB ethernet adapter. I never did check to see if > they potentially conflict as it just worked fist time trying. > > mbeth0 > mbeth1 > exeth0 > > In my top secret highly confidential system (which I would have to > Men In Black neuralise you if I revealed) I rename so that it makes > my firewall rules easy to read. > > > > > > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
‐‐‐ Original Message ‐‐‐ On Wednesday, March 3, 2021 7:54 PM, tito via Dng wrote: > On Wed, 03 Mar 2021 16:15:10 + > g4sra via Dng dng@lists.dyne.org wrote: > > > > > Your 'predictable' names name are being assigned by what ? > > By the kernel, I suppose as you can pass a kernel command line > parameter with grub (net.ifnames=0 or net.ifnames=1) > to switch between eth* and en* names. > Search under /lib/udev, you will find rules that post-boot process the kernel command line. It is very common to pass configuration options to userspace via the kernel command line at boot. The kernel simply ignores anything it doesn't understand. > > I was there, I did try hard, but I was not able to make ifrename > work reliably in the case you want to rename and reorder > the interfaces (that is change the name and the number) > because you change it one by one but the names you want > are already in use by other interfaces that are up. > The key is to be imaginative with the naming, using standard network device names is not recommended an will cause issues if anything is hotplugged. And to demonstrate how imaginative I am and always practise what I preach, in one router I use the following. wan0 // this should actually be man0 for metropolitan area network, but I didn't like 'man' and it reaches the wide area network eventually anyway. lan0 // local area network interface wlan0 // wireless local area network access point interface In another I prefixed 'mb' for devices on the motherboard and 'ex' for an external USB ethernet adapter. I never did check to see if they potentially conflict as it just worked fist time trying. mbeth0 mbeth1 exeth0 In my top secret highly confidential system (which I would have to Men In Black neuralise you if I revealed) I rename so that it makes my firewall rules easy to read. publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 03 Mar 2021 16:15:10 +
g4sra via Dng wrote:
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, March 3, 2021 3:21 PM, tito via Dng
> wrote:
>
> > On Wed, 03 Mar 2021 14:52:57 +
> > g4sra via Dng dng@lists.dyne.org wrote:
> >
>
> > > <-- huge snip -->
> > > Just for completeness should someone dig this thread up trying to
> > > solve an issue...such as a 12 port router
> > > The kernel's FDT determines the order of detection for built-in
> > > interfaces. Learn how to make them, then don't change it and the
> > > interfaces will always come up the same way.
> >
>
> > Hi,
> > Cannot confirm that as I have a board with 8 onboard ports
> >
>
> > 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection
> > (2) I219-LM (rev 31) 09:00.0 Ethernet controller: Intel Corporation
> > I211 Gigabit Network Connection (rev 03) 0a:00.0 Ethernet
> > controller: Intel Corporation I211 Gigabit Network Connection (rev
> > 03) 0b:00.0 Ethernet controller: Intel Corporation I211 Gigabit
> > Network Connection (rev 03) 0c:00.0 Ethernet controller: Intel
> > Corporation I211 Gigabit Network Connection (rev 03) 0d:00.0
> > Ethernet controller: Intel Corporation I211 Gigabit Network
> > Connection (rev 03) 0e:00.0 Ethernet controller: Intel Corporation
> > I211 Gigabit Network Connection (rev 03) 0f:00.0 Ethernet
> > controller: Intel Corporation I211 Gigabit Network Connection (rev
> > 03)
> >
>
> > and they used to come up in all possible permutations.
> > When I added a 4 port addon card
> >
>
> > 07:00.0 Ethernet controller: Intel Corporation 82576 Gigabit
> > Network Connection (rev 01) 07:00.1 Ethernet controller: Intel
> > Corporation 82576 Gigabit Network Connection (rev 01) 08:00.0
> > Ethernet controller: Intel Corporation 82576 Gigabit Network
> > Connection (rev 01) 08:00.1 Ethernet controller: Intel Corporation
> > 82576 Gigabit Network Connection (rev 01)
> >
>
> > things got even more funny.
> >
>
> > > Mask (delete, override with empty) e/udev rules and scripts and
> > > use the purpose created 'ifrename' utility. And don't use SystemD
> > > OS..
> >
>
> > eudev could do nothing because the names I would have liked where
> > in use same for ifrename.
> Correct, you can clearly not have more than one interface per name.
>
>
>
> > It works eventually if you use so called predictable new names
> > and rename to old style names but even then you cannot be sure the
> > predictable names will stay the same at next reboot.
>
> Your 'predictable' names name are being assigned by what ?
By the kernel, I suppose as you can pass a kernel command line
parameter with grub (net.ifnames=0 or net.ifnames=1)
to switch between eth* and en* names.
> > The only working solution is to:
> >
>
> > 1. at boot rename all detected interfaces to some temporary name
> > (e.g. eth*renamed) 2. rename eth*renamed to eth{0-99} by a
> > hardcoded list of mac addresses in the wanted order.
> >
>
> > 3. don't use udev it will not work (e.g delete
> > 70-net-persistent-names.rules) 4. eventually recreate
> > 70-net-persistent-names.rules on the fly at boot after having
> > renamed the interfaces with the desired names linked to mac
> > addresses.
>
> > 5. make sure 70-net-persistent-names.rules is DELETED at reboot
> > (or is on volatile storage) or chances will be good that you will
> > be locked out of your box at the next reboot.
>
>
> I believe that is exactly what I just previously posted, 'ifrename'
> does all the heavy lifting for you. No need to write scripts, parse
> the /sys filesystem, simply create '/etc/iftab', mapping each MACAddr
> to the name you wish to assign. That is the only downside, you need
> to know some prior piece of hardware information to create the
> mapping table.
I was there, I did try hard, but I was not able to make ifrename
work reliably in the case you want to rename and reorder
the interfaces (that is change the name and the number)
because you change it one by one but the names you want
are already in use by other interfaces that are up.
Ciao
Tito
> https://www.unix.com/man-page/debian/8/ifrename/
>
> https://www.unix.com/man-page/debian/5/IFTAB/
>
> > Ciao,
> > Tito
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
‐‐‐ Original Message ‐‐‐
On Wednesday, March 3, 2021 3:21 PM, tito via Dng wrote:
> On Wed, 03 Mar 2021 14:52:57 +
> g4sra via Dng dng@lists.dyne.org wrote:
>
> > <-- huge snip -->
> > Just for completeness should someone dig this thread up trying to
> > solve an issue...such as a 12 port router
> > The kernel's FDT determines the order of detection for built-in
> > interfaces. Learn how to make them, then don't change it and the
> > interfaces will always come up the same way.
>
> Hi,
> Cannot confirm that as I have a board with 8 onboard ports
>
> 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2)
> I219-LM (rev 31)
> 09:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network
> Connection (rev 03)
> 0a:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network
> Connection (rev 03)
> 0b:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network
> Connection (rev 03)
> 0c:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network
> Connection (rev 03)
> 0d:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network
> Connection (rev 03)
> 0e:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network
> Connection (rev 03)
> 0f:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network
> Connection (rev 03)
>
> and they used to come up in all possible permutations.
> When I added a 4 port addon card
>
> 07:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network
> Connection (rev 01)
> 07:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network
> Connection (rev 01)
> 08:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network
> Connection (rev 01)
> 08:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network
> Connection (rev 01)
>
> things got even more funny.
>
> > Mask (delete, override with empty) e/udev rules and scripts and use
> > the purpose created 'ifrename' utility. And don't use SystemD OS..
>
> eudev could do nothing because the names I would have liked where in use
> same for ifrename.
Correct, you can clearly not have more than one interface per name.
> It works eventually if you use so called predictable new names
> and rename to old style names but even then you cannot be sure the predictable
> names will stay the same at next reboot.
Your 'predictable' names name are being assigned by what ?
> The only working solution is to:
>
> 1. at boot rename all detected interfaces to some temporary name (e.g.
> eth*renamed)
> 2. rename eth*renamed to eth{0-99} by a hardcoded list of mac addresses in
> the
> wanted order.
>
> 3. don't use udev it will not work (e.g delete 70-net-persistent-names.rules)
> 4. eventually recreate 70-net-persistent-names.rules on the fly at boot
> after having renamed the interfaces with the desired names linked
> to mac addresses.
>
> 5. make sure 70-net-persistent-names.rules is DELETED at reboot (or is on
> volatile storage)
> or chances will be good that you will be locked out of your box at the
> next reboot.
>
I believe that is exactly what I just previously posted, 'ifrename' does all
the heavy lifting for you.
No need to write scripts, parse the /sys filesystem, simply create
'/etc/iftab', mapping each MACAddr to the name you wish to assign.
That is the only downside, you need to know some prior piece of hardware
information to create the mapping table.
https://www.unix.com/man-page/debian/8/ifrename/
https://www.unix.com/man-page/debian/5/IFTAB/
> Ciao,
> Tito
publickey - g4sra@protonmail.com - 0x42E94623.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 03 Mar 2021 14:52:57 +
g4sra via Dng wrote:
> <-- huge snip -->
>
> Just for completeness should someone dig this thread up trying to
> solve an issue...such as a 12 port router
>
> The kernel's FDT determines the order of detection for built-in
> interfaces. Learn how to make them, then don't change it and the
> interfaces will always come up the same way.
Hi,
Cannot confirm that as I have a board with 8 onboard ports
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-LM
(rev 31)
09:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection
(rev 03)
0a:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection
(rev 03)
0b:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection
(rev 03)
0c:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection
(rev 03)
0d:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection
(rev 03)
0e:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection
(rev 03)
0f:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection
(rev 03)
and they used to come up in all possible permutations.
When I added a 4 port addon card
07:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection
(rev 01)
07:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection
(rev 01)
08:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection
(rev 01)
08:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection
(rev 01)
things got even more funny.
> Mask (delete, override with empty) e/udev rules and scripts and use
> the purpose created 'ifrename' utility. And don't use SystemD OS..
eudev could do nothing because the names I would have liked where in use
same for ifrename. It works eventually if you use so called predictable new
names
and rename to old style names but even then you cannot be sure the predictable
names will stay the same at next reboot.
The only working solution is to:
1) at boot rename all detected interfaces to some temporary name (e.g.
eth*renamed)
2) rename eth*renamed to eth{0-99} by a hardcoded list of mac addresses in the
wanted order.
3) don't use udev it will not work (e.g delete 70-net-persistent-names.rules)
4) eventually recreate 70-net-persistent-names.rules on the fly at boot
after having renamed the interfaces with the desired names linked
to mac addresses.
5) make sure 70-net-persistent-names.rules is DELETED at reboot (or is on
volatile storage)
or chances will be good that you will be locked out of your box at the
next reboot.
Ciao,
Tito
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
<-- huge snip --> Just for completeness should someone dig this thread up trying to solve an issue...such as a 12 port router The kernel's FDT determines the order of detection for built-in interfaces. Learn how to make them, then don't change it and the interfaces will always come up the same way. Mask (delete, override with empty) e/udev rules and scripts and use the purpose created 'ifrename' utility. And don't use SystemD OS.. publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 15:07:14 +0100 John Hughes wrote: > On 03/03/2021 14:01, tito wrote: > > On Wed, 3 Mar 2021 10:16:13 +0100 > > John Hughes wrote: > > > >> On 02/03/2021 15:57, tito via Dng wrote: > >>> I would add that renaming of multiple cards/ports works > >>> only if you rename all of them to a different intermediate name > >>> and then back to wanted name and order otherwise renaming > >>> can fail because the name is already assigned to another > >>> card/port. > >> Just avoid the "ethX" names (because of race conditions and because > >> they're stupid). Use something descriptive. > > Hi, > > they are less stupid than enp0s0p1 or the like and mnemonically > > easier. > > lan > > wan-isp (e.g. one of my machines has wan-cogent, wan-orange...) > > Nothing mnemonic about "eth0". > > Hi, if you number your plenty ports from left to right then you know that eth0 is the first port on the left and usually position is linked with function so it is double mnemonic. In your example providers can change with time and so the interfaces' names in my view whoever the provider is it will be port eth0 and eth1 and there will be no need to change configuration files by hand. Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
Le 03/03/2021 à 14:18, Antony Stone a écrit : > I agree that "eth0" is less stupid than "enp0s0p1" etc., however I too like > the use of descriptive names such as "CableModem", "Clients", "Servers" etc. In case people like ethX names, which is my case, I just came with the idea to use letters instead of numbers, ethA, ethB etc (or lower case as the admin prefers). It's as simple as letters and disks are named with this scheme after all: sda, sdb etc. -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wednesday 03 March 2021 at 14:03:46, tito via Dng wrote: > On Wed, 3 Mar 2021 10:16:13 +0100 John Hughes wrote: > > > > Just avoid the "ethX" names (because of race conditions and because > > they're stupid). Use something descriptive. > > they are less stupid than enp0s0p1 or the like and mnemonically easier. I agree that "eth0" is less stupid than "enp0s0p1" etc., however I too like the use of descriptive names such as "CableModem", "Clients", "Servers" etc. I haven't yet come across a tool (tcpdump, tshark, ip, dhcpd etc.) which doesn't nicely handle descriptive names for interfaces. Antony. -- I bought a book on memory techniques, but I've forgotten where I put it. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 10:40:20 +0100 Florian Zieboll via Dng wrote: > On Wed, 3 Mar 2021 08:04:19 +0100 > tito via Dng wrote: > > > you can set the device names by MAC addresses at boot > > and in the past it worked as udev/eudev net-persisent-name.rules > > (but seems to be broken, optimized out nowadays). > > > Thanks, Tito, for the clue! I am using udev (resp. eudev) rules to > define the NIC names by MAC addresses and had not been aware of the > upcoming change (with buster / beowulf it is still working). Hi, it works in simple setups (few cards, few ports, only onboard chips) using the previously created net-persistent-names.rules files. In more complex setups it doesn't work because the logic to rename the interfaces to a intermediate name was ripped out so there can be name collisions and big surprises at reboot that can be fixed only by creating a systemd ?link file. Was bitten by this when setting up a router with 12 ports and had to develop a script to get it done (doesn't work well with eudev yet... because ti needs to recreate net-persistent name at boot but in volatile way) Ciao, Tito > For the sake of completeness and y'all's convenience, here a link to > the related info in the Debianwiki: > > https://wiki.debian.org/NetworkInterfaceNames > > libre Grüße, > Florian > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 10:16:13 +0100 John Hughes wrote: > On 02/03/2021 15:57, tito via Dng wrote: > > I would add that renaming of multiple cards/ports works > > only if you rename all of them to a different intermediate name > > and then back to wanted name and order otherwise renaming > > can fail because the name is already assigned to another > > card/port. > Just avoid the "ethX" names (because of race conditions and because > they're stupid). Use something descriptive. Hi, they are less stupid than enp0s0p1 or the like and mnemonically easier. Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 12:13:04 +0100 Florian Zieboll via Dng wrote: > Sure, it is more error prone to work with enx"$mac" NIC names, but as > it's probably too late for complaining, I just made my router "future > proof": > > backup /etc/: > $ cp -a /etc /etc.bkp > > cd to /etc/: > $ cd /etc/ > > delete related custom udev rules > $ rm ./udev/rules.d/7?-persistent-net-*\.rules > > define future NIC names as variables to avoid mistakes: > $ eth0_new=`udevadm test-builtin net_id /sys/class/net/eth0 > 2>/dev/null | grep "ID_NET_NAME_MAC=" | sed 's/ID_NET_NAME_MAC=//'` $ > 2>eth1_new=`udevadm test-builtin net_id /sys/class/net/eth1 > 2>2>/dev/null | grep "ID_NET_NAME_MAC=" | sed 's/ID_NET_NAME_MAC=//'` > > test run to stdout (commented lines are excluded) > $ grep -r ^[^#]*eth[0-1] ./* | sed -e "s/eth0/$eth0_new/g" -e > "s/eth1/$eth1_new/g" > > replace NIC names "inplace" (with commented lines still excluded) > $ grep -rl ^[^#]*eth[0-1] ./* | xargs -l1 sed -i -e > "s/eth0/$eth0_new/g" -e "s/eth1/$eth1_new/g" > > reboot > > so far, everything seems to work fine -_- Ooops, that was too quick: I forgot to remove the active dhcp leases under /var/lib/dhcp/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 10:49:19 +0100
Antony Stone wrote:
> On Wednesday 03 March 2021 at 10:40:20, Florian Zieboll via Dng wrote:
>
> > On Wed, 3 Mar 2021 08:04:19 +0100
> >
> > tito via Dng wrote:
> > > you can set the device names by MAC addresses at boot
> > > and in the past it worked as udev/eudev net-persisent-name.rules
> > > (but seems to be broken, optimized out nowadays).
> >
> > Thanks, Tito, for the clue! I am using udev (resp. eudev) rules to
> > define the NIC names by MAC addresses and had not been aware of the
> > upcoming change (with buster / beowulf it is still working).
> >
> > For the sake of completeness and y'all's convenience, here a link
> > to the related info in the Debianwiki:
> >
> > https://wiki.debian.org/NetworkInterfaceNames
>
> That was where I started 2½ months ago and found that things were
> certainly more complicated than they used to be under previous
> versions of De{bi,vu}an (but I did end up with a working solution).
>
> https://lists.dyne.org/lurker/message/20201212.131553.0a6af87d.en.html
Sure, it is more error prone to work with enx"$mac" NIC names, but as
it's probably too late for complaining, I just made my router "future
proof":
backup /etc/:
$ cp -a /etc /etc.bkp
cd to /etc/:
$ cd /etc/
delete related custom udev rules
$ rm ./udev/rules.d/7?-persistent-net-*\.rules
define future NIC names as variables to avoid mistakes:
$ eth0_new=`udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null |
grep "ID_NET_NAME_MAC=" | sed 's/ID_NET_NAME_MAC=//'`
$ eth1_new=`udevadm test-builtin net_id /sys/class/net/eth1 2>/dev/null |
grep "ID_NET_NAME_MAC=" | sed 's/ID_NET_NAME_MAC=//'`
test run to stdout (commented lines are excluded)
$ grep -r ^[^#]*eth[0-1] ./* | sed -e "s/eth0/$eth0_new/g" -e
"s/eth1/$eth1_new/g"
replace NIC names "inplace" (with commented lines still excluded)
$ grep -rl ^[^#]*eth[0-1] ./* | xargs -l1 sed -i -e "s/eth0/$eth0_new/g" -e
"s/eth1/$eth1_new/g"
reboot
so far, everything seems to work fine -_-
libre Grüße,
Florian
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wednesday 03 March 2021 at 10:40:20, Florian Zieboll via Dng wrote:
> On Wed, 3 Mar 2021 08:04:19 +0100
>
> tito via Dng wrote:
> > you can set the device names by MAC addresses at boot
> > and in the past it worked as udev/eudev net-persisent-name.rules
> > (but seems to be broken, optimized out nowadays).
>
> Thanks, Tito, for the clue! I am using udev (resp. eudev) rules to
> define the NIC names by MAC addresses and had not been aware of the
> upcoming change (with buster / beowulf it is still working).
>
> For the sake of completeness and y'all's convenience, here a link to the
> related info in the Debianwiki:
>
> https://wiki.debian.org/NetworkInterfaceNames
That was where I started 2½ months ago and found that things were certainly
more complicated than they used to be under previous versions of De{bi,vu}an
(but I did end up with a working solution).
https://lists.dyne.org/lurker/message/20201212.131553.0a6af87d.en.html
Antony.
--
There are two possible outcomes:
If the result confirms the hypothesis, then you've made a measurement.
If the result is contrary to the hypothesis, then you've made a discovery.
- Enrico Fermi
Please reply to the list;
please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 08:04:19 +0100 tito via Dng wrote: > you can set the device names by MAC addresses at boot > and in the past it worked as udev/eudev net-persisent-name.rules > (but seems to be broken, optimized out nowadays). Thanks, Tito, for the clue! I am using udev (resp. eudev) rules to define the NIC names by MAC addresses and had not been aware of the upcoming change (with buster / beowulf it is still working). For the sake of completeness and y'all's convenience, here a link to the related info in the Debianwiki: https://wiki.debian.org/NetworkInterfaceNames libre Grüße, Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
Of course the code was wrong; I've corrected it below...
On 03/03 19:24, Ralph Ronnquist wrote:
> On 03/03 01:06, Steve Litt wrote:
> >
> > Am I hearing correctly when I think you two are saying I can make
> > multiple network devices have determinate names (even if I don't select
> > those names) by doing something with their MAC addresses? If so, how do
> > I do it?
>
> Since you do networking setup via a script you can do this at the top
> of that script before the interfaces are configured. Something like
> the following:
>
> for IF in $(ls /sys/class/net) ; do
> case "$(ip link show $IF | awk '$1=="link/ether" {print $2;}')" in
> 4a:4a:8d:dc:d4:bf)
ip link set $IF name somewhatspecial
> ;;
> 06:22:66:ff:5a:e2)
ip link set $IF name veryspecial
> ;;
> esac
> done
>
> where you choose your own MAC addresses as case patterns and your own
> names instead of the ${blah}special .. anything unused less than 16
> 7-bit ascii is fine.
>
> That loop only works for unconfigured, "down" interfaces. In
> particular, when interfaces are configured during boot, then the
> renaming should occur before that configuration.
>
> If configuration is via hotplug handling than the hotplug handling
> would provide the enumeration, and one only need have to define the
> recognition-to-action "rules" and make sure they are used before
> confguration.
>
> Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On 03/03 01:06, Steve Litt wrote:
>
> Am I hearing correctly when I think you two are saying I can make
> multiple network devices have determinate names (even if I don't select
> those names) by doing something with their MAC addresses? If so, how do
> I do it?
Since you do networking setup via a script you can do this at the top
of that script before the interfaces are configured. Something like
the following:
for IF in $(ls /sys/class/net) ; do
case "$(ip link show $IF | awk '$1=="link/ether" {print $2;}')" in
4a:4a:8d:dc:d4:bf)
ip link set name somewhatspecial
;;
06:22:66:ff:5a:e2)
ip link set name veryspecial
;;
esac
done
where you choose your own MAC addresses as case patterns and your own
names instead of the ${blah}special .. anything unused less than 16
7-bit ascii is fine.
That loop only works for unconfigured, "down" interfaces. In
particular, when interfaces are configured during boot, then the
renaming should occur before that configuration.
If configuration is via hotplug handling than the hotplug handling
would provide the enumeration, and one only need have to define the
recognition-to-action "rules" and make sure they are used before
confguration.
Ralph.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
Le 03/03/2021 à 08:04, tito via Dng a écrit : >> Am I hearing correctly when I think you two are saying I can make >> multiple network devices have determinate names (even if I don't >> select those names) by doing something with their MAC addresses? If >> so, how do I do it? >> >> SteveT >> >> Steve Litt >> Autumn 2020 featured book: Thriving in Tough Times >> http://www.troubleshooters.com/thrive > Hi, > you can set the device names by MAC addresses at boot > and in the past it worked as udev/eudev net-persisent-name.rules > (but seems to be broken, optimized out nowadays). I love this expression, "optimised out". To stay in the same style, I consider the result of this intended "optimisation" as definitely "suboptimal" (~: -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 01:06:55 -0500 Steve Litt wrote: > > On Wed, 3 Mar 2021 13:06:45 +1100 > Ralph Ronnquist via Dng wrote: > > > On 03/03 00:19, g4sra via Dng wrote: > > > ‐‐‐ Original Message ‐‐‐ > > > On Wednesday, March 3, 2021 12:15 AM, spiralofhope > > > wrote: > > > > On Wed, 3 Mar 2021 01:34:40 +1100 > > > > Ralph Ronnquist via Dng dng@lists.dyne.org wrote: > > > > > For bare-metal hardware I believe there is a first possible > > > > > "race" between different modules (that handle different card > > > > > types), and a second possible "race" for multiple same-type > > > > > cards, which are handled by the one and same module. > > > > > > > I've always found this strange.. > > > > > > > Is there nothing like hard drives' UUID? > > > > > > Yes, MAC Addresses. > > > Sysadmins are just generally too lazy to use them. > > > > Well, this is really a fundamental problem, the "das ding an sich" > > that Kant brought up some few years ago to the merriment and > > pleasure of his contemporary philosphical minded peers. > > > > But yes, MAC address for network interfaces are alike UUID for > > partitions in that they are used for identifing the *functions* of > > devices so that further configurations can be made with respect to > > those identifications regardless of which actual, physical device > > implements them (the functions). > > Am I hearing correctly when I think you two are saying I can make > multiple network devices have determinate names (even if I don't > select those names) by doing something with their MAC addresses? If > so, how do I do it? > > SteveT > > Steve Litt > Autumn 2020 featured book: Thriving in Tough Times > http://www.troubleshooters.com/thrive Hi, you can set the device names by MAC addresses at boot and in the past it worked as udev/eudev net-persisent-name.rules (but seems to be broken, optimized out nowadays). Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 13:06:45 +1100 Ralph Ronnquist via Dng wrote: > On 03/03 00:19, g4sra via Dng wrote: > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, March 3, 2021 12:15 AM, spiralofhope > > wrote: > > > On Wed, 3 Mar 2021 01:34:40 +1100 > > > Ralph Ronnquist via Dng dng@lists.dyne.org wrote: > > > > For bare-metal hardware I believe there is a first possible > > > > "race" between different modules (that handle different card > > > > types), and a second possible "race" for multiple same-type > > > > cards, which are handled by the one and same module. > > > > > I've always found this strange.. > > > > > Is there nothing like hard drives' UUID? > > > > Yes, MAC Addresses. > > Sysadmins are just generally too lazy to use them. > > Well, this is really a fundamental problem, the "das ding an sich" > that Kant brought up some few years ago to the merriment and pleasure > of his contemporary philosphical minded peers. > > But yes, MAC address for network interfaces are alike UUID for > partitions in that they are used for identifing the *functions* of > devices so that further configurations can be made with respect to > those identifications regardless of which actual, physical device > implements them (the functions). Am I hearing correctly when I think you two are saying I can make multiple network devices have determinate names (even if I don't select those names) by doing something with their MAC addresses? If so, how do I do it? SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On 03/03 00:19, g4sra via Dng wrote: > ‐‐‐ Original Message ‐‐‐ > On Wednesday, March 3, 2021 12:15 AM, spiralofhope > wrote: > > > On Wed, 3 Mar 2021 01:34:40 +1100 > > Ralph Ronnquist via Dng dng@lists.dyne.org wrote: > > > For bare-metal hardware I believe there is a first possible "race" > > > between different modules (that handle different card types), and a > > > second possible "race" for multiple same-type cards, which are handled > > > by the one and same module. > > > I've always found this strange.. > > > Is there nothing like hard drives' UUID? > > Yes, MAC Addresses. > Sysadmins are just generally too lazy to use them. Well, this is really a fundamental problem, the "das ding an sich" that Kant brought up some few years ago to the merriment and pleasure of his contemporary philosphical minded peers. But yes, MAC address for network interfaces are alike UUID for partitions in that they are used for identifing the *functions* of devices so that further configurations can be made with respect to those identifications regardless of which actual, physical device implements them (the functions). The same function (e.g. partition) can then be transferred to a different physical device without needing to change those configurations. Between a physical device and the function you find the adapter, which implements actual device control and makes the device be of a class, so that software can access it by virtue of a class API. The names "eth0" and such then corresponds to the disk adapter naming like "sda" and such; they are identification labels for the adapters rather than for the actual devices that the adapters operate on. I think Lewis Carroll had a stab at this issue as well in "Through The Looking Glass" where the name of the Black Knight was called something... or how it was. Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
‐‐‐ Original Message ‐‐‐ On Wednesday, March 3, 2021 12:15 AM, spiralofhope wrote: > On Wed, 3 Mar 2021 01:34:40 +1100 > Ralph Ronnquist via Dng dng@lists.dyne.org wrote: > > > For bare-metal hardware I believe there is a first possible "race" > > between different modules (that handle different card types), and a > > second possible "race" for multiple same-type cards, which are handled > > by the one and same module. > > I've always found this strange.. > > Is there nothing like hard drives' UUID? > Yes, MAC Addresses. Sysadmins are just generally too lazy to use them. publickey - g4sra@protonmail.com - 0x42E94623.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 01:34:40 +1100 Ralph Ronnquist via Dng wrote: > For bare-metal hardware I believe there is a first possible "race" > between different modules (that handle different card types), and a > second possible "race" for multiple same-type cards, which are handled > by the one and same module. I've always found this strange.. Is there nothing like hard drives' UUID? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 01:34:40 +1100 Ralph Ronnquist via Dng wrote: > On 02/03 14:29, tito wrote: > > On Wed, 3 Mar 2021 00:06:27 +1100 > > Ralph Ronnquist via Dng wrote: > > > > > On 02/03 06:48, Steve Litt wrote: > > > > Hi all, > > > > > > > > As you know, I was asking many Qemu LAN-peer questions on this > > > > list a week ago. My documentation on the subject has finally > > > > achieved first-draft status. If you'd like to see it, go to: > > > > > > > > http://troubleshooters.com/linux/qemu/nobs.htm > > > > > > Thank you for the dedication :) > > > > > > The following are three specific comments to your write-up: > > > > > > 1) Re the name "eth0" of the VM guest network interface; this > > > name is invented by the kernel module that gets loaded by the > > > kernel upon discovery of the hardware unit. It's not a Qemu > > > naming; it's the Linux kernel (module). > > > > > > Afaik, all Ethernet kernel modules will name the adapters they > > > discover in the "ethN" series of names, and there is no way to > > > tell them to do something else. > > > > > > But the hotplug handling subsystem comes in later, i.e. after > > > that the adapter has been registered with the kernel name, and > > > possibly renames the adapter as per the one or the other funnily > > > named naming scheme. That is for instance how your Void Linux > > > ends up with the name "enp42s0". > > > > > > The intended default in Devuan is to *not* rename the adapater in > > > the hotplug subsystem (aka udev or eudev) but rather retain the > > > name that the module assigned. Of course, it's still possible to > > > have hotplug code (aka rules) to rename the adapters, but that's > > > not the intended default in Devuan. > > > > > > Note: I say "intended default" because any particular installation > > > typically has further layers of software that also might bring in > > > hotplug handling deviations that implements a different "local > > > default". > > > > Hi, > > nonetheless even in devuan you have no guarantee that your > > network interface will come up always with the same name > > (unless you have only one) as bios quirks and pnp enumeration > > can change the order of network interface discovery and thus > > their naming. > > > > Ciao, > > Tito > > > ... > > Yes that is true for bare-metal hardware. But I think that in a Qemu > emulation the device order is fully determinstic and therefore that > randomness doesn't come up. > > For bare-metal hardware I believe there is a first possible "race" > between different modules (that handle different card types), and a > second possible "race" for multiple same-type cards, which are handled > by the one and same module. Yep, experienced all of them mixed in various manners on my routers same module race different modules race onboard and addon cards race > In theory each and every actual network device should have a globally > unique MAC address, and for that reason one might want the adapter > names to be functionally dependent on that, so as to have any one > actual device always have the same adapter name (when it comes to > networking configuration time). > > The crux for that is that renaming happens in hotplug handling or > later. I.e. each card will be renamed after having got an initial > module-assigned name, and also at that time any other card may have at > random either their initial module-assigned name or their name after > renaming. And of course, an interface may only be renamed if > unconfigured. I would add that renaming of multiple cards/ports works only if you rename all of them to a different intermediate name and then back to wanted name and order otherwise renaming can fail because the name is already assigned to another card/port. Ciao, Tito > Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On 02/03 14:29, tito wrote: > On Wed, 3 Mar 2021 00:06:27 +1100 > Ralph Ronnquist via Dng wrote: > > > On 02/03 06:48, Steve Litt wrote: > > > Hi all, > > > > > > As you know, I was asking many Qemu LAN-peer questions on this list > > > a week ago. My documentation on the subject has finally achieved > > > first-draft status. If you'd like to see it, go to: > > > > > > http://troubleshooters.com/linux/qemu/nobs.htm > > > > Thank you for the dedication :) > > > > The following are three specific comments to your write-up: > > > > 1) Re the name "eth0" of the VM guest network interface; this name is > > invented by the kernel module that gets loaded by the kernel upon > > discovery of the hardware unit. It's not a Qemu naming; it's the Linux > > kernel (module). > > > > Afaik, all Ethernet kernel modules will name the adapters they > > discover in the "ethN" series of names, and there is no way to tell > > them to do something else. > > > > But the hotplug handling subsystem comes in later, i.e. after that the > > adapter has been registered with the kernel name, and possibly renames > > the adapter as per the one or the other funnily named naming scheme. > > That is for instance how your Void Linux ends up with the name > > "enp42s0". > > > > The intended default in Devuan is to *not* rename the adapater in the > > hotplug subsystem (aka udev or eudev) but rather retain the name that > > the module assigned. Of course, it's still possible to have hotplug > > code (aka rules) to rename the adapters, but that's not the intended > > default in Devuan. > > > > Note: I say "intended default" because any particular installation > > typically has further layers of software that also might bring in > > hotplug handling deviations that implements a different "local > > default". > > Hi, > nonetheless even in devuan you have no guarantee that your > network interface will come up always with the same name > (unless you have only one) as bios quirks and pnp enumeration > can change the order of network interface discovery and thus > their naming. > > Ciao, > Tito > > ... Yes that is true for bare-metal hardware. But I think that in a Qemu emulation the device order is fully determinstic and therefore that randomness doesn't come up. For bare-metal hardware I believe there is a first possible "race" between different modules (that handle different card types), and a second possible "race" for multiple same-type cards, which are handled by the one and same module. In theory each and every actual network device should have a globally unique MAC address, and for that reason one might want the adapter names to be functionally dependent on that, so as to have any one actual device always have the same adapter name (when it comes to networking configuration time). The crux for that is that renaming happens in hotplug handling or later. I.e. each card will be renamed after having got an initial module-assigned name, and also at that time any other card may have at random either their initial module-assigned name or their name after renaming. And of course, an interface may only be renamed if unconfigured. Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On Wed, 3 Mar 2021 00:06:27 +1100 Ralph Ronnquist via Dng wrote: > On 02/03 06:48, Steve Litt wrote: > > Hi all, > > > > As you know, I was asking many Qemu LAN-peer questions on this list > > a week ago. My documentation on the subject has finally achieved > > first-draft status. If you'd like to see it, go to: > > > > http://troubleshooters.com/linux/qemu/nobs.htm > > Thank you for the dedication :) > > The following are three specific comments to your write-up: > > 1) Re the name "eth0" of the VM guest network interface; this name is > invented by the kernel module that gets loaded by the kernel upon > discovery of the hardware unit. It's not a Qemu naming; it's the Linux > kernel (module). > > Afaik, all Ethernet kernel modules will name the adapters they > discover in the "ethN" series of names, and there is no way to tell > them to do something else. > > But the hotplug handling subsystem comes in later, i.e. after that the > adapter has been registered with the kernel name, and possibly renames > the adapter as per the one or the other funnily named naming scheme. > That is for instance how your Void Linux ends up with the name > "enp42s0". > > The intended default in Devuan is to *not* rename the adapater in the > hotplug subsystem (aka udev or eudev) but rather retain the name that > the module assigned. Of course, it's still possible to have hotplug > code (aka rules) to rename the adapters, but that's not the intended > default in Devuan. > > Note: I say "intended default" because any particular installation > typically has further layers of software that also might bring in > hotplug handling deviations that implements a different "local > default". Hi, nonetheless even in devuan you have no guarantee that your network interface will come up always with the same name (unless you have only one) as bios quirks and pnp enumeration can change the order of network interface discovery and thus their naming. Ciao, Tito > > 2) Re VM client gateway with DHCP configuration. This belongs to the > (default) configuration of the DHCP client daemon on the VM client. > That configuration, in /etc/dhcp/dhclient.conf, includes the setting > to ask for the "router" from the DHCP service, which in itself has a > configuration of this, i.e. which router to tell the client(s) to use. > > The normal setup for that is that the router also provides the DHCP > service and thus is configured to nominate itself as networking > gateway. > > 3) Re specifying the physical device on the host to connect to the > bridge; when using the "bridge" type netdev setup it will create a tap > device with an invented name, and afaik there is no easy way to play > with that one. It is automatic and hidden, but if a tap of the > invented name happens to exist already then it will be used. > > If you instead use the "tap" type netdev setup you may specify the > names of both the tap (to create unless pre-existing) and bridge > (pre-existing) in the parameters. > > regards, > > Ralph. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
On 02/03 06:48, Steve Litt wrote: > Hi all, > > As you know, I was asking many Qemu LAN-peer questions on this list a > week ago. My documentation on the subject has finally achieved > first-draft status. If you'd like to see it, go to: > > http://troubleshooters.com/linux/qemu/nobs.htm Thank you for the dedication :) The following are three specific comments to your write-up: 1) Re the name "eth0" of the VM guest network interface; this name is invented by the kernel module that gets loaded by the kernel upon discovery of the hardware unit. It's not a Qemu naming; it's the Linux kernel (module). Afaik, all Ethernet kernel modules will name the adapters they discover in the "ethN" series of names, and there is no way to tell them to do something else. But the hotplug handling subsystem comes in later, i.e. after that the adapter has been registered with the kernel name, and possibly renames the adapter as per the one or the other funnily named naming scheme. That is for instance how your Void Linux ends up with the name "enp42s0". The intended default in Devuan is to *not* rename the adapater in the hotplug subsystem (aka udev or eudev) but rather retain the name that the module assigned. Of course, it's still possible to have hotplug code (aka rules) to rename the adapters, but that's not the intended default in Devuan. Note: I say "intended default" because any particular installation typically has further layers of software that also might bring in hotplug handling deviations that implements a different "local default". 2) Re VM client gateway with DHCP configuration. This belongs to the (default) configuration of the DHCP client daemon on the VM client. That configuration, in /etc/dhcp/dhclient.conf, includes the setting to ask for the "router" from the DHCP service, which in itself has a configuration of this, i.e. which router to tell the client(s) to use. The normal setup for that is that the router also provides the DHCP service and thus is configured to nominate itself as networking gateway. 3) Re specifying the physical device on the host to connect to the bridge; when using the "bridge" type netdev setup it will create a tap device with an invented name, and afaik there is no easy way to play with that one. It is automatic and hidden, but if a tap of the invented name happens to exist already then it will be used. If you instead use the "tap" type netdev setup you may specify the names of both the tap (to create unless pre-existing) and bridge (pre-existing) in the parameters. regards, Ralph. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] My Qemu LAN-peer documentation is now in its first draft
Hi all, As you know, I was asking many Qemu LAN-peer questions on this list a week ago. My documentation on the subject has finally achieved first-draft status. If you'd like to see it, go to: http://troubleshooters.com/linux/qemu/nobs.htm SteveT Steve Litt Autumn 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
