Unable to ping other devices in the network through ethernet port on a custom board

Question

I am on a embedded development platform and trying to bring up the ethernet and do a ping test. As of now, I have the ethernet up after the linux boot, but I am unable to ping other systems. My thinking suggests that the phy is not configured correctly. I started investigating the interface with ethtool . Below are the results.

root@xilinx:~# ethtool eth0
Settings for eth0:
        Supported ports: [ TP    MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
                                1000baseX/Full
        Supported pause frame use: Transmit-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
                                1000baseX/Full
        Advertised pause frame use: Transmit-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        master-slave cfg: forced master
        master-slave status: resolution error
        Port: MII
        PHYAD: 1
        Transceiver: external
        Link detected: no

Driver details

root@xilinx:~# ethtool -i eth0
driver: macb
version: 5.10.0-xilinx-v2021.2
firmware-version:
expansion-rom-version:
bus-info: ff0e0000.ethernet
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

Basically all of my statistics counter are 0

root@xilinx:~# ethtool -S eth0
NIC statistics:
     tx_octets: 0
     tx_frames: 0
     tx_broadcast_frames: 0
     tx_multicast_frames: 0
     tx_pause_frames: 0
     tx_64_byte_frames: 0
     tx_65_127_byte_frames: 0
     tx_128_255_byte_frames: 0
     tx_256_511_byte_frames: 0
     tx_512_1023_byte_frames: 0
     tx_1024_1518_byte_frames: 0
     tx_greater_than_1518_byte_frames: 0
     tx_underrun: 0
     tx_single_collision_frames: 0
     tx_multiple_collision_frames: 0
     tx_excessive_collisions: 0
     tx_late_collisions: 0
     tx_deferred_frames: 0
     tx_carrier_sense_errors: 0
     rx_octets: 0
     rx_frames: 0
     rx_broadcast_frames: 0
     rx_multicast_frames: 0
     rx_pause_frames: 0
     rx_64_byte_frames: 0
     rx_65_127_byte_frames: 0
     rx_128_255_byte_frames: 0
     rx_256_511_byte_frames: 0
     rx_512_1023_byte_frames: 0
     rx_1024_1518_byte_frames: 0
     rx_greater_than_1518_byte_frames: 0
     rx_undersized_frames: 0
     rx_oversize_frames: 0
     rx_jabbers: 0
     rx_frame_check_sequence_errors: 0
     rx_length_field_frame_errors: 0
     rx_symbol_errors: 0
     rx_alignment_errors: 0
     rx_resource_errors: 0
     rx_overruns: 0
     rx_ip_header_checksum_errors: 0
     rx_tcp_checksum_errors: 0
     rx_udp_checksum_errors: 0
     q0_rx_packets: 0
     q0_rx_bytes: 0
     q0_rx_dropped: 0
     q0_tx_packets: 0
     q0_tx_bytes: 0
     q0_tx_dropped: 0
     q1_rx_packets: 0
     q1_rx_bytes: 0
     q1_rx_dropped: 0
     q1_tx_packets: 0
     q1_tx_bytes: 0
     q1_tx_dropped: 0

Will be happy to take your suggestions on tracking the issue further.

I would suggest using managed switch on the other end so you can troubleshoot negotiation or traffic flow issues. Within the given data I see only one suspicious thing: `master-slave status: resolution error`. In gigabit ethernet one side of the link is always master and the other is slave. Master provides clock for the link and slave derives clock from the line. If there is a master-slave negotiation failure both things may assume they are masters and that will lead to failure. — Peter Zhabin, Jun 23 '22 at 17:01

score 1 · Answer 1 · answered Jun 29 '22 at 20:13

1

    master-slave cfg: forced master
    master-slave status: resolution error

This might be the problem. Master-slave must be auto negotiated. forced master likely breaks protocol, disabling the link.

    Supported ports: [ TP    MII ]
    ...
    Port: MII

This might be another problem (possibly connected to the one above). If you want to use the twisted-pair port you're on the wrong side. The MII port is where you'd connect an SFP module to or that you'd use for an internal, PHY-less link.

answered Jun 29 '22 at 20:13

Zac67

8,639
2
10
28

Hi @Zac67, would you mind explaining a bit more about the using the twisted-pair port and why/how do you say I am on the wrong side. In my case I have the MAC inside the chip and the phy is an external ti chip. – user2532296 Jul 01 '22 at 11:54
I don't and can't know what you're using but you need to select the correct port. `Link detected: no` indicates that it might currently be the wrong one or that the cable is faulty. Possibly you also need to try a crossover cable as Auto MDI-X might not be present. – Zac67 Jul 01 '22 at 12:13

score 1 · Answer 2 · answered Jun 29 '22 at 21:51

Link detected: no

First off, do you have a bad cable? Are you getting blinky lights on your interface and on your switch? Are you using a cat5e cable or better?

Another thing to try is to force the speed and duplex instead of auto-negotiating. You could even try falling back to 100baseT.

Last, look up the ethernet driver module to see if it has known bugs. Depending on the module you might want to update your kernel.

Oh, one more thing - does "ip link" show the status as UP?

Unable to ping other devices in the network through ethernet port on a custom board

2 Answers2