netdev - RE: em1 is visible to iproute2 but not ethtool or tcpdump

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Mar 2013 20:45:29 +0000
From:	"Allan, Bruce W" <bruce.w.allan@...el.com>
To:	Andy Lutomirski <luto@...capital.net>,
	Network Development <netdev@...r.kernel.org>
CC:	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>
Subject: RE: em1 is visible to iproute2 but not ethtool or tcpdump

> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-
> owner@...r.kernel.org] On Behalf Of Andy Lutomirski
> Sent: Thursday, March 14, 2013 9:54 AM
> To: Network Development
> Cc: e1000-devel@...ts.sourceforge.net
> Subject: em1 is visible to iproute2 but not ethtool or tcpdump
> 
> My e1000e device is em1.  It has this rather strange behavior on
> Fedora's 3.8.1 (although 3.7.something did the same thing, I believe):
> 
> $ ip link show dev em1
> 6: em1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
> pfifo_fast
> state DOWN qlen 1000
>     link/ether f0:de:f1:59:f6:c9 brd ff:ff:ff:ff:ff:ff
> $ strace -e socket,ioctl ethtool em1
> socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
> Settings for em1:
> ioctl(3, SIOCETHTOOL, 0x7fffa6c554d0)   = -1 ENODEV (No such device)
> Cannot get device settings: No such device
> ioctl(3, SIOCETHTOOL, 0x7fffa6c554d0)   = -1 ENODEV (No such device)
> Cannot get wake-on-lan settings: No such device
> ioctl(3, SIOCETHTOOL, 0x7fffa6c554d0)   = -1 ENODEV (No such device)
> Cannot get message level: No such device
> ioctl(3, SIOCETHTOOL, 0x7fffa6c554d0)   = -1 ENODEV (No such device)
> Cannot get link status: No such device
> No data available
> +++ exited with 75 +++
> $ sudo tcpdump -i em1
> tcpdump: em1: SIOETHTOOL(ETHTOOL_GTSO) ioctl failed: No such device
> 
> A sufficient number of rmmod/modprobe cycles will make it work.
> 
> This is, perhaps, helpful:
> 
> $ sudo ip link set dev em1 name foobar
> RTNETLINK answers: Device or resource busy
> $ sudo ip link set dev em1 down
> $ sudo ip link set dev em1 name foobar
> $ sudo ethtool foobar
> Settings for foobar:
> 	Supported ports: [ TP ]
> 	Supported link modes:   10baseT/Half 10baseT/Full
> 	                        100baseT/Half 100baseT/Full
> 	                        1000baseT/Full
> 	Supported pause frame use: No
> 	Supports auto-negotiation: Yes
> 	Advertised link modes:  10baseT/Half 10baseT/Full
> 	                        100baseT/Half 100baseT/Full
> 	                        1000baseT/Full
> 	Advertised pause frame use: No
> 	Advertised auto-negotiation: Yes
> 	Speed: Unknown!
> 	Duplex: Unknown! (255)
> 	Port: Twisted Pair
> 	PHYAD: 1
> 	Transceiver: internal
> 	Auto-negotiation: on
> 	MDI-X: Unknown
> 	Supports Wake-on: pumbg
> 	Wake-on: g
> 	Current message level: 0x00000007 (7)
> 			       drv probe link
> 	Link detected: no
> $ sudo ip link set dev foobar name em1
> $ sudo ethtool em1
> Settings for em1:
> 	Supported ports: [ TP ]
> 	Supported link modes:   10baseT/Half 10baseT/Full
> 	                        100baseT/Half 100baseT/Full
> 	                        1000baseT/Full
> 	Supported pause frame use: No
> 	Supports auto-negotiation: Yes
> 	Advertised link modes:  10baseT/Half 10baseT/Full
> 	                        100baseT/Half 100baseT/Full
> 	                        1000baseT/Full
> 	Advertised pause frame use: No
> 	Advertised auto-negotiation: Yes
> 	Speed: Unknown!
> 	Duplex: Unknown! (255)
> 	Port: Twisted Pair
> 	PHYAD: 1
> 	Transceiver: internal
> 	Auto-negotiation: on
> 	MDI-X: Unknown
> 	Supports Wake-on: pumbg
> 	Wake-on: g
> 	Current message level: 0x00000007 (7)
> 			       drv probe link
> 	Link detected: no
> $
> 
> This bug (?) isn't a show-stopper, but it's rather annoying.  I
> suspect a core networking bug, not an e1000e bug, but I cc'd the e1000
> people just in case.

This sounds related to some runtime power management (RPM) issues that have
already been fixed.  First check whether RPM is enabled for your device - the file
/sys/devices/pciNNNN:NN/NNNN:NN:NN.N/power/control (where NNNN... is
the PCI domain, bus, slot and function of your device) will contain "auto" when it
is enabled.  To disable RPM for that device, change the value in the file to "on".

HTH,
Bruce.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html