Resolving SIMATIC IOT2040 Port 2 Ethernet No-Internet Faults

Resolving SIMATIC IOT2040 Port 2 (eth1) Ethernet No-Internet Faults

The SIMATIC IOT2040 is a fanless industrial IoT gateway (Siemens order number 6ES7647-0AA00-1YA2) based on the Intel Quark X1020 SoC. It ships with two 10/100 Mbit/s RJ45 Ethernet interfaces, two USB 2.0 ports, an RS232/RS485 combo port, and runs a Yocto-based Linux image. By Siemens convention, the bottom RJ45 jack is eth0 (engineering / management plane) and the top RJ45 jack is eth1 (field / LAN / upstream). A frequent commissioning fault is that the upstream link on eth1 (port 2) fails to acquire a DHCP lease, even though the same patch cable and switch port provide a working link to a Windows PC. This article documents the physical layer, link layer, and IP layer diagnostics that isolate the root cause and walks through the configuration changes required to bring eth1 online reliably.

1. SIMATIC IOT2040 Ethernet Hardware Architecture

The two Ethernet controllers of the IOT2040 are driven from the Quark SoC's integrated MAC and an external PHY on the carrier board. The relevant datasheet facts that drive link behaviour are summarised below.

The two interfaces are independent PCIe / USB-based MACs and each maintains its own auto-negotiation state machine. A failure to obtain a link on eth1 is therefore not caused by eth0 and is not caused by a global network daemon crash — the two ports are wired to independent PHYs and independent Linux interfaces.

2. Root Cause Taxonomy for "eth1 Has No Internet"

Engineers should triage the fault in this order, top to bottom, because each lower layer is a precondition for the one above.

3. Cable Length, Category, and Signal Integrity

IEEE 802.3u (100BASE-TX) defines a maximum end-to-end channel length of 100 m between two active devices, with up to 90 m of horizontal solid-core cable and up to 10 m of stranded patch cord at each end. The 10 m cable that fails in the field is well inside this spec on paper, so the failure is not length — it is quality, shielding, or connector integrity.

The four cable-related issues that produce this exact symptom on the IOT2040 are:

1. Copper-Clad Aluminium (CCA) conductors. Cables sold as "Cat 5e" at very low unit cost frequently contain aluminium conductors with a thin copper skin. These exceed the 100 Ω ± 15 % DC loop resistance of TIA-568 and the IOT2040 PHY can fail to train on longer runs.
2. Kinked or crush-damaged pairs. Catastrophic twists, staples, or 90-degree bends deform the pair geometry, raising return loss. The first few metres of the run are the most common location of damage.
3. Missing or broken retention tab on the RJ45 plug. A loose plug can cause intermittent link that DHCP interprets as no server.
4. Unshielded cable in an industrial cabinet. When the patch cord runs parallel to a VFD output cable or contactor coil wiring, common-mode noise is injected into the PHY and frames are corrupted. The IOT2040 has no on-board magnetics isolation beyond the integrated transformer in the RJ45 jack, so a 3 m shielded cable often behaves better than a 10 m unshielded one.

4. Prerequisites for the Diagnostic Procedure

• SIMATIC IOT2040 with a known-good example image (e.g. SIMATIC_IOT2000_SD_Image_V2.6.0 or later) on a microSD card or eMMC.
• SSH or serial console access to the device. The default image enables the serial console on the RJ45/DB9 combo port at 115200 8N1 and starts sshd on eth0 (192.168.200.1 by default).
• A second Cat 5e patch cable, 1 m to 3 m, factory-sealed, marked as 100 % copper.
• A Windows or Linux PC for side-by-side comparison of ipconfig / ifconfig on the same switch port.
• Privileged shell on the IOT2040: log in as root with the default password printed on the underside label.

5. Step-by-Step Diagnostic Procedure

Step 1 — Confirm which physical port is which

The Linux naming of eth0 / eth1 on the IOT2040 follows the silkscreen labels on the housing. The lower jack (labelled "X1 P1") is eth0 and the upper jack (labelled "X1 P2") is eth1. If you are uncertain, read the MAC address of each interface:

root@iot2040:~# cat /sys/class/net/eth0/address
00:0e:8c:xx:xx:xx
root@iot2040:~# cat /sys/class/net/eth1/address
00:0e:8c:yy:yy:yy

Compare the MAC with the label on the bottom of the enclosure; the last three bytes are printed there.

Step 2 — Verify the link is physically up on eth1

root@iot2040:~# ip link show eth1
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:0e:8c:yy:yy:yy brd ff:ff:ff:ff:ff:ff

