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

Groups > comp.os.linux.networking > #4003 > unrolled thread

Fixed IP addreses on network.

Back to article view | Back to comp.os.linux.networking

Contents

  Fixed IP addreses on network. Doug  Laidlaw  <laidlaws@hotkey.net.au> - 2017-03-30 03:23 +1100
    Re: Fixed IP addreses on network. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-03-29 20:57 +0200
      Re: Fixed IP addreses on network. Doug Laidlaw <laidlaws@hotkey.net.au> - 2017-03-30 06:20 +1100
    Re: Fixed IP addreses on network. William Unruh <unruh@invalid.ca> - 2017-03-29 21:01 +0000
      Re: Fixed IP addreses on network. Doug Laidlaw <laidlaws@hotkey.net.au> - 2017-03-30 23:32 +1100
        Re: Fixed IP addreses on network. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-03-30 20:28 +0200
        Re: Fixed IP addreses on network. Gordon <Gordon@clear.net.nz> - 2017-03-31 05:23 +0000
    Re: Fixed IP addreses on network. robert.wolfe@wildcat.uuhec.net (Robert Wolfe) - 2017-03-30 13:27 +0000
    Re: Fixed IP addreses on network. robert.wolfe@wildcat.uuhec.net (Robert Wolfe) - 2017-03-30 13:28 +0000
      Re: Fixed IP addreses on network. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-03-30 20:34 +0200
        Re: Fixed IP addreses on network. Richard Kettlewell <invalid@invalid.invalid> - 2017-03-30 20:20 +0100
          Re: Fixed IP addreses on network. Gordon <Gordon@clear.net.nz> - 2017-03-31 05:44 +0000
        Re: Fixed IP addreses on network. "Jonathan N. Little" <lws4art@gmail.com> - 2017-03-30 16:56 -0400
          Re: Fixed IP addreses on network. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-03-31 00:18 +0200
            Re: Fixed IP addreses on network. "Jonathan N. Little" <lws4art@gmail.com> - 2017-03-30 18:52 -0400
              Re: Fixed IP addreses on network. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-03-31 19:38 +0200
    Re: Fixed IP addreses on network. ray carter <ray@zianet.com> - 2017-03-30 14:04 +0000
    Re: Fixed IP addreses on network. "Jonathan N. Little" <lws4art@gmail.com> - 2017-03-30 12:33 -0400
      Re: Fixed IP addreses on network. "Carlos E. R." <robin_listas@es.invalid> - 2017-03-31 01:59 +0200
        Re: Fixed IP addreses on network. "Jonathan N. Little" <lws4art@gmail.com> - 2017-03-30 23:10 -0400
          Re: Fixed IP addreses on network. Gordon <Gordon@clear.net.nz> - 2017-03-31 05:34 +0000
            Re: Fixed IP addreses on network. "Jonathan N. Little" <lws4art@gmail.com> - 2017-03-31 08:43 -0400
            Re: Fixed IP addreses on network. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-03-31 14:10 +0000
              Re: Fixed IP addreses on network. "Jonathan N. Little" <lws4art@gmail.com> - 2017-03-31 11:02 -0400
              Re: Fixed IP addreses on network. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-03-31 19:45 +0200
          Re: Fixed IP addreses on network. "Carlos E. R." <robin_listas@es.invalid> - 2017-04-01 02:01 +0200
            Re: Fixed IP addreses on network. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-04-01 09:41 +0200
              Re: Fixed IP addreses on network. "Carlos E. R." <robin_listas@es.invalid> - 2017-04-01 12:50 +0200
                Re: Fixed IP addreses on network. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-04-02 00:17 +0200
                  Re: Fixed IP addreses on network. "Carlos E. R." <robin_listas@es.invalid> - 2017-04-02 01:22 +0200
                    Re: Fixed IP addreses on network. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-04-02 11:41 +0200
                      Re: Fixed IP addreses on network. Jerry Peters <jerry@example.invalid> - 2017-04-02 20:00 +0000
                  Re: Fixed IP addreses on network. Jerry Peters <jerry@example.invalid> - 2017-04-02 19:57 +0000
                    Re: Fixed IP addreses on network. William Unruh <unruh@invalid.ca> - 2017-04-03 00:07 +0000
                      Re: Fixed IP addreses on network. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-04-06 23:58 +0200
    Re: Fixed IP addreses on network. John Carter <me@mymailsvr.org> - 2017-03-31 04:51 +0000
    Re: Fixed IP addreses on network. Dave <noone$$@llondel.org> - 2017-04-02 14:39 -0700

