0003069: Unable to connect -- Router disconnects.

Notes
(0017178) Blews (reporter) 2017-04-17 19:16 edited on: 2017-04-17 19:16	Seems to be a problem only with TSPG's build

(0017184) mifu (reporter) 2017-04-18 00:17 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.

(0017187) AlexMax (developer) 2017-04-18 00:54	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.

(0017188) WaTaKiD (updater) 2017-04-18 01:11 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

(0017194) Cutman (reporter) 2017-04-18 12:18 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).

(0017196) Torr Samaho (administrator) 2017-04-18 17:53	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.

(0017898) Blews (reporter) 2017-06-24 15:35	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

(0017906) Torr Samaho (administrator) 2017-06-25 13:29 edited on: 2017-06-25 13:43	0003132:0017903 hopefully also takes care of this issue. Please check if this fixes the issue.

(0017955) Ru5tK1ng (updater) 2017-06-30 23:04	Confirmed with ticket author that the issue is now resolved.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	mifu Hypnotoad
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
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
2017-06-25 13:29	Torr Samaho	Note Added: 0017906
2017-06-25 13:43	Torr Samaho	Note Edited: 0017906	View Revisions
2017-06-25 13:43	Torr Samaho	Assigned To	=> Torr Samaho
2017-06-25 13:43	Torr Samaho	Status	new => needs testing
2017-06-25 13:43	Torr Samaho	Target Version	=> 3.0
2017-06-30 23:04	Ru5tK1ng	Note Added: 0017955
2017-06-30 23:04	Ru5tK1ng	Status	needs testing => resolved
2017-06-30 23:04	Ru5tK1ng	Resolution	open => fixed
2017-06-30 23:04	Ru5tK1ng	Fixed in Version	=> 3.0
2018-09-30 21:43	Blzut3	Status	resolved => closed

Relationships