|Anonymous | Login | Signup for a new account||2017-06-25 03:43 UTC|
|My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003069||Zandronum||[All Projects] Bug||public||2017-04-17 14:56||2017-06-24 15:35|
|Target Version||Fixed in Version|
|Summary||0003069: Unable to connect -- Router disconnects.|
|Description||I am currently using a tablet connected to my computer via USB Tethering (Using PDANet) to use my Wifi connection. Turns out every time I try to enter any Zandronum 3.0 server, it gets stuck on "Requesting Snapshot . . . " and I get disconnected from PDAnet|
edited on: 2017-04-17 19:16
Seems to be a problem only with TSPG's build
edited on: 2017-04-18 00:20
Updating ticket as I was helping Blews out. It turns out that sv_maxpacketsize being set to 2048 by default is what has caused this.
It seems multiple people are having issues with connecting to any 3.0 server (stock build or the tspg modified build) if sv_maxpacketsize is set to 2048. I understand this is the default now but it seems to be causing issues.
It does not matter which mod it is either. It could be doom2.wad only and this issue occurs.
EDIT: Setting my servers to use sv_maxpacketsize 1024 has fixed this issue for these users.
Is sv_maxpacketsize the maximum size of a server-transmitted UDP packet? If so, I think I know what's going on.
The UDP protocol allows you to send packets that are 65k large. However, Ethernet's maximum packet size is usually set to around 1500, and packets larger than that will be fragmented, sent in pieces, and reassembled on the other end. If any one of those fragmented packets is lost for any reason, the entire packet is discarded.
That is how things work under ideal circumstances. In reality, UDP is not treated very well by the wider internet, and sometimes fragmented UDP packets simply get blocked wholesale, or cause other undesirable behavior with poorly-programmed hardware. Fragmentation and reassembly also imposes additional latency, though I'm unsure if such latency is noticeable.
If that setting is what I think it is (and it might not be, so take my advice with a grain of salt), I think the proper solution is to bring down the maximum packet size to 1400 or so for now.
Ideally, Zandronum would have some sort of MTU negotiation, where the client and server would send each other packets of specific lengths to test how big of a packet the connection can handle, and how much latency each size introduces.
edited on: 2017-04-18 01:19
i could be mistaken, but i believe sv_maxpacketsize was increased in https://bitbucket.org/Torr_Samaho/zandronum/commits/0de25ccf820e6235569403e429d738383eb123d6 [^] for http://zandronum.com/tracker/view.php?id=1469 [^]
EDIT: well i guess i am mistaken, i just tried a fresh ini and sv_maxpacketsize is 1024
edited on: 2017-04-18 12:18
Two other users are effected by this, but not on connection. They can join the game but they get stuck inside the end game results screen and have to quit the game and rejoin to get back in (making most modes unplayable).
Torr Samaho (administrator)
sv_maxpacketsize intentionally defaults to 1024. We did some experiments with higher values years ago and it only caused problems. Unless you know exactly what you are doing, you shouldn't touch sv_maxpacketsize.
Some time ago, I increased the internal parameter PACKET_BUFFER_SIZE from 1024 to 2048, but this is unrelated to sv_maxpacketsize. WaTaKiD, I think this is what you remembered.
So, are there still any issues if sv_maxpacketsize is kept at its default value 1024? From the notes above it sounds to me as if this fixes the problems.
As of the v5b update of MM8BDM, I can't seem to join servers anymore, I'm presented with the same issue of repeating "Requesting Snapshot..."s , however my PDAnet doesn't disconnect anymore unlike the previous issue.
This has been tried on both zandronum 3.0 r170416-0710 and r170618-1927 alpha releases
|Only registered users can voice their support. Click here to register, or here to log in.|
|Opponents:||No one explicitly opposes this issue yet.|
|2017-04-17 14:56||Blews||New Issue|
|2017-04-17 19:16||Blews||Note Added: 0017178|
|2017-04-17 19:16||Blews||Note Edited: 0017178||View Revisions|
|2017-04-18 00:17||mifu||Note Added: 0017184|
|2017-04-18 00:20||mifu||Note Edited: 0017184||View Revisions|
|2017-04-18 00:54||AlexMax||Note Added: 0017187|
|2017-04-18 01:11||WaTaKiD||Note Added: 0017188|
|2017-04-18 01:19||WaTaKiD||Note Edited: 0017188||View Revisions|
|2017-04-18 12:18||Cutman||Note Added: 0017194|
|2017-04-18 12:18||Cutman||Note Edited: 0017194||View Revisions|
|2017-04-18 17:53||Torr Samaho||Note Added: 0017196|
|2017-04-18 17:53||Torr Samaho||Status||new => feedback|
|2017-06-24 15:35||Blews||Note Added: 0017898|
|2017-06-24 15:35||Blews||Status||feedback => new|
Questions or other issues? Contact Us.
|Copyright © 2000 - 2017 MantisBT Team|