Page 2 of 2 — ← Prev page 1 [2]

#4024

On 2017-03-31, Jonathan N. Little <lws4art@gmail.com> wrote:
> Carlos E. R. wrote:
>> On 2017-03-30 18:33, Jonathan N. Little wrote:
>>
>>> If you have Raspbian OS the default it is a Debian version of Linux. I
>>> have Ubuntu on mine, but the process is basically the same.
>>>
>>> 1) First discover the interface ID of your adapter. Legacy naming
>>> convention was eth0, eth1, wlan0, etc.; but with introduction of systemd
>>> the naming convention has changed. Example in a terminal window run
>>> command "ifconfig":
>>
>> That change wasn't due to systemd. It happened at the same time, but
>> this thing comes from the kernel.
>>
>
>
> Really? I did not get that impression: 
><https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/>
>

Oh boy! Systemd is all about getting into bed with the kernel. It "orders"
the kernel about.

However it does seem that one can tell systemd to just let the old
interfaces rule ok, going by the above link Kool! must try it, as I never
had any problem with eth0. I kind of grew up with her and she works just
fine.

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

#4026

Gordon wrote:
> On 2017-03-31, Jonathan N. Little <lws4art@gmail.com> wrote:
>> Carlos E. R. wrote:
>>> On 2017-03-30 18:33, Jonathan N. Little wrote:
>>>
>>>> If you have Raspbian OS the default it is a Debian version of Linux. I
>>>> have Ubuntu on mine, but the process is basically the same.
>>>>
>>>> 1) First discover the interface ID of your adapter. Legacy naming
>>>> convention was eth0, eth1, wlan0, etc.; but with introduction of systemd
>>>> the naming convention has changed. Example in a terminal window run
>>>> command "ifconfig":
>>>
>>> That change wasn't due to systemd. It happened at the same time, but
>>> this thing comes from the kernel.
>>>
>>
>>
>> Really? I did not get that impression:
>> <https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/>
>>
>
> Oh boy! Systemd is all about getting into bed with the kernel. It "orders"
> the kernel about.

Yes, its appetite knows not bounds. Most worrisome.
>
> However it does seem that one can tell systemd to just let the old
> interfaces rule ok, going by the above link Kool! must try it, as I never
> had any problem with eth0. I kind of grew up with her and she works just
> fine.
>

Well, the only issue I had was when replacing a NIC on a server or 
moving server to new hardware via image or hard drive swap. Not too 
difficult to fix with a simple edit to udev rules, but can trip you up 
at first.

-- 
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

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

#4027

On Fri, 2017-03-31, Gordon wrote:
> On 2017-03-31, Jonathan N. Little <lws4art@gmail.com> wrote:
>> Carlos E. R. wrote:
>>> On 2017-03-30 18:33, Jonathan N. Little wrote:
>>>
>>>> If you have Raspbian OS the default it is a Debian version of Linux. I
>>>> have Ubuntu on mine, but the process is basically the same.
>>>>
>>>> 1) First discover the interface ID of your adapter. Legacy naming
>>>> convention was eth0, eth1, wlan0, etc.; but with introduction of systemd
>>>> the naming convention has changed. Example in a terminal window run
>>>> command "ifconfig":
>>>
>>> That change wasn't due to systemd. It happened at the same time, but
>>> this thing comes from the kernel.
>>>
>>
>>
>> Really? I did not get that impression: 
>><https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/>
>>
>
> Oh boy! Systemd is all about getting into bed with the kernel. It "orders"
> the kernel about.
>
> However it does seem that one can tell systemd to just let the old
> interfaces rule ok, going by the above link Kool! must try it, as I never
> had any problem with eth0. I kind of grew up with her and she works just
> fine.

Easier to remember than "enxb827eb109bc0", at least ...

