Yes: write to /proc/sys/net/ipv4/ip_default_ttl
64 hops isn't enough? - Or too much? Range: 0-255 (0 is pretty
useless).
Yes: write to /proc/sys/net/ipv4/ip_default_ttl
The ADSL router - you mean as in one of those home router devices with
the NAT functionality? Someone else has addressed setting what linux
puts in the TTL, but you may need to make sure that the "router" in
doing NAT doesn't also re-write the IP TTL. Not sure that it would,
but it would be something to check.
rick jones
--
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
If it were to do that wouldn't it break stuff like traceroute?
--
Andy Ruddock
------------
andy_DOT_ruddock_AT_gmail_DOT_com (GPG Key ID 0x74F41E8F)
> If it were to do that wouldn't it break stuff like traceroute?
Frankly I wouldn't put much of _anything_ past a NAT but then I've
never really liked NATs, only grudgingly accepted them until such time
as my home ISP will start offering v6 :) Your point is valid though.
rick jones
seems that earthlink used to offer a v6 service to folks via a tunnel,
anyone not just earthlink customers, but I didn't learn about it until
recently and I think it's gone away... if it were still around I might
be tempted to flash my wrt54g.
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
I'm not sure this would be a useful method to try and detect the
presence of multiple machines behind a router.
If my ISP was so anal about it then I'd be switching ISPs at this point.
Worse trick I heard was to set the TTL to 0 (or 1 or 2, as appropriate)
on packets just before passing them to your modem. Just enough to get
to a PC, but a router/NAT box would drop them before passing them on to
a local network.
--
Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/~paulcol
Asking for technical help in newsgroups? Read this first:
http://catb.org/~esr/faqs/smart-questions.html#intro
Paul Colquhoun a écrit :
> <irb...@gmail.com> wrote:
> | Some ISPs look at the TTL (time to live) value to try to detect
> | routers. A Windows machine will use an initial TTL of 128. The
> | router will dec this by one, so if the ISP sees a TTL of 127, they
> | know to check the packet traffic for other evidence of an internal
> | network.
A workaround is to have the router normalize the TTL of outgoing
packets. On a Linux-based router, it can be done with the iptables 'TTL'
target (requires kernel 2.6.14 and above or with TTL patch from the
patch-o-matic). If you don't want to break utilities such as traceroute
which rely on TTL values, you can normalize only packets with an
original TTL above a value between 30 (default maximum number of hops in
traceroute) and the minimum initial TTL of the computers behind the router.
iptables -t mangle -A POSTROUTING -o $IF_WAN -m ttl --ttl-gt 36 \
-j TTL --ttl-set 64
> Worse trick I heard was to set the TTL to 0 (or 1 or 2, as appropriate)
> on packets just before passing them to your modem. Just enough to get
> to a PC, but a router/NAT box would drop them before passing them on to
> a local network.
Indeed that's nasty... Again, on a Linux-based router iptables comes in
handy to increase the TTL of incoming packets.
iptables -t mangle -A PREROUTING -i $IF_WAN -j TTL --ttl-inc 1
My PC is on Linux (CentOS 5.0). I suppose the above will work on my system?
Mangling the TTL of incoming packets is useful only on a router. If your
PC does not act as a router, it won't have any effect (other than
increasing the TTL of course) because the TTL is checked only in the
forwarding path.
>irb...@gmail.com wrote:
>> Some ISPs look at the TTL (time to live) value to try to detect
>> routers. A Windows machine will use an initial TTL of 128. The
>> router will dec this by one, so if the ISP sees a TTL of 127, they
>> know to check the packet traffic for other evidence of an internal
>> network.
Welll.... those ISPs must have a lot of cycles to burn. The TTL value
is an 8 bit value in the IP header (ninth octet). The initial value MAY
differ between TCP and UDP packets - and occasionally ICMP. A passive
fingerprinting tool I often use observes the differences in values in
the IP header to identify various operating systems, and the 262 such
fingerprints list five initial values:
TTL 32 60 64 128 255
number of prints 8 11 159 46 38
but these are all for TCP. Another tool I use notes a number of systems
using a TTL of 30 for UDP (with the same systems using 60 or 64 for
TCP).
RFC0791 (Internet Protocol) did not specify any value for this field.
RFC1122 (Requirements for Internet Hosts - Communication Layers) waves
hands a lot (see section 3.2.1.7) and directs the reader to the
"Assigned Numbers" RFC. RFC1060 (March 1990) recommended a value of 32,
increased in the next edition (RFC1340, July 1992) to 64, where it
remains (the "Assigned Numbers" series of documents have been replaced
by on-line databases - for IP Parameters, this is
http://www.iana.org/assignments/ip-parameters). However, this is a
_recommendation_ rather than a standard. You might also note that
most 'traceroute' type applications default to a maximum 30 hops.
>> Some ISP want to charge for every computer on the internal network.
>> Some of us think we are paying for bandwidth and the internal network
>> is none of the ISP's business.
The number of computers is only important if each one gets a separate
address from the ISP. If they're hiding behind a NAT or masquerading
box, the more important metric is bandwidth.
>I'm not sure this would be a useful method to try and detect the
>presence of multiple machines behind a router.
It's not very useful, and certainly not reliable. There are much
easier ways.
>If my ISP was so anal about it then I'd be switching ISPs at this point.
Most ISPs are more interested in whether you are using a server of most
any kind on your home (cheap) connection. If you are, you should be
paying more - obviously. ;-)
Old guy