Extremely Slow Speed on Slate 7

Test scenario 1:

1 GL-Inet Beryl AX, Firmware 4.8.1;

No Adguard or VPN’s, both WiFi’s off;

Configured as Tailscale exit node connected to cable;

Speedtest from tailscale on my phone using the Beryl AX as exit-node with expected speeds, around 150Mb/Downlink and 50Mb/Uplink

-

Test scenario 2:

1 GL-Inet Slate 7, Firmware 4.8.1;

No Adguard or VPN’s, both WiFi’s off;

Configured as Tailscale exit node connected to cable;

Speedtest from tailscale on my phone using the Slate 7 as exit node with expected speed for downlink around 150Mb

But for Uplink the speed is only 1 to 2 Mb/s …

-

Note:

On both scenarios, if the speeds are tested with a PC connected with cable to the LAN ports of both routers, the results are normal.

The extremely low downlink speed only happens on the Slate 7 using tailscale …

Hi Staci.

1 -

I did a factory reset on both routers, before the tests.

Hardware offloading is active by default

2 -

Tailscale status show the connection as direct, in both cases, there is no relay fallback;

A few Tailscale ping –size tests, shown replies from other local GL-Inet at 1ms or 2ms;

-

3 -

CPU load is low in both cases;

And as I wrote a local PC cable connection to the LAN port of both routers deliver my standard provider bandwith, about 930Mb downlink and 420Mb Uplink;

  • There is NO problem with Tailscale uploading from my phone on the Beryl AX

  • This difficulty ONLY happens with Tailscale uploading from my phone to the Slate 7

  • The hipothesis of a NIC driver quirk, makes sense if a cable test from LAN to WAN does not fail on the Slate 7 ?

  • A CPU saturation makes sense in this situation ?

  • The MTU is the factory default after a reset on both routers …

Regards,

Scalabis

Hi

Could you please let us know your detailed network settings? Based on your description, I assume:

  • The Beryl AX and Slate 7 are both running as Tailscale Exit Nodes.
  • The Beryl AX and Slate 7 are connected via Ethernet to the same network.
  • You are using the same mobile phone connected to the same network (is this a cellular network?) for testing.
  • When the phone selects the Beryl AX as the Exit Node, the speed is 150 Mbps DL and 50 Mbps UL.
  • When the phone selects the Slate 7 as the Exit Node, the speed is 150 Mbps DL and 1 to 2 Mbps UL.

We would like to further confirm with you:

  1. Is our understanding above accurate?
  2. Are these test results consistently reproducible across multiple attempts?
  3. Is the network the mobile phone is connected to stable? If it is a cellular network, did you disconnect from Tailscale and run a speed test again after testing the Exit Node speed to ensure the low UL speed is not due to cellular network fluctuation?

Hi!

I confirm all your assumptions,

I also confirm your points 1,2 and 3;

I can add / confirm:

a) The test results are consistently reproducible across several attempts;

b) The setup is really simple;

  • Flash if desired
  • Factory reset
  • Connect to wired network
  • Configure Tailscale including adding “–adverttise-exit-node”, so that it works as a exit node
  • Tested with my telephone in 5G with tailscale installed, using the above exit node
  • Both WiFi bands on the Slate 7 / Beryl AX were off
  • My telephone had the WiFi off
  • Everything ok, except Slate 7 uplink speed …

I may also add that tried a few Snapshot firmware’s on the Slate 7 with the same results.

I also tried a few MTUs on the WAN, same result.

Regards

similar issue here

GL-Inet Beryl AX vs GL-Inet Slate 7

  • enabled dropin gateway
  • connected tailscale with exit node
  • use LAN and disabled Wifi

Slate 7 extremely slow, less than 1Mbps download

while Beryl AX has 50Mbps download

PS: using Wifi directly connected to Slate 7 appears OK.

for me, it looks like something wrong with dropin gateway + tailcale exit node

Sorry for the delayed response.

Thank you for your report. We have successfully reproduced the issue locally.
However, as using our devices as Tailsale Exit Node is not currently within the scope of official support, we are unable to offer much assistance in this regard.

We have logged this issue. If we introduce official Tailsale Exit Node support in the future, we will investigate this matter further.

Hi

May we know that in your use case, Beryl AX and Slate 7 are also operating as Tailsale Exit Nodes?
Or are they connecting to other Tailsale Exit Nodes?

both AX and slate 7 are connecting to other Tailsale exit node (which operate from linux)

case1:

My computer wifi → netgear router wifi (192.168.1.x) → LAN → AX dropin gateway (192.168.1.x) → tailsale exit node → linux (NO PROBLEM 100M+)

case2:

My computer wifi → netgear router wifi (192.168.1.x) → LAN → slate 7 dropin gateway (192.168.1.x) → tailsale exit node → linux (VERY SLOW less than 1M)

case3:

My computer wifi → slate 7 wifi (in 192.168.8.x) → tailsale exit node → linux (NO PROBLEM 100M+)

I didn N times factory reset, try different setting, still less than 1M on slate7. I did not expect new models can get worst than old one, I was thinking to upgrade but i want to refund now :frowning:

Thank you for the clarification. We will try to reproduce the issue on our end.

It currently appears to be the simlar issue involving abnormal rates during WAN-to-WAN forwarding with Tailsale.

Hi!

Thanks for your reply.

I understand that you don’t support officially the Tailscale “Exit Node” option.

But as far as I know, you support, even directly at the GUI, the “Custom Exit Node” option.

If you configure a Slate 7 using the supported “Custom Exit Node” option, and connect it to a “Exit Node”, for example a Apple TV, the problem also exists and become reversed.

By reversed I mean that the downlink speed is miserable, about 1Mb/s and the upload speed is in my case around 50Mb/s.

As this is a supported option, I expect you to investigate this further.

I bought the Slate 7 specifically to be a traveling router using Tailscale and I’m just not able to do it.

Regards

Thank you for your feedback. We have successfully reproduced the issue locally.
We have asked the R&D team to investigate it and try to resolve the issue.