BTW, Debian Stable has systemd, but uses the traditional naming.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#4028

Jorgen Grahn wrote:
> On Fri, 2017-03-31, Gordon wrote:
>> On 2017-03-31, Jonathan N. Little <lws4art@gmail.com> wrote:
>>> Carlos E. R. wrote:
>>>> On 2017-03-30 18:33, Jonathan N. Little wrote:
>>>>
>>>>> If you have Raspbian OS the default it is a Debian version of Linux. I
>>>>> have Ubuntu on mine, but the process is basically the same.
>>>>>
>>>>> 1) First discover the interface ID of your adapter. Legacy naming
>>>>> convention was eth0, eth1, wlan0, etc.; but with introduction of systemd
>>>>> the naming convention has changed. Example in a terminal window run
>>>>> command "ifconfig":
>>>>
>>>> That change wasn't due to systemd. It happened at the same time, but
>>>> this thing comes from the kernel.
>>>>
>>>
>>>
>>> Really? I did not get that impression:
>>> <https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/>
>>>
>>
>> Oh boy! Systemd is all about getting into bed with the kernel. It "orders"
>> the kernel about.
>>
>> However it does seem that one can tell systemd to just let the old
>> interfaces rule ok, going by the above link Kool! must try it, as I never
>> had any problem with eth0. I kind of grew up with her and she works just
>> fine.
>
> Easier to remember than "enxb827eb109bc0", at least ...

That's for sure! However this PI interface seems over the top, my other 
systems have a more reasonable IDs such as this few examples

ifconfig | egrep -v "^\s|^$"
enp12s0   Link encap:Ethernet  HWaddr 3c:97:0e:cc:55:0a
lo        Link encap:Local Loopback
wlp6s0    Link encap:Ethernet  HWaddr a4:4e:31:c9:a1:40

ifconfig | egrep -v "^\s|^$"
enp3s0    Link encap:Ethernet  HWaddr d4:3d:7e:b6:ba:a8
lo        Link encap:Local Loopback

ifconfig | egrep -v "^\s|^$"
eno1      Link encap:Ethernet  HWaddr a0:48:1c:01:d0:f0
lo        Link encap:Local Loopback
wlo1      Link encap:Ethernet  HWaddr 48:d2:24:1f:ab:a2

-- 
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

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

#4030

Le 31/03/2017 à 16:10, Jorgen Grahn a écrit :
>
> Easier to remember than "enxb827eb109bc0", at least ...
>
> BTW, Debian Stable has systemd, but uses the traditional naming.

This has changed in the current Debian testing. By default it uses the 
new "predictable" naming unless a udev naming rule exists for an 
interface. So an upgraded system will keep the old names for already 
known interfaces and the new naming for new interfaces. A new system 
will use the new naming for all interfaces.

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

#4031

On 2017-03-31 05:10, Jonathan N. Little wrote:
> Carlos E. R. wrote:
>> On 2017-03-30 18:33, Jonathan N. Little wrote:
>>
>>> If you have Raspbian OS the default it is a Debian version of Linux. I
>>> have Ubuntu on mine, but the process is basically the same.
>>>
>>> 1) First discover the interface ID of your adapter. Legacy naming
>>> convention was eth0, eth1, wlan0, etc.; but with introduction of systemd
>>> the naming convention has changed. Example in a terminal window run
>>> command "ifconfig":
>>
>> That change wasn't due to systemd. It happened at the same time, but
>> this thing comes from the kernel.
>>
> 
> 
> Really? I did not get that impression:
> <https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/>

Read it carefully :-)

For one thing, it is not really systemd, but udev which is involved. It
comes now in the same package, that's true.

Now read this paragraph right at the start:

"The classic naming scheme for network interfaces applied by the kernel
is to simply assign names beginning with "eth0", "eth1", ... to all
interfaces as they are probed by the drivers. As the driver probing is
generally not predictable for modern technology this means that as soon
as multiple network interfaces are available the assignment of the names
"eth0", "eth1" and so on is generally not fixed anymore and it might
very well happen that "eth0" on one boot ends up being "eth1" on the
next. This can have serious security implications, for example in
firewall rules which are coded for certain naming schemes, and which are
hence very sensitive to unpredictable changing names."

