On Sat, 26 Nov 2005, in the Usenet newsgroup comp.os.linux.networking, in
article <newscache$mrlkqi$7wi$(E-Mail Removed)>, Michael Badt wrote:
>I've several PCs connected to a 10.0.0.x LAN.
The routing table is a bit confusing - it says 10.x.x.x (mask 255.0.0.0)
rather than 10.0.0.x (mask 255.255.255.0).
>Although I get Internet connectivity, I can't get NTP sync from A Mandriva
>2006_64 PC with IP address 10.0.0.1.
Can't get sync from where? 10.0.0.3 <-> 10.0.0.1? Or from some host out on
the world trying to reach your 10.0.0.1 (as opposed to anyone else's 10.0.0.1)?
>I looked at the routing table of the ADSL router, and it looks quite
>complicated as follows:
Yes
>Destination Gateway Genmask Flags Metric Ref Use Iface
>192.114.82.152 127.0.0.1 255.255.255.255 UGH 0 0 0 lo
>192.114.46.164 127.0.0.1 255.255.255.255 UGH 0 0 0 lo
>192.117.100.169 127.0.0.1 255.255.255.255 UGH 0 0 0 lo
>192.117.119.209 127.0.0.1 255.255.255.255 UGH 0 0 0 lo
For some reason, the router is claiming that those four addresses are
actually another IP address for the router. This trick is often used to
block advertising, spyware, or other unwanted connections to/from those sites.
>192.114.47.251 192.117.119.209 255.255.255.255 UGH 0 0 0 ppp0
>192.114.47.251 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
OK - that seems to be the way to the world - normally, I wouldn't worry about
192.114.47.251 (which would be a remote host) because you say you need to
send the packets to 192.117.119.209... which is itself???, to reach
192.114.47.251.
>239.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 br0
239.0.0.0 is a Multicast block, although IANA has only allocated the upper
quarter (239.192.0.0 - 239.255.255.255) to Site-Local (RFC2365) stuff.
>10.0.0.0 10.0.0.138 255.0.0.0 UG 0 0 0 br0
>10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 br0
This looks like a windoze expert set up the routing. The last line says
that all of 10.0.0.0 - 10.255.255.255 is directly attached to the 'br0'
interface, but the line above it says to reach 10.0.0.0/8, you need to
send packets to 10.0.0.138 and that host will relay the packets to the
net. However, there is no indication how to reach 10.0.0.138 other than
directly, and that negates the reason for the last line. If you really
do have to send them to 10.0.0.138 and that is a remote host, the last
line should be replace with a host route
10.0.0.138 0.0.0.0 255.255.255.255 UH 0 0 0 br0
It would appear that the routing table could be simplified as follows:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.114.47.251 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 br0
127.0.0.0 0.0.0.0 255.0.0.0.0 U 0 0 0 lo
0.0.0.0 192.114.47.251 0.0.0.0 UG 0 0 0 ppp0
>Can thus be related to my problem?
There isn't enough details to identify your problem (other than a bizarre
routing table). Running tcpdump might provide clues. Running a traceroute
(or the b0rken windoze imitation "TRACERT") from that host you are trying
to connect to 10.0.0.1 would also help.
Old guy
|