Pages: [1]
« previous next »
  Print  
Author Topic: Server not showing up in master list  (Read 22959 times)
mondo1287
Nub


Cakes 0
Posts: 22
« on: September 18, 2007, 05:59:52 AM »
EDIT: I wish I would have figured out this sooner, but to view all servers in the master list including unresponsive ones, http://dpmaster.deathmask.net/?game=openarena&sort=address&showall=yes

*Note the server is currently down, in case anyone tries to connect to it.  I did connect to it just fine from work this morning, but it never did show up in the master list.

I cannot get my server to show up in the master list.  The server is working fine, and is accessible from the internet.  It's being NAT'd, with the appropriate UDP port forwarded to it.

Startup command:
Quote
./ioq3ded.i386 +set dedicated 2 +set net_ip 10.25.10.20 +set net_port 27977 +set fs_game corkscrew +exec default.cfg +exec rails.cfg

rails.cfg
Quote
    sv_hostname "Corkscrew Server"
    sv_maxclients 16
    sv_master1 "dpmaster.deathmask.net"
    sv_maxPing 300
    sv_minPing 0
    sv_pure 1
    sv_maxRate 25000
    sv_fps 40
    sv_allowdownload 1
    set bot_nochat "1"
    sets "Arch" "i386"
    sets "CPU"  "i386"
    sets "OS"   "Linux"

    timelimit 15
    fraglimit 35



    g_motd "<message of the day>"
    g_quadfactor 4
    g_inactivity 0
    g_allowvote 1

    //Gametypes
    // 0 = Free For All
    // 1 = Tourney
    // 3 = Team Deathmatch
    // 4 = Capture The Flag
    g_gametype 0

    set d1 "map aggressor; set nextmap vstr d2"
    set d2 "map oa_dm1; set nextmap vstr d3"
    set d3 "map oa_dm2; set nextmap vstr d4"
    set d4 "map oa_dm3; set nextmap vstr d5"
    set d5 "map oa_dm4; set nextmap vstr d6"
    set d6 "map kaos2; set nextmap vstr d7"
    set d7 "map oa_dm5; set nextmap vstr d8"
    set d8 "map oa_rpg3dm2;set nextmap vstr d9"
    set d9 "map oa_shouse; set nextmap vstr d1"
    wait
    vstr d1 // start loop at d1
seta bot_enable "1"
seta bot_minplayers 4

default.cfg
Quote
eta g_railgunExplosions "1"
seta g_railgunBounces "0"
seta g_spawnProtection "2"
seta g_spawnProtectionNoFire "1"
seta g_scoring "0"
seta g_firerate "1"
seta g_allowQuad "1"
seta g_allowHaste "1"
seta g_allowInvis "1"

seta g_invis "0"
seta g_invisFire "0"
seta g_invisFlicker "1"

seta g_anticamp "0"
seta g_anticampTime "10"
seta g_anticampRadius "192"

seta g_headHunt "0"
seta g_headFromCorpse "0"

seta g_railgunDelayedFire "0"
seta g_railgunFireDelay "800"

seta g_worldDamage "0"
seta g_logCompatibilityMode "1"
seta g_sendStats "0"

Startup messages:
Quote
ioQ3 1.33+oa linux-i386 Jul  7 2007
----- FS_Startup -----
Current search path:
/home/openarena/.openarena/corkscrew
/home/openarena/openarena-0.70/corkscrew/CorkScrew_216.pk3 (102 files)
/home/openarena/openarena-0.70/corkscrew
/home/openarena/.openarena/baseoa
/home/openarena/openarena-0.70/baseoa/pak6-misc.pk3 (191 files)
/home/openarena/openarena-0.70/baseoa/pak5-TA.pk3 (11 files)
/home/openarena/openarena-0.70/baseoa/pak4-textures.pk3 (1496 files)
/home/openarena/openarena-0.70/baseoa/pak3-music.pk3 (9 files)
/home/openarena/openarena-0.70/baseoa/pak2-players.pk3 (620 files)
/home/openarena/openarena-0.70/baseoa/pak2-players-mature.pk3 (171 files)
/home/openarena/openarena-0.70/baseoa/pak1-maps.pk3 (73 files)
/home/openarena/openarena-0.70/baseoa/pak0.pk3 (926 files)
/home/openarena/openarena-0.70/baseoa

----------------------
3599 files in pk3 files
execing default.cfg
execing q3config.cfg
couldn't exec autoexec.cfg
Hunk_Clear: reset the hunk ok
--- Common Initialization Complete ---
Opening IP socket: 10.25.10.20:27977
Hostname: nemesis.mcore.local
IP: 10.25.10.20
Started tty console (use +set ttycon 0 to disable)
execing default.cfg
execing rails.cfg