The kernel does not create the interfaces always in the same order, so
what one day is eth0 on the next boot could become eth1, if you have
more than one interface. That's the big problem, and it comes right from
the kernel.

Then the article explains what can udev do about that so that the user
always sees the same name for the same network device.

First they tried to use the MAC address to fix the name, but did not
work well.

Next they tried using the biosdevname. Similar to /dev/*/by-path/ symlinks.

Some distributions support renaming the interfaces to user defined names.


So the problem originates from the kernel.
systemd/udev simply corrects the issue.


-- 
Cheers,
       Carlos E.R.

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

#4032

Le 01/04/2017 à 02:01, Carlos E. R. a écrit :
>>
>> <https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/>
>
> For one thing, it is not really systemd, but udev which is involved. It
> comes now in the same package, that's true.

The udev version introducing predictable network interface names is a 
part of the systemd package. So yes, it is systemd.

> Now read this paragraph right at the start:
>
> "The classic naming scheme for network interfaces applied by the kernel
> is to simply assign names beginning with "eth0", "eth1", ... to all
> interfaces as they are probed by the drivers. As the driver probing is
> generally not predictable for modern technology

"Modern technology" actually standing for "systemd/udev".

> The kernel does not create the interfaces always in the same order, so
> what one day is eth0 on the next boot could become eth1, if you have
> more than one interface. That's the big problem, and it comes right from
> the kernel.

Actually the problem comes from the asynchronous way "modern technology" 
probes hardware and loads drivers.

> First they tried to use the MAC address to fix the name, but did not
> work well.

It has worked pretty well here, except on a Sun SPARC workstation where 
all interfaces have the same MAC address by design, which got udev confused.

> So the problem originates from the kernel.

I beg to differ. I have perfectly stable kernel-defined interface names 
on a machine *not* running udev.

> systemd/udev simply corrects the issue.

I'd rather say systemd/udev corrects the issue it created itself.

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

#4033

On 2017-04-01 09:41, Pascal Hambourg wrote:
> Le 01/04/2017 à 02:01, Carlos E. R. a écrit :
>>>
>>> <https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/>
>>>
>>
>> For one thing, it is not really systemd, but udev which is involved. It
>> comes now in the same package, that's true.
> 
> The udev version introducing predictable network interface names is a
> part of the systemd package. So yes, it is systemd.
> 
>> Now read this paragraph right at the start:
>>
>> "The classic naming scheme for network interfaces applied by the kernel
>> is to simply assign names beginning with "eth0", "eth1", ... to all
>> interfaces as they are probed by the drivers. As the driver probing is
>> generally not predictable for modern technology
> 
> "Modern technology" actually standing for "systemd/udev".

No, it means the kernel.

> 
>> The kernel does not create the interfaces always in the same order, so
>> what one day is eth0 on the next boot could become eth1, if you have
>> more than one interface. That's the big problem, and it comes right from
>> the kernel.
> 
> Actually the problem comes from the asynchronous way "modern technology"
> probes hardware and loads drivers.

Yes, in the kernel.


>> First they tried to use the MAC address to fix the name, but did not
>> work well.
> 
> It has worked pretty well here, except on a Sun SPARC workstation where
> all interfaces have the same MAC address by design, which got udev
> confused.
> 
>> So the problem originates from the kernel.
> 
> I beg to differ. I have perfectly stable kernel-defined interface names
> on a machine *not* running udev.

Chance. Or old kernel.


>> systemd/udev simply corrects the issue.
> 
> I'd rather say systemd/udev corrects the issue it created itself.

No, the issue was created by the kernel.

I don't like systemd. But don't blame it for issues it doesn't create.

-- 
Cheers,
       Carlos E.R.

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

#4034

Le 01/04/2017 à 12:50, Carlos E. R. a écrit :
> On 2017-04-01 09:41, Pascal Hambourg wrote:
>> Le 01/04/2017 à 02:01, Carlos E. R. a écrit :
>>>
>>> "The classic naming scheme for network interfaces applied by the kernel
>>> is to simply assign names beginning with "eth0", "eth1", ... to all
>>> interfaces as they are probed by the drivers. As the driver probing is
>>> generally not predictable for modern technology
>>
>> "Modern technology" actually standing for "systemd/udev".
>
> No, it means the kernel.

No, the kernel behaviour has not changed in this matter.

>> Actually the problem comes from the asynchronous way "modern technology"
>> probes hardware and loads drivers.
>
> Yes, in the kernel.

No, the kernel is not responsible for loading modules asynchronously. 
Udev is.

>> I beg to differ. I have perfectly stable kernel-defined interface names
>> on a machine *not* running udev.
>
> Chance. Or old kernel.

Chance has nothing to do with this.
Rather old kernel (3.2.x), but a newer one would behave exactly the same.

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

#4035

On 2017-04-02 00:17, Pascal Hambourg wrote:
> Le 01/04/2017 à 12:50, Carlos E. R. a écrit :
>> On 2017-04-01 09:41, Pascal Hambourg wrote:
>>> Le 01/04/2017 à 02:01, Carlos E. R. a écrit :
>>>>
>>>> "The classic naming scheme for network interfaces applied by the kernel
>>>> is to simply assign names beginning with "eth0", "eth1", ... to all
>>>> interfaces as they are probed by the drivers. As the driver probing is
>>>> generally not predictable for modern technology
>>>
>>> "Modern technology" actually standing for "systemd/udev".
>>
>> No, it means the kernel.
> 
> No, the kernel behaviour has not changed in this matter.

I have been told by devs that it is indeed a kernel issue.

-- 
Cheers,
       Carlos E.R.

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

#4036

Le 02/04/2017 à 01:22, Carlos E. R. a écrit :
> On 2017-04-02 00:17, Pascal Hambourg wrote:
>> Le 01/04/2017 à 12:50, Carlos E. R. a écrit :
>>> On 2017-04-01 09:41, Pascal Hambourg wrote:
>>>> Le 01/04/2017 à 02:01, Carlos E. R. a écrit :
>>>>>
>>>>> "The classic naming scheme for network interfaces applied by the kernel
>>>>> is to simply assign names beginning with "eth0", "eth1", ... to all
>>>>> interfaces as they are probed by the drivers. As the driver probing is
>>>>> generally not predictable for modern technology
>>>>
>>>> "Modern technology" actually standing for "systemd/udev".
>>>
>>> No, it means the kernel.
>>
>> No, the kernel behaviour has not changed in this matter.
>
> I have been told by devs that it is indeed a kernel issue.

Did they care to explain how it was a kernel issue ?

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

#4039

Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> Le 02/04/2017 à 01:22, Carlos E. R. a écrit :
>> On 2017-04-02 00:17, Pascal Hambourg wrote:
>>> Le 01/04/2017 à 12:50, Carlos E. R. a écrit :
>>>> On 2017-04-01 09:41, Pascal Hambourg wrote:
>>>>> Le 01/04/2017 à 02:01, Carlos E. R. a écrit :
>>>>>>
>>>>>> "The classic naming scheme for network interfaces applied by the kernel
>>>>>> is to simply assign names beginning with "eth0", "eth1", ... to all
>>>>>> interfaces as they are probed by the drivers. As the driver probing is
>>>>>> generally not predictable for modern technology
>>>>>
>>>>> "Modern technology" actually standing for "systemd/udev".
>>>>
>>>> No, it means the kernel.
>>>
>>> No, the kernel behaviour has not changed in this matter.
>>
>> I have been told by devs that it is indeed a kernel issue.
> 
> Did they care to explain how it was a kernel issue ?
> 
Which devs? IIRC Linus quit accepting patches from certain devs
associated with udev & systemd because he got tired of their constant
excuses for regressions and lack of fixes for same.

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

#4038

Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> Le 01/04/2017 à 12:50, Carlos E. R. a écrit :
>> On 2017-04-01 09:41, Pascal Hambourg wrote:
>>> Le 01/04/2017 à 02:01, Carlos E. R. a écrit :
>>>>
>>>> "The classic naming scheme for network interfaces applied by the kernel
>>>> is to simply assign names beginning with "eth0", "eth1", ... to all
>>>> interfaces as they are probed by the drivers. As the driver probing is
>>>> generally not predictable for modern technology
>>>
>>> "Modern technology" actually standing for "systemd/udev".
>>
>> No, it means the kernel.
> 
> No, the kernel behaviour has not changed in this matter.
> 
>>> Actually the problem comes from the asynchronous way "modern technology"
>>> probes hardware and loads drivers.
>>
>> Yes, in the kernel.
> 
> No, the kernel is not responsible for loading modules asynchronously. 
> Udev is.
> 
>>> I beg to differ. I have perfectly stable kernel-defined interface names
>>> on a machine *not* running udev.
>>
>> Chance. Or old kernel.
> 
> Chance has nothing to do with this.
> Rather old kernel (3.2.x), but a newer one would behave exactly the same.

And does, I'm using 4.10.6 on at least one machine and getting *eth0*
as the net device name. Salix (Slackware) 14.1 so no systemd. 
Fortunately Pat hasn't bought into the systemd insanity for slack.

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

#4042

On 2017-04-02, Jerry Peters <jerry@example.invalid> wrote:
> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>> Le 01/04/2017 à 12:50, Carlos E. R. a écrit :
>>> On 2017-04-01 09:41, Pascal Hambourg wrote:
>>>> Le 01/04/2017 à 02:01, Carlos E. R. a écrit :
>>>>>
>>>>> "The classic naming scheme for network interfaces applied by the kernel
>>>>> is to simply assign names beginning with "eth0", "eth1", ... to all
>>>>> interfaces as they are probed by the drivers. As the driver probing is
>>>>> generally not predictable for modern technology
>>>>
>>>> "Modern technology" actually standing for "systemd/udev".
>>>
>>> No, it means the kernel.
>> 
>> No, the kernel behaviour has not changed in this matter.
>> 
>>>> Actually the problem comes from the asynchronous way "modern technology"
>>>> probes hardware and loads drivers.
>>>
>>> Yes, in the kernel.
>> 
>> No, the kernel is not responsible for loading modules asynchronously. 
>> Udev is.
>> 
>>>> I beg to differ. I have perfectly stable kernel-defined interface names
>>>> on a machine *not* running udev.
>>>
>>> Chance. Or old kernel.
>> 
>> Chance has nothing to do with this.
>> Rather old kernel (3.2.x), but a newer one would behave exactly the same.
>
> And does, I'm using 4.10.6 on at least one machine and getting *eth0*
> as the net device name. Salix (Slackware) 14.1 so no systemd. 
> Fortunately Pat hasn't bought into the systemd insanity for slack.

On mageia cauldron during the boot sequence I get the line
ath10k_pci 0000:3a:00.0 wlp58s0: renamed from wlan0
so the kernel names it wlan0, and ath10k_pci module then renames it.
Is the module part of the kernel?

>
>

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

#4045

Le 03/04/2017 à 02:07, William Unruh a écrit :
> On 2017-04-02, Jerry Peters <jerry@example.invalid> wrote:
>> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>>> Le 01/04/2017 à 12:50, Carlos E. R. a écrit :
>>>> On 2017-04-01 09:41, Pascal Hambourg wrote:
>>>>> Le 01/04/2017 à 02:01, Carlos E. R. a écrit :
>>>>>>
>>>>>> "The classic naming scheme for network interfaces applied by the kernel
>>>>>> is to simply assign names beginning with "eth0", "eth1", ... to all
>>>>>> interfaces as they are probed by the drivers. As the driver probing is
>>>>>> generally not predictable for modern technology
>>>>>
>>>>> "Modern technology" actually standing for "systemd/udev".
>>>>
>>>> No, it means the kernel.
>>>
>>> No, the kernel behaviour has not changed in this matter.
>>>
>>>>> Actually the problem comes from the asynchronous way "modern technology"
>>>>> probes hardware and loads drivers.
>>>>
>>>> Yes, in the kernel.
>>>
>>> No, the kernel is not responsible for loading modules asynchronously.
>>> Udev is.
>>>
>>>>> I beg to differ. I have perfectly stable kernel-defined interface names
>>>>> on a machine *not* running udev.
>>>>
>>>> Chance. Or old kernel.
>>>
>>> Chance has nothing to do with this.
>>> Rather old kernel (3.2.x), but a newer one would behave exactly the same.
>>
>> And does, I'm using 4.10.6 on at least one machine and getting *eth0*
>> as the net device name. Salix (Slackware) 14.1 so no systemd.
>> Fortunately Pat hasn't bought into the systemd insanity for slack.
>
> On mageia cauldron during the boot sequence I get the line
> ath10k_pci 0000:3a:00.0 wlp58s0: renamed from wlan0
> so the kernel names it wlan0, and ath10k_pci module then renames it.
> Is the module part of the kernel?

Yes, it is a kernel module and as such it is a part of the kernel. 
ath10k_pci is the kernel driver for your Qualcomm/Atheros wireless 
network device. Actually it is the kernel driver which assigns the 
initial interface name (wlan0), so the message is a bit puzzling.

On my Debian Wheezy (oldstable, kernel 3.2) and Jessie (stable, kernel 
3.16), the kernel message say that the network interfaces are renamed by 
udevd or systemd-udevd. Wheezy does not have systemd, and Jessie has an 
old version of systemd which does not assign predictable network 
interface names.

So I did a bit of testing with more recent versions from Debian Stretch 
(testing) of kernel (4.9, is that new enough ?) and systemd which 
assigns predictable interface names.

Here are the results :

Linux 3.16 + old systemd : message from systemd-udevd, interface renamed 
with the old scheme eth*.

Linux 4.9 + new systemd : message from the kernel driver, interface 
renamed with the new scheme enp*s*.

Linux 4.9 + old systemd : message from systemd-udevd, interface renamed 
with the old scheme eth*.

Linux 3.16 + new systemd : no message, interface renamed with the new 
scheme enp0s*.

Linux 4.9 + new systemd but udev stopped (*) : no message, interface not 
renamed keeping its initial name eth*.

(*) Make sure not only systemd-udevd.service but also 
systemd-udevd-kernel.socket is stopped, otherwise the latter restarts 
the former on events such as module loading or device discovery.

 From these results it seems clear to me that :
- the renaming scheme depends on the version of systemd, not on the 
kernel version ;
- without udevd the kernel or kernel module just assigns an initial 
interface name as usual and does not rename network interfaces on its own ;
- the kernel behaviour is globally the same regarless of its version. 
The only change is the rename message source in the kernel log.

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

#4022

Doug  Laidlaw  <laidlaws@hotkey.net.au> wrote in news:fcRCA.432076
$Tb4.251145@fx03.fr7:

> I have bought a Raspberry Pi (amazing device) and
> added it to my home network.  I would like to give it
> a fixed IP address on the network.  I read somewhere
> about associating the Pi's MAC address with a fixed
> IP address, but my router does not seem to support 
> doing that.  My desktop computer has a set IP 
> address in its config, but the Pi runs Kodi, which is
> not an operating system, they tell me, so it can't
> set its own address.
> 
> Any ideas please?
> 
> Doug.



I suggets you try the KODI forums and see what they can tell you.

I'm sorry, but I'm travelling and don;t have the URL at hand or I would 
provide it.

As for other folks herer trying to set up a static address on a PI just 
Gogle "How to set up static IP address on Raspberry Pi Jessie" and the 
first hit is on the Raspberry Piwebsite.  There are others

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

#4041

On Thu, 30 Mar 2017 03:23:38 +1100 (GMT+11:00)
Doug  Laidlaw  <laidlaws@hotkey.net.au> wrote:

> I have bought a Raspberry Pi (amazing device) and
> added it to my home network.  I would like to give it
> a fixed IP address on the network.  I read somewhere
> about associating the Pi's MAC address with a fixed
> IP address, but my router does not seem to support 
> doing that.  My desktop computer has a set IP 
> address in its config, but the Pi runs Kodi, which is
> not an operating system, they tell me, so it can't
> set its own address.
> 
Buy a second Pi and set it up as a DHCP server, then you can have full
control over it. That's how I keep everything 'permanent' in the house
with a static IP (although not with a Pi, I still have a couple of
Sheevaplugs doing that job)

Either that or see if your router will support OpenWRT and use that for
the purpose.

Dave

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.linux.networking

csiph-web