Flag NO-CARRIER with state DOWN means the PHY sees no electrical link. Check both ends of the cable and the switch port LED. The IOT2040 has a green link LED on the RJ45 that lights when a valid link pulse is received. If the LED is off, the fault is L1 — swap the cable before continuing.

Step 3 — Replace the patch cable with a known-good short one

This is the actual field fix. A 3 m Cat 5e solid-copper patch from a recognised vendor such as Lapp ETHERLINE, Phoenix FL CAT5E, or Siemens 6XV1850-2H has been used in repeated cases to bring eth1 up where a 10 m+ third-party cable fails. Re-run ip link show eth1 and confirm the flag changes to state UP with LOWER_UP:

root@iot2040:~# ip link show eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ... state UP

Step 4 — Confirm DHCP client activity on eth1

On the Siemens example image, systemd-networkd is the default network manager. Check that eth1 is configured for DHCP and that the service is enabled:

root@iot2040:~# cat /etc/systemd/network/eth1.network
[Match]
Name=eth1

[Network]
DHCP=yes
IPv6AcceptRA=no

root@iot2040:~# systemctl is-enabled systemd-networkd
enabled
root@iot2040:~# systemctl status systemd-networkd

Watch DHCP transactions in real time:

root@iot2040:~# journalctl -u systemd-networkd -f
eth1: DHCPv4 client trying
eth1: DHCPv4 lease lost
eth1: DHCPv4 client trying
eth1: DHCPv4 lease acquired
eth1:  address 10.10.20.45/24

Four DHCPDISCOVER/DHCPREQUEST cycles per the standard RFC 2131 retransmission scheme with the default timeouts are normal. If the log shows only DHCPv4 client trying with no OFFER, the request is not leaving the device, or the switch is dropping it — fall back to the cable swap and the switch-port verification below.

Step 5 — Validate the IP, route, and DNS

root@iot2040:~# ip -4 addr show eth1
    inet 10.10.20.45/24 brd 10.10.20.255 scope global eth1
root@iot2040:~# ip route show default
default via 10.10.20.1 dev eth1
root@iot2040:~# cat /etc/resolv.conf
nameserver 10.10.20.1
root@iot2040:~# ping -c 3 8.8.8.8
root@iot2040:~# ping -c 3 google.com

If the IP route is missing after a successful DHCP lease, add the gateway explicitly with the [Route] section in /etc/systemd/network/eth1.network or fall back to /etc/network/interfaces for a static configuration.

6. Configuring eth1 with /etc/network/interfaces (Legacy Method)

On images older than V2.4, the IOT2040 uses the Debian /etc/network/interfaces file with ifupdown and the Busybox udhcpc client. Use this layout to enable DHCP on eth1:

# /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.200.1
    netmask 255.255.255.0

allow-hotplug eth1
iface eth1 inet dhcp
    hostname iot2040
    request subnet-mask, broadcast-address, routers, domain-name-servers

Apply without reboot:

root@iot2040:~# ifdown eth1 && ifup eth1
Internet Systems Consortium DHCP Client 4.3.6
Listening on LPF/eth1/00:0e:8c:yy:yy:yy
Sending on   LPF/eth1/00:0e:8c:yy:yy:yy
Sending on   Socket/fallback
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPACK from 10.10.20.1
bound to 10.10.20.45 -- renewal in 2147483647 seconds.

For deterministic commissioning, replace dhcp with a static block. The IOT2040 has no DNS resolver dependency on the image, so resolv.conf can be set with one or more nameserver entries pointing at the plant DNS.

auto eth1
iface eth1 inet static
    address 10.10.20.45
    netmask 255.255.255.0
    gateway 10.10.20.1
    dns-nameservers 10.10.20.1 8.8.8.8

7. Link-Speed Verification with ethtool

The example image includes ethtool in the ethtool package. Use it to read the negotiated speed, the duplex mode, and the link-partner advertisement.

