net: add name_assign_type netdev attribute
Based on a patch by David Herrmann.
The name_assign_type attribute gives hints where the interface name of a
given net-device comes from. These values are currently defined:
NET_NAME_ENUM:
The ifname is provided by the kernel with an enumerated
suffix, typically based on order of discovery. Names may
be reused and unpredictable.
NET_NAME_PREDICTABLE:
The ifname has been assigned by the kernel in a predictable way
that is guaranteed to avoid reuse and always be the same for a
given device. Examples include statically created devices like
the loopback device and names deduced from hardware properties
(including being given explicitly by the firmware). Names
depending on the order of discovery, or in any other way on the
existence of other devices, must not be marked as PREDICTABLE.
NET_NAME_USER:
The ifname was provided by user-space during net-device setup.
NET_NAME_RENAMED:
The net-device has been renamed from userspace. Once this type is set,
it cannot change again.
NET_NAME_UNKNOWN:
This is an internal placeholder to indicate that we yet haven't yet
categorized the name. It will not be exposed to userspace, rather
-EINVAL is returned.
The aim of these patches is to improve user-space renaming of interfaces. As
a general rule, userspace must rename interfaces to guarantee that names stay
the same every time a given piece of hardware appears (at boot, or when
attaching it). However, there are several situations where userspace should
not perform the renaming, and that depends on both the policy of the local
admin, but crucially also on the nature of the current interface name.
If an interface was created in repsonse to a userspace request, and userspace
already provided a name, we most probably want to leave that name alone. The
main instance of this is wifi-P2P devices created over nl80211, which currently
have a long-standing bug where they are getting renamed by udev. We label such
names NET_NAME_USER.
If an interface, unbeknown to us, has already been renamed from userspace, we
most probably want to leave also that alone. This will typically happen when
third-party plugins (for instance to udev, but the interface is generic so could
be from anywhere) renames the interface without informing udev about it. A
typical situation is when you switch root from an installer or an initrd to the
real system and the new instance of udev does not know what happened before
the switch. These types of problems have caused repeated issues in the past. To
solve this, once an interface has been renamed, its name is labelled
NET_NAME_RENAMED.
In many cases, the kernel is actually able to name interfaces in such a
way that there is no need for userspace to rename them. This is the case when
the enumeration order of devices, or in fact any other (non-parent) device on
the system, can not influence the name of the interface. Examples include
statically created devices, or any naming schemes based on hardware properties
of the interface. In this case the admin may prefer to use the kernel-provided
names, and to make that possible we label such names NET_NAME_PREDICTABLE.
We want the kernel to have tho possibilty of performing predictable interface
naming itself (and exposing to userspace that it has), as the information
necessary for a proper naming scheme for a certain class of devices may not
be exposed to userspace.
The case where renaming is almost certainly desired, is when the kernel has
given the interface a name using global device enumeration based on order of
discovery (ethX, wlanY, etc). These naming schemes are labelled NET_NAME_ENUM.
Lastly, a fallback is left as NET_NAME_UNKNOWN, to indicate that a driver has
not yet been ported. This is mostly useful as a transitionary measure, allowing
us to label the various naming schemes bit by bit.
v8: minor documentation fixes
v9: move comment to the right commit
Signed-off-by: Tom Gundersen <teg@jklm.no>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-14 14:37:22 +00:00
|
|
|
What: /sys/class/net/<iface>/name_assign_type
|
|
|
|
|
Date: July 2014
|
|
|
|
|
KernelVersion: 3.17
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the name assignment type. Possible values are:
|
2020-10-30 07:40:50 +00:00
|
|
|
|
|
|
|
|
== ==========================================================
|
|
|
|
|
1 enumerated by the kernel, possibly in an unpredictable way
|
|
|
|
|
2 predictably named by the kernel
|
|
|
|
|
3 named by userspace
|
|
|
|
|
4 renamed
|
|
|
|
|
== ==========================================================
|
net: add name_assign_type netdev attribute
Based on a patch by David Herrmann.
The name_assign_type attribute gives hints where the interface name of a
given net-device comes from. These values are currently defined:
NET_NAME_ENUM:
The ifname is provided by the kernel with an enumerated
suffix, typically based on order of discovery. Names may
be reused and unpredictable.
NET_NAME_PREDICTABLE:
The ifname has been assigned by the kernel in a predictable way
that is guaranteed to avoid reuse and always be the same for a
given device. Examples include statically created devices like
the loopback device and names deduced from hardware properties
(including being given explicitly by the firmware). Names
depending on the order of discovery, or in any other way on the
existence of other devices, must not be marked as PREDICTABLE.
NET_NAME_USER:
The ifname was provided by user-space during net-device setup.
NET_NAME_RENAMED:
The net-device has been renamed from userspace. Once this type is set,
it cannot change again.
NET_NAME_UNKNOWN:
This is an internal placeholder to indicate that we yet haven't yet
categorized the name. It will not be exposed to userspace, rather
-EINVAL is returned.
The aim of these patches is to improve user-space renaming of interfaces. As
a general rule, userspace must rename interfaces to guarantee that names stay
the same every time a given piece of hardware appears (at boot, or when
attaching it). However, there are several situations where userspace should
not perform the renaming, and that depends on both the policy of the local
admin, but crucially also on the nature of the current interface name.
If an interface was created in repsonse to a userspace request, and userspace
already provided a name, we most probably want to leave that name alone. The
main instance of this is wifi-P2P devices created over nl80211, which currently
have a long-standing bug where they are getting renamed by udev. We label such
names NET_NAME_USER.
If an interface, unbeknown to us, has already been renamed from userspace, we
most probably want to leave also that alone. This will typically happen when
third-party plugins (for instance to udev, but the interface is generic so could
be from anywhere) renames the interface without informing udev about it. A
typical situation is when you switch root from an installer or an initrd to the
real system and the new instance of udev does not know what happened before
the switch. These types of problems have caused repeated issues in the past. To
solve this, once an interface has been renamed, its name is labelled
NET_NAME_RENAMED.
In many cases, the kernel is actually able to name interfaces in such a
way that there is no need for userspace to rename them. This is the case when
the enumeration order of devices, or in fact any other (non-parent) device on
the system, can not influence the name of the interface. Examples include
statically created devices, or any naming schemes based on hardware properties
of the interface. In this case the admin may prefer to use the kernel-provided
names, and to make that possible we label such names NET_NAME_PREDICTABLE.
We want the kernel to have tho possibilty of performing predictable interface
naming itself (and exposing to userspace that it has), as the information
necessary for a proper naming scheme for a certain class of devices may not
be exposed to userspace.
The case where renaming is almost certainly desired, is when the kernel has
given the interface a name using global device enumeration based on order of
discovery (ethX, wlanY, etc). These naming schemes are labelled NET_NAME_ENUM.
Lastly, a fallback is left as NET_NAME_UNKNOWN, to indicate that a driver has
not yet been ported. This is mostly useful as a transitionary measure, allowing
us to label the various naming schemes bit by bit.
v8: minor documentation fixes
v9: move comment to the right commit
Signed-off-by: Tom Gundersen <teg@jklm.no>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-14 14:37:22 +00:00
|
|
|
|
2014-03-28 21:25:57 +00:00
|
|
|
What: /sys/class/net/<iface>/addr_assign_type
|
|
|
|
|
Date: July 2010
|
|
|
|
|
KernelVersion: 3.2
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the address assignment type. Possible values are:
|
2020-10-30 07:40:50 +00:00
|
|
|
|
|
|
|
|
== =============================
|
|
|
|
|
0 permanent address
|
|
|
|
|
1 randomly generated
|
|
|
|
|
2 stolen from another device
|
|
|
|
|
3 set using dev_set_mac_address
|
|
|
|
|
== =============================
|
2014-03-28 21:25:57 +00:00
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/addr_len
|
|
|
|
|
Date: April 2005
|
|
|
|
|
KernelVersion: 2.6.12
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the hardware address size in bytes.
|
|
|
|
|
Values vary based on the lower-level protocol used by the
|
|
|
|
|
interface (Ethernet, FDDI, ATM, IEEE 802.15.4...). See
|
|
|
|
|
include/uapi/linux/if_*.h for actual values.
|
|
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/address
|
|
|
|
|
Date: April 2005
|
|
|
|
|
KernelVersion: 2.6.12
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Hardware address currently assigned to this interface.
|
|
|
|
|
Format is a string, e.g: 00:11:22:33:44:55 for an Ethernet MAC
|
|
|
|
|
address.
|
|
|
|
|
|
2015-05-04 20:47:13 +00:00
|
|
|
What: /sys/class/net/<bridge iface>/bridge/group_fwd_mask
|
|
|
|
|
Date: January 2012
|
|
|
|
|
KernelVersion: 3.2
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Bitmask to allow forwarding of link local frames with address
|
|
|
|
|
01-80-C2-00-00-0X on a bridge device. Only values that set bits
|
|
|
|
|
not matching BR_GROUPFWD_RESTRICTED in net/bridge/br_private.h
|
|
|
|
|
allowed.
|
|
|
|
|
Default value 0 does not forward any link local frames.
|
|
|
|
|
|
|
|
|
|
Restricted bits:
|
2020-10-30 07:40:50 +00:00
|
|
|
|
|
|
|
|
== ========================================================
|
|
|
|
|
0 01-80-C2-00-00-00 Bridge Group Address used for STP
|
|
|
|
|
1 01-80-C2-00-00-01 (MAC Control) 802.3 used for MAC PAUSE
|
|
|
|
|
2 01-80-C2-00-00-02 (Link Aggregation) 802.3ad
|
|
|
|
|
== ========================================================
|
2015-05-04 20:47:13 +00:00
|
|
|
|
|
|
|
|
Any values not setting these bits can be used. Take special
|
|
|
|
|
care when forwarding control frames e.g. 802.1X-PAE or LLDP.
|
|
|
|
|
|
2014-03-28 21:25:57 +00:00
|
|
|
What: /sys/class/net/<iface>/broadcast
|
|
|
|
|
Date: April 2005
|
|
|
|
|
KernelVersion: 2.6.12
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Hardware broadcast address for this interface. Format is a
|
|
|
|
|
string, e.g: ff:ff:ff:ff:ff:ff for an Ethernet broadcast MAC
|
|
|
|
|
address.
|
|
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/carrier
|
|
|
|
|
Date: April 2005
|
|
|
|
|
KernelVersion: 2.6.12
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the current physical link state of the interface.
|
2023-08-14 21:28:20 +00:00
|
|
|
Possible values are:
|
2020-10-30 07:40:50 +00:00
|
|
|
|
|
|
|
|
== =====================
|
|
|
|
|
0 physical link is down
|
|
|
|
|
1 physical link is up
|
|
|
|
|
== =====================
|
2014-03-28 21:25:57 +00:00
|
|
|
|
|
|
|
|
Note: some special devices, e.g: bonding and team drivers will
|
|
|
|
|
allow this attribute to be written to force a link state for
|
|
|
|
|
operating correctly and designating another fallback interface.
|
|
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/dev_id
|
|
|
|
|
Date: April 2008
|
|
|
|
|
KernelVersion: 2.6.26
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the device unique identifier. Format is an hexadecimal
|
|
|
|
|
value. This is used to disambiguate interfaces which might be
|
|
|
|
|
stacked (e.g: VLAN interfaces) but still have the same MAC
|
|
|
|
|
address as their parent device.
|
|
|
|
|
|
2018-09-06 14:51:10 +00:00
|
|
|
What: /sys/class/net/<iface>/dev_port
|
|
|
|
|
Date: February 2014
|
|
|
|
|
KernelVersion: 3.15
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the port number of this network device, formatted
|
|
|
|
|
as a decimal value. Some NICs have multiple independent ports
|
|
|
|
|
on the same PCI bus, device and function. This attribute allows
|
|
|
|
|
userspace to distinguish the respective interfaces.
|
|
|
|
|
|
|
|
|
|
Note: some device drivers started to use 'dev_id' for this
|
|
|
|
|
purpose since long before 3.15 and have not adopted the new
|
|
|
|
|
attribute ever since. To query the port number, some tools look
|
|
|
|
|
exclusively at 'dev_port', while others only consult 'dev_id'.
|
|
|
|
|
If a network device has multiple client adapter ports as
|
|
|
|
|
described in the previous paragraph and does not set this
|
|
|
|
|
attribute to its port number, it's a kernel bug.
|
|
|
|
|
|
2014-03-28 21:25:57 +00:00
|
|
|
What: /sys/class/net/<iface>/dormant
|
|
|
|
|
Date: March 2006
|
|
|
|
|
KernelVersion: 2.6.17
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates whether the interface is in dormant state. Possible
|
|
|
|
|
values are:
|
|
|
|
|
0: interface is not dormant
|
|
|
|
|
1: interface is dormant
|
|
|
|
|
|
|
|
|
|
This attribute can be used by supplicant software to signal that
|
|
|
|
|
the device is not usable unless some supplicant-based
|
|
|
|
|
authentication is performed (e.g: 802.1x). 'link_mode' attribute
|
|
|
|
|
will also reflect the dormant state.
|
|
|
|
|
|
2020-04-19 22:11:51 +00:00
|
|
|
What: /sys/class/net/<iface>/testing
|
|
|
|
|
Date: April 2002
|
|
|
|
|
KernelVersion: 5.8
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates whether the interface is under test. Possible
|
|
|
|
|
values are:
|
2020-10-30 07:40:50 +00:00
|
|
|
|
|
|
|
|
== =============================
|
|
|
|
|
0 interface is not being tested
|
|
|
|
|
1 interface is being tested
|
|
|
|
|
== =============================
|
2020-04-19 22:11:51 +00:00
|
|
|
|
|
|
|
|
When an interface is under test, it cannot be expected
|
|
|
|
|
to pass packets as normal.
|
|
|
|
|
|
2020-11-02 10:32:13 +00:00
|
|
|
What: /sys/class/net/<iface>/duplex
|
2014-03-28 21:25:57 +00:00
|
|
|
Date: October 2009
|
|
|
|
|
KernelVersion: 2.6.33
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the interface latest or current duplex value. Possible
|
|
|
|
|
values are:
|
2020-10-30 07:40:50 +00:00
|
|
|
|
|
|
|
|
==== ===========
|
|
|
|
|
half half duplex
|
|
|
|
|
full full duplex
|
|
|
|
|
==== ===========
|
2014-03-28 21:25:57 +00:00
|
|
|
|
|
|
|
|
Note: This attribute is only valid for interfaces that implement
|
2018-08-28 17:56:58 +00:00
|
|
|
the ethtool get_link_ksettings method (mostly Ethernet).
|
2014-03-28 21:25:57 +00:00
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/flags
|
|
|
|
|
Date: April 2005
|
|
|
|
|
KernelVersion: 2.6.12
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the interface flags as a bitmask in hexadecimal. See
|
|
|
|
|
include/uapi/linux/if.h for a list of all possible values and
|
|
|
|
|
the flags semantics.
|
|
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/ifalias
|
|
|
|
|
Date: September 2008
|
|
|
|
|
KernelVersion: 2.6.28
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates/stores an interface alias name as a string. This can
|
|
|
|
|
be used for system management purposes.
|
|
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/ifindex
|
|
|
|
|
Date: April 2005
|
|
|
|
|
KernelVersion: 2.6.12
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the system-wide interface unique index identifier as a
|
|
|
|
|
decimal number. This attribute is used for mapping an interface
|
|
|
|
|
identifier to an interface name. It is used throughout the
|
|
|
|
|
networking stack for specifying the interface specific
|
|
|
|
|
requests/events.
|
|
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/iflink
|
|
|
|
|
Date: April 2005
|
|
|
|
|
KernelVersion: 2.6.12
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the system-wide interface unique index identifier a
|
|
|
|
|
the interface is linked to. Format is decimal. This attribute is
|
|
|
|
|
used to resolve interfaces chaining, linking and stacking.
|
|
|
|
|
Physical interfaces have the same 'ifindex' and 'iflink' values.
|
|
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/link_mode
|
|
|
|
|
Date: March 2006
|
|
|
|
|
KernelVersion: 2.6.17
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the interface link mode, as a decimal number. This
|
|
|
|
|
attribute should be used in conjunction with 'dormant' attribute
|
|
|
|
|
to determine the interface usability. Possible values:
|
2020-10-30 07:40:50 +00:00
|
|
|
|
|
|
|
|
== =================
|
|
|
|
|
0 default link mode
|
|
|
|
|
1 dormant link mode
|
|
|
|
|
== =================
|
2014-03-28 21:25:57 +00:00
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/mtu
|
|
|
|
|
Date: April 2005
|
|
|
|
|
KernelVersion: 2.6.12
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the interface currently configured MTU value, in
|
|
|
|
|
bytes, and in decimal format. Specific values depends on the
|
|
|
|
|
lower-level interface protocol used. Ethernet devices will show
|
|
|
|
|
a 'mtu' attribute value of 1500 unless changed.
|
|
|
|
|
|
2014-08-12 23:26:57 +00:00
|
|
|
What: /sys/class/net/<iface>/netdev_group
|
2014-03-28 21:25:57 +00:00
|
|
|
Date: January 2011
|
|
|
|
|
KernelVersion: 2.6.39
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the interface network device group, as a decimal
|
|
|
|
|
integer. Default value is 0 which corresponds to the initial
|
|
|
|
|
network devices group. The group can be changed to affect
|
|
|
|
|
routing decisions (see: net/ipv4/fib_rules and
|
|
|
|
|
net/ipv6/fib6_rules.c).
|
|
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/operstate
|
|
|
|
|
Date: March 2006
|
|
|
|
|
KernelVersion: 2.6.17
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the interface RFC2863 operational state as a string.
|
2020-10-30 07:40:50 +00:00
|
|
|
|
2014-03-28 21:25:57 +00:00
|
|
|
Possible values are:
|
2020-10-30 07:40:50 +00:00
|
|
|
|
2014-03-28 21:25:57 +00:00
|
|
|
"unknown", "notpresent", "down", "lowerlayerdown", "testing",
|
|
|
|
|
"dormant", "up".
|
|
|
|
|
|
2014-05-23 23:35:40 +00:00
|
|
|
What: /sys/class/net/<iface>/phys_port_id
|
|
|
|
|
Date: July 2013
|
|
|
|
|
KernelVersion: 3.12
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the interface unique physical port identifier within
|
|
|
|
|
the NIC, as a string.
|
|
|
|
|
|
2015-03-18 02:23:15 +00:00
|
|
|
What: /sys/class/net/<iface>/phys_port_name
|
|
|
|
|
Date: March 2015
|
|
|
|
|
KernelVersion: 4.0
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the interface physical port name within the NIC,
|
|
|
|
|
as a string.
|
|
|
|
|
|
2014-03-28 21:25:57 +00:00
|
|
|
What: /sys/class/net/<iface>/speed
|
|
|
|
|
Date: October 2009
|
|
|
|
|
KernelVersion: 2.6.33
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the interface latest or current speed value. Value is
|
|
|
|
|
an integer representing the link speed in Mbits/sec.
|
|
|
|
|
|
|
|
|
|
Note: this attribute is only valid for interfaces that implement
|
2018-08-28 17:56:58 +00:00
|
|
|
the ethtool get_link_ksettings method (mostly Ethernet).
|
2014-03-28 21:25:57 +00:00
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/tx_queue_len
|
|
|
|
|
Date: April 2005
|
|
|
|
|
KernelVersion: 2.6.12
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the interface transmit queue len in number of packets,
|
|
|
|
|
as an integer value. Value depend on the type of interface,
|
|
|
|
|
Ethernet network adapters have a default value of 1000 unless
|
|
|
|
|
configured otherwise
|
|
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/type
|
|
|
|
|
Date: April 2005
|
|
|
|
|
KernelVersion: 2.6.12
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the interface protocol type as a decimal value. See
|
|
|
|
|
include/uapi/linux/if_arp.h for all possible values.
|
2014-11-28 13:34:19 +00:00
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/phys_switch_id
|
|
|
|
|
Date: November 2014
|
|
|
|
|
KernelVersion: 3.19
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Indicates the unique physical switch identifier of a switch this
|
|
|
|
|
port belongs to, as a string.
|
2017-05-25 16:21:42 +00:00
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/phydev
|
|
|
|
|
Date: May 2017
|
|
|
|
|
KernelVersion: 4.13
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Symbolic link to the PHY device this network device is attached
|
|
|
|
|
to.
|
2018-01-18 17:59:13 +00:00
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/carrier_changes
|
|
|
|
|
Date: Mar 2014
|
|
|
|
|
KernelVersion: 3.15
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
32-bit unsigned integer counting the number of times the link has
|
|
|
|
|
seen a change from UP to DOWN and vice versa
|
|
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/carrier_up_count
|
|
|
|
|
Date: Jan 2018
|
|
|
|
|
KernelVersion: 4.16
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
32-bit unsigned integer counting the number of times the link has
|
|
|
|
|
been up
|
|
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/carrier_down_count
|
|
|
|
|
Date: Jan 2018
|
|
|
|
|
KernelVersion: 4.16
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
32-bit unsigned integer counting the number of times the link has
|
|
|
|
|
been down
|
2021-02-08 19:34:10 +00:00
|
|
|
|
|
|
|
|
What: /sys/class/net/<iface>/threaded
|
|
|
|
|
Date: Jan 2021
|
|
|
|
|
KernelVersion: 5.12
|
|
|
|
|
Contact: netdev@vger.kernel.org
|
|
|
|
|
Description:
|
|
|
|
|
Boolean value to control the threaded mode per device. User could
|
|
|
|
|
set this value to enable/disable threaded mode for all napi
|
|
|
|
|
belonging to this device, without the need to do device up/down.
|
|
|
|
|
|
|
|
|
|
Possible values:
|
|
|
|
|
== ==================================
|
|
|
|
|
0 threaded mode disabled for this dev
|
|
|
|
|
1 threaded mode enabled for this dev
|
|
|
|
|
== ==================================
|