On Thu, 30 Dec 2004 16:28:44 -0500 (EST), Alex Angerhofer wrote:

On Thu, 30 Dec 2004, Alex Angerhofer wrote:

...

Hi list,

I have a strange problem with dhcpd.

1. the setup: nibbio (SuSE 9.2 on amd64) is connected to a DSL modem with ethernet device 1. Device 2 connects to my local network on which two other PCs are connected. I am running dhcpd (from the stock distribution) on nibbio which hands out leases on the private subnet. So far so good.

2. the initial problem: Just recently, out of the blue, the eth device order decided to change, i.e., device 1 is now eth1 and device 2 is now eth0 where they were previously coming up the other way. This foiled my dhcpd server which was tied to eth1. After googling a bit I found that with kernel 2.6.x the devices were now called eth-id-MAC whith the proper MAC addresses in order to positively identify them and that aliases introduced in modprobe.conf wouldn't really make any sense anymore or would tend to be irrelevant (see for example: http://support.novell.com/cgi-bin/search/searchtid.cgi?/en/2004/05/91_syscon... ). So, I decided that the way to go would be to tie dhcpd to eth-id-MAC_of_device_2 rather than eth1 which it had been set before. However, this makes dhcpd fail with the following error message in the logs:

Dec 30 15:52:38 nibbio dhcpd: No subnet declaration for eth-id-00:09:5b (0.0.0.0).

Obviously, eth-id-00:09:5b is not the entire interface name. Apparently, dhcpd only takes the 15 first characters of whatever is given to it. I confirmed this behavior by leaving out eth- in the DHCPD_INTERFACE field and by trying just the MAC address. dhcpd fails to run in any case and only 15 characters are given.

Has anybody else seen this problem, and perhaps found a solution?

Best regards, Alex.

Following up on my own message, I see that this problem has been found in SuSE 9.1 already and fixed with the dhcp-relay 3.0.1rc13-28.7 YOU patch. Apparently, the bug fix didn't make it into 9.2? Would it be alright to simply install the rpm in the 9.1 distribution?

Best regards, Alex.

-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

Hi, recently there was a thread on the list with subject "SuSE 9.2 Pro changing eth0 to eth1". The discussion was long, and there were a lot of good ideas to solve the problem, maybe you should take a look. Here is a link: http://lists.suse.com/archive/suse-linux-e/2004-Dec/index.html#3110 Cheers and Happy New Year Sunny -- Get Firefox http://www.spreadfirefox.com/?q=affiliates&id=10745&t=85

On Thu, 30 Dec 2004, Alex Angerhofer wrote:

On Thu, 30 Dec 2004, Richard Bos wrote:

...

Op donderdag 30 december 2004 22:09, schreef Alex Angerhofer:

...

2. the initial problem: Just recently, out of the blue, the eth device order decided to change, i.e., device 1 is now eth1 and device 2 is now eth0 where they were previously coming up the other way. This foiled my dhcpd server which was tied to eth1. After googling a bit I found that with kernel 2.6.x the devices were now called eth-id-MAC whith the proper MAC addresses in order to positively identify them and that aliases introduced in modprobe.conf wouldn't really make any sense anymore or would tend to be irrelevant (see for example: http://support.novell.com/cgi-bin/search/searchtid.cgi?/en/2004/05/91_sysco nfig.html ). So, I decided that the way to go would be to tie dhcpd to eth-id-MAC_of_device_2 rather than eth1 which it had been set before. However, this makes dhcpd fail with the following error message in the logs:

Perhaps you can use persistent names, see section 22.4.6. Hotplug and PCMCIA: file:/usr/share/doc/manual/suselinux-adminguide_en/html/ch22s04.html

That appears to have helped. Thank you very much Richard, and everybody else who has responded.

I guess it was too early to report success here. After a reboot the same reversal of eth devices happened as before. I guess, the correct solution should not be to use the deprecated old ethx names but rather go with the MAC-related names. But that would require SuSE to fix their 9.2 version of the dhcpd packages (at least on x86_64, don't know about i386). What is the correct procedure to put a bug report into the queue? Best regards, Alex. )

* Alex Angerhofer [12-30-04 17:43]:

I guess it was too early to report success here. After a reboot the same reversal of eth devices happened as before. I guess, the correct solution should not be to use the deprecated old ethx names but rather go with the MAC-related names. But that would require SuSE to fix their 9.2 version of the dhcpd packages (at least on x86_64, don't know about i386).

I suggest you read or re-read the message thread that was proposed previous. It had a *solution* which would survive a reboot and an explanation. And it did not indicate the necessity for a bug-report. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos

On Thu, 30 Dec 2004, Alex Angerhofer wrote:

On Thu, 30 Dec 2004, Patrick Shanahan wrote:

...

* Alex Angerhofer [12-30-04 17:43]:

...

I guess it was too early to report success here. After a reboot the same reversal of eth devices happened as before. I guess, the correct solution should not be to use the deprecated old ethx names but rather go with the MAC-related names. But that would require SuSE to fix their 9.2 version of the dhcpd packages (at least on x86_64, don't know about i386).

I suggest you read or re-read the message thread that was proposed previous. It had a *solution* which would survive a reboot and an explanation. And it did not indicate the necessity for a bug-report.

Dear Patrick,

thanks for the exhortation. I scanned the thread again. I had tried both main solutions that were recommended, i.e., placing extra udev rules and using the PERSISTENT_NAMES field in the /etc/sysconfig/network/ifcfg-eth-id-MAC files, but neither one worked for me. I am still following up on some extra googling I have been doing. However, even if there is a solution that forces the devices to come up with persistent names, it is still a bug that dhcpd doesn't recognize device names that are more than 15 characters long. Furthermore, this had been fixed in SuSE 9.1 with a YOU update patch, which didn't make it into the 9.2 updates. Thus I filed a bug report and for the time being am switching the ethx names by hand.

Best regards, Alex.

I finally seem to have it working now. It took another look at the SuSE knowledgebase here: http://support.novell.com/cgi-bin/search/searchtid.cgi?/en/2004/05/91_coldho... If you scroll down to the heading "Network Devices and Their Interface Names" you will find a reference to the race condition that exists when the nics are called up. The recommended procedure is to set HOTPLUG_PCI_QUEUE_NIC_EVENTS=no *and* at the same time "set dedicated interface names in the interface configuration files." In fact when you go to the sysconfig editor ---> Hardware ---> Hotplug --> HOTPLUG_PCI_QUEUE_NIC_EVENTS the text advises you that you don't need this set if you use PERSISTENT_NAMES for your interfaces. Still, the dhcpd behavior is a bug and ought to be fixed. Cheers, Alex.

* Alex Angerhofer [12-30-04 19:51]:

thanks for the exhortation. I scanned the thread again. I had tried both main solutions that were recommended, i.e., placing extra udev rules and using the PERSISTENT_NAMES field in the /etc/sysconfig/network/ifcfg-eth-id-MAC files, but neither one worked for me.

Then it was my Olden-Timers[tm] kicking in again. My apologies for misleading you. gud luk, -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/photos