Need advice on cabling from RPi 4B UE300 to FTTH ONT

Hi,

I please need advice on the cabling that connects my OpenWRT Router to an FTTH ONT which has been driving me crazy as of late.

General topology:
FTTH ONT --> TP-Link UE300 USB ethernet adapter (eth1/wan) --> Raspberry Pi 4B (eth0/lan) as the router --> managed switch --> PCs/WiFi AP/printer.

For about two and a half years I'd been using the RPi 4B and UE300 as my router connected to a DOCSIS 3.0 modem without any issues. As the modem was sitting right next to the router in the living room, they were connected with an approx. 1 meter patch cable.

Recently I got an FTTH connection that has the ONT in the apartments hall whereas all the network equipment including the router and the PCs (still) are in the living room.
To connect the router to the ONT I got a brand new 20 meter Cat6A S/FTP patch cable.
Initially everything was working fine until my download speed of 250MBit got cut in less than half to 95MBit which in turn messed up the SQM setup.

Here's what I found during troubleshooting so far:

  1. When I connected the ISP provided router with a short cable to the ONT and with the new 20m Cat6A cable to my PC I got a 10(ten!)MBit connection from router to PC.

  2. When ONT and UE300 are connected with the 20m Cat6A cable the UE300 works at full GBit for a couple of hours and then switches to 100MBit ethernet speed which results in the 95Mbit download speed I first noticed.

UE300 initial ethtool status
root@Router:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP    MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: MII
        PHYAD: 32
        Transceiver: internal
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00007fff (32767)
                               drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
        Link detected: yes
root@Router:~#
UE300 ethtool status after some hours (note the missing 1GBit advertised link mode)
root@Router:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP    MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 100Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: MII
        PHYAD: 32
        Transceiver: internal
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00007fff (32767)
                               drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
        Link detected: yes
root@Router:~#
  1. For testing I currently have the ONT and UE300 connected with an old 10m Cat5e cable I had lying around and use the new 20m patch cable to connect my PC to the switch. Both connections have been working at full 1GBit speed for over 8 hours. (As the cable acts as a trip wire in the living room door the wife approval factor is quite low though...)

Which has me scratching my head as to what the best option to connect ONT and router is:

  1. Is it just that the new 20m patch cable is faulty and replacing it would solve everything?
  2. Is using patch cables of that length a bad idea in general and do I have to get an installation cable with a patch panel or keystone jacks instead?
  3. Should I move the router to the hall so it's next to the ONT and connect router and switch with the 20m patch cable?
  4. Should I connect the ONT and switch with the 20m patch cable and use a VLAN to connect the switch ports where ONT and eth0 of the RPi are connected foregoing the UE300 completely? Isn't this a problem because it puts the switch in front of the firewall?
  5. Get an optical connector and a 20m fiber cable and put the ONT in the living room next to the other network equipment?
  6. What about the 90 degree bends (corner from hall to living room door and around the door frame) for either the ethernet or optical cable?

Thanks for reading all of my ramblings and thanks for your help in advance!

I would assume that this is a real possiblity. Or, it could be debris or bent pins in the ONT's RJ45 connector.

You could try this... if the 20m cable is faulty/marginal, it'll likely exhibit the same behavior on the link between the pi and the switch.

don't do this.... the 20m cable is likely the problem.
But regarding the general idea -- if you have a low end managed switch from TP-Link or Netgear, don't do this at all as there are major shortcomings in the firmware and this could be a significant risk of problems or security issues. If it is a higher end (business grade), you can achieve this safely.

20m is well within the ethernet spec, so a fiber isn't necessary... it only adds expense and complexity to your setup.

not good for either if you exceed the bend radius ratings of the cable. Copper is fairly forgiving unless cycled or bent with an extremely tight radius and force. fiber depends on the materials -- it could snap or kink internally. Stick with copper, though.

1 Like

Thank you for your quick reply!

Hm, I hadn't thought of that... Thanks, I will check the ONTs connector!

Thanks for taking this into consideration. You're right on the money, it's indeed a cheap Zyxel switch I got for learning about and using basic VLANs.
So I will definitely not put the switch in front of the firewall!

Just wanted to make sure as up until recently I thought the 100m in the spec was referring to patch cables but now I read about the "90 meters (295 ft) of solid horizontal cabling between the patch panel and the wall jack, plus 5 meters (16 ft) of stranded patch cable between each jack and the attached device.[13]" on Wikipedia. Which makes it sound like you're supposed to only use patch cables of max. 5m...

Looked into it for the first time today, all the unknown variables left me a bit confused to say the least...

So thanks to your feedback my plan is to:

  1. Keep watching how ONT and UE300 work with the old 10m Cat5e cable between them for a couple more hours.
  2. Check the ONTs RJ45 jack for debris or bent pins.
  3. Try putting the router next to the ONT with the new 20m Cat6A cable between router and switch to see if they show the same behavior as ONT and UE300.
  4. Report back.

