True. Wouldn’t that be nice? I doubt Starlink has support channels built for vendor-to-vendor engineer issues. Just the game of “it’s their fault”, pointing the finger.
I installed the latest firmware, 8.2.1 build 5372, on my Transit Duo today. I am still having the similar speed issues running the ETH WAN compared to using the Wifi WAN. Wifi WAN speeds are double to triple the speeds of the ETH WAN. When using the ETH WAN, I would get jitter value any where in the hundreds to thousands when trying to run speed tests.
I only have a USW Flex Mini available to do the switch insertion test. Connecting the switch in between, with no changes to the ETH WAN on transit, I am getting the same slow speed and spotty usage. Forcing the 1GB FD on the Transit, I am now getting expected ETH speeds.
I am glad I found this thread. I had been playing with the 1GB FD setting and MTU settings and could get something semi usable, but was just so pathetic compared to switching over to Wifi WAN.
A relative of mine is about to get his Starlink. I was hoping to provide a spare Balance One or possibly Surf Soho to manage a dual WAN Starlink and DSL configuration. It looks like the Balance One may have the same issue and require a hardware switch work around:
https://forum.peplink.com/t/starlink-and-balance-one-core/627d2b0b0b79fbafb6a4678b/
Does anyone know if a Surf Soho requires the hardware switch workaround?
One suspects there are different chips and hardware in the various Peplink products having this issue. I don’t know whether or not to hope that augers well for a Peplink fix or not. One has to wonder if the hardware varies, something Peplink firmware is doing causes the issue. Anyway, fingers crossed for Peplink, Starlink or both to fix this.
Update from support:
We have conducted some tests after having been through several discussions on the situation.
So, we would like to take this opportunity to share more details we found thus far in addressing the port compatibility issue between Starlink Gen 2 + ETH Adapter (in Bypass mode) + Transit/Transit Pro E - WAN interface.
- The port compatibility issue is an effect of the combination of both the Starlink ETH Adapter chipset and certain Peplink models (eg. MAX Transit, Transit Pro E) - WAN chipset, that we have seen so far. Changing either peer device will see this symptom disappear. Nevertheless, we will try to find any feasible option(s) that could help our customers to overcome the hurdle when using our product(s).
- The team has gathered more in-depth information on the Starlink ETH Adapter, which we think the wired signal reception could be improved using a Shielded Twisted-pair (STP) cable.
- We are sourcing the similar service (Starlink Gen 2 + ETH Adapter) to be set up on our premises so we could conduct in-depth research.
- Trying to get in touch with the Starlink service support that can help to work on this matter.
The switch workaround has still been working great. So if anyone else if having this issue, try picking up a cheap switch and put that in-between Starlink and the Pepwave Transit. Support has been really good, but until they can get their hands on a Starlink unit and do further in-depth analysis, the switch workaround is the best bet. I know they want to resolve this as quickly as possible for their customers.
5 Likes
So I’ve run into this same issue and found this thread. But I recently added a switch to my setup, and it didn’t make a difference at all? I think started adjusting my active connections, and noticed that if I have Starlink as a WAN, and my 2 cell sims as active, I don’t seem to have the issue - but as soon as I add Wifi WAN as an active connection, I run into the packet loss?
Also, does anyone know what setups are / are not impacted by this? I’ve chatted with others running the same setup (Max Transit Duo + current firmware + Starlink as WAN) that don’t run into this issue at all?
This thread has been super helpful, but I don’t think we’ve pinpointed the issue, and I don’t think adding a switch is an absolute workaround.
I’m also seeing a huge increase in speed by inserting a switch between my Starlink v1 round dishy (no Starlink wifi) and my Balance 20 (hardware 6).
Maxes out at 10mbps download without the switch and jumps up to 50-150mbps with a switch.
I have been following this thread but it has been quiet for 22 days…anyone have news?
1 Like
I’m having this same issue but I’m unable to test a switch in the middle at this time. Has anyone heard an update from peplink or starlink on a non-switch fix?
1 Like
Hey Everyone,
An update on this. Peplink has the ethernet adapter on order and waiting for it to arrive.
I helped with initial testing and troubleshooting and have been testing a special firmware/license the last couple of weeks that allows you to assign one of the LAN ports to be used as a WAN port. The LAN ports use a different chipset that is not affected by the incompatibility between Starlink and the Pepwave device. Using this Virtual WAN port, I’m able to get full speeds from my Starlink setup and has been working flawlessly. I get my full speeds down and up and pages/content loads quickly and as expected.
You can see their post here.
Since they are now advertising this, you can contact support and get your Virtual WAN license and use one of the LAN ports with Starlink.
They have an ethernet adapter on order for further testing/development, but until that, the two solutions are 1) insert a switch in between Starlink and Pepwave or 2) Contact support to use the Virtual WAN feature on a LAN port.
4 Likes
Has anyone tried a USB WAN ethernet adapter? Can I Use Ethernet Adapters on the USB WAN? or is adding a switch / getting the Virtual WAN on LAN seen as the better options?
Hey Todd,
Not sure what model you have, but mine (the Transit Pro E) doesn’t have any USB ports on it, so I cannot try that method. The only methods that work are adding a switch or getting the Virtual WAN license. I’ve been running the Virtual WAN now since the end of June without any issues. Took a few minutes to get it setup, but now that it is, it’s just plug and play with Starlink every time we move.
1 Like
Network engineer here. As soon as I started reading the first messages in the thread, I knew the likely cause of the issue-one side of the conversation is having an autonegotiation problem, and putting in a generic switch between is usually the fix, because the errant side can better negotiate with the generic chipset. Before I could jump in, you folks beat me to it!
Given we can’t adjust the Starlink ethernet adapter side, that seems like the culprit.
This is a common problem. We see this frequently with video equipment talking to Cisco routers and switches. You have no control of the video equipment side and can only hardcode the Cisco side. Usually (“usually”) it’s a company that doesn’t specialize in making network equipment (ie: video vendors for us) that tends to have the most flaky stuff.
Some of you found that even when hardcoding the Peplink side down to 100M, it “worked,” but the performance was terrible. When I’ve done captures in this situation, usually the problematic adapter (the Starlink in this case) is still trying to auto-negotiate and fragment or flap the heck out of your connection, but fast enough to not timeout your pings.
Sometimes you will only see this in one direction, and sometimes it’s just at layer 1 (for you OSI model nerds).
I haven’t seen any Chinese-made chipsets that have come out recently that can’t be fixed without proper drivers. It’s probably not a Peplink issue, and I’m skeptical that anything they can do will make a difference.
It’s more of a Starlink problem. They can fix their drivers. Even if they allow you to hardcode settings on their side, it can still have some funky behavior.
So until Starlink updates their drivers the easiest thing is to indeed to go with the cheap switch, which uses a different algorythm to auto-negotiate with the Starlink.
1 Like
does anyone know if you’d still need the switch if you were to ditch the Starlink Router altogether using the ”router hack delete” that can be found in various forums?
1 Like
The problem is with the little Starlink ethernet adapter. Does the hack bypass of and just drop you to an RJ45? The only thing I’d worry is if the dish side ethernet uses the same chipset, which it may from a manufacturing standpoint.
Based on recent tear down videos/articles the adapter is merely a pass through device with provisions for power injection. There are no active components.
I have been working with Starlink on this and it appears to be an issue with the way the two devices negotiate the link when set to “Auto” or “1gb”
So far the work around for this issue is to set the link speed on the PepWave to “100M” or use an intermediate bridging device like a switch. Granted 100M will slow your download speed a bit when using starlink.
1 Like
Do we know a list of pepwave / peplink devices that would be impacted here ?
Agreed the best solution might be a peplink firmware to allow hard setting of Ethernet speed on wan to all speeds. I see some here trying 100, does transit not have option to 1g full ?
Also noted there 3 versions of SL dish units out but more commonly known are the gen1 aka round (had 2 hardware versions) and gen 2 rectangular. I’m betting most here are talking gen2 since gen1 did not need Ethernet adapter.
We have been using Starlink (Gen1 & Gen2 via ethernet) with Peplink routers for over 12 months without connectivity / speed issues.
The routers we have been using are as follows:
- Balance One Core - 6 Year Old model running FW8.2.1
- UBR LTE - running FW8.2.1
- HD4 MBX - running FW8.2.1
- Balance 310 5G - running FW8.2.1
- Balance 20 & 20x - Running FW8.2.1
We have many Transit Duo’s old and new and of various CAT’s but have never had the need to use Starlink with them but we will be testing this weekend just to see if we see the same issues as outlined in this thread.
Regards,
Ozzie
SimpliWIFi
https://simpliwifi.agency
Update with support.
We haven’t seen the same type of problem reported by other customers (packet loss or uplink 80 kbps) using Transit Duo here. In our case it was problem of downlink mainly, around 20 Mbps without packet loss.
8.2.1s075 firmware improved downlink in our lab but it didn’t help for customers, who used Transits, neither for you.
Our SWE team does not have much ideas from software side. We cannot do experiments on customer equipment because we need the physical access to the board to connect console cable in a case we brick the unit.
After consulting with hardware and software engineers, it looks that this compatibility issue cannot be solved by software from our side. We should look for the alternative methods, which we know already like the switch, 100 Mbps port speed, other port + Virtual WAN or maybe even cut the cable?
So it seems they have been unable to come up with a solution/fix on the software side of things. It doesn’t appear to affect all Pepwave devices, just ones like me (Transit Pro E) with the chipset they are using on the WAN port. As using the virtual WAN on the LAN side of things has been working perfectly fine for me. You can then convert the WAN port into a LAN port so you are not loosing ports.
As a Network Engineer, I was not satisfied with this so I went with the “Starlink Router Delete Mod” by modifying my Starlink cable from the Dishy. We live in our 5th wheel full-time and wanted to be able to run it off 12v anyways so I did not need an inverter. There are a lot of tutorials online and the infamous diagram for switching the pairs when terminating the shielded CAT5e cable end from Dishy.
In the end, I now have:
Dishy->Cable cut->PoE Injector (powered by a 12v to 48v up converter power supply by MeanWell)->Pepwave Transit Pro E WAN port
I used the PoE injector DishyPowa: https://dishypowa.com/
Power Supply: DDR-120A-48 MEAN WELL USA Inc. | Power Supplies - External/Internal (Off-Board) | DigiKey
Using DishyPowa you can keep the standard T-568B pinout when terminating and no need for custom cable end on the router side of the PoE injector. It’s been working rock-solid for me. Actually, using it this way straight from the Dishy, it works on the WAN port. So the network chip Starlink is using on their router side (with adapter) seems to be the problem. But there are workarounds: 1) Use a switch in between, or contact PepWave and activate the Virtual WAN feature and plug Starlink into a LAN port.
I used the Starlink Ethernet adapter and cut it so I did not have to destroy the OEM cable from dishy until a replacement came in (or there were issues and I can easily go back to the Starlink Router).
Cutting the ethernet adapter cable. Notice how there are 2 sets of wires. The thin ones are for the ethernet jack on the adapter and the thicker ones are from Dishy. I just cut off the thin ones as it’s for the Starlink router. Ethernet jack on adapter is useless anyways doing this hack.
4 Likes
I bought a Max Transit in 2021 and just received our Starlink this week. Plugged it into the router with the SL network adapter, no switch in between and no other extra components. It seems I am getting regular speeds and do not have any excessive packet loss. I have not run any heavy tests yet. Is there a way to definitely tell whether this problem exists or not? Or would I know it by now?
Regards,
Maciek