Bugzilla – Bug 132709
LTC19643-LLADDR not used in ifup-dhcp
Last modified: 2016-02-13 05:41:43 UTC
LTC Owner is: gjlynx@us.ibm.com LTC Originator is: gmuelas@de.ibm.com Problem description: When setting up an OSA Card with YAST to use be in Layer2 mode (changing/adding manually LLADDR in 'ifcfg-...' file, because LTC Bug 17202-Novell Bug 98958 did not make it to Beta4), and then also to get the IP address dynamicly (with dhcpcd), it does not work, receiving messages in the console like: Nov 8 13:51:22 t2926003 dhcpcd[2037]: dhcpStart: ioctl SIOCSIFFLAGS: Operation not permitted This probably has something to do, that dhcpcd could be trying to do something with the Real MAC Address of the OSA Card, which when using Layer2 mode is not allowed to be used, but only a Virtual MAC Address which has to be different than the real one. In any case, if I set, also with YAST, a manual IP Address (and the MAC Address in the right ifcfg), restart the interfaces (which then makes the interface to be up and running with the manual IP Address and the virtual MAC address), and then in YAST change the interface to get the IP Address dynamicly (with dhcpcd), and again restart then interfaces, then it works, and gets an IP Address in the range offered by the DHCP Server. Problem comes again when rebooting, probably because the MAC address is reseted to the default MAC address, and dhcpcd tries to do some kind of operation with the MAC address which is runing at that moment, and the interface is again with no IP Address! :-( If this is a customer issue, please indicate the impact to the customer: Not yet, but it'll be, since lots of customers are moving to Layer2. If this is not an installation problem, Describe any custom patches installed. None Provide output from "uname -a", if possible: Linux t2926003 2.6.5-7.233-s390x #1 SMP Tue Oct 25 13:43:46 UTC 2005 s390x s390x s390x GNU/Linux Hardware Environment Machine type (p650, x235, SF2, etc.): eServer zSeries Cpu type (Power4, Power5, IA-64, etc.): z9 Describe any special hardware you think might be relevant to this problem: (any) OSA Card direct attached supporting Layer2 (uCode >= 6.25) Is this reproducible? Yes If so, how long does it (did it) take to reproduce it? Not long. Describe the steps: Having a DHCP server runing somewhere in the same physical network or being accessible from this client: - With YAST set up network interface to be in Layer2, - Still with YAST, give a virual MAC Address to be different than the real MAC Address. (at the time that I'm reporting this Bug, it is still needed to write the virtual MAC Address manually to the apropiate 'ifcfg-...' file as value for LLADDR...see LTC Bug 17202-Novell Bug 98958), - Still with YAST, set network interface to get IP Address Dynacmicly (using dhcpcd) - Finish, and you'll see how NO ipaddress is obtained and an error message in /var/log/messages appears (probably because dhcpcd tries to do something with the default=real MAC Address, which is not allowed to set/use in Layer2 mode): Nov 8 13:51:22 t2926003 dhcpcd[2037]: dhcpStart: ioctl SIOCSIFFLAGS: Operation not permitted Is the system (not just the application) hung? No Did the system produce an OOPS message on the console? No Is the system sitting in a debugger right now? No Created mirror request (id=4888)Novell Bugzilla Is YAST/dhcpcd problem Assign to SuSE team as requested.
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.