netdev - Re: Unable to TX data on VSC8531

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <44fe99ec-42a0-688f-16a0-0a3be3750290@mistywest.com>
Date:   Mon, 1 May 2023 12:57:04 -0700
From:   Ron Eggler <ron.eggler@...tywest.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org
Subject: Re: Unable to TX data on VSC8531

Hi Andrew,

On 4/30/23 07:23, Andrew Lunn wrote:
> On Sun, Apr 30, 2023 at 07:08:21AM -0700, Ron Eggler wrote:
>> Hi,
>>
>> I've posted here previously about the bring up of two network interfaces on
>> an embedded platform that is using two the Microsemi VSC8531 PHYs. (previous
>> thread: issues to bring up two VSC8531 PHYs, Thanks to Heiner Kallweit &
>> Andrew Lunn).
>> I'm able to seemingly fully access & operate the network interfaces through
>> ifconfig (and the ip commands) and I set the ip address to match my /24
>> network. However, while it looks like I can receive & see traffic on the
>> line with tcpdump
> So receive definitely works?
It would appear so as I can monitor traffic that's on the line with 
tcpdump and my arp table sometimes gets populated when an arp broadcast 
for an incomplete entry in the table can be picked up (due to other 
traffic on the network).
> It is a long shot, but a couple of decades ago, i had a board where
> the PHY came up in loopback mode. All transmits never went out the
> cable, they just came straight back again.
>
> When running tcpdump during transmit, do you see each packet twice?

Good idea, I tried this out but cannot make out anything related to 
pings (or arp requests) in tcpdump when I ping at the same time.

However, one thing:

After a fresh rebootI executed:

# ping 192.168.1.222 -c 1

and see the following:

# ifconfig
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500  metric 1
         inet 192.168.1.123  netmask 255.255.255.0  broadcast 192.168.1.255
         ether be:a8:27:1f:63:6e  txqueuelen 1000  (Ethernet)
         RX packets 469  bytes 103447 (101.0 KiB)
         RX errors 0  dropped 203  overruns 0  frame 0
         TX packets 0  bytes 0 (0.0 B)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
         device interrupt 170

eth1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500  metric 1
         ether fe:92:66:6c:4e:24  txqueuelen 1000  (Ethernet)
         RX packets 0  bytes 0 (0.0 B)
         RX errors 0  dropped 0  overruns 0  frame 0
         TX packets 0  bytes 0 (0.0 B)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
         device interrupt 173

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536  metric 1
         inet 127.0.0.1  netmask 255.0.0.0
         loop  txqueuelen 1000  (Local Loopback)
         RX packets 1  bytes 112 (112.0 B)
         RX errors 0  dropped 0  overruns 0  frame 0
         TX packets 1  bytes 112 (112.0 B)
         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

it appears like the ping got sent to the loopback device instead of the 
eth0, is this possible?

The routing table looks like:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
192.168.1.0     *               255.255.255.0   U     0 0        0 eth0

What's going on here?

> Please run mii-tool on the interface. e.g. for my device:
>
> mii-tool -vv enp2s0:
> Using SIOCGMIIPHY=0x8947
> enp2s0:: no link
>    registers for MII PHY 0:
>      1040 79c9 001c c800 0de1 0000 0064 0000
>      0000 0200 0000 0000 0000 0000 0000 2000
>      0000 0000 ffff 0000 0000 0400 0f00 0f00
>      319b 0053 1002 80d9 84ca 0000 0000 0000
>    product info: vendor 00:e0:4c or 00:07:32, model 0 rev 0
>    basic mode:   autonegotiation enabled
>    basic status: no link
>    capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>    advertising:  1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

I got the following:

# mii-tool -vv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 100baseTx-FD, link ok
   registers for MII PHY 0:
     1040 796d 0007 0572 01e1 45e1 0007 2801
     0000 0300 4000 0000 0000 0000 0000 3000
     9000 0000 0008 0000 0000 0000 3201 1000
     0000 a020 a000 0000 802d 0021 0400 0000
   product info: vendor 00:01:c1, model 23 rev 2
   basic mode:   autonegotiation enabled
   basic status: autonegotiation complete, link ok
   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 
10baseT-FD 10baseT-HD
   advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 
10baseT-FD 10baseT-HD flow-control

-- 
Ron