The corkscrew mod shouldn't be the problem, as it still doesn't show up when launched without it.  The server address is 74.129.231.5:27977 if someone wants to try and connect to it.  It is sending heartbeats as well.  I've also tried deleting q3config.cfg multiple times.  rails.cfg and default.cfg are located in ~/.openarena/baseoa and the game files are in ~/openarena-0.70/
« Last Edit: September 20, 2007, 11:04:01 AM by mondo1287 » Logged
Ghost Dog
Guest
« Reply #1 on: September 18, 2007, 12:10:46 PM »
Hi,

In another Forum i have read, that net_Port must be 27960.
Logged
mondo1287
Nub


Cakes 0
Posts: 22
« Reply #2 on: September 18, 2007, 03:38:43 PM »
You can set it to any port you like, as long as it's properly forwarded by your firewall.
Logged
beast
Lesser Nub


Cakes 0
Posts: 142
« Reply #3 on: September 18, 2007, 03:42:33 PM »
Remove +set net_ip from the command line and see if that fixes the problem.
Logged
mondo1287
Nub


Cakes 0
Posts: 22
« Reply #4 on: September 18, 2007, 04:33:40 PM »
Quote from: beast on September 18, 2007, 03:42:33 PM
Remove +set net_ip from the command line and see if that fixes the problem.

No dice.  I'm currently trying to get it work on a Server 2003 box, still the same problem though.  Here's something interesting from my firewall logs.

Quote
09/18/2007 18:24:23.400   UDP packet dropped   Source: 71.183.184.61, 3771, WAN   Destination: 74.129.231.5, 8050, WAN   Port: 8050   14
09/18/2007 18:23:12.944   UDP packet dropped   Source: 69.138.182.128, 27960, WAN   Destination: 74.129.231.5, 8050, WAN   Port: 8050   14

I'm not sure what to make of that.  Those seem to be either the master server, or clients trying to connect.  Strange that they would be trying to connect to port 8050.  What would cause the master to server to think that it's running on a different port?  Does anyone know how the heartbeat works?

EDIT:

I've found what I was looking for:
http://www.forumplanet.com/planetquake/topic.asp?fid=5761&tid=1780880&p=1

I have an older, but rather high end enterprise grade Sonicwall firewall which I'm pretty sure is the problem.  It can handle 32000 concurrent connections, which means it will definitely modify outgoing udp packets so that it can keep each connection on a unique port.  So what is happening is that when my server sends a heartbeat on port 27977, the router changes the source port to a random port, i.e. 8050.  The problem is that the master server doesn't care about net_port, nor does it even receive any data about what the server configuration is, it only checks the source port of the heartbeat packet, and assumes that is the correct server port.  I setup a syslog server for the firewall, and it seems what I'm describing is true, the master server is trying to query my server repeatedly on the wrong port.  The quote I posted above with the dropped udp packets, is the master server querying the random port which had been closed, but looking at the syslog I can see the master server doing a query every minute.  The random port gets closed after about 5 minutes and then logs the dropped udp packet, but the master server soon receives another heartbeat telling it a new port.

In the above link, it looks as if a quake4 developer agreed to change the heartbeat packet to include the net_port setting and have the master server use that, and ignore the source port of the heartbeat packet.

I've submitted a post in the development section to discuss a possible change to the heartbeat code as described in the forumplanet link above.
http://openarena.ws/board/index.php?topic=1167.0
« Last Edit: September 18, 2007, 08:16:38 PM by mondo1287 » Logged
next_ghost
Half-Nub


Cakes 0
Posts: 76
« Reply #5 on: September 19, 2007, 04:58:43 AM »
Quote from: mondo1287 on September 18, 2007, 04:33:40 PM
Code:
09/18/2007 18:24:23.400	UDP packet dropped	Source: 71.183.184.61, 3771, WAN	Destination: 74.129.231.5, 8050, WAN	Port: 8050	14
09/18/2007 18:23:12.944	UDP packet dropped	Source: 69.138.182.128, 27960, WAN	Destination: 74.129.231.5, 8050, WAN	Port: 8050	14

I'm not sure what to make of that.  Those seem to be either the master server, or clients trying to connect.  Strange that they would be trying to connect to port 8050.  What would cause the master to server to think that it's running on a different port?  Does anyone know how the heartbeat works?

Master server at the moment resolves to 64.22.107.125 for me. Try capturing the initial server communication with Wireshark and see if there's outbound "heartbeat" (this text will appear in data section) packet followed by inbound "getinfo". If you don't get "getinfo" packet, your server won't be listed on the master server. If you do, you WILL get listed.

Quote
EDIT:
...

Unless your router is broken and doesn't handle NAT properly, it won't help and TTimo said that in the thread.
Logged
mondo1287
Nub


