Interesting … It seems the preponderance of the evidence suggests the issues are with Starlink, not other modems/devices. I don’t hear of issues with Motorola, ARRIS, TP-Link, Netgear modems, etc., for example. Just Starlink. Do I understand this correctly? (I am not making an argument at this point – I just want to understand the scope and limitations of the issue.)
1 Like
One argument against it being entirely starlink’s fault is that plugging the ethernet cable from the starlink ethernet adapter directly into a Macbook also alleviates the problem. So presumably whatever network firmware implemented by mac os/whatever LAN chips they’re using can avoid this issue
1 Like
Yes, or using a different vendor’s router works. My Mikrotik router I have works just fine. Would assume other vendors work too depending on the chipset used.
@Zachary_Hazell & @Sam_Atkins : TU. That’s very helpful information. Sounds like we need to hear more from Peplink on this.
[Side note: I wonder why messages are now being quoted when the person creating the reply did not request it. Uuugh.]
1 Like
Been working with Peplink support on this. They did not have a Starlink gen2 dish/router to test with so I have been assisting with my setup. I setup a remote assistance session with their engineering team who spent a few hours trying some things out. They see the packet loss but was unable to determine where it’s coming from. We changed out cables and they gathered logs for analysis.
Their findings:
- PING from the Transit Pro-E WAN interface to our device WAN IP (202.190.63.215), we can see the packets sent out successfully, but lost along the path to the destination.
- PING from the Transit Pro-E WAN interface to Starlink IP (192.168.100.1), we also see the same packet loss situation as happening in (1) above. It looks like those lost packets went into the “black hole”.
- From the Transit Pro-E, Engineering Team sees all the packets handled out (forwarded ) from the WAN interface without error or drop at the driver level, thus, we can safely conclude there aren’t any issues within the router OS.
- It looks like it is a compatibility issue between the Ethernet chipset (Transit Pro-E) and USB-to-Ethernet chipset (Starlink ETH Adapter), as we tried to adjust some parameters at the Transit Pro-E WAN ethernet driver but the result is the same.
- Moving forward, for testing purposes, we would like to try to build a special firmware that uses a newer Ethernet chipset driver, to see if that could change the behavior or overcome the compatibility issue. Target it shall be ready in a day or two.
They got back to me after a few days and sent me this special firmware. But after installing it, it did not appear to help resolve any issues and still have a very high packet loss.
Their latest response on my ticket is:
Currently, we have a few preliminary ideas that we are discussing internally, so I foresee we shall be able to come back to you with an update early next week. Please bear with us a little bit more while.
Support has been really good with their updates and great to work with. Hope they can figure out what is going on.
6 Likes
What an outstanding update, thank you! Looking forward to hearing what comes next. I think I speak for us all when I say thank you for working with the Peplink support team to sort this out.
2 Likes
Kudos to them for putting forth the effort, but it’s hard to see how they’d be able to effectively debug this without seeing the traffic between Starlink and Peplink devices directly. Other than that it’s taking SWAGs and getting lucky. That can work (BTDT), but it’s hardly optimal 
In an ideal world they could reach out to Starlink directly, each side could send one another hardware, and both sides would get to work on it.
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