|
Bugzilla – Full Text Bug Listing |
| Summary: | LTC19643-LLADDR not used in ifup-dhcp | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | LTC BugProxy <bugproxy> |
| Component: | Network | Assignee: | Christian Zoz <zoz> |
| Status: | VERIFIED FIXED | QA Contact: | Klaus Kämpf <kkaempf> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | fdg, hare, ihno |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugzilla.linux.ibm.com/show_bug.cgi?id=19643 | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | "yast.logs.tgz" | ||
|
Description
LTC BugProxy
2005-11-08 14:26:19 UTC
Yast2 logs, please. Does calling 'ifdown qeth0; ip link set qeth0 address XX:XX:XX:XX:XX' work? Created attachment 56692 [details]
"yast.logs.tgz"
---- Additional Comments From gmuelas@de.ibm.com 2005-11-08 10:42 EDT ------- Yast2 Logs Yast2 logs asked...are not attached ---- Additional Comments From gmuelas@de.ibm.com 2005-11-08 10:47 EDT ------- Oops, sorry, I meant: Yast2 logs asked...are NOW attached :-) Like you see in the following output, \'ifdown eth1; ip link set eth1 address XX:XX:XX:XX:XX\' it did work...but still having the same problem after every reboot...what does exactly try dhcpcd to do with the MAC address? (like we see, it does only not work, when dhcpcd is called and the real MAC address is still active...but after changing to the virtual MAC address it works) t2926003:~ # ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:0D:60:50:0D:EE BROADCAST NOTRAILERS MULTICAST MTU:1492 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) t2926003:~ # ifdown eth1 eth1 eth1 configuration: qeth-bus-ccw-0.0.fc24 t2926003:~ # ifup eth1 eth1 eth1 configuration: qeth-bus-ccw-0.0.fc24 SIOCSIFFLAGS: Operation not permitted Starting DHCP Client Daemon on eth1... . . . . . no IP address yet... backgrounding.t2926003:~ # t2926003:~ # ifdown eth1 eth1 eth1 configuration: qeth-bus-ccw-0.0.fc24 t2926003:~ # ip link set eth1 address 00:0D:60:26:01:03 t2926003:~ # ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:0D:60:26:01:03 BROADCAST NOTRAILERS MULTICAST MTU:1492 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) t2926003:~ # ifup eth1 eth1 eth1 configuration: qeth-bus-ccw-0.0.fc24 Starting DHCP Client Daemon on eth1... . IP/Netmask: 10.100.26.248 / 255.255.0.0t2926003:~ # t2926003:~ # ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:0D:60:26:01:03 inet addr:10.100.26.248 Bcast:10.100.255.255 Mask:255.255.0.0 inet6 addr: fe80::d:6000:26:103/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1492 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:328 (328.0 b) TX bytes:1366 (1.3 Kb) The MAC address should be present in ifcfg-*:LLADDR. YaST uses that variable only in RC1, not Beta4. Please check whether ifup works when LLADDR is present. If not, it is a sysconfig bug (Hannes). Hmm, of ifup and ifup-dhcp, only the former sets lladdr. That may be the bug. ---- Additional Comments From gmuelas@de.ibm.com 2005-11-11 11:28 EDT ------- Hi, I think I was missunderstood, like I said in my bug description, when testing on SP3 Beta4 I added editing the ifcfg file the LLADDR variable with a correct value to the ifcfg-... file. Now, with SP33 RC1, like you correctly point, LLADDR is correctly written in ifcfg-... by YAST, so there is no need to edit the ifcfg-... file. But the problem is still by SP3 RC1: When setting up an OSA Card with YAST to be used in Layer2 mode (givin a correct virtual MAC address which is different than the real MAC address) and to get the IP address dynamicly (with dhcpcd), it does not work, receiving messages in the console like: Nov 11 16:55:13 t2926002 dhcpcd[2528]: dhcpStart: ioctl SIOCSIFFLAGS: Operation not permitted and the interface does not have any ip address set. If I retry right away with \'ifdown eth1; ifup eth1\' still does not work. In fact, it has NOT change the MAC address to the one given in YAST yet (!?) It works only, when I first do the same (layer 2 and MAC address), but assigning an static ip address (which besides setting the wished ip-address, does the important thing before, changing the MAC address). And then, if changing the network configuration to get the ip-address dynamicly it does work correctly. But this is not a good solution, since, after every reboot, appears the same problem. I still think that dhcpcd tries to do something with the MAC address (maybe setting the same MAC address again?) which the interface has at the moment that dhcpcd is called on that interface. Because when the MAC address is the default real one (after a reboot), it doesn\'t work, with an error which it sounds like is trying to set the real MAC address (which it is FORBIDEN in Layer2); while when the MAC address has already been change (after setting it up with yast,layer2 and static ip-address) to a virtual MAC address different from the real one, it does work with no failing messages. Could it be possible, to patch the ifup script (or whichever is used for interfaces configured to get ip-address dynamicly with dhcpcd), at the point where the interface is configured to get the ip address dynamicly with the dhcpcd command, to make sure that, if it is in layer2 mode (or just if LLADDR exists in ifcfg...which should only exists when layer2 is active), before executing any dhcpcd command, the MAC address should be change with your favorite command in the script (like for example: \'ifconfig $INTERFACE hw ether $LLADDR\'...or the \'ip\' equivalent)? Thanks! ---- Additional Comments From gmuelas@de.ibm.com 2005-11-11 12:41 EDT ------- hi again... I did another test: 1.- changed the MAC address manually to a different one from the real MAC address. 2.- did \'ifdown ethXX; ifup ethXX\' of the interface that was previously set up to be in layer2 mode using a virtual MAC address (different that the real one, AND DIFFERENT FROM THE ONE A USED MANUALLY IN THE 1ST STEP) and to get the ip-address dynamicly. 3.- the interface received a dynamic ip-address, but the MAC address was NOT changed to the one given in LLADDR. So, for sure, when using dynamic address (dhcpcd), the LLADDR variable and its value is totaly ignored. Could you please fix (since it is needed for Layer2 interfaces which are directly attached, and otherwise they don\'t work)? Thanks! So this is a bug in ifup. Christian, could you fix it, please? fixed and submitted for SLES9 SP3 RC2. Still needs to be fixed in SVN. ---- Additional Comments From gmuelas@de.ibm.com 2005-11-24 10:23 EDT ------- Hello, I\'ve tested it again with SUSE SLES9 SP3 RC2 64bit, where it is suppose to be fixed (see last comment from zoz@suse.de), but still happens the same: Nov 24 16:16:08 t2926002 dhcpcd[1919]: dhcpStart: ioctl SIOCSIFFLAGS: Operation not permitted uname -a (just to show you that it is the right RC): Linux t2926002 2.6.5-7.242-s390x #1 SMP Mon Nov 21 14:06:30 UTC 2005 s390x s390x s390x GNU/Linux Did the fix not make it for RC2, could you make sure it make for RC3? Thanks! I don't know if it will go into RC3. Thorsten, will it go there? (In reply to comment #10) > ---- Additional Comments From gmuelas@de.ibm.com 2005-11-24 10:23 EDT ------- > Hello, > > I\'ve tested it again with SUSE SLES9 SP3 RC2 64bit, where it is suppose to be > fixed (see last comment from zoz@suse.de), but still happens the same: Of course it cannot be in RC2 (and the above comment was wrong), since RC2 was done before the package was submitted. Will it go to RC3? Christian, which package? sysconfig Will be in RC3. due to the last comments.... Have a look at 'Product' and comment 9. ---- Additional Comments From gmuelas@de.ibm.com 2005-12-27 08:03 EDT ------- Successfuly verified with RC4a set to fixed. Closed. |