Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ General ➜ Finding TCP/IP Addresses
Finding TCP/IP Addresses

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1 2  

Posted by Zach   (2 posts)  Bio
Date Sat 15 Mar 2008 03:35 AM (UTC)
Message
Greetings,

I realize this is probably a pretty simple question, but;

How do I find the TCP/IP of a MUD? I haven't played a MUD since the late 90s/early 2000s, at which time I played WoTMUD on Telnet. I've taken a recent interest in possibly playing Aardwolf, but cannot connect because I don't know the, 1) World Name, 2) TCP/IP address, 3)Port Number.

If you know those answers, I would love to know them. Also, if at all possible, could you explain how I would go about finding them without having to ask others?

Thanks much for your time,

Zach
Top
Posted by Zeno   USA  (2,871 posts)  Bio
Date Reply #1 on Sat 15 Mar 2008 03:47 AM (UTC)
Message
Go to Aardwolf.com and you'll find the info.
Quote:
If you already have a MUD client, you can connect to Aardwolf using aardmud.org (66.162.28.88) port 4000
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top
Posted by Zach   (2 posts)  Bio
Date Reply #2 on Sat 15 Mar 2008 03:52 AM (UTC)
Message
Thank you - I just connected using that information.

Also, I'd been to Aardwolf.com - where on that site is the TCP/IP information?
Top
Posted by Nick Gammon   Australia  (23,072 posts)  Bio   Forum Administrator
Date Reply #3 on Sat 15 Mar 2008 03:52 AM (UTC)
Message
Also, the MUD Connector web site lists IP addresses and ports for all known MUDs (the one listed anyway):

http://www.mudconnect.com/
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #4 on Sat 15 Mar 2008 03:56 AM (UTC)
Message
Typically you don't need the actual IP address; the host name is enough. When you see something like:

Quote:
you can connect to Aardwolf using aardmud.org (66.162.28.88) port 4000


It means that the address is aardmud.org (or, 66.162.28.88), with a port of 4000.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Zeno   USA  (2,871 posts)  Bio
Date Reply #5 on Sat 15 Mar 2008 03:59 AM (UTC)
Message
Quote:
where on that site is the TCP/IP information?

Right on the homepage in the middle. Third paragraph down.
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #6 on Sat 15 Mar 2008 07:53 PM (UTC)
Message
Umm. On a minor note. One way to find it is to open a command window (start->run), then type something like "ping aardmud.org". You could also use "tracert aardmud.org", but that gives you the TCP/IP address for your target, but also a complete trace of everything between you and that server.

---The rest is a bit technical and not relevant to how to get the address.---

Well, at least if you don't have a modem/router with the firewall set to block ICMP information.... Then neither will work at all.

Worse, due to the way SP2 for XP and Vista both try to prevent zombie DOS attacks from your computer, the tracert programs that use TCP/IP, instead of ICMP simply don't do anything at all. Why? Well, DOS attacks work by throwing thousands of tiny requests at a server, which don't contain any information. TCP/IP tracert/ping use hundreds of small packets, with no data in them, to create time outs, with each packet on a slightly longer delay than the last (same thing ICMP ping/tracert do, but that is allowed, never mind that ICMP is a bigger security threat on some badly designed hardware). XP SP2 and Vista both consider this the ***same thing*** as a DOS attack, since all they are doing is looking at how many packets are sent, and if the data in them **appears** to be missing, or identical. If you are a network administrator, trying to figure out why two machines on your network won't talk, but you opted, for other security reasons, to block ICMP , this is a critical *tool* to figure out what is wrong. Fracking Microsoft.. Can't even deploy anti-hacker security without screwing up legitimate software.
Top
Posted by Nick Gammon   Australia  (23,072 posts)  Bio   Forum Administrator
Date Reply #7 on Sat 15 Mar 2008 08:52 PM (UTC)
Message
Quote:

Can't even deploy anti-hacker security without screwing up legitimate software.


It is more or less axiomatic in security that increasing security decreases usability or convenience. For example, having 5 locks on your front door may possibly make the house more secure, but take longer to open.

We appear to be in a race with spammers and others who would like to "own" our PCs, that they continue to exploit loopholes - many initially created for the convenience of users.