Cakes 0
Posts: 22
« Reply #6 on: September 19, 2007, 05:47:13 AM »
I think I may be getting listed, but for a very short period of time, and what I'm seeing are clients gathering their pings.  Note the server is running on port 15000 here.

Quote
Master Server (Webserver list) Ping
Sep 19 07:36:16 10.25.10.254 id=firewall sn=0040100F1C5D time="2007-09-19 07:35:56" fw=74.129.231.5 pri=6 c=262144 m=98 msg="Connection Opened" n=8986 src=64.22.107.122:54133:WAN dst=74.129.231.5:13029:LAN proto=udp/13029

Heartbeat
Sep 19 07:40:23 10.25.10.254 id=firewall sn=0040100F1C5D time="2007-09-19 07:40:03" fw=74.129.231.5 pri=6 c=1024 m=537 msg="Connection Closed" n=3965 src=10.25.10.1:15000:LAN dst=64.22.107.125:27950:WAN proto=udp/27950 sent=249 rcvd=50

Client Ping
Sep 19 07:41:34 10.25.10.254 id=firewall sn=0040100F1C5D time="2007-09-19 07:41:14" fw=74.129.231.5 pri=6 c=262144 m=98 msg="Connection Opened" n=9101 src=217.224.77.55:27960:WAN dst=74.129.231.5:13029:LAN proto=udp/13029


The master server does not use the same ip to verify the server, and the router will not do any translation for a different ip, as this would make sense for security reasons.  The router knows to translate incoming packets on the random port it chose to the real source port the server sent, but only for the original ip it sent it to.  I think maybe it's being listed until the master server tries to verify it, from another ip address.  I'll do some sniffing tonight, though, and see what I can find.  I'm probably going to need to do it on the wan and lan sides simultaneously to get a clear picture.

EDIT:

I just verified that it is being listed, but since no one can get a reply from it, it doesn't show up in the listing, and doesn't show up in the master server web list either, since the webserver is using a different ip to ping the server.  I used a local client, grabbed the master list several times, and checked the syslogs for my local ip.  Sure enough there it was, trying to connect to the outside address, on the wrong port. 

Quote
Sep 19 08:04:03 10.25.10.254 id=firewall sn=0040100F1C5D time="2007-09-19 08:03:44" fw=74.129.231.5 pri=6 c=262144 m=98 msg="Connection Opened" n=9743 src=10.25.10.62:27960:LAN dst=74.129.231.5:13081:LAN proto=udp/13081

So the server is definitely being listed, but the router isn't going to do any translation for any ip other than the ip it sent the heartbeat to.  There's nothing wrong with the router, the way the heartbeat works is just incompatible with how this router works.  I'm going to do some more testing with some other enterprise equipment at work and see if I get the same results.    I should probably put the server in the DMZ anyway, at least to see if the problem persists, but unless I NAT it in the DMZ, I'll have to pay for another public address, and NAT'ing it in the DMZ surely will produce the same results.

EDIT2:

Tested on a Sonicwall 4060, same results. 
« Last Edit: September 19, 2007, 08:05:33 AM by mondo1287 » Logged
mondo1287
Nub


Cakes 0
Posts: 22
« Reply #7 on: September 19, 2007, 05:22:37 PM »
I setup my own master server for futher verification.  I tested a local server to verify the master server was working properly, and then tested a remote server behind a Sonicwall 4060 firewall.  The 10.25.10.1 server is the local server which is running on port 15000, and it's being registered with the proper port.  The 1.1.1.1 server is the remote one (I changed the public ip address below to 1.1.1.1).  The remote server was running on port 35000, as you can see the master server saw its heartbeat coming from port 58913, and not the real source port of 35000. 

Quote
>
> New server added: 10.25.10.1:15000; 1 servers are currently registered
> Server 10.25.10.1:15000 updated its gamename: "" -> "Quake3Arena"
> New server added: 1.1.1.1:58913; 2 servers are currently registered
> Server 1.1.1.1:58913 updated its gamename: "" -> "Quake3Arena"

The firewalls I'm testing are actually PAT firewalls (http://en.wikipedia.org/wiki/Port_address_translation) firewalls, and this problem should show itself with any PAT device.
« Last Edit: September 19, 2007, 08:23:18 PM by mondo1287 » Logged
De@thByBl@st
Half-Nub


Cakes 0
Posts: 67
« Reply #8 on: September 20, 2007, 12:09:09 PM »
Personally, I've never really ran across anything running PAT at any level, not even in an ISP environment, nor do I see a need for it off the top of my head, but that's another story.

That being said, it may not be a completely bad ideal to have the heartbeat packet send the configured server port.
Logged
Pages: [1]
  Print  
« previous next »
 
Jump to: