OpenArena Message Boards

OpenArena Contributions => Development => Topic started by: rm on March 02, 2012, 05:12:08 PM



Title: 0.8.8 worsened behavior with regard to IPv6
Post by: rm on March 02, 2012, 05:12:08 PM
Hello,

I am continuing to run my IPv6 master server: http://version6.ru/en/oa
and with OA 0.8.8, I notice something a bit less than pleasant.

The hostnames: dpmaster.version6.ru is v4+v6, dpmaster6.version6.ru is v6-only.

With 0.8.5 and 0.8.8-18:
\sv_master2 dpmaster.version6.ru  <= on an IPv6-capable host, makes OA send a single request over IPv6 and get back a complete list of IPv4 and IPv6 servers; then those which are actualy accessible from the host, are displayed in the menu;
\sv_master2 dpmaster6.version6.ru <= same

Starting from 0.8.8-20 and above:
\sv_master2 dpmaster.version6.ru  <= makes OA send a single request over IPv4 and get IPv4 servers only;
\sv_master2 dpmaster6.version6.ru  <= makes OA send a single request over IPv6 and get IPv6 servers only;

This is on Windows 7 with IPv6 from HE.net.

Someone might argue this makes sense in some aspect, but in practice this new behavior makes it all much less convenient.
With 0.8.5 a seamless IPv4+IPv6 dpmaster was perfectly possible, with 0.8.8 so far it doesn't seem to be the case.

P.S.: I have dropped the 0.8.5 .exe-file into my 0.8.8 folder, and when started by the old exe the game shows the 0.8.5 behavior (as expected). So this is clearly a change in the 0.8.8's binary.

