Zwift kills my ADSL router!!

The Archives Archived: Zwift Feedback
1

Each time I use Zwift I get the same behavior. First the rider list keeps disappearing and any avatars disappear with it. Then after around 5-10s it all comes back again only to repeat again 10-15s later. This goes on for a while over and over until eventually the rider list never populates again. I can complete my ride with no other riders showing but when i save it at the end the app exits and it hasn’t saved.

I noticed after I packed up each time that my router had stopped working - it’s PPP light was off but DSL was on. Tonight I though I would try this again connecting my computer directly to the ADSL router and just putting it into “Watching” mode. The same thing happened. After about 5 minutes of the 15s on, 10s off routine the router lost PPP and stopped routing traffic. It had to be rebooted.

I’m not saying that Zwift is at issue as it seems like no traffic should kill the router but I have used the same router for 4 years and never had a problem with it (maybe restarted it 5 times before) so something about the Zwift traffic is making my router very unhappy. It is a Dynalink of some kind (I can get more details but it probably doesn’t matter).

I’ll try another router tomorrow but was just putting this out there in case anyone else has seen the same problem.

For more a more detailed look at the up-and-down nature of the rider list I took a tcpdump while the app was running. While the rider list is up I see a traffic pattern like

00:15:39.906258 IP 192.168.10.111.55340 > us-relay-28-64.zwift.com.csregagent: UDP, length 122

00:15:40.079233 IP us-relay-28-64.zwift.com.csregagent > 192.168.10.111.55340: UDP, length 1456

00:15:40.080530 IP us-relay-28-64.zwift.com.csregagent > 192.168.10.111.55340: UDP, length 1461

00:15:40.081845 IP us-relay-28-64.zwift.com.csregagent > 192.168.10.111.55340: UDP, length 1442

00:15:40.082126 IP us-relay-28-64.zwift.com.csregagent > 192.168.10.111.55340: UDP, length 1467

00:15:40.083178 IP us-relay-28-64.zwift.com.csregagent > 192.168.10.111.55340: UDP, length 313

00:15:40.106858 IP 192.168.10.111.55340 > us-relay-28-64.zwift.com.csregagent: UDP, length 122

00:15:40.277597 IP us-relay-28-64.zwift.com.csregagent > 192.168.10.111.55340: UDP, length 1456

00:15:40.278543 IP us-relay-28-64.zwift.com.csregagent > 192.168.10.111.55340: UDP, length 1461

00:15:40.279948 IP us-relay-28-64.zwift.com.csregagent > 192.168.10.111.55340: UDP, length 1442

00:15:40.281256 IP us-relay-28-64.zwift.com.csregagent > 192.168.10.111.55340: UDP, length 1467

00:15:40.281616 IP us-relay-28-64.zwift.com.csregagent > 192.168.10.111.55340: UDP, length 313

00:15:40.308349 IP 192.168.10.111.55340 > us-relay-28-64.zwift.com.csregagent: UDP, length 122

but when the rider list disappears I see

00:15:38.916545 IP 192.168.10.111.55340 > us-relay-28-64.zwift.com.csregagent: UDP, length 122

00:15:39.104211 IP 192.168.10.111.55340 > us-relay-28-64.zwift.com.csregagent: UDP, length 122

00:15:39.305791 IP 192.168.10.111.55340 > us-relay-28-64.zwift.com.csregagent: UDP, length 122

00:15:39.505755 IP 192.168.10.111.55340 > us-relay-28-64.zwift.com.csregagent: UDP, length 122

so no response coming back. Of course because this is UDP seeing the outgoing packet from my laptop does not mean it made it through my router so the first port of call is to try a different router.

I’ll update if the problem can be repeated on another router.

2

I have problems too. A new router didnt solve mine though. Will be interested in seeing how this plays out for you, so hopefully I can learn something.

3

Today I tried a different router - a Linksys WAG200G. The result was almost the same. The differences were that all riders were visible for at least 30-45 seconds before the problems started (as opposed to 10-20s for the other router). Once the issues started, instead of going to 0 riders it went down to 3 other riders and stayed around 3-5 riders showing most of the time, sometimes dropping to none.

Looking at the network packets captured on my laptop it seems like the response packets get through more often but are still being dropped for periods of time where none can be seen.

My suspicion is the use of UDP by Zwift. For a router to know that it can accept a response UDP packet it has to keep some state about outgoing packets and I suspect the router is running out of space in some table. As entries expire packets get through and then the table fills and packets get blocked. If Zwift provided a TCP option then I expect this problem would go away.

I would expect quite a lot of people to be seeing this issue though if it is a UDP state issue with routers in general as these are pretty standard routers.

I also tried setting up a packet forwarding rule for UDP packets incoming to my machine through the router to see if that would help since the router, in theory, would not have to keep state (although i expect it would still keep state for all outgoing UDP packets for a short time). That didn’t help.

Any change we could get a TCP option for Zwift for those of us stuck with this problem? The default could still be UDP.

The alternative may be that my ISP is not able to handle all the UDP state tracking if they have to do that for their NAT. Seems less likely the problem than the router having a limited state table size but I will contact my ISP to find out. They may be able to look at the times when i got disconnected or I can redo the test while I have them on the phone.

4

I got hold of another router. It is older than the others. After setting it up I managed to do my first full ride without all the riders disappearing. However, that doesn’t mean it was flawless. Riders were still disappearing at random when they were in front of me. Generally they were gone for 5-15s and then reappeared. The riders-near-you list kept shrinking to perhaps 5-10 riders then expanding again. Only once did it go down to 2 riders. 

I would say this router is behaving in much the same way but not to the same extent. I still suspect it is caused by the use of UDP for request and response and the router maintaining outgoing state so it knows to allow the response packets through the firewall (stateful firewall - otherwise the firewall would reject incoming UDP). I notice others on the forums are complaining about riders constantly disappearing and I would suggest this is the same issue and the same cause - the use of UDP.

As I said above, I suspect the solution would be to allow users to select TCP if they see these problems with the default UDP. Obviously TCP presents more problems on the server-side having to keep all those connections open but my guess is there will be more and more complaints from riders seeing eratic behavior with other riders disappearing.

This latest router has the option to turn off the firewall altogether and so it may not maintain state in that case. I’ll give that a go but it is not a mode I would want to live with since it leaves my internal network wide open.

5

I found that for the above comment the firewall was disabled in the router. That may explain why it worked much better than the other routers (and might not).

6

Hi Peter,

Can you please submit a support ticket and include all the game logs for each of the routers? You can find the logs in Documents > Zwift > Logs.

Thanks!