Ben Beeson wrote:
Monmotha,
Thanks for the info.
Well, there's the imfamouns 10.x.x.x one, which I do believe is your cable
modem (which oddly enough, acts as a bridge, but still decrements the TTL
and sends back a time exceeded as if it were a router...)
You're probably right here, the 10.x.x.x IP address is the next one after the
linux router, but I'm now curious about the bridge thing. I thought bridges
were supposed to be transparent. Does this result imply that the cablemodem
is dual-homed on a single interface?
The impression I got was that it's just a misconfigured bridge :) Since it's
the first hop after your box, and you are using the actual upstream (here it's a
24.x.x.x address, the first IP in our subnet), you aren't actually sending
packets to the device at all, so it shouldn't respond with a TTL exceeded (and
shouldn't decrement TTL) as if it were a router (because you're not takling to
it as a rotuer, and in fact you are in the same IP subnet as the ISP's router).
I have no confirmation, but I gather this is the actual IP address the cable
modem provider uses for configuration of the device. Telnetting to it gives a
rather scary "don't use this" disclaimer, thoguh if you own your cable modem
(rather than lease it like I do), this MAY not apply (IANAL!). I haven't
checked, but I wouldn't be surprised if it speaks SNMP.
Other than
that, nothing I've found hasn't been visible from a simple traceroute.
Well, when I tracerouted the IPADDR, it doesn't get all the way to the
IPADDR I look for. But when I ping it, or telnet to it, I find the spot I'm
looking for -- it is there.
That's not uncommon. You're probably going through a firewall that either
blocks incoming UDP packets to really high ports (that's how traceroute works)
or blocks outbound TTL exceeded packets (which means the firewall is stupid).
--MonMotha
