When your I/O block reports “Link Down,” when error counters spike in Studio 5000, when a DLR ring takes longer than expected to converge — the data you need lives in the Ethernet Link Object, Class 0xF6. It’s the CIP object that holds every Ethernet-layer diagnostic on every EtherNet/IP device: link status, link speed, duplex mode, MAC address, packet counters, error counters. If you’ve ever wondered where the “interface statistics” view in your engineering tool actually gets its numbers — they come from here.
This article is the complete reference for Class 0xF6 from ODVA’s CIP Networks Library Volume 2, Section 5-4. It’s the natural companion to our CIP TCP/IP Interface Object Explained article (Class 0xF5) — the two objects together describe a device’s complete network configuration and physical link state.
This article is built from ODVA CIP Networks Library Volume 2, Edition 1.4 (2007), Section 5-4 (Object Revision 3).
Table of Contents
What the Ethernet Link Object is in one paragraph
The Ethernet Link Object (Class Code 0xF6, decimal 246) maintains link-specific counters and status information for an IEEE 802.3 Ethernet communications interface. Per Volume 2 Section 5-4, every EtherNet/IP device must have exactly one instance of the Ethernet Link Object for each Ethernet 802.3 interface on the module. A device with one Ethernet port has one instance. A device with two Ethernet ports (typical for DLR-capable devices) has two instances, one per port. Devices with embedded switches may also use an instance for an internal interface. The object provides link diagnostics: link status (up/down), duplex mode (half/full), negotiation status, link speed (10/100/1000 Mbps), MAC address, and full RFC 1213 / RFC 1643 packet and error counters.
Where the Ethernet Link Object fits
EtherNet/IP devices split network configuration cleanly between two objects:
| Object | Class | Layer | What it covers |
|---|---|---|---|
| TCP/IP Interface Object | 0xF5 | Layer 3-4 | IP address, subnet mask, gateway, DNS, multicast |
| Ethernet Link Object | 0xF6 | Layer 1-2 | MAC, link speed, duplex, counters |
The TCP/IP Interface Object handles “IP and above.” The Ethernet Link Object handles “Ethernet and below.” Each object stands on its own but they reference each other: the TCP/IP Interface Object’s Attribute 4 (Physical Link Object) points to the corresponding Ethernet Link Object instance.
A device with one IP address but two Ethernet ports (typical DLR-capable I/O block) has:
- One TCP/IP Interface Object instance (one IP shared by both ports)
- Two Ethernet Link Object instances (one per physical port)
- Plus optionally a third Ethernet Link Object instance for the internal switch port
This split lets engineering tools read per-port diagnostics independently while keeping IP configuration centralized.
For the IP-layer side of the picture, see our CIP TCP/IP Interface Object Explained article.
Object revision history
Per Volume 2 Table 5-4.1, the Ethernet Link Object has evolved through three revisions:
| Revision | Changes |
|---|---|
| 1 | Initial definition |
| 2 | Added Attribute 6 (Interface Control) — for forced speed/duplex |
| 3 | Added Attributes 7-10 (Interface Type, Interface State, Admin State, Interface Label) for multi-port devices |
An error reading the Class Revision attribute implies a Revision 1 device. Current devices implement Revision 3 in nearly all cases.
Class attributes
Per Volume 2 Table 5-4.2:
| Attr ID | Need | Access | Name | Type | Purpose |
|---|---|---|---|---|---|
| 1 | Required | Get | Revision | UINT | Object revision (current value = 3) |
| 2 | Conditional | Get | Max Instance | UINT | Highest instance ID created |
| 3 | Conditional | Get | Number of Instances | UINT | How many instances exist |
Required attributes 2 and 3 only when the device has more than one instance — which is the case for any multi-port device. For single-port devices, only the Revision class attribute is required.
Instance attributes — the diagnostic toolbox
Per Volume 2 Table 5-4.3:
| Attr ID | Need | Access | Name | Type | What it tells you |
|---|---|---|---|---|---|
| 1 | Required | Get | Interface Speed | UDINT | Current speed in Mbps (0, 10, 100, 1000) |
| 2 | Required | Get | Interface Flags | DWORD | Link Status, Duplex, Negotiation Status |
| 3 | Required | Get | Physical Address | ARRAY of 6 USINTs | MAC address |
| 4 | Conditional | Get | Interface Counters | STRUCT | Inbound/outbound packet counts (RFC 1213) |
| 5 | Optional | Get | Media Counters | STRUCT | Ethernet-specific error counters (RFC 1643) |
| 6 | Optional | Set | Interface Control | STRUCT | Force speed/duplex, enable/disable auto-neg |
| 7 | Optional | Get | Interface Type | USINT | Twisted pair, fiber, internal, etc. |
| 8 | Optional | Get | Interface State | USINT | Operational, disabled, testing |
| 9 | Optional | Set | Admin State | USINT | Enable / disable the interface |
| 10 | Conditional | Get | Interface Label | SHORT_STRING | Human-readable port name (e.g., “Port 1”) |
The three required attributes — Interface Speed, Interface Flags, and Physical Address — are present on every device. The conditional and optional attributes add value for diagnostics.
Attribute 1 — Interface Speed
A UDINT containing the current operating speed of the interface in megabits per second. Per Volume 2 Section 5-4.3.2.2:
| Value | Meaning |
|---|---|
| 0 | Indeterminate (link down, or speed not yet detected) |
| 10 | 10 Mbps |
| 100 | 100 Mbps |
| 1000 | 1 Gbps |
| 10000 | 10 Gbps (rare in field devices) |
The spec specifically notes: this is media bandwidth, not effective throughput. The value is NOT doubled for full-duplex operation. A 100 Mbps interface running full duplex returns 100, not 200.
A return value of 0 typically means the link is down — the port hasn’t negotiated a speed. Combined with Interface Flags bit 0 (Link Status), this is the diagnostic engineers reach for first when an I/O block goes offline.
Attribute 2 — Interface Flags
A DWORD bitmap that’s the most-read attribute for link diagnostics. Per Volume 2 Table 5-4.4:
| Bit(s) | Field | Values |
|---|---|---|
| 0 | Link Status | 0 = inactive, 1 = active |
| 1 | Half/Full Duplex | 0 = half duplex, 1 = full duplex |
| 2-4 | Negotiation Status | 0 = in progress, 1 = failed, 2 = speed only, 3 = success, 4 = forced |
| 5 | Manual Setting Requires Reset | 0 = changes apply live, 1 = needs Identity Object Reset |
| 6 | Local Hardware Fault | 0 = no fault, 1 = hardware fault detected |
| 7-31 | Reserved | Must be 0 |
Decoding the Negotiation Status field (bits 2-4)
| Value | Meaning |
|---|---|
| 0 | Auto-negotiation in progress |
| 1 | Auto-negotiation and speed detection failed. Using default values (typically 10 Mbps half duplex) |
| 2 | Auto-negotiation failed but detected speed. Duplex was defaulted (typically half duplex) |
| 3 | Successfully negotiated speed and duplex |
| 4 | Auto-negotiation not attempted — speed and duplex are forced |
When troubleshooting “link works but performance is bad,” check this field. A value of 1 or 2 means the link came up but auto-negotiation didn’t complete cleanly — often a duplex mismatch is hiding underneath. Duplex mismatches are the single most common cause of mysterious EtherNet/IP performance problems — one end runs full duplex, the other end runs half duplex, both sides “work” but throughput collapses.
Interpreting common Interface Flags values
| Value | Decoded |
|---|---|
| 0x0000000B | Link up, full duplex, negotiation successful (the healthy state — 1+2+8 = 11) |
| 0x00000009 | Link up, half duplex, negotiation successful (suboptimal but functional) |
| 0x00000000 | Link down |
| 0x00000043 | Link up, half duplex, hardware fault detected |
| 0x00000019 | Link up, full duplex, negotiation forced |
Most production field devices report 0x0000000B when healthy.
Attribute 3 — Physical Address (MAC)
An ARRAY of 6 USINTs containing the device’s MAC address. Per Volume 2 Section 5-4.3.2.3:
Byte 0: First octet of MAC (vendor OUI byte 1)
Byte 1: Second octet
Byte 2: Third octet (last vendor OUI byte)
Byte 3: Fourth octet (vendor-assigned)
Byte 4: Fifth octet (vendor-assigned)
Byte 5: Sixth octet (vendor-assigned)Display format: “XX-XX-XX-XX-XX-XX” starting with byte 0.
This attribute is not settable — the MAC is assigned by the manufacturer at production. The first three bytes are the Organizationally Unique Identifier (OUI) — Rockwell, Beckhoff, Cisco, etc. all have their own OUIs assigned by IEEE.
Multi-port devices with shared MAC: Devices with multiple Ethernet ports but only one MAC interface (e.g., devices with embedded switching) may use the same MAC value across all Ethernet Link Object instances. The spec allows this. A 1734-AENT with two ports typically returns the same MAC for both Ethernet Link Object instances because both ports share one internal MAC interface.
Attribute 4 — Interface Counters
A STRUCT containing per-direction packet counters. Defined per RFC 1213 (MIB-II Management Information Base). Per Volume 2 Section 5-4.3.2.4:
Inbound counters
| Field | Type | Counts |
|---|---|---|
| In Octets | UDINT | Bytes received |
| In Ucast Packets | UDINT | Unicast packets received |
| In NUcast Packets | UDINT | Non-unicast (multicast + broadcast) packets received |
| In Discards | UDINT | Packets discarded (e.g., buffer overrun) |
| In Errors | UDINT | Packets containing errors (excluding discards) |
| In Unknown Protos | UDINT | Packets with unrecognized protocol |
Outbound counters
| Field | Type | Counts |
|---|---|---|
| Out Octets | UDINT | Bytes sent |
| Out Ucast Packets | UDINT | Unicast packets sent |
| Out NUcast Packets | UDINT | Non-unicast packets sent |
| Out Discards | UDINT | Outbound packets discarded |
| Out Errors | UDINT | Outbound packets containing errors |
Reading these counters: Take two snapshots, separated by a known time interval. The difference divided by the interval gives you packet/byte rates. Watching In Discards increment indicates the device is receiving packets it can’t process (buffer overflow, queue exhaustion). Out Discards increment indicates the device can’t send packets (often a sign of severe congestion or a stuck transmit queue).
Multi-port devices (those with embedded switches) handle counters in one of three ways:
- Preferred: Each instance counts only the MAC frames sent/received via the port that instance represents
- Use zero counters for external switch ports; count MAC frames in the internal interface instance only
- Use the same counter values across all instances
Engineers troubleshooting multi-port devices should verify which approach the device uses before drawing conclusions from per-port counters.
Attribute 5 — Media Counters
A STRUCT containing Ethernet-specific error counters. Defined per RFC 1643 (Definitions of Managed Objects for Ethernet-Like Interface Types). Per Volume 2 Section 5-4.3.2.5:
| Counter | What it indicates |
|---|---|
| Alignment Errors | Frames not an integral number of octets — usually a physical layer issue (bad cable, bad transceiver) |
| FCS Errors | Frame Check Sequence (CRC) errors — packet corruption in transit |
| Single Collisions | Frames transmitted after exactly one collision (normal on half duplex) |
| Multiple Collisions | Frames transmitted after multiple collisions (normal on busy half duplex) |
| SQE Test Errors | Signal Quality Error test failures (legacy Ethernet) |
| Deferred Transmissions | Frames whose first transmission was delayed (medium busy) |
| Late Collisions | Collision detected later than 512 bit-times into transmission — always indicates a problem (cable too long, duplex mismatch, repeater issue) |
| Excessive Collisions | Transmission failed after too many collision retries — severe network congestion or duplex mismatch |
| MAC Transmit Errors | Internal MAC sublayer transmit failures |
| Carrier Sense Errors | Carrier sense lost or never asserted during transmission |
| MAC Receive Errors | Internal MAC sublayer receive failures |
What to watch for
In a healthy modern EtherNet/IP network running full duplex with good cables:
- Collisions should be zero — full duplex has no collisions by design. If you see Single/Multiple/Late/Excessive Collisions incrementing, the link is actually running half duplex somewhere. This is the duplex mismatch symptom.
- FCS Errors indicate cable problems, EMI interference, or marginal connectors. Replace the cable.
- Alignment Errors indicate similar physical-layer issues.
- Late Collisions are NEVER normal. They indicate the network is misconfigured (cable too long, duplex mismatch, or repeater present in a switched network).
If the Media Counters attribute is implemented, the Interface Counters attribute must also be implemented. Devices may not implement Media Counters at all on fiber interfaces (collisions don’t apply); they should return 0 for any counter that doesn’t apply.
Attribute 6 — Interface Control
A STRUCT that lets you force speed and duplex on the interface — disabling auto-negotiation. Per Volume 2 Section 5-4.3.2.6:
| Field | Type | Purpose |
|---|---|---|
| Control Bits | WORD | Auto-negotiation enable, duplex selection |
| Forced Interface Speed | UINT | 10, 100, 1000 Mbps when not auto-negotiating |
Control Bits
| Bit | Name | Meaning |
|---|---|---|
| 0 | Auto-negotiate | 0 = disabled (forced speed/duplex), 1 = enabled |
| 1 | Forced Duplex | 0 = half duplex (when auto-neg disabled), 1 = full duplex |
| 2-15 | Reserved | Must be 0 |
This attribute is optional and settable. When implemented, an engineer can force a problematic link to a known speed/duplex combination — useful when negotiating with legacy or misbehaving switches.
Caution: Forcing one end while auto-negotiating the other end is the classic recipe for duplex mismatch. Either force both ends or auto-negotiate both ends. Never mix.
Some devices may require an Identity Object Reset after changing Interface Control before the new settings take effect. Check Interface Flags bit 5 (Manual Setting Requires Reset) to know.
Multi-port extensions (Attributes 7-10)
Object Revision 3 added four attributes to better support multi-port devices like DLR-capable I/O adapters and embedded switches.
Attribute 7 — Interface Type
A USINT identifying the physical interface type:
| Value | Type |
|---|---|
| 0 | Unknown |
| 1 | Internal (e.g., backplane-only interface) |
| 2 | Twisted pair (copper) |
| 3 | Optical fiber |
| 4-255 | Reserved |
Lets engineering tools distinguish copper ports from fiber ports from internal switch interfaces. Important for DLR design — fiber and copper segments have different distance limits and topology rules.
Attribute 8 — Interface State
A USINT showing the current operational state:
| Value | State |
|---|---|
| 0 | Unknown |
| 1 | Operational — interface enabled and link is up |
| 2 | Disabled — interface administratively disabled |
| 3 | Testing — interface is in test mode |
| 4-255 | Reserved |
Different from Interface Flags bit 0 (Link Status) — Interface State reflects the administrative + operational combined view. An interface can be administratively disabled (Interface State = 2) even though the cable is plugged in.
Attribute 9 — Admin State
A USINT (settable) that enables or disables the interface administratively:
| Value | Action |
|---|---|
| 1 | Enable the interface |
| 2 | Disable the interface |
Useful for managed multi-port devices where you want to lock down unused ports. Disabling a port via Admin State is also a common diagnostic technique — disable one port of a DLR ring to verify the supervisor properly fails over.
Attribute 10 — Interface Label
A SHORT_STRING containing a human-readable name for the interface (e.g., “Port 1”, “Front Port”, “Fiber Uplink”). Conditional — required when the device has multiple Ethernet Link Object instances, so engineers can tell which instance corresponds to which physical port.
Services supported
The standard services that work on the Ethernet Link Object:
| Service | Code | Common usage |
|---|---|---|
| Get_Attribute_Single | 0x0E | Read individual diagnostic values |
| Get_Attributes_All | 0x01 | Read complete interface state |
| Set_Attribute_Single | 0x10 | Write Interface Control or Admin State |
To read a device’s MAC address: Service 0x0E, Class 0xF6, Instance 1, Attribute 3.
To read link status: Service 0x0E, Class 0xF6, Instance 1, Attribute 2, then check bit 0.
To read all diagnostics in one transaction: Service 0x01, Class 0xF6, Instance 1.
For broader service code coverage, see our CIP Service Codes Complete Reference.
Multi-port devices in DLR — what to expect
A typical DLR-capable I/O adapter (like a 1734-AENTR Point I/O adapter) exposes:
| Instance | Purpose |
|---|---|
| Instance 1 | Front-panel Port 1 (one Ethernet jack) |
| Instance 2 | Front-panel Port 2 (the other Ethernet jack) |
| Instance 3 | (Optional) Internal switch port |
Each instance has its own Interface Flags, Speed, Counters, and Interface Label. Engineers troubleshooting DLR ring issues read both port instances to see which one has lost link or accumulated errors.
For example, when a cable break occurs in a DLR ring, the two devices adjacent to the break report:
- One port: Interface Flags bit 0 = 0 (link down)
- Other port: Interface Flags bit 0 = 1 (link up — to the other side of the ring)
The TCP/IP Interface Object’s Last Active Node attributes (in the Ring Supervisor) point at the devices adjacent to the break. Cross-referencing those with the Ethernet Link Object’s per-port link status tells you exactly which cable segment broke.
For full DLR mechanics, see our DLR Device Level Ring Explained article.
Common diagnostic workflows
Verify a device’s MAC address
Service: 0x0E (Get_Attribute_Single)
Path: Class 0xF6, Instance 1, Attribute 3Returns 6 bytes. Display as XX-XX-XX-XX-XX-XX.
Check link status
Service: 0x0E
Path: Class 0xF6, Instance 1, Attribute 2 (Interface Flags)Bit 0 = 1 means link up.
Read all interface diagnostics
Service: 0x01 (Get_Attributes_All)
Path: Class 0xF6, Instance 1Returns Speed, Flags, MAC, and Counters in one transaction.
Force 100 Mbps full duplex
Service: 0x10 (Set_Attribute_Single)
Path: Class 0xF6, Instance 1, Attribute 6 (Interface Control)
Data:
Control Bits = 0x0002 (auto-neg off, force full duplex)
Forced Interface Speed = 100Disable an interface administratively
Service: 0x10
Path: Class 0xF6, Instance 1, Attribute 9 (Admin State)
Data: 0x02 (disable)Common errors and what they mean
| Symptom | Likely cause | What to check |
|---|---|---|
| Set_Attribute_Single returns 0x14 (Attribute not supported) | Device doesn’t implement that attribute | Verify attribute is implemented per device’s EDS |
| Set_Attribute_Single on Attribute 6 returns 0x09 | Invalid Control Bits or Forced Speed combination | Use valid combinations from Table 5-4.5 |
| Interface Flags reports 0x0000 persistently | Link genuinely down (cable, switch port, hardware) | Physical inspection of cable and port |
| Negotiation Status = 1 (failed) | Speed/duplex mismatch with the partner | Force both ends OR auto-neg both ends |
| Counters show collisions despite full duplex configured | Actual link running half duplex (mismatch) | Check Interface Flags bit 1 to confirm actual duplex |
| Interface Speed = 0 | Link down or not yet negotiated | Check Interface Flags bit 0 |
| Get_Attributes_All returns truncated data | Optional attributes not implemented | Use Get_Attribute_Single for specific values |
| FCS Errors incrementing | Cable problem, EMI, marginal hardware | Replace cable, check shielding, separate from VFDs |
| Late Collisions incrementing | Cable too long OR duplex mismatch OR hub/repeater in path | Verify cable length ≤ 100 m and full duplex on both ends |
For broader CIP error code coverage, see our CIP General Status Codes Reference.
Reading Ethernet Link Object in Wireshark
Useful filters when troubleshooting:
cip # All CIP traffic
cip.class == 0xF6 # All Ethernet Link Object access
cip.class == 0xF6 && cip.service == 0x0E # Read attribute requests
cip.class == 0xF6 && cip.service == 0x10 # Set attribute requestsA useful diagnostic pattern: when an I/O block exhibits intermittent communication problems, capture in Wireshark, filter on cip.class == 0xF6, and watch how often engineering tools read interface counters. Tools polling the counters frequently often suggests the operator is actively troubleshooting a link issue.
For broader Wireshark workflows, see our Wireshark for EtherNet/IP guide.
Frequently asked questions
What is the CIP Ethernet Link Object?
The CIP Ethernet Link Object (Class Code 0xF6) is the CIP object that holds Ethernet link-layer information for an EtherNet/IP device — MAC address, link speed, duplex mode, link status, and packet/error counters. Every EtherNet/IP device implements one instance per Ethernet port. Defined in ODVA’s CIP Networks Library Volume 2, Section 5-4.
What is the class code for the Ethernet Link Object?
The class code is 0xF6 (decimal 246). It is the sibling of the TCP/IP Interface Object (Class 0xF5). Together, the two objects describe a device’s complete network configuration: 0xF5 handles IP-layer settings (IP address, subnet, gateway), 0xF6 handles Ethernet-layer settings (MAC, speed, duplex, counters).
How do I read a device’s MAC address via CIP?
Use Get_Attribute_Single (service 0x0E) on Class 0xF6, Instance 1, Attribute 3 (Physical Address). The response is an array of 6 USINTs in MAC address byte order. The recommended display format is “XX-XX-XX-XX-XX-XX” starting with the first byte. The MAC address is read-only — it cannot be changed via CIP.
How do I check if an EtherNet/IP device’s link is up?
Read Attribute 2 (Interface Flags) of the Ethernet Link Object via Get_Attribute_Single (Class 0xF6, Instance 1, Attribute 2). Check bit 0 of the returned DWORD: 0 means link is down, 1 means link is up. Bit 1 indicates duplex mode (0 = half, 1 = full). Bits 2-4 indicate negotiation status.
What does the Ethernet Link Object Negotiation Status mean?
Bits 2-4 of the Interface Flags attribute encode auto-negotiation status. Value 0 = negotiation in progress, 1 = negotiation failed (using defaults), 2 = speed detected but duplex defaulted, 3 = successfully negotiated, 4 = auto-negotiation not attempted (speed and duplex forced). When troubleshooting performance issues, look here first — value 1 or 2 indicates partial negotiation failure often hiding a duplex mismatch.
What is the difference between Interface Counters and Media Counters?
Interface Counters (Attribute 4) follow RFC 1213 MIB-II and count high-level packet activity — bytes in/out, unicast and non-unicast packets, discards, errors. Media Counters (Attribute 5) follow RFC 1643 and count Ethernet-specific events — alignment errors, FCS errors, collisions, deferred transmissions, MAC errors. If Media Counters is implemented, Interface Counters must be implemented too. The two are paired for full Ethernet diagnostics.
How many Ethernet Link Object instances does a DLR-capable device have?
Typically two — one Ethernet Link Object instance per physical Ethernet port. Some devices add a third instance for the internal switch interface. A 1734-AENTR Point I/O adapter has two front-panel Ethernet ports, so it exposes two Ethernet Link Object instances (Instance 1 and Instance 2). Each instance has its own Interface Flags, Speed, MAC (often shared), counters, and Interface Label.
Can I force a specific link speed via CIP?
Yes, if the device implements Attribute 6 (Interface Control). Set Attribute 6 with Control Bits configured for auto-negotiation off and the desired duplex, plus Forced Interface Speed set to 10, 100, or 1000. Caution: forcing one end while the other end auto-negotiates causes duplex mismatch — always force both ends or auto-negotiate both ends, never mix.
Why am I seeing collisions on a full-duplex EtherNet/IP link?
Full-duplex links cannot have collisions by design — the medium has separate transmit and receive paths. If you see Single Collisions, Multiple Collisions, or Late Collisions incrementing in the Media Counters, the link is actually running half duplex somewhere despite what your configuration thinks. This is the classic duplex mismatch symptom. Check Interface Flags bit 1 to confirm the actual duplex mode, and verify both ends of the link use matching settings.
What does the Interface Label attribute do?
Attribute 10 (Interface Label) is a human-readable SHORT_STRING that names the interface for diagnostic display — examples: “Port 1,” “Front Port,” “Fiber Uplink.” It’s required (conditional) when a device has multiple Ethernet Link Object instances so engineering tools can show which instance corresponds to which physical port. Single-port devices don’t need it.
How do I disable an EtherNet/IP port via CIP?
If the device implements Attribute 9 (Admin State), write value 2 (Disable) via Set_Attribute_Single on Class 0xF6, Instance N, Attribute 9. Write value 1 to re-enable. This administratively shuts down the port without unplugging it — useful for locking down unused ports and testing DLR ring failover by forcing a port down.
Where can I find the official Ethernet Link Object specification?
The Ethernet Link Object is defined in ODVA’s CIP Networks Library Volume 2: EtherNet/IP Adaptation of CIP, Chapter 5 (Object Library), Section 5-4. The current edition is 1.4 (2007), with Object Revision 3. Counter definitions reference RFC 1213 (MIB-II) for Interface Counters and RFC 1643 (Ethernet-like MIB) for Media Counters. ODVA members can access the full specification at odva.org.