View Full Version : LFS lan problem
KeMoT
8th April 2006, 17:31
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 :(
Krane
8th April 2006, 18:48
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...
KeMoT
8th April 2006, 19:53
You wrote <server IP> which server ? my lan main server or our team dedicated LFS server ?
maczo
8th April 2006, 20:03
You wrote <server IP> which server ? my lan main server or our team dedicated LFS server ?
I'd say the LFS server.
KeMoT
8th April 2006, 20:07
Thank you maczo :)
Telnet " thinks " a little bit and says it can't connect.
Tracert says something about maximum time reached...
Albieg
8th April 2006, 23:26
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.
KeMoT
9th April 2006, 07:04
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.
Albieg
9th April 2006, 12:05
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.
KeMoT
9th April 2006, 16:39
Thank you for your willing to help :)
I will write about progress if any.
KeMoT
10th April 2006, 22:31
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 ? :(
filur
10th April 2006, 22:46
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.
KeMoT
10th April 2006, 22:52
Don't ask me, I just say what my Administrator has said. :(
Albieg
11th April 2006, 10:36
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.
filur
11th April 2006, 10:57
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.
Becky Rose
11th April 2006, 11:15
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.
filur
11th April 2006, 11:20
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. :)
KeMoT
11th April 2006, 11:20
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
KeMoT
16th April 2006, 16:54
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.
kamo2000
17th April 2006, 23:05
anything new? any new ideas?
KeMoT
17th April 2006, 23:08
Filur says server is ok, ping ~70 ms.
I am lost of ideas :(
Becky Rose
17th April 2006, 23:15
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.
Becky Rose
17th April 2006, 23:19
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.
filur
17th April 2006, 23:28
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.
:confused:
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.
KeMoT
18th April 2006, 06:59
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 :(
filur
18th April 2006, 08:21
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 ?
KeMoT
18th April 2006, 08:23
Administrator has said that no ports are being blocked.
Becky Rose
18th April 2006, 09:28
The port might not be blocked, it might be in use by something else. The figures you suggest implies that the default LFS port is in use on your network, and changing the port number of the LFS server you want to connect too should resolve it. (remember that most LFS 'servers' share a machine with several other LFS servers and only 1 will be on the default port).
kamo2000
18th April 2006, 12:13
well i don;t know if i understand clearly, but i also started server on non standrad port and he still can;'t connect..everybody else can..i have public ip nothing blocked...no matter what we tried it failed...and the funniest thing is i can connect to him if he start his own server.
filur
18th April 2006, 12:21
well i don;t know if i understand clearly, but i also started server on non standrad port and he still can;'t connect..everybody else can..i have public ip nothing blocked...no matter what we tried it failed...and the funniest thing is i can connect to him if he start his own server.
Can he connect to you at all, if you start an ftp or webserver, file transfer on IRC, anything?
kamo2000
18th April 2006, 15:57
we didn;t tried any other connection..and we can't right now.
KeMoT
18th April 2006, 19:29
Kamo created FTP account for me, he used no-ip ( I think so ) and some software for creating such accounts.
Our teammates checked, FTP did work for them but for me it didn't - Total commander hangs up when receiving directory list.
Kamo gave me the log with how it looked like from his side, here it is:
21:01:19.078 [1248] Client connected from 83.18.0.6.
21:01:19.078 [1248] 220 Welcome to Quick 'n Easy FTP Server
21:01:19.125 [1248] USER wojtek
21:01:19.140 [1248] 331 Password required for wojtek
21:01:19.968 [1248] PASS
21:01:19.984 [1248] 230 User successfully logged in.
21:01:20.031 [1248] SYST
21:01:20.031 [1248] 215 UNIX emulated by Quick 'n Easy FTP Server.
21:01:20.078 [1248] FEAT
21:01:20.093 [1248] 211-Extensions supported SIZE MDTM XCRC 211 END
21:01:20.140 [1248] PWD
21:01:20.140 [1248] 257 "/" is current directory.
21:01:20.250 [1248] TYPE A
21:01:20.265 [1248] 200 Type set to ASCII
21:01:20.296 [1248] PORT 192,168,255,17,19,139
21:01:20.312 [1248] 200 Port command successful.
21:01:20.343 [1248] LIST
21:01:20.343 [1248] 150 Opening ASCII mode data connection for directory list.
21:01:30.375 [1248] 421 Failed to create data connection socket.
21:01:57.593 [1248] QUIT
21:01:57.609 [1248] 221 Bye
21:01:57.609 [1248] Client disconnected from 83.18.0.6.
I tried to connect several times - the same effect :(
I want to add:
1. Total commander is on unblocked list in XP SP2 firewall
2. I tried when firewall was deactivated - no any change
3. I use FTP a lot and it works fine ( Total commander too ).
I am affraid we are never going to find out what is causing this mess :(
NotAnIllusion
18th April 2006, 21:20
You could try PASV mode instead of PORT. :shrug:
KeMoT
18th April 2006, 22:18
You could try PASV mode instead of PORT. :shrug:
Kamo told me not to use PASSIVE mode so I did that, besides, with PASSIVE it is the same :(
NotAnIllusion
18th April 2006, 22:42
Tried a different client? Sometimes when I get a data connection error with both passive and active modes changing the client works. Probably something to do with how they handle the data connection, dunno.
noob4ever
18th April 2006, 23:12
hey
haha
use "loading" insted of "thinking" :)
Yaamboo
19th April 2006, 10:09
"Quick 'n Easy FTP Server is a multi threaded FTP server for Windows 98/NT/XP/2003 that can be easily setup even by inexperienced users."
http://www.pablosoftwaresolutions.com/html/quick__n_easy_ftp_server.html
:scratchch
http://www.pablosoftwaresolutions.com/forum/viewtopic.php?t=13
Tell your admin to look at this link.
vBulletin® v3.8.6, Copyright ©2000-2012, Jelsoft Enterprises Ltd.