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?
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.
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.
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.
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
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. ;-)
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.
**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." :(
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.
If you were talking about tcptraceroute it would have helped to say so, and not talk about the traceroute program. :P It wasn't clear if you were talking about something else, or weren't quite correct about how traceroute worked.
Still, I wouldn't be so harsh on the network administrators or Microsoft for making the decisions they did. As Nick said, they are trying to plug holes. Yes, it's an endless battle, but if you never plug any holes, you're going to be even worse off than if you plugged what you can.
For instance I think it makes sense to block most incoming ICMP requests. For the vast majority of desktop computers, I don't see any reason to sit there responding to pings: it's just a vector for denial of service, and (again for the vast majority of desktops) you have no need to ping the machine anyhow. Very, very few people care about tracerouting into a desktop machine. Windows isn't really designed to be fixed over the network, especially from one LAN to another.
Quote: Won't that apply to ICMP packets too?
Indeed. The new ICMP method works by encoding the route in the message itself, so as it passes through routers they tack themselves on to the route; when it eventually gets discarded (or reaches the destination) it starts having the return route put onto the packet.
So indeed there is no guarantee that the different packets will all take the same route, but presumably the ICMP route information will indicate which route a given packet took.
Quote: 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
Eh, Hawaii was blocked off from a good chunk of the Blogoshpere for a bit when some knucklehead set a NAT table wrong in California. That issue happened with blocking TCP/IP, so that is not restricted to ICMP.
Quote: if you need to fix your neighbors computer, you can't tell the difference between a ICMP block *or* a disconnected modem.
Actually, the disconnected modem has one less LED glowing on the modem. :p And yes, that is an annoyance of a firewall, but firewalls are designed to block things, so I say job well done.
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.
Yeah, the Intarweb is broken. IP actually has no built-in mechanism for any computer to tell where any other computer is. That is what routing tables are for. If a backbone somewhere decides that it will send you to foo instead of bar from now on, that will be the new route. It's one of those things where you just send something out and hope it gets to the correct place.
Quote: If a backbone somewhere decides that it will send you to foo instead of bar from now on, that will be the new route. It's one of those things where you just send something out and hope it gets to the correct place.
In fact, that is exactly what happened about a month ago when a Pakistani ISP tried to block YouTube. :P They routed YouTube to a site they ran -- but they broadcasted the information to the whole world, not just their clients... and so, the whole world was trying to contact a Pakistani website thinking it was YouTube. As a result a huge chunk of the Pakistani network was shut down because it couldn't handle the huge volume, and because a higher-up ISP realized that they had to stop broadcasting the bad routing information until they could figure out how to filter it.
Stupid thing being that routing information was added to the spec later on, as businesses got involved, and concluded it was too inefficient to let the network find its own path via wide area broadcasts. The original design was intended to be bullet proof, so that if some key router failed, everything else found a way around. Fixing it to be more efficient actually broke its stability.
Oh, and actually David, I thought saying TCP/IP traceroute was clear enough. I hadn't realized that there was something called IP traceroute, so didn't realize it might be confusing. This is especially true since, despite the program in question being the most well known, there are several of them around.
Quote: was too inefficient to let the network find its own path via wide area broadcasts
Well... yes. Would you want to see the Time Warner traffic on the east coast of the U.S. use IP broadcasting every time someone brings up Google? Their backbones probably have that site at the top of the routing list. The only inefficency with the routing tables is that people did not make them dynamic enough. There should be some failsafe there that would request ping times occasionally to make sure that the next servers down the line are all responding. I highly doubt that 99% of the backbones would only have one way to get to any site.
Oh bugger, I forgot to reply to the original question on the forum. There are online whois and ping sites that will show IP addresses. This is usefull to use if you get a weird or inconclusive result on your desktop.
http://centralops.net/co/
Quote: Stupid thing being that routing information was added to the spec later on, as businesses got involved, and concluded it was too inefficient to let the network find its own path via wide area broadcasts.
I don't think we are talking about the same thing. I was talking about publishing prefix-to-IP mappings for the CIDR system, not a map of hops to follow.
I just get a little edgy when you label these decisions "stupid" and so forth because it's a very complex system and wasn't really designed for the current usage; networking in general is a remarkably complex beast. It's not exactly fair to labeling the people who work in it "stupid" just because it doesn't do exactly what you want it to do. :-/
Yes, we are talking about different things. I was **not** referring to your post about adding actual path data to the ping/tracert. As for stupid. Its not stupid to want to make the system more efficient, it ***is*** stupid how they, all too often, set up the systems that do that such that no alternate route is allowed, unless some massive delay happens, and *other* systems inform their routers that they can get there some other way. That is the key problem with the system as it stands. I have had 1-2 times where the direct path via Nevada failed, due to flooding, and I couldn't get to some place in California, *but* I could connect via the Pheonix network path to some place that was physically less than 50 miles away from the first one, also in California. That *is* stupid. And, to make it even dumber, nothing in that chain was smart enough to find an alternate path for anything at all that went via Nevada. I find this quite ridiculous. Its like if your own phone stopped being able to call your neighbors phone, due to someone a block away hitting a phone pole, yet, somehow, you could both call in to complain to the phone company about the problem. If you can both hit a central location, from both paths, not being able to get to anything on the other path is... incomprehensible, unless the reason is because someone has been busy hardwiring the pathing information into the system, in such a fashion that no alternates *can* be found. What term would you prefer I use to describe this overzealous optimizing? lol
EDIT- Normal problems resolve, even in bad cases, within minutes, or maybe hours. The case I ran into here lasted for two days. Literally half the country was cut off from me, despite the fact that half the places I *could* get to where in the same states, or even sometimes the same cities, as the ones I *couldn't*. Oh, and in one case, Northern California was lost to me, due to work being done in LA, for 3-4 months. One could get to Oregon, Washington, etc. from both me, and from there, or from those states to N. California, but not from me to there. I.e., a route "existed" which still linked the places I could get to, to the ones I couldn't, but the system was "optimized" in that collection of routers on both paths to *ignore* the solution, since key locations had, "If you are trying to get to IPs X through Y, always take path Q, never Z."
Well, then you run into the problem that MS is with IE8. lol Seriously though, someone is already doing that. One supposes they know the kinds of mistakes made in the existing implementation and have come up with ideas to address them.
Oh, and to be clear, I didn't mean the people that developed any of it where stupid. Too interested in pragmatic solutions to short term problems, instead of thinking of the long term impact, maybe. But a lot of people fall for that and not everyone can/does/has been taught to look for possible problems. I have a few times got in trouble for pointing out what I considered obvious possible problems in an implementation of something, including recently with some code, where the problem was real in an environment like Mushclient, but where the environment it ran in, in this case, parsed the data passing between the functions. I.e., the data was "changed" by the C++ between calls, so that the code did work, despite the fact that, not knowing that, there was no way in hell it should have. I look for possible problems, and try to think of what the solution might need to be to prevent disaster. A lot of coders, even experts, look only towards a) the deadline, b) compromises, and c) code that is functional when nothing goes wrong. I find this way of looking at code to be difficult to comprehend when anyone but myself has to rely on it.
I suppose, I am a standards person in that respect. For an interesting look at the mess you get when people set standards, but provide no way to test against them, so pragmatists get involved, then someone comes along and decides to enforce standards again, there is this article:
They would have been better off imho, rewriting the standard entirely, like they discussed with the new internet standards. I can understand both sides, to an extent, but if you can't provide something to test against, your own standard had bloody well better include a pragmatic approach in its design. ;)