Netlink interface for ethtool¶
Basic information¶
Netlink interface for ethtool uses generic netlink family ethtool
(userspace application should use macros ETHTOOL_GENL_NAME and
ETHTOOL_GENL_VERSION defined in <linux/ethtool_netlink.h> uapi
header). This family does not use a specific header, all information in
requests and replies is passed using netlink attributes.
The ethtool netlink interface uses extended ACK for error and warning reporting, userspace application developers are encouraged to make these messages available to user in a suitable way.
Requests can be divided into three categories: “get” (retrieving information), “set” (setting parameters) and “action” (invoking an action).
All “set” and “action” type requests require admin privileges
(CAP_NET_ADMIN in the namespace). Most “get” type requests are allowed for
anyone but there are exceptions (where the response contains sensitive
information). In some cases, the request as such is allowed for anyone but
unprivileged users have attributes with sensitive information (e.g.
wake-on-lan password) omitted.
Conventions¶
Attributes which represent a boolean value usually use NLA_U8 type so that we can distinguish three states: “on”, “off” and “not present” (meaning the information is not available in “get” requests or value is not to be changed in “set” requests). For these attributes, the “true” value should be passed as number 1 but any non-zero value should be understood as “true” by recipient. In the tables below, “bool” denotes NLA_U8 attributes interpreted in this way.
In the message structure descriptions below, if an attribute name is suffixed with “+”, parent nest can contain multiple attributes of the same type. This implements an array of entries.
Request header¶
Each request or reply message contains a nested attribute with common header. Structure of this header is
ETHTOOL_A_HEADER_DEV_INDEXu32 device ifindex ETHTOOL_A_HEADER_DEV_NAMEstring device name ETHTOOL_A_HEADER_FLAGSu32 flags common for all requests
ETHTOOL_A_HEADER_DEV_INDEX and ETHTOOL_A_HEADER_DEV_NAME identify the
device message relates to. One of them is sufficient in requests, if both are
used, they must identify the same device. Some requests, e.g. global string
sets, do not require device identification. Most GET requests also allow
dump requests without device identification to query the same information for
all devices providing it (each device in a separate message).
ETHTOOL_A_HEADER_FLAGS is a bitmap of request flags common for all request
types. The interpretation of these flags is the same for all request types but
the flags may not apply to requests. Recognized flags are:
ETHTOOL_FLAG_COMPACT_BITSETSuse compact format bitsets in reply ETHTOOL_FLAG_OMIT_REPLYomit optional reply (_SET and _ACT)
New request flags should follow the general idea that if the flag is not set, the behaviour is backward compatible, i.e. requests from old clients not aware of the flag should be interpreted the way the client expects. A client must not set flags it does not understand.
Bit sets¶
For short bitmaps of (reasonably) fixed length, standard NLA_BITFIELD32
type is used. For arbitrary length bitmaps, ethtool netlink uses a nested
attribute with contents of one of two forms: compact (two binary bitmaps
representing bit values and mask of affected bits) and bit-by-bit (list of
bits identified by either index or name).
Verbose (bit-by-bit) bitsets allow sending symbolic names for bits together with their values which saves a round trip (when the bitset is passed in a request) or at least a second request (when the bitset is in a reply). This is useful for one shot applications like traditional ethtool command. On the other hand, long running applications like ethtool monitor (displaying notifications) or network management daemons may prefer fetching the names only once and using compact form to save message size. Notifications from ethtool netlink interface always use compact form for bitsets.
A bitset can represent either a value/mask pair (ETHTOOL_A_BITSET_NOMASK
not set) or a single bitmap (ETHTOOL_A_BITSET_NOMASK set). In requests
modifying a bitmap, the former changes the bit set in mask to values set in
value and preserves the rest; the latter sets the bits set in the bitmap and
clears the rest.
Compact form: nested (bitset) atrribute contents:
ETHTOOL_A_BITSET_NOMASKflag no mask, only a list ETHTOOL_A_BITSET_SIZEu32 number of significant bits ETHTOOL_A_BITSET_VALUEbinary bitmap of bit values ETHTOOL_A_BITSET_MASKbinary bitmap of valid bits
Value and mask must have length at least ETHTOOL_A_BITSET_SIZE bits
rounded up to a multiple of 32 bits. They consist of 32-bit words in host byte
order, words ordered from least significant to most significant (i.e. the same
way as bitmaps are passed with ioctl interface).
For compact form, ETHTOOL_A_BITSET_SIZE and ETHTOOL_A_BITSET_VALUE are
mandatory. ETHTOOL_A_BITSET_MASK attribute is mandatory if
ETHTOOL_A_BITSET_NOMASK is not set (bitset represents a value/mask pair);
if ETHTOOL_A_BITSET_NOMASK is not set, ETHTOOL_A_BITSET_MASK is not
allowed (bitset represents a single bitmap.
Kernel bit set length may differ from userspace length if older application is used on newer kernel or vice versa. If userspace bitmap is longer, an error is issued only if the request actually tries to set values of some bits not recognized by kernel.
Bit-by-bit form: nested (bitset) attribute contents:
ETHTOOL_A_BITSET_NOMASKflag no mask, only a list ETHTOOL_A_BITSET_SIZEu32 number of significant bits ETHTOOL_A_BITSET_BITSnested array of bits ETHTOOL_A_BITSET_BITS_BIT+nested one bit ETHTOOL_A_BITSET_BIT_INDEXu32 bit index (0 for LSB) ETHTOOL_A_BITSET_BIT_NAMEstring bit name ETHTOOL_A_BITSET_BIT_VALUEflag present if bit is set
Bit size is optional for bit-by-bit form. ETHTOOL_A_BITSET_BITS nest can
only contain ETHTOOL_A_BITSET_BITS_BIT attributes but there can be an
arbitrary number of them. A bit may be identified by its index or by its
name. When used in requests, listed bits are set to 0 or 1 according to
ETHTOOL_A_BITSET_BIT_VALUE, the rest is preserved. A request fails if
index exceeds kernel bit length or if name is not recognized.
When ETHTOOL_A_BITSET_NOMASK flag is present, bitset is interpreted as
a simple bitmap. ETHTOOL_A_BITSET_BIT_VALUE attributes are not used in
such case. Such bitset represents a bitmap with listed bits set and the rest
zero.
In requests, application can use either form. Form used by kernel in reply is
determined by ETHTOOL_FLAG_COMPACT_BITSETS flag in flags field of request
header. Semantics of value and mask depends on the attribute.
List of message types¶
All constants identifying message types use ETHTOOL_CMD_ prefix and suffix
according to message purpose:
_GETuserspace request to retrieve data _SETuserspace request to set data _ACTuserspace request to perform an action _GET_REPLYkernel reply to a GETrequest_SET_REPLYkernel reply to a SETrequest_ACT_REPLYkernel reply to an ACTrequest_NTFkernel notification
Userspace to kernel:
ETHTOOL_MSG_STRSET_GETget string set ETHTOOL_MSG_LINKINFO_GETget link settings ETHTOOL_MSG_LINKINFO_SETset link settings ETHTOOL_MSG_LINKMODES_GETget link modes info ETHTOOL_MSG_LINKMODES_SETset link modes info ETHTOOL_MSG_LINKSTATE_GETget link state ETHTOOL_MSG_DEBUG_GETget debugging settings ETHTOOL_MSG_DEBUG_SETset debugging settings ETHTOOL_MSG_WOL_GETget wake-on-lan settings ETHTOOL_MSG_WOL_SETset wake-on-lan settings ETHTOOL_MSG_FEATURES_GETget device features ETHTOOL_MSG_FEATURES_SETset device features ETHTOOL_MSG_PRIVFLAGS_GETget private flags ETHTOOL_MSG_PRIVFLAGS_SETset private flags ETHTOOL_MSG_RINGS_GETget ring sizes ETHTOOL_MSG_RINGS_SETset ring sizes ETHTOOL_MSG_CHANNELS_GETget channel counts ETHTOOL_MSG_CHANNELS_SETset channel counts ETHTOOL_MSG_COALESCE_GETget coalescing parameters ETHTOOL_MSG_COALESCE_SETset coalescing parameters ETHTOOL_MSG_PAUSE_GETget pause parameters ETHTOOL_MSG_PAUSE_SETset pause parameters ETHTOOL_MSG_EEE_GETget EEE settings ETHTOOL_MSG_EEE_SETset EEE settings ETHTOOL_MSG_TSINFO_GETget timestamping info ETHTOOL_MSG_CABLE_TEST_ACTaction start cable test ETHTOOL_MSG_CABLE_TEST_TDR_ACTaction start raw TDR cable test ETHTOOL_MSG_TUNNEL_INFO_GETget tunnel offload info
Kernel to userspace:
ETHTOOL_MSG_STRSET_GET_REPLYstring set contents ETHTOOL_MSG_LINKINFO_GET_REPLYlink settings ETHTOOL_MSG_LINKINFO_NTFlink settings notification ETHTOOL_MSG_LINKMODES_GET_REPLYlink modes info ETHTOOL_MSG_LINKMODES_NTFlink modes notification ETHTOOL_MSG_LINKSTATE_GET_REPLYlink state info ETHTOOL_MSG_DEBUG_GET_REPLYdebugging settings ETHTOOL_MSG_DEBUG_NTFdebugging settings notification ETHTOOL_MSG_WOL_GET_REPLYwake-on-lan settings ETHTOOL_MSG_WOL_NTFwake-on-lan settings notification ETHTOOL_MSG_FEATURES_GET_REPLYdevice features ETHTOOL_MSG_FEATURES_SET_REPLYoptional reply to FEATURES_SET ETHTOOL_MSG_FEATURES_NTFnetdev features notification ETHTOOL_MSG_PRIVFLAGS_GET_REPLYprivate flags ETHTOOL_MSG_PRIVFLAGS_NTFprivate flags ETHTOOL_MSG_RINGS_GET_REPLYring sizes ETHTOOL_MSG_RINGS_NTFring sizes ETHTOOL_MSG_CHANNELS_GET_REPLYchannel counts ETHTOOL_MSG_CHANNELS_NTFchannel counts ETHTOOL_MSG_COALESCE_GET_REPLYcoalescing parameters ETHTOOL_MSG_COALESCE_NTFcoalescing parameters ETHTOOL_MSG_PAUSE_GET_REPLYpause parameters ETHTOOL_MSG_PAUSE_NTFpause parameters ETHTOOL_MSG_EEE_GET_REPLYEEE settings ETHTOOL_MSG_EEE_NTFEEE settings ETHTOOL_MSG_TSINFO_GET_REPLYtimestamping info ETHTOOL_MSG_CABLE_TEST_NTFCable test results ETHTOOL_MSG_CABLE_TEST_TDR_NTFCable test TDR results ETHTOOL_MSG_TUNNEL_INFO_GET_REPLYtunnel offload info
GET requests are sent by userspace applications to retrieve device
information. They usually do not contain any message specific attributes.
Kernel replies with corresponding “GET_REPLY” message. For most types, GET
request with NLM_F_DUMP and no device identification can be used to query
the information for all devices supporting the request.
If the data can be also modified, corresponding SET message with the same
layout as corresponding GET_REPLY is used to request changes. Only
attributes where a change is requested are included in such request (also, not
all attributes may be changed). Replies to most SET request consist only
of error code and extack; if kernel provides additional data, it is sent in
the form of corresponding SET_REPLY message which can be suppressed by
setting ETHTOOL_FLAG_OMIT_REPLY flag in request header.
Data modification also triggers sending a NTF message with a notification.
These usually bear only a subset of attributes which was affected by the
change. The same notification is issued if the data is modified using other
means (mostly ioctl ethtool interface). Unlike notifications from ethtool
netlink code which are only sent if something actually changed, notifications
triggered by ioctl interface may be sent even if the request did not actually
change any data.
ACT messages request kernel (driver) to perform a specific action. If some
information is reported by kernel (which can be suppressed by setting
ETHTOOL_FLAG_OMIT_REPLY flag in request header), the reply takes form of
an ACT_REPLY message. Performing an action also triggers a notification
(NTF message).
Later sections describe the format and semantics of these messages.
STRSET_GET¶
Requests contents of a string set as provided by ioctl commands
ETHTOOL_GSSET_INFO and ETHTOOL_GSTRINGS. String sets are not user
writeable so that the corresponding STRSET_SET message is only used in
kernel replies. There are two types of string sets: global (independent of
a device, e.g. device feature names) and device specific (e.g. device private
flags).
Request contents:
ETHTOOL_A_STRSET_HEADERnested request header ETHTOOL_A_STRSET_STRINGSETSnested string set to request ETHTOOL_A_STRINGSETS_STRINGSET+nested one string set ETHTOOL_A_STRINGSET_IDu32 set id
Kernel response contents:
ETHTOOL_A_STRSET_HEADERnested reply header ETHTOOL_A_STRSET_STRINGSETSnested array of string sets ETHTOOL_A_STRINGSETS_STRINGSET+nested one string set ETHTOOL_A_STRINGSET_IDu32 set id ETHTOOL_A_STRINGSET_COUNTu32 number of strings ETHTOOL_A_STRINGSET_STRINGSnested array of strings ETHTOOL_A_STRINGS_STRING+nested one string ETHTOOL_A_STRING_INDEXu32 string index ETHTOOL_A_STRING_VALUEstring string value ETHTOOL_A_STRSET_COUNTS_ONLYflag return only counts
Device identification in request header is optional. Depending on its presence
a and NLM_F_DUMP flag, there are three type of STRSET_GET requests:
- no
NLM_F_DUMP,no device: get “global” stringsets- no
NLM_F_DUMP, with device: get string sets related to the deviceNLM_F_DUMP, no device: get device related string sets for all devices
If there is no ETHTOOL_A_STRSET_STRINGSETS array, all string sets of
requested type are returned, otherwise only those specified in the request.
Flag ETHTOOL_A_STRSET_COUNTS_ONLY tells kernel to only return string
counts of the sets, not the actual strings.
LINKINFO_GET¶
Requests link settings as provided by ETHTOOL_GLINKSETTINGS except for
link modes and autonegotiation related information. The request does not use
any attributes.
Request contents:
ETHTOOL_A_LINKINFO_HEADERnested request header
Kernel response contents:
ETHTOOL_A_LINKINFO_HEADERnested reply header ETHTOOL_A_LINKINFO_PORTu8 physical port ETHTOOL_A_LINKINFO_PHYADDRu8 phy MDIO address ETHTOOL_A_LINKINFO_TP_MDIXu8 MDI(-X) status ETHTOOL_A_LINKINFO_TP_MDIX_CTRLu8 MDI(-X) control ETHTOOL_A_LINKINFO_TRANSCEIVERu8 transceiver
Attributes and their values have the same meaning as matching members of the corresponding ioctl structures.
LINKINFO_GET allows dump requests (kernel returns reply message for all
devices supporting the request).
LINKINFO_SET¶
LINKINFO_SET request allows setting some of the attributes reported by
LINKINFO_GET.
Request contents:
ETHTOOL_A_LINKINFO_HEADERnested request header ETHTOOL_A_LINKINFO_PORTu8 physical port ETHTOOL_A_LINKINFO_PHYADDRu8 phy MDIO address ETHTOOL_A_LINKINFO_TP_MDIX_CTRLu8 MDI(-X) control
MDI(-X) status and transceiver cannot be set, request with the corresponding attributes is rejected.
LINKMODES_GET¶
Requests link modes (supported, advertised and peer advertised) and related
information (autonegotiation status, link speed and duplex) as provided by
ETHTOOL_GLINKSETTINGS. The request does not use any attributes.
Request contents:
ETHTOOL_A_LINKMODES_HEADERnested request header
Kernel response contents:
ETHTOOL_A_LINKMODES_HEADERnested reply header ETHTOOL_A_LINKMODES_AUTONEGu8 autonegotiation status ETHTOOL_A_LINKMODES_OURSbitset advertised link modes ETHTOOL_A_LINKMODES_PEERbitset partner link modes ETHTOOL_A_LINKMODES_SPEEDu32 link speed (Mb/s) ETHTOOL_A_LINKMODES_DUPLEXu8 duplex mode ETHTOOL_A_LINKMODES_MASTER_SLAVE_CFGu8 Master/slave port mode ETHTOOL_A_LINKMODES_MASTER_SLAVE_STATEu8 Master/slave port state
For ETHTOOL_A_LINKMODES_OURS, value represents advertised modes and mask
represents supported modes. ETHTOOL_A_LINKMODES_PEER in the reply is a bit
list.
LINKMODES_GET allows dump requests (kernel returns reply messages for all
devices supporting the request).
LINKMODES_SET¶
Request contents:
ETHTOOL_A_LINKMODES_HEADERnested request header ETHTOOL_A_LINKMODES_AUTONEGu8 autonegotiation status ETHTOOL_A_LINKMODES_OURSbitset advertised link modes ETHTOOL_A_LINKMODES_PEERbitset partner link modes ETHTOOL_A_LINKMODES_SPEEDu32 link speed (Mb/s) ETHTOOL_A_LINKMODES_DUPLEXu8 duplex mode ETHTOOL_A_LINKMODES_MASTER_SLAVE_CFGu8 Master/slave port mode
ETHTOOL_A_LINKMODES_OURS bit set allows setting advertised link modes. If
autonegotiation is on (either set now or kept from before), advertised modes
are not changed (no ETHTOOL_A_LINKMODES_OURS attribute) and at least one
of speed and duplex is specified, kernel adjusts advertised modes to all
supported modes matching speed, duplex or both (whatever is specified). This
autoselection is done on ethtool side with ioctl interface, netlink interface
is supposed to allow requesting changes without knowing what exactly kernel
supports.
LINKSTATE_GET¶
Requests link state information. Link up/down flag (as provided by
ETHTOOL_GLINK ioctl command) is provided. Optionally, extended state might
be provided as well. In general, extended state describes reasons for why a port
is down, or why it operates in some non-obvious mode. This request does not have
any attributes.
Request contents:
ETHTOOL_A_LINKSTATE_HEADERnested request header
Kernel response contents:
ETHTOOL_A_LINKSTATE_HEADERnested reply header ETHTOOL_A_LINKSTATE_LINKbool link state (up/down) ETHTOOL_A_LINKSTATE_SQIu32 Current Signal Quality Index ETHTOOL_A_LINKSTATE_SQI_MAXu32 Max support SQI value ETHTOOL_A_LINKSTATE_EXT_STATEu8 link extended state ETHTOOL_A_LINKSTATE_EXT_SUBSTATEu8 link extended substate
For most NIC drivers, the value of ETHTOOL_A_LINKSTATE_LINK returns
carrier flag provided by netif_carrier_ok() but there are drivers which
define their own handler.
ETHTOOL_A_LINKSTATE_EXT_STATE and ETHTOOL_A_LINKSTATE_EXT_SUBSTATE are
optional values. ethtool core can provide either both
ETHTOOL_A_LINKSTATE_EXT_STATE and ETHTOOL_A_LINKSTATE_EXT_SUBSTATE,
or only ETHTOOL_A_LINKSTATE_EXT_STATE, or none of them.
LINKSTATE_GET allows dump requests (kernel returns reply messages for all
devices supporting the request).
Link extended states:
ETHTOOL_LINK_EXT_STATE_AUTONEGStates relating to the autonegotiation or issues therein ETHTOOL_LINK_EXT_STATE_LINK_TRAINING_FAILUREFailure during link training ETHTOOL_LINK_EXT_STATE_LINK_LOGICAL_MISMATCHLogical mismatch in physical coding sublayer or forward error correction sublayer ETHTOOL_LINK_EXT_STATE_BAD_SIGNAL_INTEGRITYSignal integrity issues ETHTOOL_LINK_EXT_STATE_NO_CABLENo cable connected ETHTOOL_LINK_EXT_STATE_CABLE_ISSUEFailure is related to cable, e.g., unsupported cable ETHTOOL_LINK_EXT_STATE_EEPROM_ISSUEFailure is related to EEPROM, e.g., failure during reading or parsing the data ETHTOOL_LINK_EXT_STATE_CALIBRATION_FAILUREFailure during calibration algorithm ETHTOOL_LINK_EXT_STATE_POWER_BUDGET_EXCEEDEDThe hardware is not able to provide the power required from cable or module ETHTOOL_LINK_EXT_STATE_OVERHEATThe module is overheated
Link extended substates:
Autoneg substates:
ETHTOOL_LINK_EXT_SUBSTATE_AN_NO_PARTNER_DETECTEDPeer side is down ETHTOOL_LINK_EXT_SUBSTATE_AN_ACK_NOT_RECEIVEDAck not received from peer side ETHTOOL_LINK_EXT_SUBSTATE_AN_NEXT_PAGE_EXCHANGE_FAILEDNext page exchange failed ETHTOOL_LINK_EXT_SUBSTATE_AN_NO_PARTNER_DETECTED_FORCE_MODEPeer side is down during force mode or there is no agreement of speed ETHTOOL_LINK_EXT_SUBSTATE_AN_FEC_MISMATCH_DURING_OVERRIDEForward error correction modes in both sides are mismatched ETHTOOL_LINK_EXT_SUBSTATE_AN_NO_HCDNo Highest Common Denominator Link training substates:
ETHTOOL_LINK_EXT_SUBSTATE_LT_KR_FRAME_LOCK_NOT_ACQUIREDFrames were not recognized, the lock failed ETHTOOL_LINK_EXT_SUBSTATE_LT_KR_LINK_INHIBIT_TIMEOUTThe lock did not occur before timeout ETHTOOL_LINK_EXT_SUBSTATE_LT_KR_LINK_PARTNER_DID_NOT_SET_RECEIVER_READYPeer side did not send ready signal after training process ETHTOOL_LINK_EXT_SUBSTATE_LT_REMOTE_FAULTRemote side is not ready yet Link logical mismatch substates:
ETHTOOL_LINK_EXT_SUBSTATE_LLM_PCS_DID_NOT_ACQUIRE_BLOCK_LOCKPhysical coding sublayer was not locked in first phase - block lock ETHTOOL_LINK_EXT_SUBSTATE_LLM_PCS_DID_NOT_ACQUIRE_AM_LOCKPhysical coding sublayer was not locked in second phase - alignment markers lock ETHTOOL_LINK_EXT_SUBSTATE_LLM_PCS_DID_NOT_GET_ALIGN_STATUSPhysical coding sublayer did not get align status ETHTOOL_LINK_EXT_SUBSTATE_LLM_FC_FEC_IS_NOT_LOCKEDFC forward error correction is not locked ETHTOOL_LINK_EXT_SUBSTATE_LLM_RS_FEC_IS_NOT_LOCKEDRS forward error correction is not locked Bad signal integrity substates:
ETHTOOL_LINK_EXT_SUBSTATE_BSI_LARGE_NUMBER_OF_PHYSICAL_ERRORSLarge number of physical errors ETHTOOL_LINK_EXT_SUBSTATE_BSI_UNSUPPORTED_RATEThe system attempted to operate the cable at a rate that is not formally supported, which led to signal integrity issues Cable issue substates:
ETHTOOL_LINK_EXT_SUBSTATE_CI_UNSUPPORTED_CABLEUnsupported cable ETHTOOL_LINK_EXT_SUBSTATE_CI_CABLE_TEST_FAILURECable test failure
DEBUG_GET¶
Requests debugging settings of a device. At the moment, only message mask is provided.
Request contents:
ETHTOOL_A_DEBUG_HEADERnested request header
Kernel response contents:
ETHTOOL_A_DEBUG_HEADERnested reply header ETHTOOL_A_DEBUG_MSGMASKbitset message mask
The message mask (ETHTOOL_A_DEBUG_MSGMASK) is equal to message level as
provided by ETHTOOL_GMSGLVL and set by ETHTOOL_SMSGLVL in ioctl
interface. While it is called message level there for historical reasons, most
drivers and almost all newer drivers use it as a mask of enabled message
classes (represented by NETIF_MSG_* constants); therefore netlink
interface follows its actual use in practice.
DEBUG_GET allows dump requests (kernel returns reply messages for all
devices supporting the request).
DEBUG_SET¶
Set or update debugging settings of a device. At the moment, only message mask is supported.
Request contents:
ETHTOOL_A_DEBUG_HEADERnested request header ETHTOOL_A_DEBUG_MSGMASKbitset message mask
ETHTOOL_A_DEBUG_MSGMASK bit set allows setting or modifying mask of
enabled debugging message types for the device.
WOL_GET¶
Query device wake-on-lan settings. Unlike most “GET” type requests,
ETHTOOL_MSG_WOL_GET requires (netns) CAP_NET_ADMIN privileges as it
(potentially) provides SecureOn(tm) password which is confidential.
Request contents:
ETHTOOL_A_WOL_HEADERnested request header
Kernel response contents:
ETHTOOL_A_WOL_HEADERnested reply header ETHTOOL_A_WOL_MODESbitset mask of enabled WoL modes ETHTOOL_A_WOL_SOPASSbinary SecureOn(tm) password
In reply, ETHTOOL_A_WOL_MODES mask consists of modes supported by the
device, value of modes which are enabled. ETHTOOL_A_WOL_SOPASS is only
included in reply if WAKE_MAGICSECURE mode is supported.
WOL_SET¶
Set or update wake-on-lan settings.
Request contents:
ETHTOOL_A_WOL_HEADERnested request header ETHTOOL_A_WOL_MODESbitset enabled WoL modes ETHTOOL_A_WOL_SOPASSbinary SecureOn(tm) password
ETHTOOL_A_WOL_SOPASS is only allowed for devices supporting
WAKE_MAGICSECURE mode.
FEATURES_GET¶
Gets netdev features like ETHTOOL_GFEATURES ioctl request.
Request contents:
ETHTOOL_A_FEATURES_HEADERnested request header
Kernel response contents:
ETHTOOL_A_FEATURES_HEADERnested reply header ETHTOOL_A_FEATURES_HWbitset dev->hw_features ETHTOOL_A_FEATURES_WANTEDbitset dev->wanted_features ETHTOOL_A_FEATURES_ACTIVEbitset dev->features ETHTOOL_A_FEATURES_NOCHANGEbitset NETIF_F_NEVER_CHANGE
Bitmaps in kernel response have the same meaning as bitmaps used in ioctl interference but attribute names are different (they are based on corresponding members of struct net_device). Legacy “flags” are not provided, if userspace needs them (most likely only ethtool for backward compatibility), it can calculate their values from related feature bits itself. ETHA_FEATURES_HW uses mask consisting of all features recognized by kernel (to provide all names when using verbose bitmap format), the other three use no mask (simple bit lists).
FEATURES_SET¶
Request to set netdev features like ETHTOOL_SFEATURES ioctl request.
Request contents:
ETHTOOL_A_FEATURES_HEADERnested request header ETHTOOL_A_FEATURES_WANTEDbitset requested features
Kernel response contents:
ETHTOOL_A_FEATURES_HEADERnested reply header ETHTOOL_A_FEATURES_WANTEDbitset diff wanted vs. result ETHTOOL_A_FEATURES_ACTIVEbitset diff old vs. new active
Request constains only one bitset which can be either value/mask pair (request to change specific feature bits and leave the rest) or only a value (request to set all features to specified set).
As request is subject to netdev_change_features() sanity checks, optional
kernel reply (can be suppressed by ETHTOOL_FLAG_OMIT_REPLY flag in request
header) informs client about the actual result. ETHTOOL_A_FEATURES_WANTED
reports the difference between client request and actual result: mask consists
of bits which differ between requested features and result (dev->features
after the operation), value consists of values of these bits in the request
(i.e. negated values from resulting features). ETHTOOL_A_FEATURES_ACTIVE
reports the difference between old and new dev->features: mask consists of
bits which have changed, values are their values in new dev->features (after
the operation).
ETHTOOL_MSG_FEATURES_NTF notification is sent not only if device features
are modified using ETHTOOL_MSG_FEATURES_SET request or on of ethtool ioctl
request but also each time features are modified with netdev_update_features()
or netdev_change_features().
PRIVFLAGS_GET¶
Gets private flags like ETHTOOL_GPFLAGS ioctl request.
Request contents:
ETHTOOL_A_PRIVFLAGS_HEADERnested request header
Kernel response contents:
ETHTOOL_A_PRIVFLAGS_HEADERnested reply header ETHTOOL_A_PRIVFLAGS_FLAGSbitset private flags
ETHTOOL_A_PRIVFLAGS_FLAGS is a bitset with values of device private flags.
These flags are defined by driver, their number and names (and also meaning)
are device dependent. For compact bitset format, names can be retrieved as
ETH_SS_PRIV_FLAGS string set. If verbose bitset format is requested,
response uses all private flags supported by the device as mask so that client
gets the full information without having to fetch the string set with names.
PRIVFLAGS_SET¶
Sets or modifies values of device private flags like ETHTOOL_SPFLAGS
ioctl request.
Request contents:
ETHTOOL_A_PRIVFLAGS_HEADERnested request header ETHTOOL_A_PRIVFLAGS_FLAGSbitset private flags
ETHTOOL_A_PRIVFLAGS_FLAGS can either set the whole set of private flags or
modify only values of some of them.
RINGS_GET¶
Gets ring sizes like ETHTOOL_GRINGPARAM ioctl request.
Request contents:
ETHTOOL_A_RINGS_HEADERnested request header
Kernel response contents:
ETHTOOL_A_RINGS_HEADERnested reply header ETHTOOL_A_RINGS_RX_MAXu32 max size of RX ring ETHTOOL_A_RINGS_RX_MINI_MAXu32 max size of RX mini ring ETHTOOL_A_RINGS_RX_JUMBO_MAXu32 max size of RX jumbo ring ETHTOOL_A_RINGS_TX_MAXu32 max size of TX ring ETHTOOL_A_RINGS_RXu32 size of RX ring ETHTOOL_A_RINGS_RX_MINIu32 size of RX mini ring ETHTOOL_A_RINGS_RX_JUMBOu32 size of RX jumbo ring ETHTOOL_A_RINGS_TXu32 size of TX ring
RINGS_SET¶
Sets ring sizes like ETHTOOL_SRINGPARAM ioctl request.
Request contents:
ETHTOOL_A_RINGS_HEADERnested reply header ETHTOOL_A_RINGS_RXu32 size of RX ring ETHTOOL_A_RINGS_RX_MINIu32 size of RX mini ring ETHTOOL_A_RINGS_RX_JUMBOu32 size of RX jumbo ring ETHTOOL_A_RINGS_TXu32 size of TX ring
Kernel checks that requested ring sizes do not exceed limits reported by driver. Driver may impose additional constraints and may not suspport all attributes.
CHANNELS_GET¶
Gets channel counts like ETHTOOL_GCHANNELS ioctl request.
Request contents:
ETHTOOL_A_CHANNELS_HEADERnested request header
Kernel response contents:
ETHTOOL_A_CHANNELS_HEADERnested reply header ETHTOOL_A_CHANNELS_RX_MAXu32 max receive channels ETHTOOL_A_CHANNELS_TX_MAXu32 max transmit channels ETHTOOL_A_CHANNELS_OTHER_MAXu32 max other channels ETHTOOL_A_CHANNELS_COMBINED_MAXu32 max combined channels ETHTOOL_A_CHANNELS_RX_COUNTu32 receive channel count ETHTOOL_A_CHANNELS_TX_COUNTu32 transmit channel count ETHTOOL_A_CHANNELS_OTHER_COUNTu32 other channel count ETHTOOL_A_CHANNELS_COMBINED_COUNTu32 combined channel count
CHANNELS_SET¶
Sets channel counts like ETHTOOL_SCHANNELS ioctl request.
Request contents:
ETHTOOL_A_CHANNELS_HEADERnested request header ETHTOOL_A_CHANNELS_RX_COUNTu32 receive channel count ETHTOOL_A_CHANNELS_TX_COUNTu32 transmit channel count ETHTOOL_A_CHANNELS_OTHER_COUNTu32 other channel count ETHTOOL_A_CHANNELS_COMBINED_COUNTu32 combined channel count
Kernel checks that requested channel counts do not exceed limits reported by driver. Driver may impose additional constraints and may not suspport all attributes.
COALESCE_GET¶
Gets coalescing parameters like ETHTOOL_GCOALESCE ioctl request.
Request contents:
ETHTOOL_A_COALESCE_HEADERnested request header
Kernel response contents:
ETHTOOL_A_COALESCE_HEADERnested reply header ETHTOOL_A_COALESCE_RX_USECSu32 delay (us), normal Rx ETHTOOL_A_COALESCE_RX_MAX_FRAMESu32 max packets, normal Rx ETHTOOL_A_COALESCE_RX_USECS_IRQu32 delay (us), Rx in IRQ ETHTOOL_A_COALESCE_RX_MAX_FRAMES_IRQu32 max packets, Rx in IRQ ETHTOOL_A_COALESCE_TX_USECSu32 delay (us), normal Tx ETHTOOL_A_COALESCE_TX_MAX_FRAMESu32 max packets, normal Tx ETHTOOL_A_COALESCE_TX_USECS_IRQu32 delay (us), Tx in IRQ ETHTOOL_A_COALESCE_TX_MAX_FRAMES_IRQu32 IRQ packets, Tx in IRQ ETHTOOL_A_COALESCE_STATS_BLOCK_USECSu32 delay of stats update ETHTOOL_A_COALESCE_USE_ADAPTIVE_RXbool adaptive Rx coalesce ETHTOOL_A_COALESCE_USE_ADAPTIVE_TXbool adaptive Tx coalesce ETHTOOL_A_COALESCE_PKT_RATE_LOWu32 threshold for low rate ETHTOOL_A_COALESCE_RX_USECS_LOWu32 delay (us), low Rx ETHTOOL_A_COALESCE_RX_MAX_FRAMES_LOWu32 max packets, low Rx ETHTOOL_A_COALESCE_TX_USECS_LOWu32 delay (us), low Tx ETHTOOL_A_COALESCE_TX_MAX_FRAMES_LOWu32 max packets, low Tx ETHTOOL_A_COALESCE_PKT_RATE_HIGHu32 threshold for high rate ETHTOOL_A_COALESCE_RX_USECS_HIGHu32 delay (us), high Rx ETHTOOL_A_COALESCE_RX_MAX_FRAMES_HIGHu32 max packets, high Rx ETHTOOL_A_COALESCE_TX_USECS_HIGHu32 delay (us), high Tx ETHTOOL_A_COALESCE_TX_MAX_FRAMES_HIGHu32 max packets, high Tx ETHTOOL_A_COALESCE_RATE_SAMPLE_INTERVALu32 rate sampling interval
Attributes are only included in reply if their value is not zero or the
corresponding bit in ethtool_ops::supported_coalesce_params is set (i.e.
they are declared as supported by driver).
COALESCE_SET¶
Sets coalescing parameters like ETHTOOL_SCOALESCE ioctl request.
Request contents:
ETHTOOL_A_COALESCE_HEADERnested request header ETHTOOL_A_COALESCE_RX_USECSu32 delay (us), normal Rx ETHTOOL_A_COALESCE_RX_MAX_FRAMESu32 max packets, normal Rx ETHTOOL_A_COALESCE_RX_USECS_IRQu32 delay (us), Rx in IRQ ETHTOOL_A_COALESCE_RX_MAX_FRAMES_IRQu32 max packets, Rx in IRQ ETHTOOL_A_COALESCE_TX_USECSu32 delay (us), normal Tx ETHTOOL_A_COALESCE_TX_MAX_FRAMESu32 max packets, normal Tx ETHTOOL_A_COALESCE_TX_USECS_IRQu32 delay (us), Tx in IRQ ETHTOOL_A_COALESCE_TX_MAX_FRAMES_IRQu32 IRQ packets, Tx in IRQ ETHTOOL_A_COALESCE_STATS_BLOCK_USECSu32 delay of stats update ETHTOOL_A_COALESCE_USE_ADAPTIVE_RXbool adaptive Rx coalesce ETHTOOL_A_COALESCE_USE_ADAPTIVE_TXbool adaptive Tx coalesce ETHTOOL_A_COALESCE_PKT_RATE_LOWu32 threshold for low rate ETHTOOL_A_COALESCE_RX_USECS_LOWu32 delay (us), low Rx ETHTOOL_A_COALESCE_RX_MAX_FRAMES_LOWu32 max packets, low Rx ETHTOOL_A_COALESCE_TX_USECS_LOWu32 delay (us), low Tx ETHTOOL_A_COALESCE_TX_MAX_FRAMES_LOWu32 max packets, low Tx ETHTOOL_A_COALESCE_PKT_RATE_HIGHu32 threshold for high rate ETHTOOL_A_COALESCE_RX_USECS_HIGHu32 delay (us), high Rx ETHTOOL_A_COALESCE_RX_MAX_FRAMES_HIGHu32 max packets, high Rx ETHTOOL_A_COALESCE_TX_USECS_HIGHu32 delay (us), high Tx ETHTOOL_A_COALESCE_TX_MAX_FRAMES_HIGHu32 max packets, high Tx ETHTOOL_A_COALESCE_RATE_SAMPLE_INTERVALu32 rate sampling interval
Request is rejected if it attributes declared as unsupported by driver (i.e.
such that the corresponding bit in ethtool_ops::supported_coalesce_params
is not set), regardless of their values. Driver may impose additional
constraints on coalescing parameters and their values.
PAUSE_GET¶
Gets channel counts like ETHTOOL_GPAUSE ioctl request.
Request contents:
ETHTOOL_A_PAUSE_HEADERnested request header
Kernel response contents:
ETHTOOL_A_PAUSE_HEADERnested request header ETHTOOL_A_PAUSE_AUTONEGbool pause autonegotiation ETHTOOL_A_PAUSE_RXbool receive pause frames ETHTOOL_A_PAUSE_TXbool transmit pause frames
PAUSE_SET¶
Sets pause parameters like ETHTOOL_GPAUSEPARAM ioctl request.
Request contents:
ETHTOOL_A_PAUSE_HEADERnested request header ETHTOOL_A_PAUSE_AUTONEGbool pause autonegotiation ETHTOOL_A_PAUSE_RXbool receive pause frames ETHTOOL_A_PAUSE_TXbool transmit pause frames
EEE_GET¶
Gets channel counts like ETHTOOL_GEEE ioctl request.
Request contents:
ETHTOOL_A_EEE_HEADERnested request header
Kernel response contents:
ETHTOOL_A_EEE_HEADERnested request header ETHTOOL_A_EEE_MODES_OURSbool supported/advertised modes ETHTOOL_A_EEE_MODES_PEERbool peer advertised link modes ETHTOOL_A_EEE_ACTIVEbool EEE is actively used ETHTOOL_A_EEE_ENABLEDbool EEE is enabled ETHTOOL_A_EEE_TX_LPI_ENABLEDbool Tx lpi enabled ETHTOOL_A_EEE_TX_LPI_TIMERu32 Tx lpi timeout (in us)
In ETHTOOL_A_EEE_MODES_OURS, mask consists of link modes for which EEE is
enabled, value of link modes for which EEE is advertised. Link modes for which
peer advertises EEE are listed in ETHTOOL_A_EEE_MODES_PEER (no mask). The
netlink interface allows reporting EEE status for all link modes but only
first 32 are provided by the ethtool_ops callback.
EEE_SET¶
Sets pause parameters like ETHTOOL_GEEEPARAM ioctl request.
Request contents:
ETHTOOL_A_EEE_HEADERnested request header ETHTOOL_A_EEE_MODES_OURSbool advertised modes ETHTOOL_A_EEE_ENABLEDbool EEE is enabled ETHTOOL_A_EEE_TX_LPI_ENABLEDbool Tx lpi enabled ETHTOOL_A_EEE_TX_LPI_TIMERu32 Tx lpi timeout (in us)
ETHTOOL_A_EEE_MODES_OURS is used to either list link modes to advertise
EEE for (if there is no mask) or specify changes to the list (if there is
a mask). The netlink interface allows reporting EEE status for all link modes
but only first 32 can be set at the moment as that is what the ethtool_ops
callback supports.
TSINFO_GET¶
Gets timestamping information like ETHTOOL_GET_TS_INFO ioctl request.
Request contents:
ETHTOOL_A_TSINFO_HEADERnested request header
Kernel response contents:
ETHTOOL_A_TSINFO_HEADERnested request header ETHTOOL_A_TSINFO_TIMESTAMPINGbitset SO_TIMESTAMPING flags ETHTOOL_A_TSINFO_TX_TYPESbitset supported Tx types ETHTOOL_A_TSINFO_RX_FILTERSbitset supported Rx filters ETHTOOL_A_TSINFO_PHC_INDEXu32 PTP hw clock index
ETHTOOL_A_TSINFO_PHC_INDEX is absent if there is no associated PHC (there
is no special value for this case). The bitset attributes are omitted if they
would be empty (no bit set).
CABLE_TEST¶
Start a cable test.
Request contents:
ETHTOOL_A_CABLE_TEST_HEADERnested request header
Notification contents:
An Ethernet cable typically contains 1, 2 or 4 pairs. The length of the pair can only be measured when there is a fault in the pair and hence a reflection. Information about the fault may not be available, depending on the specific hardware. Hence the contents of the notify message are mostly optional. The attributes can be repeated an arbitrary number of times, in an arbitrary order, for an arbitrary number of pairs.
The example shows the notification sent when the test is completed for a T2 cable, i.e. two pairs. One pair is OK and hence has no length information. The second pair has a fault and does have length information.
ETHTOOL_A_CABLE_TEST_HEADERnested reply header ETHTOOL_A_CABLE_TEST_STATUSu8 completed ETHTOOL_A_CABLE_TEST_NTF_NESTnested all the results ETHTOOL_A_CABLE_NEST_RESULTnested cable test result ETHTOOL_A_CABLE_RESULTS_PAIRu8 pair number ETHTOOL_A_CABLE_RESULTS_CODEu8 result code ETHTOOL_A_CABLE_NEST_RESULTnested cable test results ETHTOOL_A_CABLE_RESULTS_PAIRu8 pair number ETHTOOL_A_CABLE_RESULTS_CODEu8 result code ETHTOOL_A_CABLE_NEST_FAULT_LENGTHnested cable length ETHTOOL_A_CABLE_FAULT_LENGTH_PAIRu8 pair number ETHTOOL_A_CABLE_FAULT_LENGTH_CMu32 length in cm
CABLE_TEST TDR¶
Start a cable test and report raw TDR data
Request contents:
ETHTOOL_A_CABLE_TEST_TDR_HEADERnested reply header ETHTOOL_A_CABLE_TEST_TDR_CFGnested test configuration ETHTOOL_A_CABLE_STEP_FIRST_DISTANCEu32 first data distance ETHTOOL_A_CABLE_STEP_LAST_DISTANCEu32 last data distance ETHTOOL_A_CABLE_STEP_STEP_DISTANCEu32 distance of each step ETHTOOL_A_CABLE_TEST_TDR_CFG_PAIRu8 pair to test
The ETHTOOL_A_CABLE_TEST_TDR_CFG is optional, as well as all members of the nest. All distances are expressed in centimeters. The PHY takes the distances as a guide, and rounds to the nearest distance it actually supports. If a pair is passed, only that one pair will be tested. Otherwise all pairs are tested.
Notification contents:
Raw TDR data is gathered by sending a pulse down the cable and recording the amplitude of the reflected pulse for a given distance.
It can take a number of seconds to collect TDR data, especial if the full 100 meters is probed at 1 meter intervals. When the test is started a notification will be sent containing just ETHTOOL_A_CABLE_TEST_TDR_STATUS with the value ETHTOOL_A_CABLE_TEST_NTF_STATUS_STARTED.
When the test has completed a second notification will be sent containing ETHTOOL_A_CABLE_TEST_TDR_STATUS with the value ETHTOOL_A_CABLE_TEST_NTF_STATUS_COMPLETED and the TDR data.
The message may optionally contain the amplitude of the pulse send down the cable. This is measured in mV. A reflection should not be bigger than transmitted pulse.
Before the raw TDR data should be an ETHTOOL_A_CABLE_TDR_NEST_STEP nest containing information about the distance along the cable for the first reading, the last reading, and the step between each reading. Distances are measured in centimeters. These should be the exact values the PHY used. These may be different to what the user requested, if the native measurement resolution is greater than 1 cm.
For each step along the cable, a ETHTOOL_A_CABLE_TDR_NEST_AMPLITUDE is used to report the amplitude of the reflection for a given pair.
ETHTOOL_A_CABLE_TEST_TDR_HEADERnested reply header ETHTOOL_A_CABLE_TEST_TDR_STATUSu8 completed ETHTOOL_A_CABLE_TEST_TDR_NTF_NESTnested all the results ETHTOOL_A_CABLE_TDR_NEST_PULSEnested TX Pulse amplitude ETHTOOL_A_CABLE_PULSE_mVs16 Pulse amplitude ETHTOOL_A_CABLE_NEST_STEPnested TDR step info ETHTOOL_A_CABLE_STEP_FIRST_DISTANCEu32 First data distance ETHTOOL_A_CABLE_STEP_LAST_DISTANCEu32 Last data distance ETHTOOL_A_CABLE_STEP_STEP_DISTANCEu32 distance of each step ETHTOOL_A_CABLE_TDR_NEST_AMPLITUDEnested Reflection amplitude ETHTOOL_A_CABLE_RESULTS_PAIRu8 pair number ETHTOOL_A_CABLE_AMPLITUDE_mVs16 Reflection amplitude ETHTOOL_A_CABLE_TDR_NEST_AMPLITUDEnested Reflection amplitude ETHTOOL_A_CABLE_RESULTS_PAIRu8 pair number ETHTOOL_A_CABLE_AMPLITUDE_mVs16 Reflection amplitude ETHTOOL_A_CABLE_TDR_NEST_AMPLITUDEnested Reflection amplitude ETHTOOL_A_CABLE_RESULTS_PAIRu8 pair number ETHTOOL_A_CABLE_AMPLITUDE_mVs16 Reflection amplitude
TUNNEL_INFO¶
Gets information about the tunnel state NIC is aware of.
Request contents:
ETHTOOL_A_TUNNEL_INFO_HEADERnested request header
Kernel response contents:
ETHTOOL_A_TUNNEL_INFO_HEADERnested reply header ETHTOOL_A_TUNNEL_INFO_UDP_PORTSnested all UDP port tables ETHTOOL_A_TUNNEL_UDP_TABLEnested one UDP port table ETHTOOL_A_TUNNEL_UDP_TABLE_SIZEu32 max size of the table ETHTOOL_A_TUNNEL_UDP_TABLE_TYPESbitset tunnel types which table can hold ETHTOOL_A_TUNNEL_UDP_TABLE_ENTRYnested offloaded UDP port ETHTOOL_A_TUNNEL_UDP_ENTRY_PORTbe16 UDP port ETHTOOL_A_TUNNEL_UDP_ENTRY_TYPEu32 tunnel type
For UDP tunnel table empty ETHTOOL_A_TUNNEL_UDP_TABLE_TYPES indicates that
the table contains static entries, hard-coded by the NIC.
Request translation¶
The following table maps ioctl commands to netlink commands providing their functionality. Entries with “n/a” in right column are commands which do not have their netlink replacement yet. Entries which “n/a” in the left column are netlink only.
ioctl command netlink command ETHTOOL_GSETETHTOOL_MSG_LINKINFO_GETETHTOOL_MSG_LINKMODES_GETETHTOOL_SSETETHTOOL_MSG_LINKINFO_SETETHTOOL_MSG_LINKMODES_SETETHTOOL_GDRVINFOn/a ETHTOOL_GREGSn/a ETHTOOL_GWOLETHTOOL_MSG_WOL_GETETHTOOL_SWOLETHTOOL_MSG_WOL_SETETHTOOL_GMSGLVLETHTOOL_MSG_DEBUG_GETETHTOOL_SMSGLVLETHTOOL_MSG_DEBUG_SETETHTOOL_NWAY_RSTn/a ETHTOOL_GLINKETHTOOL_MSG_LINKSTATE_GETETHTOOL_GEEPROMn/a ETHTOOL_SEEPROMn/a ETHTOOL_GCOALESCEETHTOOL_MSG_COALESCE_GETETHTOOL_SCOALESCEETHTOOL_MSG_COALESCE_SETETHTOOL_GRINGPARAMETHTOOL_MSG_RINGS_GETETHTOOL_SRINGPARAMETHTOOL_MSG_RINGS_SETETHTOOL_GPAUSEPARAMETHTOOL_MSG_PAUSE_GETETHTOOL_SPAUSEPARAMETHTOOL_MSG_PAUSE_SETETHTOOL_GRXCSUMETHTOOL_MSG_FEATURES_GETETHTOOL_SRXCSUMETHTOOL_MSG_FEATURES_SETETHTOOL_GTXCSUMETHTOOL_MSG_FEATURES_GETETHTOOL_STXCSUMETHTOOL_MSG_FEATURES_SETETHTOOL_GSGETHTOOL_MSG_FEATURES_GETETHTOOL_SSGETHTOOL_MSG_FEATURES_SETETHTOOL_TESTn/a ETHTOOL_GSTRINGSETHTOOL_MSG_STRSET_GETETHTOOL_PHYS_IDn/a ETHTOOL_GSTATSn/a ETHTOOL_GTSOETHTOOL_MSG_FEATURES_GETETHTOOL_STSOETHTOOL_MSG_FEATURES_SETETHTOOL_GPERMADDRrtnetlink RTM_GETLINKETHTOOL_GUFOETHTOOL_MSG_FEATURES_GETETHTOOL_SUFOETHTOOL_MSG_FEATURES_SETETHTOOL_GGSOETHTOOL_MSG_FEATURES_GETETHTOOL_SGSOETHTOOL_MSG_FEATURES_SETETHTOOL_GFLAGSETHTOOL_MSG_FEATURES_GETETHTOOL_SFLAGSETHTOOL_MSG_FEATURES_SETETHTOOL_GPFLAGSETHTOOL_MSG_PRIVFLAGS_GETETHTOOL_SPFLAGSETHTOOL_MSG_PRIVFLAGS_SETETHTOOL_GRXFHn/a ETHTOOL_SRXFHn/a ETHTOOL_GGROETHTOOL_MSG_FEATURES_GETETHTOOL_SGROETHTOOL_MSG_FEATURES_SETETHTOOL_GRXRINGSn/a ETHTOOL_GRXCLSRLCNTn/a ETHTOOL_GRXCLSRULEn/a ETHTOOL_GRXCLSRLALLn/a ETHTOOL_SRXCLSRLDELn/a ETHTOOL_SRXCLSRLINSn/a ETHTOOL_FLASHDEVn/a ETHTOOL_RESETn/a ETHTOOL_SRXNTUPLEn/a ETHTOOL_GRXNTUPLEn/a ETHTOOL_GSSET_INFOETHTOOL_MSG_STRSET_GETETHTOOL_GRXFHINDIRn/a ETHTOOL_SRXFHINDIRn/a ETHTOOL_GFEATURESETHTOOL_MSG_FEATURES_GETETHTOOL_SFEATURESETHTOOL_MSG_FEATURES_SETETHTOOL_GCHANNELSETHTOOL_MSG_CHANNELS_GETETHTOOL_SCHANNELSETHTOOL_MSG_CHANNELS_SETETHTOOL_SET_DUMPn/a ETHTOOL_GET_DUMP_FLAGn/a ETHTOOL_GET_DUMP_DATAn/a ETHTOOL_GET_TS_INFOETHTOOL_MSG_TSINFO_GETETHTOOL_GMODULEINFOn/a ETHTOOL_GMODULEEEPROMn/a ETHTOOL_GEEEETHTOOL_MSG_EEE_GETETHTOOL_SEEEETHTOOL_MSG_EEE_SETETHTOOL_GRSSHn/a ETHTOOL_SRSSHn/a ETHTOOL_GTUNABLEn/a ETHTOOL_STUNABLEn/a ETHTOOL_GPHYSTATSn/a ETHTOOL_PERQUEUEn/a ETHTOOL_GLINKSETTINGSETHTOOL_MSG_LINKINFO_GETETHTOOL_MSG_LINKMODES_GETETHTOOL_SLINKSETTINGSETHTOOL_MSG_LINKINFO_SETETHTOOL_MSG_LINKMODES_SETETHTOOL_PHY_GTUNABLEn/a ETHTOOL_PHY_STUNABLEn/a ETHTOOL_GFECPARAMn/a ETHTOOL_SFECPARAMn/a n/a ‘’ETHTOOL_MSG_CABLE_TEST_ACT’‘ n/a ‘’ETHTOOL_MSG_CABLE_TEST_TDR_ACT’‘ n/a ETHTOOL_MSG_TUNNEL_INFO_GET