Get local IP address(es), World.LocalAddress

I am wondering if there is a way to obtain one's own local IP address(es) via scripting. (VBS in particular).

In the chat plugin, one can issue the "#info" alias and recieve a result similar to this:

One thing I would like to suggest is that an additional line be displayed, before the port line, which indicates the local IP. "Incoming connections IP: _____________"

I would likely then create a trigger to send that data to people who send me an approriate tell, such as "* tells you: chatinfo"

One way to achieve this might be to have Nick add a new function, perhaps called "LocalAddress", which returns the local IP address. The function could be smart enough to choose the local IP address which is being used to connect to the mud (in case the computer has multiple local addresses). Alternatively, return an array of all local IP addresses.

Shadowfyr found this page for me which explains one method, which uses Wscript.Shell to read the registry to obtain the answer, but we are unsure if the method would work under all Windoze platforms.

http://www.codeproject.com/vbscript/ipaddress.asp

An internal method is definitely needed. While Wscript.Shell could do it, the result is not much different than trying to capture the output from WinCfgIP or IPConfig, though I am not sure which would actually be more complicated.

Looking around the web, it seems most of the 'scam' pages that try to sell you security software to obscure your IP (like that wouldn't break TCP/IP) use built in function from browsers. One method returns what the browser 'thinks' is the IP, so stupid ones report 127.0.0.1 and localhost. The other method uses ISS to get the 'real' remote IP everyone else sees, but since both are browser extensions and not part of the scripting languages...

Suprised you overlooked the need to get this in a script Nick. ;)

Yes, well these things become more necessary as extra functions are added. Before chat, for instance, who cared what your IP address was?

I have added another selector to the world.GetInfo, which returns the host name. You can pass that to GetHostAddress to find the address list.

Ok... Sounds like a round about way of doing things. Why a list? On most non-server and non-networked machines you should end up with:

hostname: localhost (useless)
local IP: 127.0.0.1 (also useless)
Gateway IP/Remote IP: xxx.xxx.xxx.xxx <- this is the one you need.
Subnet IP: xxx.xxx.xxx.xxx (default 255.0.0.0 and completely useless for unless on a network and you where too stupid to assign a different IP for each machine)

I think you list ends up returning 'local IP' and 'Remote IP'. Local is always going to be 127.0.0.1, the remote IP is always going to be the one you want someone else to use, but apparently you can end up with a third IP due to redirection or some such and then you have a serious mess. There should be some way to identify which IP is which in a list and get the right one of them, especially if you are on a dial-up like AOheL where the IP changes each time you connect. This list doesn't make any sense to me...

If you're behind a NAT device of some variety, your computer really *can't* find out what IP the rest of the world sees it as--at least not without actually contacting an outside site. So if you were using it to try and let other people connect to your computer somehow... well, just fetching what IP the computer *thinks* it has wouldn't necessarily be effective.

Well.. I assume that with a NAT, you are probably not going to be on a dynamic IP, so someone, like your tech support for your connection should have some clue what it is. Besides, on a NAT, you probably aren't going to be the 'server' for a session anyway.

Go to the File menu -> Windows Socket Information.

The address(es) there are what you would see. On my PC it is only one, 10.0.0.3, because I am behind NAT.

Thus, I don't see 127.0.0.1 which is fine, however I agree with Neva that knowing 10.0.0.3 isn't much use either.

If there are more than one, probably one is the "obviously correct" one, it isn't too much trouble to select that from a list.

A *lot* of people using NAT have dynamic IPs. Very, very few of the cable and DSL companies will give out statics. It's rather irksome. :) At the same time, they often won't let you have more than one dynamic IP, or they want you to pay lots extra for more, so NAT devices like broadband routers are getting pretty heavy usage recently.

Bring on IP v6 eh? :)

Meanwhile, if you are behind NAT, and you don't have configuration of it, then knowing the address isn't much use. You would need to configure port forwarding at the NAT router.

Well, I have two listed under Winsocks. One is my dialup connection, which is the IP address I would like to fetch with MUSHclient, the other is my network card, which is a private address. I suppose I can do some custom scripting on my end to select the IP which does not start with 169.

Eh? What's this? I just went to bring up the Winsocks info a second time and MUSHclient has hung! It's frozen! :(

Ok, finally got control back. Looks like fetching the Winsocks info was a bit slow. I'm sure it's Windoze fault.

Anyway... I was going to suggest that the CHAT Plugin be updated to present the IP address of the user's computer, but in cases like mine, it may report the incorrect IP if it shows only one. I suppose it could just show all IP addresses on that line though, it would be better than nothing. So, that's my suggestion. Show all IP addresses on a line. (As I suggest in my first post).

Thanks for the hard work and implementing suggestions, Nick. :)