That is technically correct, the specs say 100m max - and they consider 90m solid core cat-5e installation cable and two 5m cat-5e patch cables made out of stranded wires for that. However, cat-6a is better spec'ed than the minimum requirements with cat-5e and 20m total, in one uninterrupted cable run (as long as we're talking about a round cable, preferably shielded, and not a flat one), is not an issue here; you'd probably even get 2.5GBASE-T over the distance that way (easily).

Based on your description, there is something wrong - and cables/ connectors would be the primary suspects (no, it is not unexpected to find out that a new cable is broken - and bent pins/ debris in the connectors or similar issues preventing a firm connection is not at all uncommon). Keep in mind that ONT or the ethernet card (UE300) might also be at fault, but we're really talking about a hard fault here - not something that might- or might not work by design. (A quick and cheap way to rule out the UE300 would be to reverse the roles (wan/ lan assignments) of the onboard ethernet and UE300).

Technically, with the RPi4 (no wireless to speak of and only 1+1 ethernet ports), there wouldn't be much of a loss in terms of functionality to hang it right next to the ONT (and keep everything else, switch and APs where they are), so if that meets you requirements - go for it, but still find out the where the hard bug is in your connection first (and fix it).

1 Like

Hi @psherman and @slh,

thank you again for your feedback and encouragement. The last time I experienced a faulty cable was about 20 years ago with a Cat 5 (non e) cable that caused intermittent disconnects in a small GBit network. Since then all the new cables I got were always perfectly fine so I didn't think of a brand new cable being faulty at first and then it still felt like chasing ghosts. So it's good to know that new cables being faulty isn't that uncommon after all!

Update to my last post:

  1. With the old 10m Cat 5e cable between ONT and UE300 the UE300 did not switch to 100MBit and there was no connection loss for a bit over 34 hours. So ONT and UE300 seem to be working as expected.
    At the same time I had the new 20m Cat 6A cable connecting my PC to the switch at full 1GBit and "netstat -e" showed 0 dropped packets and 0 errors. The PC wasn't continuously on for the full 34 hours though.
  2. As @slh suggested I then reversed the RPis ethernet port assignments (internal to wan and UE300 to lan) and connected RPi and ONT with the new Cat 6A cable again.
    This is how it's currently running and at over 19 hours it's still at 1GBit with no connection loss.
  3. The ONTs RJ45 jack seems to be fine. I couldn't find any debris or bent pins when I checked it (as I switched the cables after the 34 hours).

Some more observations:

  1. Due to the Cat 6A cables stiffness it kept some of the coiling it had in the packaging and refuses to sit completely straight in the ONTs RJ45 jack.
    I'd understand if this would lead to a continuously bad connection but not why 1GBit would work at first and only switch to 100MBit after some time (often only after about 20 hours of working correctly).
  2. One other variable could be that I didn't bother to put the Cat 6A cable back as it was the first time. Currently it's running across the living room floor the same as the Cat 5e cable was.
    The first time it was running around the living room door frame and along the walls, which means near to the power cables and 5 meters of the APs PoE cable.

Since all the patch cables I have are S/FTP, the latter lead me down the rabbit hole of reading up on grounding the cables shielding...
Some claim it's a must when using shielded cables others say it's optional in small home networks.
The switch I'm using (ZyXel GS1200-8HPV2) only has plastic RJ45 jacks and is not grounded, so only the patch cables of the PCs, NAS and laptop docking station are grounded (on one side) through their respective PSUs.
The PoE AP, printer and RPi router (and ONT) are not grounded at all (but still connected trough shielded cables).
Might this be a problem or is this not a significant factor in a home setup?

As to not go down the rabbit hole too deep, I'm considering sidegrading the ZyXel switch with something like the HPE Aruba Instant On 1830 (JL811A) or MikroTik CSS610-8P-2S+IN which have grounded power plugs and metal RJ45 jacks and rely on the switch to do the grounding of the patch cables.
(The ONTs plastic jack would be connected with a short UTP cable to the UE300s plastic jack and the RPis internal erhernet port would be connected to the grounded switch with a/the current 20m Cat 6A S/FTP cable.)
Would that be worth the investment?

Thanks again for your time and your advice!

Short update:
After passing the 24 hour mark without any issues (no switch to 100MBit or connection loss), I set the regular port assignments (RPis internal port eht0 as lan and the UE300s eth1 as wan) and connected the Cat 6A cable in it's "trip wire configuration" to the UE300.
Let's see if the issues reoccur.

In the meantime I also found this article from 2007 and hope that since then the physics didn't change:

