WAN Interface speed duplex troubleshooting assistance requested

[stumper]

WAN Interface on my Protectli v1210 fails to negotiate speed/duplex correctly when ISP coax is connected to cable modem, but does negotiate properly (2500/fdx) when I disconnect the ISP coax.

I'm fairly certain this is an ISP issue, but would appreciate some advice on how to collect meaningful information to help with ISP tech support

Setup
- Cox 2Gbps Internet
- Motorola SB8611 cable modem
- Protectli V1210, 2 Intel® I226-V 2.5Gigabit Ethernet NIC ports, RJ-45
- OpnSense 26.1.9

Issue
- WAN Interface fails to autonegotiate to 2500 and fails to get WAN IP (same issue if I hard configure 2500-t)
- Same issue with either interface (igc0 or igc1)
- Same issue with multiple cables
- Same issue with two different cable modems (Motorola SB861))
- Removing the ISP coax from cable modem, then WAN interface negotiates properly and receives default IP (192.168.100.x) from cable modem
- Factory reset / default OpnSense does not resolve nor does CMOS reset on Protectli
- Replacing OpnSense firewall with an older Asuswrt router (gt-ax6000) and the WAN interface on the router does negotiate properly to 2500/fdx and obtain WAN IP

Questions
1. Are there any interface settings and/or tunable I can configure to resolve this
2. What cli command can I run to help diagnose this + information I should capture to bring to ISP, so I can avoid the "simple" questions (change the cable, reset the router, ...)

[nero355]

- Same issue with multiple cables

Do they all happen to be Shielded UTP cables ??

I have only read about Ubiquiti Switches acting weird when Shielded UTP cables are used but maybe this specific Protectli model has the same issue ?!

[stumper]

Unshielded cables only used. I had heard about the shielded cable issues previously as well. Protectli support is stumped as well, but have offered to send a replacement unit which is encouraging.

[dseven]

Google AI thinks it's likely a grounding issue on the cable side - if the cable is not (properly) grounded, voltages have to find another way, which might be via the ethernet connection to the firewall. I don't believe everything AI comes up with, but this seems plausible.

How are you observing the "failure to autonegotiate"? Do you see anything in dmesg when the failure occurs?

[stumper]

Yea - I got the same findings from Google AI about it possibly being a grounding issue. Curious tho other devices I tried do not have the issue, but it could be something about the Protectli appliance.

UI interface Overview details for the given interface and ifconfig igc# (also no errors) show 100/fdx auto negotiated and interface never receives an IP address. Hard coding the speed/duplex and the interface fails to come up.

nothing in dmesg I could glean.

[nero355]

Google AI thinks it's likely a grounding issue on the cable side - if the cable is not (properly) grounded, voltages have to find another way, which might be via the ethernet connection to the firewall. I don't believe everything AI comes up with, but this seems plausible.

Yea - I got the same findings from Google AI about it possibly being a grounding issue. Curious tho other devices I tried do not have the issue, but it could be something about the Protectli appliance.

That's why I mentioned Shielded UTP cables :
When you use those and one of the two sides are not properly grounded there is a higher chance you will get weird issues compared to using regular Unshielded UTP cables ;)

And grounding loops can also be an issue !!


/(Bad)ExperienceDoesn'tNeedMachineLearningChatbots :P