Server does not show up in master list

[SerajewelKS]

Or at least I'm pretty sure it's not (checking at gametracker.com). I'm going to try to be terse with my description of my configuration. If something is unclear please ask for clarification.

My setup is modem (192.168.1.254) <--> (eth0:182.168.1.64) linux box (eth1:192.168.8.1) <--> switch <--> (182.168.8.10) srcds server

The Linux box is acting as my router. I have configured the necessary port forwards:

Code:

ravens:~# iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 355K packets, 34M bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:27015 to:192.168.8.10
    0     0 DNAT       udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           udp dpt:27005 to:192.168.8.10
   24  1251 DNAT       udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           udp dpt:27015 to:192.168.8.10
    0     0 DNAT       udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           udp dpt:27020 to:192.168.8.10
    0     0 DNAT       udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           udp dpt:26901 to:192.168.8.10

Chain POSTROUTING (policy ACCEPT 169K packets, 15M bytes)
pkts bytes target     prot opt in     out     source               destination
234K   19M MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 40728 packets, 3434K bytes)
pkts bytes target     prot opt in     out     source               destination

As you can see, the rule for UDP port 27015 is getting matched, so connections are coming in to the server successfully. Still, my game is not listed on the master list.

My server.cfg:

Code:

hostname "SKS experimental"
sv_password ""

rcon_password "***"
sv_rcon_banpenalty 5
sv_rcon_maxfailures 10

sv_lan 0
sv_region 0
sv_contact ***
sv_pausable 0
sv_pure 1
sv_allowupload 0
sv_allowdownload 0
sv_voiceenable 1
sv_alltalk 0

I note that if I do not specify +ip then the server listens on 127.0.1.1 (loopback) so I specify the internal address in my run script:

Code:

#!/bin/sh

./srcds_run -console -game tf -hostport 27015 +maxplayers 24 +map ctf_2fort +ip 192.168.8.10

Which usually outputs something like:

Code:

chris@tf2:~/steam/orangebox$ ./run.sh
Auto detecting CPU
Using AMD Optimised binary.
Server will auto-restart if there is a crash.

Console initialized.
Game.dll loaded for "Team Fortress"
Particles: Missing 'particles/error.pcf'
maxplayers set to 24
maxplayers set to 24
Unknown command "startupmenu"
Network: IP 192.168.8.10, mode MP, dedicated Yes, ports 27015 SV / 27005 CL
ConVarRef room_type doesn't point to an existing ConVar
exec: couldn't exec skill1.cfg
Executing dedicated server config file
--------------------------------------------------------
sv_pure set to 1.
Note: Changes to sv_pure take effect when the next map is loaded.
--------------------------------------------------------
exec: couldn't exec ctf_2fort.cfg
Adding master server 68.142.72.250:27011
Adding master server 69.28.151.162:27011
Connection to Steam servers successful.
   VAC secure mode is activated.

I can connect and play fine by using the private IP, and others can connect by specifying the external IP (or my hostname), but the server doesn't show up in the server list.

Checking on sv_lan gives:

Code:

sv_lan
"sv_lan" = "0"
- Server is a lan server ( no heartbeat, no authentication, no non-class C addresses )

Not sure if this is significant.

Ideas?

[css]

Nice setup.

I've got few suggestion which may cause the problem - all of which are educated guesses more than talk of experience.

Suggestion 1.

Do port forwarding from UDP port 27011 -> 192.168.8.10. That's because Steam master servers are in port 27011. But then again, the game server initializes the connection to master servers, so NAT should work there even without port forwarding. Anyways, the port forwarding shouldn't do any harm.

Here you see the master servers use port 27011.

Code:

Adding master server 68.142.72.250:27011
Adding master server 69.28.151.162:27011

Suggestion 2.