"A second antenna myth is that common mode signals appearing on a screen or shield can only be dissipated through a low-impedance ground path. The fear is that an ungrounded screen will radiate signals that are “bouncing back and forth” and “building up” over the screen/shield. In fact, left ungrounded, a screen/shield will substantially attenuate higher-frequency signals because of the low-pass filter formed by its resistance, distributed shunt capacitance, and series inductance.

The effects of leaving both ends of a foil twisted-pair cable ungrounded can also be verified by using the abovementioned experimental method. The coupling between two UTP cables is still a minimum of 20 dB worse than the interaction between two ungrounded F/UTP cables. (Note that 20 dB of margin corresponds to 10 times less voltage coupling.) Even under worst-case, ungrounded conditions, the UTP cable behaves more like an antenna than the F/UTP cable.

Modeled and experimental results clearly dispel these antenna myth. Screens and shields offer substantially improved noise immunity compared to unshielded constructions above 30 MHz, even when improperly grounded."

So if I understand correctly, there's no need to worry about grounding the shielded cables in a non-industrial home network and I'll not get a new switch to play around with.

In my limited experience in dealing with RF noise I can say this is a bit of a black art, occasionally grounding something can either help, change nothing noticeably, (or rarely even make things worse), so some trial and error is in order... ethernet typically is relative robust...

…especially with such short cable runs (20m is not much, even with stranded wire).

1 Like

Hopefully the last update:

Over night with the cable completely untouched there were some (4-5?) entries of "Network device 'eth1' link is down" in the log and in the morning eth1 was set to 100MBit.
This was with the new Cat 6A cable connected to the UE300 without being near the APs PoE cable or power cables ("trip wire configuration").
=> So there's probably no need to deal in any RF noise black art (I really liked that description).

I now placed the RPi router in the hall next to the ONT and connected the UE300 to the ONT using the ISPs short UTP cable. The RPis internal ethernet port is connected to the switch with the new Cat 6A cable.
When I plugged the cable into the switch, the switch ports LEDs would not light up at first until I wiggled the plug a little.
A bit more wiggling of the cable and the LEDs went dark again.
While I was typing this post I got a hard internet disconnect while the cable completely untouched.

The plug has no obvious defects, the contacts look fine, the wires inside the plug look fine but it seems it's ever so slightly too small to fit snugly into the jack. Furthermore it's the only one of the cables that are connected to the switch that loses connection when wiggled.
Since the UE300s port doesn't have LEDs it wasn't as obvious as with the switches port.
=> I have now learned to appreciate the blinking ethernet port LEDs and will return the new cable tomorrow. It still baffles me that the cable can have a full GBit connection, often for hours at a time and then suddenly loses connection (switch) or even more confusing just fall back to 100MBit (UE300) but at least now I'm confident to have found the bug in the system.

Thanks again @psherman and @slh for pointing out that new cables being faulty aren't as uncommon an occurrence as I thought based an my personal experience over the years.

One likely related factoid, gigabit ethernet uses all 4 wire pairs simultaneously, while 100 Mbps 'Fast' ethernet only uses 2 of the wire pairs, so if a single contact goes bad the autonegotiation apparently falls back to fast ethernet.

2 Likes

For me personally, the most common failure case of ethernet cables is the little plastic clasp which secures it in the socket breaking off (or almost breaking off, becoming weak). While the cable is technically still fine, you can't really use it anymore in that condition, as it is no longer locked to the socket and will wiggle itself out, losing contact.

But following this forum, broken cables, connectors, bent pins or debris/ dirt/ wall paint in the sockets are also common occurances - and really the first thing to check/ call out in cases like this. It happens, regularly.

1 Like

Most embarrasing cable issue I had was when I took a cable out of the box to connect a router to modem and could not get Gigabit ethernet to work, no matter what I tried in ethtool or even how often I reflashed the firmware, ethernet speed was stuck at 100 Mbps...
Turned out the cable had only 2 instead of 4 pairs... (luckily that fact was printed on the cable, so I eventually got the message, but boy this took a few days)... I picked that cable partly because the other candidates had the same broken plastic tab that @slh mentioned, however these other cables all found their uses, I shpuld really take these out of business.

For closure: it definitely was the new Cat 6A cable (or most likely the plug at one end) that was at fault.

I got it replaced with a Cat 6 "non-A" (the store didn't have another 20m Cat 6A in stock) patch cable about a week ago and didn't have a single disconnect or 100MBit fallback ever since.

Moral of the story:
Don't think that a new cable can't be faulty because it's brand new and you didn't personally experience a new cable being faulty yet.
Also: Do appreciate the green and orange port LEDs you like to ignore during normal operation.

So @psherman and @slh were right from the get go. Unfortunately I can only select one comment as solution.

Yup. I'd say that this is a rare case, but bad cables still make their way out of the factories (and/or get damaged at some point after, even though they're still quite new).

Glad it's now solved!

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.