(post updated a bit based on the research below).


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: Gig on March 02, 2012, 05:26:17 PM
Knowing that 085 executables are version 13, and 088 executables are version 28, you may try using different versions between them (available at http://files.poulsander.com/~poul19/public_files/oa/dev081/) until you find the first one that changes behavior.

This may help Sago identifying what happened.


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: rm on March 03, 2012, 02:57:50 AM
Gig
Thanks.
The change occurs somewhere between versions 18 and 20.

- openarena-engine-bin-0.8.x-18 = good
- openarena-engine-bin-0.8.x-20 = bad

The website has no version 19 to test.


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: probe_79 on March 03, 2012, 05:58:04 AM
Hi,

I can confirm the following behaviour.
Setup: dual-stack windows 7

- with /sv_master2 dpmaster.version6.ru it only shows IPv4 servers only
with the older OA version it was showing both
 
- with /sv_master2 dpmaster6.version6.ru, it shows IPv6 servers
now I'm using this one, it's ok as a workaround

But the behaviour should be as in all the RFC's, and as you experience with all the dual-stack webservers.
- resolve dpmaster.version6.ru for an AAAA record, if found use this one, IPv6
- if not resolve for an A record and use IPv4


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: GrosBedo on March 03, 2012, 07:03:03 AM
Code:

If you want the engine to use a different directory in your homepath than
  e.g. "Quake3" on Windows or ".q3a" on Linux, then set a new name at startup
  by adding
 
    +set com_homepath <homedirname>
 
  to the command line. Then you can control which kind of messages to send to
  the master server:
 
    +set sv_heartbeat <heartbeat> +set sv_flatline <flatline>
    +set cl_gamename <gamename>
 
  The <heartbeat> and <flatline> message can be specific to your game. The
  flatline message is sent to signal the master server that the game server is
  quitting. Vanilla quake3 uses "QuakeArena-1" both for the heartbeat and
  flatline messages.
 [b] The cl_gamename message is for dpmaster to specify which game the client
  wants a server list for. It is only used in the new ipv6 based getServersExt
  query.[/b]
 
  Example line:
 
    +set com_basegame basefoo +set com_homepath .foo
    +set sv_heartbeat fooalive +set sv_flatline foodead
    +set cl_gamename foo

So it may be linked to the new getServersExt function.

Anyway there are too many changes in this version for me to be able to really pinpoint the problem (why are there so many changes in one version?).


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: Gig on March 03, 2012, 08:55:47 AM
@rm:
I haven't understood a thing: are you making tests using new and old binaries for the (standard) server, for the client or both?

@GrosBedo:
I don't know why that has got many changes... maybe Sago imported some ioquake3 updates that time. I also don't know why there is no version 19... probably it was a try to do something that went horribly wrong... she should dig into the 0.8.x binaries thread to find more info.
Anyway, I suppose we are in the hands of Sago, now (I really have great respect of him... but however I hope you will get confortable with the source code, too... so you will become able to help him with this and similar things... he's great but I'm sorry he's alone!).


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: GrosBedo on March 03, 2012, 12:22:41 PM
I'm getting comfortable but unfortunately I have very limited spare time so I will never be more than a contributor.

About the import of ioquake3, yes I do think so too, so I think this may even be a bug induced by ioquake3. To further test that, RM could try the latest ioquake3 binary to see if that also produces the same bug. Chances that this will be the case.


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: grey matter on March 03, 2012, 01:21:45 PM
If the IP of a master server is v6, ioquake3 will send a getServersExt request (with an additional "ipv6" keyword if the client does not have v4 enabled at all). If the master server is v4, it will send a getServers request.
Both request types make use of the new com_gamename dpmaster protocol in ioquake3.
The code for this is in CL_GlobalServers_f() in code/client/cl_main.c.

I didn't take a look at the OA code. From what I see, there are two possible problems;
  • dpmaster might not return the same servers for getServers and getServersExt queries, even though they use the same keywords. This does sound like a dpmaster bug (it should ony do this if the "ipv6" keyword is present).
  • OA might inconsistently send a gamename for either request only, causing dpmaster to only return matching servers. I don't know the gamenames used by OA (especially v0.8.1/5 vs v0.8.8), but if they are not the same, then dpmaster's filtered reply is correct.


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: grey matter on March 03, 2012, 01:35:28 PM
Bump.
Looking at the code from openarena-engine-source-0.8.8.tar.bz2 it seems my point #2 applies.

OA v0.8.8 sends a "getServersExt openarena <keywords>" request to v6 master servers, but a "getServers <keywords>" request to v4 master servers (should be "getServers <gamename> <keywords>" as in ioquake3) {note: this might work with dpmaster if you patch it to know that protocol 71 means OA or there are only OA servers listed with that protocol. You should really be using requests with <gamename> instead}.
OA also uses a hearbeat of "QuakeArena-1" (for legacy Quake 3 master server support) instead of "DarkPlaces" (for proper dpmaster <gamename> support) {note: same as above; might work when adding protocol 71 as OA to dpmaster}.

You should just use the entire updated heartbeat code from ioquake3 to comply with dpmaster.


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: GrosBedo on March 03, 2012, 03:34:22 PM
Maybe a candidate for the hotfix patch?


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: rm on March 03, 2012, 03:52:39 PM
Quote
@rm:
I haven't understood a thing: are you making tests using new and old binaries for the (standard) server, for the client or both?
Regarding the versions thing, I was swapping the client binaries only.
The dpmaster is the same, and all the servers (run by other people) are the same in both cases.

Quote
OA v0.8.8 sends a "getServersExt openarena <keywords>" request to v6 master servers, but a "getServers <keywords>" request to v4 master servers (should be "getServers <gamename> <keywords>" as in ioquake3).
From what I can see, with 0.8.8 (i.e. since engine version 20) there are two problems:

1) when seeing a v4+v6 hostname, it only uses the v4 address and sends a getServers, NOT getServersExt query; obviously it gets v4 servers only as the result.

2) when seeing a v6-only hostname, it uses getServersExt, but for some reason gathers only IPv6-running servers from the result, not both v4 and v6 servers in the same list, as version 18 is capable of doing.


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: Gig on March 03, 2012, 06:59:38 PM
I'm not IPv6-compliant, so I cannot do any test.

Anyway, I'm quite curious to know what happens using a 0.8.8 client to search for a 0.8.8 server (both using 088 executables)... just a guess: maybe client and server may need to use the same version, that may contain a specific change...