Use the external IP in +ip x.x.x.x. Otherwise when the game server contacts to the Steam master servers it might say that "I'm at 192.168.8.10". BUT the problem is that according to the master server protocol the game server does not specifically tell its IP to master servers. That's why it shouldn't matter what you have in the +ip parameter.

Here you can see the game server binds to 192.168.8.10 address.

Code:

Network: IP 192.168.8.10, mode MP, dedicated Yes, ports 27015 SV / 27005 CL

Suggestion 3.
Make sure the server isn't found from the master server list. Wait few minutes after you've started the server and then see if it's on the list. Also make sure that you can see it in favorites. Someone on this forum said that his friends can play on his server, but the server isn't visible in favorites or in steam master server list. Double check that your server isn't on the list.


General tips
You've got Linux box just in the right place. You can use the Linux box in cool way to dump all LAN <-> net traffic. Nothing slips by if you don't want it. You've got the control. The only funny thing is that the modem also has LAN IP, so does it do NAT too? Wicked.

You can try to use tcpdump to debug where all the packets are going and coming from. I've had similar setup that you've got. The modem had external IP and the Linux box was connected to modem and LAN switch. The biggest difference is that the Linux box was bridging the connection instead of NATing.


Probably the best tip
Find some NAT instructions from this forum or some other forum and follow that setup. You've got quite complex setup already, so I suggest you go through again some NAT setup instructions for srcds and verify your setup.

[SerajewelKS]

css Wrote:Do port forwarding from UDP port 27011 -> 192.168.8.10. That's because Steam master servers are in port 27011. But then again, the game server initializes the connection to master servers, so NAT should work there even without port forwarding. Anyways, the port forwarding shouldn't do any harm.

I'm not sure that this will do anything at all, but it did give me an idea. I grepped the firewall logs (I log every rejected TCP connection) for the master server IP addresses and saw nothing -- so there is no incoming TCP activity from the master servers. I will add a logging rule for rejected UDP connections as well and see if there is anything in the logs in a few hours.

css Wrote:Use the external IP in +ip x.x.x.x.

I have tried this before too, and it doesn't work either.

css Wrote:Make sure the server isn't found from the master server list. Wait few minutes after you've started the server and then see if it's on the list. Also make sure that you can see it in favorites. Someone on this forum said that his friends can play on his server, but the server isn't visible in favorites or in steam master server list. Double check that your server isn't on the list.

AFAIK it's not showing up in the master server list (hence this thread) but if I add it to favorites by the internal IP then it works. My modem does not appear to do hairpin NAT so adding it by the external IP from my LAN fails. However, one of my friends was able to connect after adding my server to his favorites by external IP. So game connections can get through just fine.

css Wrote:You've got Linux box just in the right place. You can use the Linux box in cool way to dump all LAN <-> net traffic. Nothing slips by if you don't want it. You've got the control.

That's why it's there. Using Linux on my desktop since ~'02 has taught me that there is no device I'd rather have doing my routing.

css Wrote:The only funny thing is that the modem also has LAN IP, so does it do NAT too? Wicked.

Yes, and it's not that uncommon. I could have DMZ'd my router box but there are some rather annoying complications that arise when my ISP decides to rotate my IP address. I'd rather keep all the ISP connection negotiation off my box, let the modem screw around with that.

css Wrote:You can try to use tcpdump to debug where all the packets are going and coming from. I've had similar setup that you've got. The modem had external IP and the Linux box was connected to modem and LAN switch. The biggest difference is that the Linux box was bridging the connection instead of NATing.

I was using tcpdump to debug at one point. For some reason it was unable to reach the master servers at all, or enable VAC. tcpdump helped me find the problem though -- I had forgot to specify the default route (AKA gateway) on the server box. :X

BTW, I didn't specify this in my configuration (because theoretically it doesn't matter) but the srcds server is in fact running in a virtual machine on my desktop. I have the VM bridged through the host to the rest of the network.