As soon as one method is blocked, they turn their attention to another. For example, with spam, detecting certain words in spam has led to an increase in spam where the message is actually in a GIF file attached to the email, so it can't be scanned for text. Now you can always block messages with GIF files in them, but then next time your Auntie Flo tries to send you pictures of a recent picnic, they get blocked too.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #8 on Sat 15 Mar 2008 11:21 PM (UTC)
Message
IP traceroute (it doesn't use TCP) was a clever hack in the first place. It's not enshrined anywhere as a feature that Must Be Supported. ICMP traceroute was designed to overcome the many shortcomings of IP traceroute.

It is perfectly reasonable to block empty packets in many situations, especially if you get many of them in short succession. I'm not sure why you think it's so evil.

I'm also not sure why you think that ICMP is a bigger threat on some hardware. What do you think it would do? Old hardware that doesn't know about ICMP traceroute should just toss the packet like any other unrecognized packet.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #9 on Mon 17 Mar 2008 02:34 AM (UTC)
Message
Actually David, I suspect you have that backwards. TCP/IP trace was built "after" ICMP, as an alternative to get around people that blocked the former. And yes I ***mean*** TCP/IP, not IP. The two are completely different.

Look, the theory behind it is that, yes, ICMP works fine, but if its blocked, how do you get the same info? Well, TCP/IP (Again not **IP**), has packet time outs. So, you send out a packet request in TCP/IP, with some stupid time out. The router recieves it, checks the transit time, concludes that your timeout was too short, and sends back, again via TCP/IP, "Sorry, but your HTTP request timed out before I could deliver it." By doing that, they can produce "identical" results to ICMP.

Why not just use ICMP? Because some admins are morons. Yes, there are probably some bad implementations one some hardware, and some I think they have even found, but what kind of privilege escalation does that give you? Oh, know, they might be able to ask some computer on my network what its name is, or how its connected to the router? Whimper! That's just too scary! As far as I know even a borked version with a buffer overflow, or similar bug, can't escalate privilege above ICMP, so doing so is pretty damn useless as a hack.

This doesn't stop a) ISPs from setting their router/modem firewalls to block them for no damn reason, nor from some backbones doing the same stupid thing. Remember some years back we had some hickups in the backbone running from here to California on the way to NY, then Europe. Some twit set their router to block ICMP, so that when the network went a little wonky, the only way to find out if the server I wanted to get to was up at all was to just connect to it. Normally I would run a batch file, which would, every once in a while, run a tracert, so I could watch the network condition and see when there at least *should be* a connection again. Same with something like Ping. Its not uncommon for some services, if they lose a connection, to ping their remote host, until they get a response, rather than sending out larger packets to what might be an overburdened server, to reconnect. So, what happens to your service if some moron running a router sets it to block all ICMP packets, so that ping will **never** tell you that the route is open and a connection can be attempted again?

Point is, its gotten common enough in the paranoia of the last 5+ years that some people have decided to write TCP/IP tracers, which use HTTP type requests to find the information, since the ICMP won't bloody work any more.

What even the IP tracert you are talking about is/was, that isn't what I am talking about (or if it is, one of us has it wrong about *when* they came up with it). Oh, and there was a service you could install, prior to yet another patch from MS, called WinPCap, which did something to bypass the problem, so that the tracert would work again. What ever additional change they made, that won't work either any more.

Anyway. Point is that the patch they did to try to curtail this actually made it harder to *fix* potentially even more critical problems. Since the only way you can trace something is either via TCP/IP or ICMP, if the later is blocked, the former can and does generate information that is damn near worthless, in some configurations, to find the same information. Its like the difference between giving someone a GPS or a basic map, with all the names, street numbers, and even any indication if its the right city, removed. And all to prevent something that **didn't stop** after they patched it this way. lol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #10 on Mon 17 Mar 2008 02:55 AM (UTC)
Message
Well, hey, I'm just saying. The traceroute features of ICMP were not in the original spec. But don't believe me: go check out the RFCs yourself.

Here's the original ICMP RFC:
http://www.stanford.edu/class/cs244a/rfc/rfc792.txt
Note that there is no traceroute message in there.

Here is a description of the ICMP traceroute message. Note that it refers to the "new" traceroute using ICMP.
http://www.networksorcery.com/enp/protocol/icmp/msg30.htm


And unfortunately, no, traceroute does not work with TCP/IP. IP is a network-level protocol whereas ICMP is a transport layer protocol built on top of IP. ICMP is like TCP in that it is built on top of IP. But again, don't believe me: go check the specs yourself.
http://www.networksorcery.com/enp/topic/ipsuite.htm

Note that ICMP and TCP are both transport layer protocols built on top of IP. And note that the payload for each of those protocols is contained inside the IP packet.

The "TCP/IP" traceroute you describe is not implemented with TCP at all. You are however correct about its usage of successively increasing timeouts to figure out what routers a packet follows. But this is not done with TCP/IP: it is all done on the network layer using IP-level "time to live" header fields. In fact, if you think about this, it doesn't make any sense to do this with TCP, because the whole point of TCP is to provide a reliable transmission mechanism, not the unreliable mechanism that IP alone provides.

So like I said... nothing like some good ol'-fashioned fact checking before slamming network admins. ;-)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,072 posts)  Bio   Forum Administrator
Date Reply #11 on Mon 17 Mar 2008 04:48 AM (UTC)
Message
Is this relevant?

http://en.wikipedia.org/wiki/Tcptraceroute
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #12 on Mon 17 Mar 2008 05:01 AM (UTC)
Message
It is relevant but it's a separate program from traceroute. As the site notes, traceroute uses dummy packets like empty UDP or ICMP echo (aka ping) with increasing TTLs to "trace" a route to a host. This was at the time a clever usage of a feature that wasn't designed for this but there are several problems with this approach. For example, there is no guarantee that you're actually tracing a single route to a host; it could just be that different routes got the different TTL packets. Furthermore, it doesn't trace the return route. That is why the ICMP protocol was extended to include traceroute-like features (namely, pushing the route into the packet itself, instead of looking for which router rejected your ttl-expired packet).

tcptraceroute looks like it tries to address the firewall problem, but it's a rather different program from traceroute. traceroute itself doesn't use TCP.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #13 on Mon 17 Mar 2008 06:40 PM (UTC)
Message
**But**, "Tcptraceroute" the system I was talking about. That is I think where the confusion came from here. IP came first, then ICMP, then someone got the idea of tweaking Ping to produce tracert (it basically just ping with time to live set low, so you get a bounce), and some where in there TCP came in too. Recently though, a lot of people have been blocking ICMP in firewalls, and that screws tracert, so they came up with Tcptraceroute to try to get around it. Of course, soon after than MS got the genius idea that preventing you from sending out the packets it needs would prevent zombies from DOS attacking, or the like. It doesn't really, they just find ways around it, and now you can't use ICMP *or* TcpTraceroute. Well, unless you boot into Linux, where you have both options, and probably don't have to worry about the firewalls, on the machine at least. You might with the modem/router at your ISP, but Linux won't block TcpTraceroute, so you can still use that to do it.

BTW, MS' own firewall blocks, by default, ICMP packets coming "in" to the machine, but not out. So, you can trace problems to other servers on the net (useless if you are administering your own internal network and Windows is acting as a router some place in it), and only useful for nuts like me who like to ping/tracert servers when I can't get to them, just to see what broke on the internet.

In any case, the point is, there are issues with trying to a) determine why you can't connect to a mud (such as a router down some place) or b) finding the real IP (we had a problem on ours for a while where the DNS would fail every other day, due to something not updating right, so the only way to get there was with the direct IP), if you are running Windows, or your ISP is paranoid and blocked ICMP on their modem/router firewalls. The only thing more annoying though is that if you need to fix your neighbors computer, you can't tell the difference between a ICMP block *or* a disconnected modem. Both die at the modem with a message, "You can't get there from here." :(
Top
Posted by Nick Gammon   Australia  (23,072 posts)  Bio   Forum Administrator
Date Reply #14 on Mon 17 Mar 2008 07:49 PM (UTC)

Amended on Mon 17 Mar 2008 07:50 PM (UTC) by Nick Gammon

Message
David:
Quote:

For example, there is no guarantee that you're actually tracing a single route to a host; it could just be that different routes got the different TTL packets.


Won't that apply to ICMP packets too? From Wikipedia:

Wikipedia (Tracert):
Quote:

Traceroute works by increasing the "time-to-live" value of each successive batch of packets sent.


So each packet might take a different path.

Shadowfyr:
Quote:

... you can't tell the difference between a ICMP block *or* a disconnected modem ...


Well we have the people who amuse themselves thinking of Denial of Service attacks to thank for that. This is conceptually similar to email spam - it is getting harder to tell the difference between genuine mail and spam. This also wouldn't be a problem without spammers.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

70,308 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home