5/22 To people with TCP/IP clue: A friend of mine has a wireless router
at home (D-Link's DI-614+, but there doesn't seem to be much in
the way of useful model-specific docs around of any but the "here's
how you click a button" kind). The thing comes with a built-in
capability for firewalling, "virtual server" (i.e. port forwarding to
a specific LAN machine, set up by port number on the external
interface), etc. At the moment, we can't get traceroute (from local
machines to the outside world) to work whatsoever; it shows the first
hop to the router, and doesn't give anything past that. I've tried
allowing all ICMP&UDP traffic in both directions, but to no avail.
Presumably I don't understand the traceroute mechanism
well enough, and am missing something. Any suggestions?
\_ I had this problem with an SMC router. I have reported this to the
manufacturer. Later, they have come up with a firmware that fixed
this problem. Lots of those home broadband routers have very lousy
TCP/IP implementations, so the problems like this are expected to
pop up all the time.
\_ That's, err, good to know I suppose. I'll try that route,
thanks. -op (other advice still solicited though)
\_ Not an expert, but I believe traceroute is simply a series of pings
with a timeout short but increasing timeout-- so you ping http://yahoo.com,
and router1 responds but router2 does not because the timeout has
elapsed. For the second ping, you increase the timeout so router2
replies but not router3. And so on. Short answer is that your fw
is most likely preventing the ICMP echo from getting back to your
PC.
\_ you're right...you're not an expert.
\_ hello cranky asshole router guy!
\_ CARG does have a point, he indicated that ICMPs are
\_ CARG does have a point, op indicated that ICMPs are
allowed to pass through, which implies that he has more
clue than I thought he did. I just didn't read his post
all the way through and gave him the handwavy traceroute
explanation that wasn't very helpful. -- nae
\_ it's also inaccurate; traceroute is not a series
of pings. -CARG
\_ it is for some m$ implementations, i hear. -op
\_ timeout or ttl (time to live) based on number of hops
\_ That's just the micro$oft "tracert" implementation (or rather,
a distorted account thereof); most others use UDP. But in any
case, see below; this is probably not the problem. -op
\_ The default setting on the router is probably to filter ICMP
echos.
\_ Yes, but I'm fairly certain I put in a firewall rule to allow
all ICMP traffic in both directions. -op
\_ In the Advanced->Filters menu, try setting ICMP type 11 to always
oops, 8 _/
In the Advanced->Firewall menu, set to allow all ICMP types
\_ WHOOPS. Upon noticing the ICMP option missing in the "Filters"
dialog's "protocols" dropdown, I found out I'm several firmware
updates behind. However, the latest firmware update, even though
labelled "fixes traceroute issue" on D-Link's site, still
has no ICMP option there and traceroute is still not working. -op
\- hello has anyone seen the following "traceroute problem":
on a couple of solaris boxes, all of a sudden something
weird happens to the tcpstack and it never sends ICMP Port
UnRchables back to you? So any udp traffic is silently
absorbed if there is no application to fwd it to? ok tnx --psb
\_ Look for your answer on http://broadbandreports.com. |
http://csua.com/feed/