My experience with IP's is that the only way to actually accurately determine someones IP is to connect to somewhere on the outside world-- and grab the IP that you used from there.

I believe there is no way to determine which IP will be internet accessible until you make a connection.

So: Why not just have a global 'validated_ip' variable somewhere which is set to our ip after connection when this information is available to us?

Looking up IP addresses involves DNS - I warn on the functions page for GetHostName that this might be slow.



Hmm - the area of IP addresses, NAT, port forwarding and private IPs is quite muddy. Here is what happens, I believe.

First, because there is a shortage of IP addresses (the 4-byte IP address range is running out, partly because early allocations were very inefficient, in that some people got allocated large blocks of addresses that they don't necessarily use), a lot of places (schools, companies, ISPs) are now using NAT - Network Address Translation - where a local, or "private" IP address on their internal network is rewritten, by the router, as it is sent to the "real" Internet.

For example, John at School A might have address 10.0.0.3 (one of the private addresses which will never appear on the real Internet) and Mary at School B might also have the exact same address: 10.0.0.3.

To talk to the Internet they go through their routers, and the NAT part rewrites the packets, inserting their own (the router's) IP address, and changing the port number to one of the router's choosing. Then when the reply comes back, by inspecting the port number, and consulting an internal table, the (reply) packet can go back to the originating PC.

For instance, of School A's router was IP address 1.2.3.4 and School B's router was 5.6.7.8, then the packet flow would look like this:


10.0.0.3 -->(router) --> 1.2.3.4 --> (internet) --> 5.6.7.8 --> (router) --> 10.0.0.3


Now you can see that both PCs (John and Mary's) are set to IP address 10.0.0.3, and that is what any tools will tell them that their address is. However clearly John cannot set up a call (a chat call, say) to 10.0.0.3 because that would simply go to himself.

This is where "port forwarding" comes into it. The administrator for School B (router 5.6.7.8) might configure "port forwarding" - in fact s/he probably would if there was a web server on the internal network somewhere that was supposed to be accessible to the Internet.

How this works is that, if configured, you might send a call to 5.6.7.8 port 5000. The router would see that incoming call, and look at its internal rules. They might say, "incoming calls to port 5000 are to be forwarded to 10.0.0.3 port 4000". Then Mary would get the incoming call to port 4000 at her PC.

Say that had been done, Mary could look at the chat message and see that it had come from IP 1.2.3.4. However she could still not make a call back to 1.2.3.4 unless the router there was similarly configured to direct calls back to John's PC.

The upshot is, there is no easy way of knowing the address if you are behind NAT, and even if you find out (for instance, it might very well be your router address) that won't help you unless port forwarding is configured to send the packets on to you anyway. If you have gone to the trouble of doing that you probably already know the IP address and port, so you don't really need MUSHclient to find it for you automatically.

The simple solution is for everyone to call someone who is not behind NAT. eg. if Peter has a "real" IP address then both John and Mary can call Peter, however neither Peter nor John can call Mary, nor Peter nor Mary can call John.

Ack... Had to bring this subject back up again. The method you suggest using won't work for my machine at all (seems I have a dynamic IP and didn't realize). If I use this:

a = GetHostName ("127.0.0.1")
For Each ip In GetHostAddress (a)
Note ip
Next

It just gives me back only '127.0.0.1'. Ipconfig however returns:

Windows 98 IP Configuration

0 Ethernet adapter :

IP Address. . . . . . . . . : 66.185.229.92
Subnet Mask . . . . . . . . : 255.0.0.0
Default Gateway . . . . . . : 66.185.229.92

We really need something for convenience sake that can correctly return this information, since for 90% of us the normal method of getting our IP is patently worthless. :p I tried when this was first being discussed to find some clue as to how this is done, but didn't have much luck. :(

Hmm. Ok. I found the issue. Seems that you need the name of your sign-in account to get the right IP. This is fun, since half the people won't have a clue what that is (I didn't). lol

However, I did find what may be a more reliable way to retrieve this information, though I am not sure what it will do with multiple connections, networks, etc.:

http://skyscraper.fortunecity.com/gigo/311/winprog.html#ipconf

It however does return the correct host name, ip, etc. for your connection, which Mushclient only does if you know what to tell it what you actually want it to retrieve.

Looks complicated - I'll see about putting that in, in a future version.