Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

  Serge:

Exactly so. I think this 'network redetect' works easily if there is one 
network device (option 'r'). With more than one, and if the order 
(eth0/eth1) matters, the user configures 70-persistent-net.rules 
manually and then uses 'network redetect' with option 'k' to restart 
networking; it makes life easier in this situation too. I haven't been 
able to test it with wireless lan devices, though.

BTW I see the existing network script has a never-executed call at the 
end to a non-existent /etc/init.d/wlan.

Dominic

On 30/08/2010 21:50, Serge Leschinsky wrote:
> Heiko, Dominic,
>
>
> as far as I can see this feature is opposite to concatenation of
> 70-persistent-net.rules, and in essence it's a way to clean this file up from
> "outdated" records without reboot. For me it's "nice to have".
>
>
> Serge
>
>
>
> On 08/30/2010 08:33 AM, Heiko Zuerker wrote:
>> Does anybody have an opinion on this?
>>
>> Heiko
>>
>> Quoting Dominic Raferd<dl...@ed...>:
>>
>>> Back in April I submitted to Mantis some code for the
>>> /etc/init.d/network script which added a new 'redetect' options to allow
>>> redetection of changed network hardware
>>> https://sourceforge.net/apps/mantisbt/devil-linux/view.php?id=70. This
>>> was felt to be unnecessary because of the introduction of mactab, but it
>>> might be worth reconsidering if we are now removing mactab.
>>>
>>> Dominic
>>>
>>> Here's the help info for it:
>>>
>>> 'network redetect' will disrupt any existing network connection and may
>>> leave it broken. It is intended for use from a local terminal and in
>>> cases where network hardware has changed and needs to be reconfigured to
>>> work properly. Or (with 'k' option) where
>>> /etc/udev/rules.d/70-persistent-net.rules file has been changed
>>> manually, and the network needs to be restarted to reflect the changes.
>>> If pre-existing network hardware is working, but additional new network
>>> hardware is not, 'network redetect' is probably not the right tool -
>>> instead, configure the new hardware from the NET section of 'setup'.
>>>
>>> Usually you first run with option 'r', this stops the network, removes
>>> any prior information about network devices stored at
>>> /etc/udev/rules.d/70-persistent-net.rules, redetects network devices,
>>> recreates this file and then attempts to restart the network. To restart
>>> the network it needs a network module; if you choose the 'autoselect'
>>> option when and if requested, it will override any existing module set
>>> by 'setup' at /etc/sysconfig/nic/ifcfg-ethn and use the module suggested
>>> by udev.
>>>
>>> If this fails, reconfigure /etc/udev/rules.d/70-persistent-net.rules
>>> manually (for instance, switching the allocation of device NAMEs between
>>> eth0 and eth1) and then rerun 'network redetect' with the 'k' option.
>>>
>>> If you still have problems, check settings for the network device
>>> (including module) using 'setup'. When you have an operational network,
>>> save your changes with 'save-config -q'.
>>>
>>>> Heiko
>>>>
>>>>> -----Original Message-----
>>>>> From: Heiko Zuerker [mailto:he...@zu...]
>>>>> Sent: Saturday, August 28, 2010 8:06 AM
>>>>> To: dev...@li...
>>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>>> address with correct interface name
>>>>>
>>>>> Yes I agree, let's take it back out.
>>>>>
>>>>> Heiko
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Stefan Engel [mailto:ma...@en...]
>>>>>> Sent: Monday, August 23, 2010 4:12 AM
>>>>>> To: dev...@li...
>>>>>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC
>>>>>> address with correct interface name
>>>>>>
>>>>>> Hi Serge,
>>>>>>
>>>>>> I just tested my config with
>>>> /etc/udev/rules.d/70-persistent-net.rules
>>>>>> with two VMs and it's working without problems. This solution looks
>>>>> like
>>>>>> the more elegant way to assign interface names to mac addresses.
>>>>>>
>>>>>> Seems that the changes we made for dealing with /etc/mactab and
>>>>>> /etc/mactable are more or less obsolete by now.
>>>>>>
>>>>>> udev already works in the correct way when assigning the interface
>>>>>> names, without the 'workaround' I made in the network script to get
>>>>> the
>>>>>> interface names right. So if nobody really needs the changes we made
>>>>>> for working with /etc/mactab, /etc/mactable, we could roolback these
>>>>>> changes.
>>>>>>
>>>>>> Regards,
>>>>>> Stefan
>>>>>>
>>>>>> On 08/22/2010 07:56 AM, Serge Leschinsky wrote:
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> DL system has been retired recently and I found that the problem
>>>>> with
>>>>>>> MAC-interface name association was solved a bit differently.
>>>>> Probably
>>>>>>> I missed something  - in this case I'm sorry in advance.
>>>>>>>
>>>>>>> The solution is based on udev rule (70-persistent-net.rules). The
>>>>> file
>>>>>>> below is a simple concatenation of 70-persistent-net.rules from 3
>>>>>>> different DL systems, and I was able to copy configuration tarball
>>>>>>> between systems without problem with network interface renaming.
>>>>>> Is it the same what you wish to get?
>>>>>>>
>>>>>>> # cat /etc/udev/rules.d/70-persistent-net.rules
>>>>>>> # This file was automatically generated by the
>>>>>>> /lib/udev/write_net_rules # program, run by the persistent-net-
>>>>>> generator.rules rules file.
>>>>>>> #
>>>>>>> # You can modify it, as long as you keep each rule on a single #
>>>>> line,
>>>>>>> and change only the value of the NAME= key.
>>>>>>>
>>>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:14:d1:16:ab:c5", ATTR{type}=="1",
>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>>>> ACTION=="add", DRIVERS=="?*",
>>>>> ATTR{address}=="00:0a:e6:88:8f:4d",
>>>>>>> ATTR{type}=="1",
>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>> # PCI device 0x10ec:0x8169 (r8169)
>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:14:d1:16:a8:cc", ATTR{type}=="1",
>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net",
>>>>>>> ACTION=="add", DRIVERS=="?*",
>>>>> ATTR{address}=="00:0d:87:26:33:9e",
>>>>>>> ATTR{type}=="1",
>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:23:4d:0b:87:b2", ATTR{type}=="1",
>>>>>> KERNEL=="eth*", NAME="wlan0"
>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:21:70:bc:07:76", ATTR{type}=="1",
>>>>>> KERNEL=="eth*", NAME="eth0"
>>>>>>> # PCI device 0x8086:0x10f5 (e1000e)
>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:22:68:13:c2:3b", ATTR{type}=="1",
>>>>>> KERNEL=="eth*", NAME="eth1"
>>>>>>> # PCI device 0x8086:0x4237 (iwlagn)
>>>>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>>>>> ATTR{address}=="00:1e:65:6b:22:64", ATTR{type}=="1",
>>>>>> KERNEL=="wlan*", NAME="wlan1"
>>>>>>>
>>>>>>> Serge
>>>>>>>
>>>>>>>
>>>>>>> On 06/18/2010 09:13 AM, Stefan Engel wrote:
>>>>>>>> Sorry for the late reply, holiday and work kept me busy.
>>>>>>>>
>>>>>>>> I have seen the bug #73 is resolved and the network script is now
>>>>>>>> available in the latest CVS snapshot. I am about to build my own
>>>>>>>> devil distro sometime during the next days. So far the script
>>>> looks
>>>>>>>> ok and should work as intended.
>>>>>>>>
>>>>>>>> Thanks for all helping to get this task done.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Stefan
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/25/2010 03:29 AM, Stephen H F Ralph wrote:
>>>>>>>>> Having given further thought to my earlier posting from work,
>>>> and
>>>>>>>>> hopefully to ease confusion between the differing network
>>>>> scripts,
>>>>> I
>>>>>>>>> have given a version of "1.44a" to the original mactab-modified
>>>>>>>>> script, and "1.44b" to the same file as further patched by
>>>> Stefan.
>>>>>>>>> Both files have been uploaded to mantis.
>>>>>>>>>
>>>>>>>>> If Stefan can confirm I have correctly added his modifications
>>>> to
>>>>>>>>> 1.44b, then I propose this is the file to use.
>>>>>>>>>
>>>>>>>>> I'd expect Heiko to strip the temporary branding 1.44a and
>>>> 1.44b,
>>>>> by
>>>>>> the way.
>>>>>>>>> Regards - Steve
>>>>>>>>>
>>>>>>>>> "Stephen H F Ralph"<shf...@gm...>
>>>>>>>>>
>>>>>>>>>
>>>>> --------------------------------------------------------------------
>>>>>>>>> ----------
>>>>>>>
>>>>> ----------------------------------------------------------------------
>>>>>>> --------
>>>>>>> This SF.net email is sponsored by
>>>>>>>
>>>>>>> Make an app they can't live without
>>>>>>> Enter the BlackBerry Developer Challenge
>>>>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>>>>> _______________________________________________
>>>>>>> Devil-linux-develop mailing list
>>>>>>> Dev...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>> ------------------------------------------------------------------------
>>>>> ------
>>>>>> This SF.net email is sponsored by
>>>>>>
>>>>>> Make an app they can't live without
>>>>>> Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-
>>>>>> dev2dev _______________________________________________
>>>>>> Devil-linux-develop mailing list
>>>>>> Dev...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>
>>>>>
>>>> ------------------------------------------------------------------------
>>>> ------
>>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>>> Be part of this innovative community and reach millions of netbook
>>>> users
>>>>> worldwide. Take advantage of special opportunities to increase revenue
>>>>> and speed time-to-market. Join now, and jumpstart your future.
>>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>>> _______________________________________________
>>>>> Devil-linux-develop mailing list
>>>>> Dev...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>>> Be part of this innovative community and reach millions of netbook users
>>>> worldwide. Take advantage of special opportunities to increase revenue and
>>>> speed time-to-market. Join now, and jumpstart your future.
>>>> http://p.sf.net/sfu/intel-atom-d2d
>>>> _______________________________________________
>>>> Devil-linux-develop mailing list
>>>> Dev...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>> ------------------------------------------------------------------------------
>>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>>> Be part of this innovative community and reach millions of netbook users
>>> worldwide. Take advantage of special opportunities to increase revenue and
>>> speed time-to-market. Join now, and jumpstart your future.
>>> http://p.sf.net/sfu/intel-atom-d2d
>>> _______________________________________________
>>> Devil-linux-develop mailing list
>>> Dev...@li...
>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>
>>
>>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>