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.
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.
On Thu, 30 Dec 2004 16:28:44 -0500 (EST), Alex Angerhofer <alex@chem.ufl.edu> 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 Thursday 30 December 2004 03:09 pm, 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 _sysconfig.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:
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?
All I can do is confirm. When I set up my 9.1 server I ran into that so I renamed etc/sysconfig/network/ifcfg-eth-id-<mac> to etc/sysconfig/network/ifcfg-eth0. Only one nic, so no problems for me. I would like to see an answer in case I decide to add another nic. Doug
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 -- Richard Bos Without a home the journey is endless
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. Best regards, Alex.
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. )
On Thursday 30 December 2004 4:42 pm, Alex Angerhofer wrote:
What is the correct procedure to put a bug report into the queue?
Best regards, Alex
http://www.suse.de/cgi-bin/feedback.cgi is still the way AFAICT. Stan
* Alex Angerhofer <alex@chem.ufl.edu> [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, Patrick Shanahan wrote:
* Alex Angerhofer <alex@chem.ufl.edu> [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.
On Thu, 30 Dec 2004, Alex Angerhofer wrote:
On Thu, 30 Dec 2004, Patrick Shanahan wrote:
* Alex Angerhofer <alex@chem.ufl.edu> [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.
On Thu, Dec 30, 2004 at 08:34:29PM -0500, Alex Angerhofer wrote:
On Thu, 30 Dec 2004, Alex Angerhofer wrote:
On Thu, 30 Dec 2004, Patrick Shanahan wrote:
* Alex Angerhofer <alex@chem.ufl.edu> [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.
You are misunderstanding this section. The default for HOTPLUG_PCI_QUEUE_NIC_EVENTS is _yes_, the events are queued and the race condition that might change the order does not happen. Even if you use configuration names ifcfg-eth* you will not have problems unless you move cards in the machine, update kernel or hotplug or update something else which might change the initialization order for this reason or another. The fundamental thing to understand here is that the interface names eth0, eth1 and so on _can_ be subject to change, but it does _not_ matter: _Only_ if a service like dhcpd is started with 'dhcpd eth0' you can get into trouble, and that's why dhcpd is started like this since 9.1: dhcpd $(getcfg-interface eth-id-<mac>) The configuration name which is used for the lookup of the actual, current interface name is the one you used as filename for the ifcfg- file in /etc/sysconfig/network. These configuration names are put into DHCPD_INTERFACE in /etc/sysconfig/dhcpd. The YOU update for 9.1 at the time actually introduced the getcfg-interface lookup which had been forgotten at that place. You _can_ use "easier" names like internal0/internal1/external, or good/bad if you want, by assigning such names via PERSISTENT_NAMES. (You cannot use eth* as persistent names, that is not possible.) Thus, if you stick to the hotplug defaults (so the initialization order fixed) and use the recommended configuration names (eth-id-something, so the configuration is coupled to a piece of hardware), I can assure you that the interface names will not change at will. (Unless there is some weird bug preventing it to work but as far as I can tell it works fine.) Still, you should replace all references to eth0, eth1 and so on in your configuration files by $(getcfg-interface eth-id-<mac>) calls. This is done in init scripts shipping with 9.1 onwards, so they work directly with the configuration names instead of interface names, as explained above with the /etc/sysconfig/dhcpd example. And I can _assure_ you that the fix is not only in 9.1, but also in 9.2. If you still see the problem please let me know. At first, please check the DHCPD_INTERFACE in /etc/sysconfig/dhcpd and make sure it is in sync with your ifcfg-* files.
Still, the dhcpd behavior is a bug and ought to be fixed.
Is your interface name longer than 15 characters? No, is it?
Cheers, Alex.
Peter
* Alex Angerhofer <alex@chem.ufl.edu> [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
participants (7)
-
Alex Angerhofer -
Doug B -
Patrick Shanahan -
poeml＠cmdline.net -
Richard Bos -
Stan Glasoe -
Sunny