root@iot2040:~# ethtool eth1
Settings for eth1:
    Supported ports: [ TP MII ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
    Speed: 100Mb/s
    Duplex: Full
    Auto-negotiation: on
    Link detected: yes

Forcing a fixed speed is sometimes required when the partner switch has a misconfigured auto-negotiation advertisement. Use this only as a diagnostic step, not as a permanent fix:

root@iot2040:~# ethtool -s eth1 speed 100 duplex full autoneg off

Reset to auto-negotiation with:

root@iot2040:~# ethtool -s eth1 autoneg on

The -S switch dumps the PHY MIB counters. High rx_crc_errors, rx_frame_errors, or rx_length_errors counts are a smoking gun for a damaged cable or excessive EMI.

root@iot2040:~# ethtool -S eth1 | grep -E "crc|frame|length|symbol"
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_length_errors: 0
     rx_symbol_errors: 0

8. Switch-Side and VLAN Considerations

On managed switches (e.g. SCALANCE XC, SCALANCE XB, or third-party Cisco Catalyst / HPE Aruba), the port to which eth1 is connected must satisfy three conditions.

1. Port is in the same VLAN as the DHCP server. If the port is on VLAN 1 and the DHCP server is on VLAN 10, the DHCPDISCOVER will be flooded on VLAN 1 and the OFFER will never return.
2. Port is set to access (untagged), unless the IOT2040 image is configured for 802.1Q tagging. The default image does not tag frames.
3. Port security / DHCP snooping is not blocking the MAC. SCALANCE switches default to permitting all MACs; Cisco switches in many plants default to switchport port-security with a single-MAC limit. A second device (PC) on the same port can age out the IOT2040 MAC.

9. dmesg and Kernel Ring Buffer Triage

The Linux kernel logs every link state change of the Ethernet PHY. After a cable swap, always inspect the last 50 lines for hints:

root@iot2040:~# dmesg | grep -i -E "eth1|net|bcm|phy" | tail -n 20
[  421.102] smsc95xx 1-1.1:1.0 eth1: link up, 100Mbps, full-duplex, lpa 0xCDE1
[  421.890] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  427.220] smsc95xx 1-1.1:1.0 eth1: link down
[  428.412] smsc95xx 1-1.1:1.0 eth1: link up, 100Mbps, full-duplex, lpa 0xCDE1

Repeated link up / link down transitions in the buffer indicate a flaky cable or a marginal switch port. The lpa 0xCDE1 value is the link-partner advertisement register and is useful when comparing two switches: identical readings from a working and a non-working port confirm the IOT2040 PHY is fine.

10. Firmware and Image Considerations

Siemens released several example image versions for the IOT2000 family. The relevant firmware notes for eth1 behaviour are summarised below. Always confirm the version before applying any network configuration change, because file paths and service names changed between releases.

Upgrading from a V1.x image to V2.4 or later is a known path to restoring DHCP on eth1. The V2.x kernel updates the SMSC95xx USB-Ethernet driver that backs eth1 on the IOT2040, which fixes a number of cold-boot auto-negotiation issues.

11. Verification and Commissioning Checklist

After applying the fix, run the following checks and record the values in the commissioning log.

1. ip link show eth1 shows state UP, LOWER_UP, no NO-CARRIER.
2. Green link LED on the upper RJ45 jack is steady on (not blinking at a high rate that would indicate collisions).
3. ethtool eth1 reports Speed: 100Mb/s, Duplex: Full, Link detected: yes.
4. ip -4 addr show eth1 shows a non-zero inet address from the DHCP range.
5. ip route show default lists default via <gateway> dev eth1.
6. cat /etc/resolv.conf shows the plant DNS server.
7. ping -c 3 <gateway> returns 0 % packet loss.
8. ping -c 3 8.8.8.8 and ping -c 3 google.com both return 0 % packet loss.
9. Power-cycle the IOT2040 and re-confirm steps 1–8. A DHCP lease that survives a cold start confirms the configuration is persistent and the cable is healthy.

12. When to Escalate

Escalate to Siemens Technical Support via the Siemens Industry Online Support portal if all of the following are true:

• Link LED on eth1 is on with a 3 m known-good cable.
• ethtool eth1 reports Speed: 100Mb/s, Duplex: Full, Link detected: yes.
• The DHCP client logs show DHCPREQUEST on eth1 to 255.255.255.255 port 67 with no DHCPACK.
• A PC on the same port and same cable receives a DHCP address.
• The switch is confirmed to be in the correct VLAN with no port-security lock.

At this point the IOT2040 unit is likely faulty and should be RMA'd. The IOT2050 (successor) is generally a drop-in replacement, with the new article number 6ES7647-0BA00-0YA2 and 2 × 10/100/1000 Mbit/s interfaces, which is documented in the same Siemens Industry Online Support portal under the SIMATIC IOT2000 / IOT2050 product tree.

13. Related Cross-Vendor Ethernet Reference

The physical-layer and link-layer checks above are not specific to Siemens. The same triage order — cable, link LED, ethtool, DHCP client, switch VLAN, route and DNS — applies to any industrial gateway. General Ethernet troubleshooting methodology is well documented in the Microsoft Windows Ethernet troubleshooting guide and the Dell wired networking knowledge base, both of which start with the same three checks: confirm the cable, confirm the link LED, and restart the network stack. The IOT2040 procedure is the Linux equivalent of those three steps.