Bug 123813
Summary: | dhcp does not work on some laptops | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mark Baertschy <mark> |
Component: | net-tools | Assignee: | Phil Knirsch <pknirsch> |
Status: | CLOSED NOTABUG | QA Contact: | Ben Levenson <benl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2 | CC: | rvokal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-05-26 14:38:53 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Mark Baertschy
2004-05-20 17:57:46 UTC
Why do you use an alias for your interface? eth0:1 seems a little fishy to me. Please try dhcp with a real interface (eth0 e.g.) Thanks, Read ya, Phil I managed to come up with a work around last night. It is definitely related to aliasing. I believe the problem is that aliasing is broken with regards to dhcp. I'm also not overly thrilled with how system-config-network handles multiple network configs. First, I'll answer your question. Yes, the eth0:1 interface seems fishy, but that's what system-config-network sometimes does when making multiple config files. I haven't done any testing to determine what circumstances trigger which alias-naming behavior but I can assure you that I did not invent eth0:1. But, the ":1" is not the problem, or at least not the main problem. By removing the ":1" by hand I can change the error message, but dhcp still doesn't work. After playing around with scripts last night I determined that this is a bug in the network scripts that has nothing to do with hardware (including whether or not this is on a laptop) and results when you set up two aliased network configs, one of which is dhcp. On my laptop I need to have both dhcp and static ip working. At home I must use a static ip through my dsl. When I travel, obviously, dhcp is the ticket. What I want to have are two network scripts -- ifcfg-home and ifcfg-dhcp -- where ifcfg-home has a static ip. The funky eth0:1 resulted, at some point, when trying to make ifcfg-dhcp after already having a couple static ip configs on hand. If I delete all configs and then make a dhcp config with system-config-network then the config script looks better. I may still have done some hand editing, can't remember now. At any rate, I eventually have a ifcfg-dhcp that is identical to what I orginally posted except for one line: DEVICE=eth0. At the same time I have a ifcfg-home that is a working static IP config. In this state I no longer get the "requested address" error message. Instead it complains about not being able to find the config for eth0. After playing with the scripts I determine that with dhcp the scripts (I forget which one exactly) eventually try to find ifcfg-eth0 (if eth0 is the device) even though the dhcp config file was supposed to be given the alias "dhcp". I don't quite understand how all of these scripts are supposed to work, but what I did was "cp ifcfg-dhcp ifcfg-eth0" within the /etc/sysconfig/network-scripts directory. And, voila, dhcp works! Now, if I am at home I type "ifup home" to activate the static ip and if I am away from home I type "ifup dhcp" to activate the dhcp interface. Obviously, this is a bit of a hack. I hope that somebody who better understands these scripts can figure out how to make the aliasing work better with dhcp. I suspect that most people who use dhcp do not need to also use static ip and therefore have no reason to alias their dhcp config. I apologize for some of the information being incomplete and there are some obvious things to test now that I know this work around. But, I am at a conference right now and I don't have much time to play and I am very dependent on dhcp working. I might do some more tests later. I asked because dhcp is know not to work with aliased interfaces and wondered where you got it from. And the whole networking-scripts (and all other /etc/sysconfig files for that matter) are nicely described here: /usr/share/doc/initscripts-7.53/sysconfig.txt (depending on the initscripts version you have installed you certainly might have another directory :)) Hope this helps, Read ya, Phil I strongly disagree with your categorizing this as "notabug". This is most definitely a bug, or maybe two, and the solution is a workaround it is not resolved. So, dhcp not working with aliased interfaces is a known bug. Known by whom? Sure, the developers know about it, but how is Joe User supposed to know this? I don't see it in the release notes. I searched newsgroups, bugzilla, etc. and never found any mention. The point is that system-config-network will happily allow a user to alias a dhcp interface with no indication that this is broken. For users that need multiple interfaces aliasing is a necessary feature and it is perfectly reasonable to expect aliasing to work equally well with static and dhcp. Aliasing works with some interfaces, not with others: that's a bug!! And what about the whole "eth0:1" issue? Just now I used system-config-network to create a new interface just to see what it would do. I clicked the "New" button and created a new interface using only the default settings. Do you know what I ended up with? A new interface with file name ifcfg-eth0:1, the device is eth0:1 and bootproto is dhcp. Didn't you say eth0:1 was fishy and not a "real interface"? Why does system-config-network create a non-working interface (BY DEFAULT) if other interfaces are present? That's notabug? WTF?! I am a longtime redhat user. I was a paying customer with RH9. Redhat enterprise is to out-of-date for my taste, hence I decided to switch to Fedora. I want to see mainstream linux distros (including Fedora) become useable without having to hack scripts or scour newsgroups. I assumed the Fedora project shared this vision, perhaps I was wrong. |