[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  Finding TCP/IP Addresses
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Finding TCP/IP Addresses
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please)
Maximum of 6000 characters. Text only please, no HTML.
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...


Subject review (reverse sequence)

Pages: 1 2  

Posted by Shadowfyr   USA  (1,776 posts)  [Biography] bio
Date Fri 21 Mar 2008 02:44 AM (UTC)  quote  ]
Message
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:

http://www.joelonsoftware.com/items/2008/03/17.html

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. ;)

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Thu 20 Mar 2008 04:51 AM (UTC)  quote  ]
Message
Maybe you should redesign the Internet and make it work better, then. :-) I'm sure it can't be all that difficult. . .

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Shadowfyr   USA  (1,776 posts)  [Biography] bio
Date Thu 20 Mar 2008 02:33 AM (UTC)  quote  ]

Amended on Thu 20 Mar 2008 02:42 AM (UTC) by Shadowfyr

Message
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."

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Tue 18 Mar 2008 11:10 PM (UTC)  quote  ]
Message
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. :-/

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Tue 18 Mar 2008 08:47 PM (UTC)  quote  ]
Message
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/

It is much easier to fight for one's ideals than to live up to them.
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Tue 18 Mar 2008 08:37 PM (UTC)  quote  ]
Message
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.

It is much easier to fight for one's ideals than to live up to them.
[Go to top] top

Posted by Shadowfyr   USA  (1,776 posts)  [Biography] bio
Date Tue 18 Mar 2008 07:56 PM (UTC)  quote  ]

Amended on Tue 18 Mar 2008 08:01 PM (UTC) by Shadowfyr

Message
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.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Tue 18 Mar 2008 12:35 AM (UTC)  quote  ]
Message
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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Tue 18 Mar 2008 12:09 AM (UTC)  quote  ]
Message
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.

It is much easier to fight for one's ideals than to live up to them.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Mon 17 Mar 2008 11:47 PM (UTC)  quote  ]
Message
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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Nick Gammon   Australia  (19,631 posts)  [Biography] bio   Forum Administrator
Date Mon 17 Mar 2008 07:49 PM (UTC)  quote  ]

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
[Go to top] top

Posted by Shadowfyr   USA  (1,776 posts)  [Biography] bio
Date Mon 17 Mar 2008 06:40 PM (UTC)  quote  ]
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." :(

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Mon 17 Mar 2008 05:01 AM (UTC)  quote  ]
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
[Go to top] top

Posted by Nick Gammon   Australia  (19,631 posts)  [Biography] bio   Forum Administrator
Date Mon 17 Mar 2008 04:48 AM (UTC)  quote  ]
Message
Is this relevant?

http://en.wikipedia.org/wiki/Tcptraceroute

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Mon 17 Mar 2008 02:55 AM (UTC)  quote  ]
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
[Go to top] 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.


12,064 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.   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Web site powered by FutureQuest.Net]