I got big problem with my LFS

I am connected to a lan so I am behind router/firewall/nat.
When I start the game and go to online play, list of servers is refreshing about 5 minutes because out of almost 400 servers

about 160 is not reachable because games says there is no response from them.
Among them is our team server which is laso not on the list due to lack of response
I know this server is working because my team mates are racing on it.
I can't connect to it even by selecting " join specific game " - I write its exact name but I get only connect failed after

some seconds of " thinking "

When my team mate started a server on his connection and gave me its exact name - the same happened.
Also, when my team mates are online, I can find them by using command " find " in the waiting room but I can't see the servers where they are racing on


Today, my Administrator came to me and checked what is going on, after what he said:
No ports are blocked in our lan, firewall/router logs say nothing is being blocked, I even forwarded port 63392 directly to your computer - I don't know what else I could do for you.
This didn't solve my problem

I am using Windows XP HOME with service pack 2, I am not using any firewalls.
All I can do on my side is to turn off NOD32 ( anti virus software ) and XP SP 2 built in firewall on my lan connection - this seems to speed up checking the list of servers a little bit but nothing else.


Please, make the brainstorm and try to help me because I am out of ideas, my Admninistrator is willing to help but we don't know what to do and team mates are getting angry with it...

Help, please...


P.S. Sorry it this has been discussed but I tried to search and didn't find any similar problems,. besides I didn't know exactly what to look for

try this->

start -> run -> telnet <server ip> 63392

start -> run -> cmd -> tracert <server ip>

Can the telnet connect and tracert complete without any dead hops?


It might be possible that there's a router dead somewhere between you and the server...

You wrote <server IP> which server ? my lan main server or our team dedicated LFS server ?

Quote from KeMoT :

You wrote <server IP> which server ? my lan main server or our team dedicated LFS server ?

I'd say the LFS server.

Thank you maczo

Telnet " thinks " a little bit and says it can't connect.
Tracert says something about maximum time reached...

