Bug 842054 - ip link set up/down not working
ip link set up/down not working
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: iproute (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Šabata
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-21 07:38 EDT by Bruno Wolff III
Modified: 2012-08-22 09:08 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-21 10:48:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bruno Wolff III 2012-07-21 07:38:37 EDT
Description of problem:
I needed to switch the names of eth0 and eth1 around after a system came up with them switched and I was unable to change the up/down state of either link. (A device needs to be down to rename.) eth0 was connected and up and eth1 was not connected and down. ip link set dev eth0 down and ip link set dev eth1 up do not return an error, but the link state isn't changed. I was able to do this a few months ago.

Version-Release number of selected component (if applicable):
kernel-PAE-3.5.0-0.rc7.git0.1.fc18.i686
iproute-3.4.0-1.fc18.i686

How reproducible:
Consistent on one machine.
  
Actual results:
[root@bruno bruno]# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 00:0d:61:15:bd:f6 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000
    link/ether 00:40:05:33:e9:f7 brd ff:ff:ff:ff:ff:ff
[root@bruno bruno]# ip link set dev eth1 up
[root@bruno bruno]# ip link set dev eth0 down
[root@bruno bruno]# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 00:0d:61:15:bd:f6 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000
    link/ether 00:40:05:33:e9:f7 brd ff:ff:ff:ff:ff:ff
Comment 1 Bruno Wolff III 2012-07-21 07:44:44 EDT
I just noticed the ip link set dev eth0 down does clear ip4 addesses from eth0.
Also doing some more testing with trying to rename eth1, it looks like I am actually setting the links up and down, but that the state shown by ip link doesn't change to match.
Comment 2 Bruno Wolff III 2012-07-21 07:49:51 EDT
Further testing shows that I can't rename eth0 even if I set it down (RTNETLINK answers: Device or resource busy). I can't rename eth1 after setting it up, even though ip link shows it as down. But if I set it down, then I can rename the device.
Comment 3 Bruno Wolff III 2012-07-27 01:25:12 EDT
I had a boot where things came up normally instead of with eth0 and eth1 switched and ip link set was working normally. I don't know if swapping device names resulted in that situation or booting in enforcing mode (I need permissive during boot to avoid a systemd issue.).
Comment 4 Bruno Wolff III 2012-08-21 10:48:43 EDT
I haven't seen the network devices get into this state in quite a while now, so I am going to assume that something fixed this.
Comment 5 Petr Šabata 2012-08-22 04:07:49 EDT
Have you possibly updated to 3.5.x?
Comment 6 Bruno Wolff III 2012-08-22 09:08:23 EDT
I am using iproute-3.5.1-1.fc19.i686 now with 3.6 kernels now.

I think the half up / half down status may have been related to running netconsole. I think I may have been using it when I reported this and then stopped without thinking that it was related to this bug.

I started using it again and noticed a similar effect (with odd reporting), but using set up and set down seemed to work more sanely. So I reported it as a separate possible bug (bug 850805).

Note You need to log in before you can comment on or make changes to this bug.