netdev - Re: issues to bring up two VSC8531 PHYs

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] [day] [month] [year] [list]

Message-ID: <06e3c69c-2792-66f1-13b4-ddc894787d09@mistywest.com>
Date:   Sun, 23 Apr 2023 15:53:11 -0700
From:   Ron Eggler <ron.eggler@...tywest.com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org,
        Russell King - ARM Linux <linux@...linux.org.uk>
Subject: Re: issues to bring up two VSC8531 PHYs


On 4/21/23 17:09, Florian Fainelli wrote:
>
>
> On 4/21/2023 3:55 PM, Ron Eggler wrote:
>>
>> On 4/21/23 09:35, Andrew Lunn wrote:
>>>>> You can also try:
>>>>>
>>>>> ethtool --phy-statistics ethX
>>>> after appliaction of the above patch, ethtool tells me
>>>>
>>>> # ethtool --phy-statistics eth0
>>>> PHY statistics:
>>>>       phy_receive_errors: 65535
>>>>      phy_idle_errors: 255
>>> So these have saturated. Often these counters don't wrap, they stop at
>>> the maximum value.
>>>
>>> These errors also indicate your problem is probably not between the
>>> MAC and the PHY, but between the PHY and the RJ45 socket. Or maybe how
>>> the PHY is clocked. It might not have a stable clock, or the wrong
>>> clock frequency.
>>
>> The man page 
>> (https://www.man7.org/linux/man-pages/man8/ethtool.8.html) does not 
>> give any details about what phy_receive_errors or phy_idle_errors 
>> refer to exactly, is there any documentation about it that I could 
>> not find?
>
> The statistics are inherently PHY specific and how a driver writer 
> choses to map a name to a specific PHY counter is backed within the 
> driver.
Thank you, I think I have moved past this now:
When I reboot, both RX & TX_CLK delay values are set to 0x0044 which 
equates 2.0ns delay and this actually lets me monitor traffic on the 
local network with tcpdump but still, my arp address doesn't go out and 
while my arp table gets populated, I'm not able to get any ping responses:
My interface in question:
# ifconfig eth0
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 92:95:1c:76:8c:3e  txqueuelen 1000  (Ethernet)
         RX packets 94  bytes 22123 (21.6 KiB)
         RX errors 0  dropped 36  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
arp table:
# arp
Address                  HWtype  HWaddress           Flags 
Mask            Iface
192.168.1.222            ether   54:04:a6:f3:19:db C                     
eth0
192.168.1.223            ether   68:ec:c5:ca:13:9f C                     
eth0
none of these hosts would reply to pings though but
# tcpdump -i eth0 ip
shows me traffic on the local network
the phy statistics now look like:
# ethtool --phy-statistics eth0
PHY statistics:
      phy_receive_errors: 0
      phy_false_carrier: 0
      phy_cu_media_link_disconnect: 0
      phy_cu_media_crc_good_count: 9667
      phy_cu_media_crc_error_count: 0
It appears like RX packets are getting dropped but interestingly the TX 
packets are showing 0 even though the ping command should send out some 
data:
# ifconfig eth0
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 92:95:1c:76:8c:3e  txqueuelen 1000  (Ethernet)
         RX packets 9885  bytes 2202753 (2.1 MiB)
         RX errors 0  dropped 3916  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

what could be going on here and how can I trouble shoot this further?

Thank you!


-- 
RON EGGLER Firmware Engineer (he/him/his) www.mistywest.com