As far as I know it's not necessary that a server listens to port 63392.
1) Ask a teammate to join the server in windowed mode with a tcp connection diag program operating (as I stated in another thread, I think tcpview by sysinternals, a free and small download, is enough). A netstat -on from command prompt is enough too if you can relate process IDs to the LFS process. You can use Process Explorer or Task Manager to get LFS PID).
2) Ask your teammate to check the number of the remote port (not your computer's outgoing port) used by LFS after connection. In my experience the TCP and UDP ports of the server do not have to be 63392. The sequence should be this: first the master server is contacted, a list is retrieved from the master server, then LFS tries to connect to every server to gather info. If LFS can connect to the server the server appears on the list, otherwise it's generically added to the servers who did not reply since they are not clearly stated. So only servers you can really join are listed.
3) Once your teammate has succesfully joined the server and told you that info, try to telnet to that port.
An example of what your teammate should do:
Start LFS and press Shift+F4 to set it in windowed mode. Start Task Manager. Select the processes tab. Write down LFS PID (in my case, now, it's 932, but it depends on too many things to explain and all things considered it's not important to know them in this case. The PID is always different so your teammate will have to check). If the PID is not shown, use the menus to display it (view, select columns, or stuff like that).
Then the LFS server of your team must be joined. After joining the server, open a command prompt and issue a netstat -on (the o options lists the pid, the n option uses numeric addresses instead of DNS names. Find the correct PID (in my case 932) between the various lines that may appear. In my case the relevant line is:
TCP 11.22.33.44:1413 115.112.80.200:27770 ESTABLISHED 932
The IP addresses used here are fake. The line above tells me that Process ID 932 (LFS.exe) established a connection from TCP port 1413 of 11.22.33.44 (local computer) to port 27770 of the remote server having IP address 115.112.80.200. Not so incidentally, this is the port used by a server usually frequented by junkies... Your teammate should give you the second address complete with the port, which is the remote address of the server to which a connnection has been established. Then you (and not your teammate, but he could do it just to compare results) should try to telnet to that address from the command prompt. Obviously when you do this the server has to be on... In this example, the command would be telnet 115.112.80.200 27770 . If the command prompt clears (pressing enter after a few seconds will return you to the prompt), it means telnet is able to contact the remote server on the port used by LFS.
If telnet halts and then says you are unable to connect there is a huge chance that that port is filtered out somewhere in the route, maybe even on your computer. At that point you should try telnetting out of another computer in your lan. If you have no luck, the problem is not on your computer. If your sysadmin can read and understand all of this ranting he may well be able to help you.
If you are really interested in solving this problem you can try doing this on your computer with a server you can already join, so you know what kind of results you should have from telnet.
As stated by Krane, both telnet and tracert can be useful as diagnostic applications since they are readily available in every version of Windows. Tracert traces the route to the remote server, but it does it using the ICMP protocol, and some hosts or routers are programmed not to respond to ICMP protocol, but nevertheless if telnet fails, tracert could help you to identify the exact point in the route where the connection fails, and thus give you and your sysadmin more info about the possibility of solving this problem.
What if a telnet issued from your computer answers correctly ? Well, woah... an array of possibilities opens, at this point. I've written enough for now Try to understand and have your sysadmin near. It's very difficult to troubleshoot such problems in a forum, so you'll have to figure some things out by yourself, but if you have a basic understanding of the way these things work your chances to have a meaningful help - at least to identify the problem, which is the first step - will simply skyrocket.
Good luck,
Albie

Edit: please resist the temptation of posting real IP addresses in a public forum.

Thank you Albieg

I already contacted my Administrator, gave him the results of what I found yesterday with tracert and telnet and our team server's IP, he checked something and said something like that " IT looks like your team server doesn't allow connections from network using IP-Masquerade but I need to check something from within another network - I will be able to do it on monday "

He has also told me that our lan cannot work properly without this IP-Masquerade.

Some NAT problems, I see. Yes, your network couldn't work without IP Masquerade. That is the name used for a form of Network Address Translation, the system used to share a single public IP address (the IP of the router) from a private IP range (the IP range of the LAN). I could try a test setup if needed, it would be easy, but I'll wait to know if your network administrator manages to sort the problem out because I would need to know a lot more about the configuration and the hardware, both of the server and your LAN, and I wouldn't like that to appear here. In my opinion your network administrator telnetted out succesfully from the Linux box, so Monday, comparing the results with another network, hopefully he'll know what rules are needed to address the problem in your LAN, provided the problem could be solved there (and not server side). Let's wait and see. Again, good luck.

Thank you for your willing to help
I will write about progress if any.

Sorry for double post under post but I wanted it to be more visible.

Today my Administrator found out that our teamserver simply rejects any connections from any computer behind NAT and/or IP masquerade

What to do ?

That sounds really strange, the purpose of NAT is to solve the issue of multiple connection from a single IP, i can't see how your team server can even figure it out in order to reject a connection, never heard of any server or network service that rejects something based on the client using NAT.

Don't ask me, I just say what my Administrator has said.

The oddest part imho is the very high number of servers who do not reply: 160 servers are too many.
About NAT, filur is right. I started LFS on my laptop. The network environment is first natted by Shorewall on a Debian Sarge (in short, an ip masqueraded environment based on Linux and iptables) and then passes through another NAT (on a Netopia router). The rules used for those 2 nat/firewalls are fairly standard, Shorewall is configured to allow all outgoing traffic from the network zone to which I connected my laptop. Only 10 servers did not answer. I had the same result with a direct connection from my home (public ip address directly bound to my computer through a PPP connection via adsl modem, all incoming and outgoing traffic allowed from LFS.exe). As far as I can see there should be normally no particular problem with NAT, since NAT was designed to be transparent, so there should be a "knowledge" of the NAT only in the LAN where NAT is implemented, and not on the Internet.
The rationale is: if the admin is able to telnet out to a specific LFS Server port from the appliance offering NAT services and you're not able to do it on your computer there should be in this case a routing problem in your LAN. If the admin isn't able to do it there could be routing problems everywhere. To investigate further a serious packet analysis may be needed.
I'll do some more tests (with another Debian Sarge NAT passing through a Cisco Router, with no additional NAT in this case), when I can, but it may not be so soon.

Quote from KeMoT :

Don't ask me, I just say what my Administrator has said.

Perhaps if you post the name of that team server, we'd see that pretty much everyone behind NAT should be perfectly able to connect, and you could go ask your admin what he's talking about.

I'm very much behind NAT myself, just grabbed the entire server list and got 377 servers, 11 with no reply.

You should only have to worry about NAT if you are acting as a server, as a client there is no extra configuration.

The 160 no replies are interesting here. If you refresh the list a few times does this number vary? It could be an intermittant drop out problem - are you on wireless (if so, dont be! LFS is really jittery with wireless and it's quite unsafe for other people avoiding your lag-bouncing car for you to race on it).

It should work without any NAT entry at all for your IP on the router.

Disable all local software firewalls as they are affording you zero protection anyway, your router is protecting you from the outside world and your software firewalls are only protecting you from your work colleagues - and possibly preventing office networking functions such as file sharing and network printing etc.

Ask your admin to check the NAT entry, LFS requires both TCP *AND* UDP data on the appropriate port to be forwarded. The 160 no replies could be servers operating on different ports.

Although i've not tried multiple concurrent connections to the same server from behind my NAT (I only have 1 LFS license afterall) I see no reason why a single machine should not connect to LFS despite IP masquerading. There *could* be issues with some games not able to differentiate between two players on the router, but this isn't the case here.

It's more likely that the network port LFS is on is also running another service on your network, you could try asking your team to run their server on a different port.

Quote from Becky Rose :

Disable all local software firewalls as they are affording you zero protection anyway, your router is protecting you from the outside world and your software firewalls are only protecting you from your work colleagues

They're able to block outgoing unwantedness too.

I am not on wireless.
I do not host any server or dedi, I only try to join.
No, the amount of no reply servers is always about the same.
As I have said before - I use no software firewalls

filur, the server is for new polish LFS team but the team is not yet ready to go so I don't wanna say it's name.
I'll pm you about it.

anything new? any new ideas?

Filur says server is ok, ping ~70 ms.
I am lost of ideas

Have you tried asking your team to run the server on another port yet?

I think the 160 no replies is a port issue conflicting with a network service on your LAN.

It just occured to me also, You could try disabling DNS caching in your computer management services list - as this can cause intermittant network timeouts (again i'm thinking of the 160 no replies here). Especially true if you have a hosts file.

If you need detailed instructions to test this just ask, but basically you right click my computer, goto management, goto services and edit the properties of DNS Caching, set it to disabled and stop the service then try again.

I doubt it's the problem if you're not a hosts file user (in which case you'd probably know about it already), but in my opinion you're better off disabling it in 2000/XP anyway as it uses background CPU juice and makes no discernable different on broadband anyway.

Ask your administrator what he's on about, a server can't refuse your connection based on sniffing out that you're behind NAT. It's all pretty strange really, logically, you should be able to connect to (almost) everything, or if there's a network problem - nothing, not ~60% of servers.

Since there's no network config on behalf of an LFS server, and you can connect to certain servers, everything is basically working.



I've opened a server on a very non-standard port, see if you can connect to "NAT?", Blackwood RallyX/FO8.

Edit: @Becky, i really doubt the master server use anything other then pure IP's, there's really no reason to use hostnames.

Yes, I can see it even join it - no problem.
Ping is ~84ms

Today morning I had 377 servers and no response from 138 of them

So, you could join my server which was running on a nowhere-near standard random port, from behind NAT, with no configuration needed at your end.

138 servers makes no sense. Is your network actually blocking some ports ?