Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

A port scanner to help identify network and connectivity issues

Felix Duesenburg
Taken over by Aliens
Join date: 14 Aug 2006
Posts: 30
02-15-2007 06:02
Struggling with an annoying issue which prevents me from teleporting or crossing region borders - /263/2f/163703/1.html - has led me to come up with the following idea which should be quite easy to implement:

A port scanner, e.g. NMAP - http://insecure.org/nmap/ - or a similar tool, could be installed on a Linden server. The SL client could get a feature, callable from the help menu, that would have the port scanner check the relevant connection parameters and create a report if there are problems. This would help identify network and connectivity issues and quite likely relief Linden employees from a substantial number of support requests.

I am currently trying to find out what's happening with my network, but the trouble is, NMAP would have to be installed somewhere outside i.o. to find out if I'm blocked somehow. But if I install it on a remote web server or company server I may have access to, they are likely to be protected in some way too that interferes with the result. Therefore it would be ideal to have this on the SL site directly. So far, identifying network issues is, for anybody who is not an expert in this field, like fishing in muddy water.

Cheers :)
Lex Neva
wears dorky glasses
Join date: 27 Nov 2004
Posts: 1,361
02-15-2007 09:41
Simply running an nmap scan can often be considered a hostile action. For that reason alone, LL probably wouldn't want to expose that kind of functionality on their servers. Then there's the possibility that a malicious person could somehow convicne the LL NMAP functionality to scan someone ELSE through some kind of forged packet, in essence causing LL to do their dirty work for them. All in all a bad idea.

I also don't think it'd help you. NMAP would detect open ports, sure, but as far as I understand it, the servers never initiate a connection to clients, which is why SL works on a majority of network setups, even behind firewall/router appliances that use NAT (network address translation). I don't think that an NMAP scan would give you any useful information.

A properly functioning NAT setup should allow SL to work just fine. All connections to the server are initiated from the client, so the NAT device should be able to see this and create the proper connection. What might be tripping you up is the fact that SL uses UDP... that can be slightly more difficult to handle in a router device.
Felix Duesenburg
Taken over by Aliens
Join date: 14 Aug 2006
Posts: 30
Rename to: Network Diagnosis Tool
02-15-2007 13:39
You may be right... could open a can of worms if nmap were installed "naked" and accessible without a properly designed wrapper script. This is especially dangerous since the client source is open. It was merely an example. However, my knowlegde about this subject is patchy at best.

Let's put it another way: "Some kind of tool" accessible from the help menu of the SL client, that would serve to diagnose any kind of network issues and pinpoint exactly what needs to be done in case it's not running as it should. It could use heuristics to step through the most likely scenarios, or frequent errors. As pointed out in the other thread referenced above, my problem hasn't been fixed yet with the standard set of instructions, but I don't even know for certain whether the owner of this router knows what he's talking about. With a diagnosis tool this could be found out in a minute.

I really believe it would be worth the effort, as it would help reducing the workload for LL support.
Lex Neva
wears dorky glasses
Join date: 27 Nov 2004
Posts: 1,361
02-16-2007 09:27
Well, that's an interesting idea. I guess it would take the form of a mode in the client (or a standalone program) that would attempt to open a connection to an LL server on the various ports that SL uses, to see which connection opens successfully. That already brings up a question, though, what about false negatives? Say LL's network connection is down, or their test server fails. That might result in a false negative. I guess what I'm saying is that it's far from easy to design the heuristics, and if the program gives false information, then it hurts more than it helps.

Out of curiosity, what problems are you having, and what have you tried to fix them?