I’ve got a problem and at this point I’ve pretty much eliminated everything except the Peplink from the equation. I have a BR1 Max 5G router where I use Starlink as my WAN. Starting a few weeks ago I started encountering a problem when I would set up the Starlink (in my RV) that Peplink would report “Cable not connected” – additionally, I noted the port traffic indicator lights on the device correspondingly weren’t lighting up.
At first, I thought this was a bad cable that had been plugged / unplugged for a year… so I replaced it with a new cable
Then I thought maybe the PoE injector for the Starlink was bad, so I replaced all of that.
Finally, Starlink sent me a brand new dish because one of the two things left to check was that perhaps the connection from the cable to the dish itself had loosened and failed
After all of this I am still encountering Cable Not Connected errors… Once, I touched nothing but simply restarted the Peplink and the cable magically reconnected. This last iteration that didn’t work so, I unplugged the dish for about 10 seconds, plugged it back in and suddenly it was working again.
I’m at a loss, and at this point the only common denominator left is my Peplink. Thoughts?
We’ve seen this a number of few times now and came to a few conclusions.
If using Starlink Maritime/HP kits, we had to fix the speed to 100FullDuplex, then it would come online.
Others we discovered the cable between the dish and power supply could be the cause of this too.
With Starlink Roam/RV we found that the ethernet adapters and Starlink Routers would sometimes just die and had to be replaced.
I’m running on an 12V->48V step up with a PoE injector using the standard 150’ SL cable with no modifications. Everything is almost brand new at this point except the Peplink, which is about a year old.
If it happens again I’ll try the Duplex settings to see if that fixes things. I also adjusted the MTU to 1500 from 1440, although I doubt that would have any impact on “Cable Disconnected”
Agree - it’s doubtful the MTU will make any fixes to this, but the duplex settings we have witnessed multiple times can make a difference. We’re still unsure why sometimes this is a thing - it is however not a Peplink issue as we’ve seen this across multiple devices.
Strange that it only started happening a good 12 months after my initial install… hence why my last thought was Peplink and I replaced everything else (which is fine I suppose, the 12V power solutions for SL have drastically improved over my custom patch cables a year ago).
For now everything is running as expected… presuming the problem happens again I will try adjusting the duplex and see if that solves it (and report back).
but you’d have to find it in 12v i think that is 24v. its hard to jump from 12v to 48v on a reliable converter. i would also say you want to be around 50v or a little more not 48v.
Since recent days, we seem to have this problem on one device after another, currently on a total of 5 devices already. All 5 devices are rather new, and have been working correctly (with the Starlink) for weeks to months, until now. Changing the MTU to 1500 and speed to 100 Mbps FD doesn’t help.
Starlink released a bunch of firmware updates over the last 2 weeks that had bugs with 3rd party routers. The 3dca6b5d-2dbe-4eef-8091-75efdef3e5b9.uterm_manifest.release that was published yesterday fixes the issue in both V1 and V2 terminals.
The workaround was to use the original router (double NAT).
Hello @kevinp,
We use the same Fluke meter for testing all our custom cables; it does not do a certification (as required by the Australian/New Zealand standards as are necessary for Structured Cabling installations), though it sure does pick out the majority of issues and validates the performance. The unit exports a handy report when paired with the Fluke software, and we are optimistic that some AU/NZ certification may follow with future firmware updates.
This model can be plugged directly into Peplink routers & switches for testing the port’s functionality, such as PoE, Port Speed, DHCP and internet connection (if certain public IPs are visible through the firewall).
It’s a HP dish (Maritime) connected to the Starlink PSU (240V).
For some reason, now it works again. This is what I can see in InControl:
Hardware version: hp1Proto0
Software version: 3dca6b5d-2dbe-4eef-8091-75efdef3e5b9.utermManifest.release
I guess the Starlink firmware seems to be fixed? However, this one seems to date from 2024-03-26.
I am indeed using the original OEM PSU from Starlink which has a 240V input and directly connects to the HP dish using the standard 8m cable from Starlink.
Indeed, it seems all our BR1’s that got this issue the past weeks, are now again working perfect with Starlink HP dishes on the WAN interface. Does everyone else who ran into this problem have the same experience?