css Wrote:Find some NAT instructions from this forum or some other forum and follow that setup. You've got quite complex setup already, so I suggest you go through again some NAT setup instructions for srcds and verify your setup.

Already done this several times. I cannot find anything that I haven't tried before.

Thanks for the reply, hopefully we'll get to the bottom of this. (BTW the server has been running since last night. If you have the time, you could search for "SKS experimental" in your TF2 client to verify that it is actually not showing up.)

[extant1]

When you say you can't see it in the master list, can any of your friends or persons outside the network find it? I have heard somewhere that you can't see your own server listed for some reason. As to the source of this and if it's true, who knows, but it's worth a shot to test it out.

[SerajewelKS]

extant1 Wrote:When you say you can't see it in the master list, can any of your friends or persons outside the network find it? I have heard somewhere that you can't see your own server listed for some reason. As to the source of this and if it's true, who knows, but it's worth a shot to test it out.

I cannot see it in the master list if I check from the game, because my modem does not do hairpin NAT. (If your modem or router does then you will be able to see your own games, FYI.) But as I said I am checking at gametracker.com to see if it's listed, and a friend has told me that he cannot see my server when he searches in-game. This is the same friend who can connect to my server using my external IP address.


On a related note, I have done some analysis of my network traffic. I added some rules to my firewall to log traffic coming from the same network that the master servers are hosted on, but only traffic that does not match any forwarding rules (that is, traffic that the router box would just drop on the floor not knowing where it's supposed to go).

Every time that srcds sends out a master server ping I see eight packets match this rule. Example:

Code:

IN=eth0 OUT= SRC=68.142.64.165 DST=192.168.1.64 PROTO=UDP SPT=27017 DPT=58406

Now here are my observations:

• The source address is never either of the master servers, and changes each time. (All eight packets are the same source, but the next group of eight usually has a different one.)
• The destination port changes similarly, and is never the port srcds sends pings from. (This port is always 26901.)
• The source port is the same port that srcds sends the master server pings to.
  

The only thing I can figure is that it's testing network connectivity or something, but how can I be expected to forward such a packet to the right place when I have not seen the destination port before and it's coming from an IP address unrelated to a previous connection?

Is this even a connectivity test? WTF is going on?

[css]

SerajewelKS Wrote:The only thing I can figure is that it's testing network connectivity or something, but how can I be expected to forward such a packet to the right place when I have not seen the destination port before and it's coming from an IP address unrelated to a previous connection?

Is this even a connectivity test? WTF is going on?

Whoa. You've got it figured out well. Quite rarely people know what they're doing

The packet from master servers isn't connectivity testing. The master servers don't do connectivity testing. In the previous post I already posted link to the master server protocol, but here it is again: http://developer.valvesoftware.com/wiki/Master_Server_Query_Protocol#Game_server_to_master_server . More specifically the important part is this:

Quote:A "heartbeat" occurs every five minutes in order to let the master servers know that a game server is still "alive". The game server simply goes through the process of "joining" the master server list again.

It means the master servers are passive, and the game server must keep itself listed.

I think you lost your train of thought here:

Quote:... but only traffic that does not match any forwarding rules (that is, traffic that the router box would just drop on the floor not knowing where it's supposed to go) .... and what here?

I think the following might be result from some tricky NATing.

Code:

IN=eth0 OUT= SRC=68.142.64.165 DST=192.168.1.64 PROTO=UDP SPT=27017 DPT=58406

The packet has reached only the linux box at this point. It might be going to the Linux box to port XXXXX (58406), but when the Linux box sends it forward, it might NAT it back to port YYYYY (which was what your game server initially used and is expecting to get response to). I suspect this because the destination (DST) address is 192.168.1.64, which is your Linux box's address. The Linux box didn't send the packet initially, but that's how it looked when the modem received it, and that's why the modem sent the reply to 192.168.1.64 instead of 192.168.8.10. At this point the Linux box is receiving packet which it will keep on passing forward with NAT'd source address (instead of using its own 192.168.1.64 IP, it fakes the packet is coming from 68.142.64.165 and your game server is happily thinking it's connected to somwhere big ). Also at this point the Linux box most likely changes source and/or destination port number, so that's why the reply seems to come to previously unused port number.

You have to be extremely careful when interpreting the firewall rules in the Linux box. Be extra careful when you set rules to PREROUTING and POSTROUTING in the nat table. If you set firewall rules to the default filter table in the FORWARD chain, then I think the Linux box will show wrong destination IP in your case. It'll change the destination address when it does NATing. The real address and port will be seen in nat table's POSTROUTING chain. Hmm... actually it might be mangle table. In "man iptables" (man is your friend) it says that nat table is consulted when a packet that creates a new connection is encountered, but that's not interesting in this case, because the connection is already initialized by the game server so the packets from the master servers don't hit the nat table's rules. In the mangle table however the documentation doesn't say anything about only new connections, so apparently you'll see the "raw" pre-natted and post-natted packets in PREROUTING and POSTROUTING tables.

Last good tip
Check the Custom tab in TF2. Many of these "my server is not on the list" problems on TF2 are asked by admins who only look at the Internet tab. Click on the Custom tab and try to find your server there . Unfortunately I can't check if your server is on the list now.

[SerajewelKS]

css Wrote:Whoa. You've got it figured out well. Quite rarely people know what they're doing

Thanks, I like to consider myself someone with a clue. That's one of the reasons I'm so surprised that I'm having this hard of a time getting it working right.

css Wrote:I think you lost your train of thought here:

Quote:... but only traffic that does not match any forwarding rules (that is, traffic that the router box would just drop on the floor not knowing where it's supposed to go) .... and what here?

Not sure which train car you are referring to. Makes sense to me anyway. I was explaining that I added a rule to catch traffic coming back from the Valve networks that my router was going to discard because it didn't know where to send it.

css Wrote:I think the following might be result from some tricky NATing.

Code:

IN=eth0 OUT= SRC=68.142.64.165 DST=192.168.1.64 PROTO=UDP SPT=27017 DPT=58406

The packet has reached only the linux box at this point. It might be going to the Linux box to port XXXXX (58406), but when the Linux box sends it forward, it might NAT it back to port YYYYY

This is possible, I didn't think of that, but honestly I doubt this is the case. When I sniff on eth0 I see packets like:

Code:

16:14:30.473579 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 128) 192.168.1.64.26901 > 72.165.61.162.27017: UDP, length 100

So it seems to not be mapping the source port since this is the network interface on the other side of the MASQUERADE rule.

Anyway, I think what happened is I was restarting the server a few times to see what packets were being sent initially and it seems that those packets were probably the Valve servers trying to chat with the server instance now closed. Why the source port was so high is still a mystery to me.

css Wrote:Check the Custom tab in TF2. Many of these "my server is not on the list" problems on TF2 are asked by admins who only look at the Internet tab. Click on the Custom tab and try to find your server there . Unfortunately I can't check if your server is on the list now.

Thanks for the tip, but I can't check it myself. I'll ask a friend to try if I can catch one on tonight.

(I would expect gametracker to show custom games though, no?)

[css]

SerajewelKS Wrote:Why the source port was so high is still a mystery to me.

I don't have anything to the primary topic, I'll babble about the possible NAT scenario


The network setup

Code:

Modem                            Linux                           Game Server
1.2.3.4 : 192.168.1.254 <-> 192.168.1.64 : 192.168.8.1 <-> Switch <-> 192.168.8.10

Now, what happens when the Game Server (GS) sends following packet?

Code:

GS: 192.168.8.10:27015 -> 68.142.64.165:27011

First the packet is passed to the default gateway (through switch of course), which is the Linux box 192.168.8.1. No NATing yet.


Then Linux box processes the packet internally. Then it does NAT and passes the packet to Modem 192.168.1.254 from its own "external" 192.168.1.64 IP and randomly(?) selected port for NATing.

Code:

L: 192.168.1.64:38000 -> 68.142.64.165:27011

The destination address in the packet is 68.142.64.165:27011, but at this point the source address is NAT'd to 192.168.1.64.


Now, when the Modem receives the packet from the Linux box, it thinks the packet originated from the Linux box because the source address is already NAT'd to 192.168.1.64:38000. The Modem does NAT once more and sends the packet to the 'net from its external IP and randomly(?) selected port.

Code:

M: 1.2.3.4:40000 -> 68.142.64.165:27011

-- The packet reaches 68.142.64.165:27011 and the master server replies using a new randomly(!) selected port --

Code:

MS: 68.142.64.165:44000 -> 1.2.3.4:40000

Now, when the Modem receives packet from 68.142.64.165:44000, it knows the packet is related to the connection opened from Linux box at 192.168.1.64:38000. It NATs the source address and port to 68.142.64.165:44000 (or random port?) and passes the packet to Linux box 192.168.1.64 to port 38000. Note that Modem thinks the Linux box was the originating source of the packet!

Code:

M: 68.142.64.165:44000 -> 192.168.1.64:38000

Then Linux box processes the packet again internally to get it to the 192.168.8.0/24 network (or wtf happens here exactly?). Then it does NAT and sends the reply to Game Server from address 68.142.64.165:44000 (or random port?).

Code:

L: 68.142.64.165:44000 -> 192.168.8.10:27015

This should probably clarify why the Linux box might see some weird packets going to ports which were never opened by the Game Server. That's because the NATting changes the port number which is used. Especially if there were two or more servers in port 27015, the Linux or the modem couldn't use the same port for each connection. That's why they need to open new ports for the connections.

It's been a looong time since I've been doing NAT stuff, so this is educated guessing more than experience. But this is how NAT works, so in general terms this should explain something. Maybe some bystander even learns what NAT means.

[css]

I don't know how gametracker works. If you have Linux box out there somewhere you can try using http://qstat.org/ to see if it's reachable.

The command is "qstat -a2s 1.2.3.4:27015" and it'll query the server.

Qstat results don't guarantee master server visibility, but at least it's easier to test thing out than calling a friend and keep asking "does it work yet"

[SerajewelKS]

css Wrote:I don't know how gametracker works. If you have Linux box out there somewhere you can try using http://qstat.org/ to see if it's reachable.

The command is "qstat -a2s 1.2.3.4:27015" and it'll query the server.

Qstat results don't guarantee master server visibility, but at least it's easier to test thing out than calling a friend and keep asking "does it work yet"

Code:

chris@layla:~$ quakestat -a2s 99.172.137.34:27015
ADDRESS           PLAYERS      MAP   RESPONSE TIME    NAME
99.172.137.34:27015    0/24 ctf_2fort     35 / 0  tf SKS experimental

I tested to see exactly how the probing is done by refreshing the server list while looking for outgoing packets to the server. Every time I refreshed the custom list I would see something like:

Code:

ravens:~# tcpdump -nli eth1 'host 99.172.137.34'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
18:32:08.883352 IP 192.168.8.168.2012 > 99.172.137.34.49175: UDP, length 25
18:32:09.134170 IP 192.168.8.168.2012 > 99.172.137.34.49176: UDP, length 25
18:32:09.347807 IP 192.168.8.168.2012 > 99.172.137.34.49727: UDP, length 25
18:32:09.552973 IP 192.168.8.168.2012 > 99.172.137.34.49726: UDP, length 25
18:32:09.779716 IP 192.168.8.168.2012 > 99.172.137.34.49741: UDP, length 25

So apparently Valve's method of checking server availability is to send a UDP packet on a different port. Brilliant.

I discovered that my modem does in fact do hairpin NAT, so I can connect to my server using its external address. But apparently ICMP gets lost somewhere and the client never sees any replies to the above five packets and presumably concludes that the server is down. I tried adding in some firewall rules to catch these packets on their way out to the modem and return "connection refused" as would have happened had it hit the router or server VM. Even though the rules matched I still did not see the server in the list.

Can I just say that Valve has managed to produce one incredibly #$%&ing bass-ackwards PoS server mechanism?

[css]

SerajewelKS Wrote:I tested to see exactly how the probing is done by refreshing the server list while looking for outgoing packets to the server. Every time I refreshed the custom list I would see something like:

Code:

ravens:~# tcpdump -nli eth1 'host 99.172.137.34'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
18:32:08.883352 IP 192.168.8.168.2012 > 99.172.137.34.49175: UDP, length 25
18:32:09.134170 IP 192.168.8.168.2012 > 99.172.137.34.49176: UDP, length 25
18:32:09.347807 IP 192.168.8.168.2012 > 99.172.137.34.49727: UDP, length 25
18:32:09.552973 IP 192.168.8.168.2012 > 99.172.137.34.49726: UDP, length 25
18:32:09.779716 IP 192.168.8.168.2012 > 99.172.137.34.49741: UDP, length 25

So apparently Valve's method of checking server availability is to send a UDP packet on a different port. Brilliant.

I don't get it. What packets are these? Where are they coming and where they are going? They're probably something that the Game Server (or Game Client, you?) sent using the external 99.172.137.34 IP, and it used the random 49xxx port where it's expecting the reply.

Valve's master server's do not do active server checking. The game server "joins" the master servers every five minutes. In the process the game server receives "challenge" code from master servers, but the connection is always initiated by the game server.

Quote:Can I just say that Valve has managed to produce one incredibly #$%&ing bass-ackwards PoS server mechanism?

No.

[SerajewelKS]

css Wrote:

SerajewelKS Wrote:I tested to see exactly how the probing is done by refreshing the server list while looking for outgoing packets to the server. Every time I refreshed the custom list I would see something like:

Code:

ravens:~# tcpdump -nli eth1 'host 99.172.137.34'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
18:32:08.883352 IP 192.168.8.168.2012 > 99.172.137.34.49175: UDP, length 25
18:32:09.134170 IP 192.168.8.168.2012 > 99.172.137.34.49176: UDP, length 25
18:32:09.347807 IP 192.168.8.168.2012 > 99.172.137.34.49727: UDP, length 25
18:32:09.552973 IP 192.168.8.168.2012 > 99.172.137.34.49726: UDP, length 25
18:32:09.779716 IP 192.168.8.168.2012 > 99.172.137.34.49741: UDP, length 25

So apparently Valve's method of checking server availability is to send a UDP packet on a different port. Brilliant.

I don't get it. What packets are these? Where are they coming and where they are going? They're probably something that the Game Server (or Game Client, you?) sent using the external 99.172.137.34 IP, and it used the random 49xxx port where it's expecting the reply.

They are coming from my instance of the TF2 client to my external IP (that is, the IP that Valve's master server reports my server on) when I hit the refresh button on the custom tab. This seems to indicate that the master server is in fact delivering my server to clients (on the custom tab anyway). These are the only packets sent to my external address. In other words, I can assume that other TF2 clients are doing this as well, and in fact when my TF2 server is running I see a very large spike in UDP traffic to ports 49152-65535. All of the traffic comes from IP addresses five at a time as in the above example. My question is simply: is this traffic expected to reach the box hosting the server? What happens if the clients don't get any reply to these packets? Currently my firewall is set to reject unauthorized packets instead of drop them so I'd expect clients to be getting "connection refused" responses from my server.

I'm not sure exactly what other response they could be expecting though. The srcds client is not listening on anything >= 49152. So it looks to me that the method clients use to test server availability is to send five UDP packets to ports on the server that are not guaranteed to be open, nor are guaranteed to trigger any sort of response. This seems incredibly stupid.

Alternate interpretations of the data are welcome, but I sure can't come up with any.

css Wrote:Valve's master server's do not do active server checking.

I never claimed they did.

css Wrote:

Quote:Can I just say that Valve has managed to produce one incredibly #$%&ing bass-ackwards PoS server mechanism?

No.

You are welcome to that opinion. Honestly my data gathering has suggested to me that the source server system does some very odd and unorthodox things that break easily, and for some reason when there are plenty of better alternative ways to accomplish the same thing that are actually established network practices.

[css]

SerajewelKS Wrote:Alternate interpretations of the data are welcome, but I sure can't come up with any.

Provide more data from your network so it's easier to understand what's happening. My guess is that you are seeing NAT'd data, which doesn't have the same port as it had when the data was sent out. The data size (25 bytes) suggests it's the TF2 client's "A2S_INFO" packet, which is exactly 25 bytes long ("ÿÿÿÿTSource Engine Query"). These data packets should be going to port 27015. I don't have good explanation why they're destined to >= 49175 ports.

SerajewelKS Wrote:So it looks to me that the method clients use to test server availability is to send five UDP packets to ports on the server that are not guaranteed to be open, nor are guaranteed to trigger any sort of response. This seems incredibly stupid.

This is incredibly stupid. Valve isn't doing this. You must realize this yourself too, but you are finding the easy explanation for the packets you are seeing in the network.

Try to track the flow of packets from your TF2 client to the Modem and then back to the TF2 server when you are refreshing favorites (add your external server IP to favorites). You should see if the packets go through the Linux and Modem NAT properly and how they reach the server. Obviously you should also see the TF2 server in your TF2 client favorites list too. If the packets don't get through, then you don't see the server.

[SerajewelKS]

css Wrote:Provide more data from your network so it's easier to understand what's happening. My guess is that you are seeing NAT'd data, which doesn't have the same port as it had when the data was sent out.

I am sniffing on the LAN side of the router box, before NAT happens. And this does not explain why other clients are also sending data to these 49152+ ports, which I see when sniffing on the Internet side of the router. So it's not just my client being bizarre, other clients are using this exact same method. I am seeing zero traffic to the router on port 27015 unless I initiate a connection to the server myself.

Note that I am not 100% certain that this is the clients probing the server, but seeing as this is the only traffic generated by my client and destined for my external IP, it seems likely that this is what it's doing.

css Wrote:The data size (25 bytes) suggests it's the TF2 client's "A2S_INFO" packet, which is exactly 25 bytes long ("ÿÿÿÿTSource Engine Query"). These data packets should be going to port 27015. I don't have good explanation why they're destined to >= 49175 ports.

Me either. Especially why it's sending to five different ports at once.

css Wrote:This is incredibly stupid. Valve isn't doing this. You must realize this yourself too, but you are finding the easy explanation for the packets you are seeing in the network.

I'm not looking for an easy explanation, I am looking for any explanation.

css Wrote:Try to track the flow of packets from your TF2 client to the Modem and then back to the TF2 server when you are refreshing favorites (add your external server IP to favorites). You should see if the packets go through the Linux and Modem NAT properly and how they reach the server. Obviously you should also see the TF2 server in your TF2 client favorites list too. If the packets don't get through, then you don't see the server.

The packets don't reach the TF2 server because they shouldn't reach the server -- they are rejected by the router box, and rightly so. Packets going to a port the server isn't listening on will die when they hit the server anyway, there is no getting around that. (Unless srcds is talking directly to the interface via its /dev node there is no way it would see these packets. And lsof says it's not.)

[SerajewelKS]

While I'm thinking about it, I might sniff for packets going to or coming from someone else's working server and see what happens when refreshing the client's server list in that case. I just realized I have all this data about a setup that is not working and no data about setups that do work.