PS: how many servers are managed by your IPv6 dpmaster? I suppose only those who manually set the secondary dpmaster...


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: grey matter on March 03, 2012, 07:12:51 PM
1) when seeing a v4+v6 hostname, it only uses the v4 address and sends a getServers, NOT getServersExt query; obviously it gets v4 servers only as the result.
That's a setup problem. When resolving a masterserver name, an IPv4 address is checked prior to a v6 one, unless you set net_enabled | NET_PRIOV6 (see ioq3/README).

2) when seeing a v6-only hostname, it uses getServersExt, but for some reason gathers only IPv6-running servers from the result, not both v4 and v6 servers in the same list, as version 18 is capable of doing.
getServers will only ever return v4. getServersExt does not return v4, unless you add the "ipv4" keyword. If you add "ipv6" it'll return those. If you don't supply any keyword or supply both, all addresses are returned.

OA 0.8.8 has the code swapped, it adds the "ipv6" keyword if the client has v4 enabled, causing the reply to only return v6 :)
If you want to hack dpmaster to partially work around this, you'd return v4&v6 for getServersExt if "ipv6" is supplied and only v6 if not (i.e. reversing logic, since OA does incorrect swapped requests).

I'm not IPv6-compliant, so I cannot do any test.
You could get a free 6to4 tunnel, e.g. at http://tunnelbroker.net/


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: sago007 on March 04, 2012, 09:38:36 AM
Anyway, I suppose we are in the hands of Sago
I am afraid I cannot do much in this regard. I have not done much engine side apart from checking an ioquake3 revision out, applying some patches and compiling them for Windows and Linux.

As the patches has stopped applying cleanly I have updated them in the cases that I was able to do it.
I have my limits especially then it comes to rendering patches. I am no longer able to checkout a newer ioquake3 version and apply the rendering patches.

The last ioquake3 version I could use was likely while ioquake3 added dpmaster-support and therefore the code is only halfway changed.


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: GrosBedo on March 04, 2012, 10:06:54 AM
@sago007: I think you'll then be relieved to learn that a contributor did successfully find a way to synchronize OA 0.8.5 with the latest ioquake3 branch, and it's still synchronized (in fact with this method, it will be forever). He should soon post more details by himself.

Anyway about this ipv6 problem, we could just patch the ipv6 keyword pointed by grey matter in the hotfix to at least quickly workaround this problem for now?


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: rm on March 04, 2012, 01:30:22 PM
1) when seeing a v4+v6 hostname, it only uses the v4 address and sends a getServers, NOT getServersExt query; obviously it gets v4 servers only as the result.
That's a setup problem. When resolving a masterserver name, an IPv4 address is checked prior to a v6 one, unless you set net_enabled | NET_PRIOV6 (see ioq3/README).
So how version 18 working properly, and version 20 not working properly, on the same machine, with the same configs, is 'a setup problem'?

net_enabled 3 in both cases.


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: GrosBedo on March 04, 2012, 02:54:57 PM
@rm: did you add " | NET_PRIOV6" ?


Title: Re: 0.8.8 worsened behavior with regard to IPv6
Post by: grey matter on March 04, 2012, 04:18:42 PM
@rm: did you add " | NET_PRIOV6" ?

I should have been a little more precise on this. It is meant to say "OR the value of NET_PRIOV6 into your net_enabled". You'd thus use a net_enabled setting of 7 (1 for ipv4 + 2 for ipv6 + 4 for priov6, see README).
This will make the client prefer ipv6 addresses over v4 ones in case a masterserver has both. You could also try using an [ipv6]:port for sv_master* directly, or use a DNS name which only has an AAAA record but no A one.

Even if you do so, OA will send wrong requests to the masterserver. It adds the "ipv6" keyword if ipv4 is enabled on the client, while it should only do so if v4 is disabled. If you thus remove 1 from net_enabled, you should get both v4 and v6 addresses as a reply from a v6 masterserver. This will obviously prevent you from playing on v4 servers.
You should be able to just use /net_restart instead of restarting OA as a whole.

Imho you should not try to fix any of this at the masterserver, rather wait for a new fixed OA build. Meanwhile you could test whether things work correctly with ioquake3 (you will at least have to +set com_gamename openarena +set com_legacyprotocol 71).