ntpdaemon problem - Mandriva

This is a discussion on ntpdaemon problem - Mandriva ; On Mon, 19 May 2008 20:27:29 -0400, Bit Twister wrote: > When rndis0 broadcasted a dhcp request for a lease, > 169.254.2.1 responded with a lease. > 192.168.xxx.xxx will not travel past your ISP's gateway. Neither will 169.254.xxx.xxx They are ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 33 of 33

Thread: ntpdaemon problem

  1. Re: ntpdaemon problem

    On Mon, 19 May 2008 20:27:29 -0400, Bit Twister wrote:

    > When rndis0 broadcasted a dhcp request for a lease,
    > 169.254.2.1 responded with a lease.
    > 192.168.xxx.xxx will not travel past your ISP's gateway.


    Neither will 169.254.xxx.xxx They are both defined in RFC 3330.

    Regards, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  2. Re: ntpdaemon problem

    On Mon, 19 May 2008 21:05:18 -0400, David W. Hodgins wrote:
    > On Mon, 19 May 2008 20:27:29 -0400, Bit Twister wrote:
    >
    >> When rndis0 broadcasted a dhcp request for a lease,
    >> 169.254.2.1 responded with a lease.
    >> 192.168.xxx.xxx will not travel past your ISP's gateway.

    >
    > Neither will 169.254.xxx.xxx They are both defined in RFC 3330.


    Wonder how he got that lease from the 169.254.2.1 dhcp server.

    http://www.geobytes.com/IpLocator.htm?GetLocation


  3. Re: ntpdaemon problem

    On Mon, 19 May 2008 21:37:52 -0400, Bit Twister wrote:

    > Wonder how he got that lease from the 169.254.2.1 dhcp server.


    Most likely by syncing with a pda, that uses ethernet over usb with opensync.

    Regards, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  4. Re: ntpdaemon problem

    "David W. Hodgins" writes:

    >On Mon, 19 May 2008 19:25:00 -0400, Unruh wrote:


    >> RUnning hwclock at shutdown is a very bad thing since it destoys the rtc
    >> discipline of chrony.


    >hwclock can be used to set the system time from the bios clock, or to set
    >the bios clock, based on the system time. This problem is only about
    >recognizing the bios time is set to localtime, at startup. It does not
    >affect shutdown.


    Sure it does. If it sets the rtc to localtime on shutdown and utc on
    startup, you will get the symptoms that each time the system starts up the
    time is further out.



    >In a clean install of 2008.1, shutting the system down, rebooting and then
    >selecting 2008.0, or xp, the clock is correct. It's only on restarting 2008.1,
    >that it's ignoring the fact the bios clock is localtime.


    Yes, aparently. Where is the system clock being set?



    >Interestingly, the bios clock is still being set to the system clock, at shutdown,
    >just like in 2008. See /etc/rc.d/init.d/halt.


    >At shutdown, setting the bios time based on the system time, seems like a good
    >idea to me, especially if chrony or ntp is being used, so the next time the
    >computer is started, the bios time will be closer to correct. As chrony, or


    Absolutely terribe for chrony. fine for ntp. chrony remembers what the rtc
    was and what its rate was. If hwclock then changes the rtc, chrony's idea
    of what the rtc reads is way out.


    >ntp can only keep track of, and adjust the time while the system is up, to
    >correct for inaccuracies in the system clock, I don't see how saving the
    >more accurate time in the bios clock, at shutdown, causes any problem for
    >chrony, or ntp.


    chrony remembers what the rtc was-- how much its offset and rate error are.
    That memory is useless if the rtc is changed without chrony's knowledge.



    >> How does 2008.1 set the clock initially? There must be something in
    >> /etc/rc.sysinit that reads the rtc. It may not read the
    >> /etc/sysconfig/clock file to determine if the rtc is on localtime or not.


    >It doesn't. That's the whole problem.


    It must. Otherwise your system will show Jan 1 1970.



    >In 2008.0, rc.sysinit called hwclock to reset the system time, correcting for
    >localtime storage in the bios clock, if needed.


    It seems that it is not getting the message that it should be using
    localtime. That is the problem.



    >In 2008.1 it does not, since the system time set by the kernel is no longer being
    >corrected to account for localtime, every startup changes the clock by the offset
    >from utc.


    grep -r hwclock /etc/rc.d



    >Regards, Dave Hodgins


    >--
    >Change nomail.afraid.org to ody.ca to reply by email.
    >(nomail.afraid.org has been set up specifically for
    >use in usenet. Feel free to use it yourself.)


  5. Re: ntpdaemon problem

    On Mon, 19 May 2008 21:48:37 -0400, Unruh wrote:

    > Absolutely terribe for chrony. fine for ntp. chrony remembers what the rtc
    > was and what its rate was. If hwclock then changes the rtc, chrony's idea
    > of what the rtc reads is way out.


    As chrony, like ntp is keeping track of how fast/slow the system clock is,
    not the rtc aka bios clock, how can that info be of any use?

    > It must. Otherwise your system will show Jan 1 1970.


    I believe the system clock is set from the bios clock by the kernel, and
    it always assumes the bios clock is utc. Up to 2008.0, Mandriva used rc.sysint
    to correct this, if /etc/sysconfig/clock had UTC=false.

    > grep -r hwclock /etc/rc.d


    # grep -r hwclock /etc/rc.d
    /etc/rc.d/rc0.d/K00ntpd:sync_hwclock() {
    /etc/rc.d/rc0.d/K00ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    /etc/rc.d/rc0.d/K00ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    /etc/rc.d/rc0.d/S01halt:[ -x /sbin/hwclock ] && action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    /etc/rc.d/rc1.d/K00ntpd:sync_hwclock() {
    /etc/rc.d/rc1.d/K00ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    /etc/rc.d/rc1.d/K00ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    /etc/rc.d/rc2.d/K00ntpd:sync_hwclock() {
    /etc/rc.d/rc2.d/K00ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    /etc/rc.d/rc2.d/K00ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    /etc/rc.d/rc3.d/K00ntpd:sync_hwclock() {
    /etc/rc.d/rc3.d/K00ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    /etc/rc.d/rc3.d/K00ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    /etc/rc.d/rc4.d/K00ntpd:sync_hwclock() {
    /etc/rc.d/rc4.d/K00ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    /etc/rc.d/rc4.d/K00ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    /etc/rc.d/rc5.d/K00ntpd:sync_hwclock() {
    /etc/rc.d/rc5.d/K00ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    /etc/rc.d/rc5.d/K00ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    /etc/rc.d/rc6.d/S01reboot:[ -x /sbin/hwclock ] && action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    /etc/rc.d/rc6.d/K00ntpd:sync_hwclock() {
    /etc/rc.d/rc6.d/K00ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    /etc/rc.d/rc6.d/K00ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    /etc/rc.d/init.d/halt:[ -x /sbin/hwclock ] && action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    /etc/rc.d/init.d/ntpd:sync_hwclock() {
    /etc/rc.d/init.d/ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    /etc/rc.d/init.d/ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock

    Note that I do not run ntpd at startup, as I don't have a network connnection,
    till I run pppd, so the only reference to hwclock that are being run, are those
    in /etc/rc.d/init.d/halt and rc6.d/S01reboot.

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  6. Re: ntpdaemon problem

    "David W. Hodgins" writes:

    >On Mon, 19 May 2008 21:48:37 -0400, Unruh wrote:


    >> Absolutely terribe for chrony. fine for ntp. chrony remembers what the rtc
    >> was and what its rate was. If hwclock then changes the rtc, chrony's idea
    >> of what the rtc reads is way out.


    >As chrony, like ntp is keeping track of how fast/slow the system clock is,
    >not the rtc aka bios clock, how can that info be of any use?


    Since chrony, unlike ntp, DOES keep track of both the system clock and the
    rtc, that information is of use.



    >> It must. Otherwise your system will show Jan 1 1970.


    >I believe the system clock is set from the bios clock by the kernel, and
    >it always assumes the bios clock is utc. Up to 2008.0, Mandriva used rc.sysint
    >to correct this, if /etc/sysconfig/clock had UTC=false.


    >> grep -r hwclock /etc/rc.d


    ># grep -r hwclock /etc/rc.d
    >/etc/rc.d/rc0.d/K00ntpd:sync_hwclock() {
    >/etc/rc.d/rc0.d/K00ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    >/etc/rc.d/rc0.d/K00ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    >/etc/rc.d/rc0.d/S01halt:[ -x /sbin/hwclock ] && action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    >/etc/rc.d/rc1.d/K00ntpd:sync_hwclock() {
    >/etc/rc.d/rc1.d/K00ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    >/etc/rc.d/rc1.d/K00ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    >/etc/rc.d/rc2.d/K00ntpd:sync_hwclock() {
    >/etc/rc.d/rc2.d/K00ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    >/etc/rc.d/rc2.d/K00ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    >/etc/rc.d/rc3.d/K00ntpd:sync_hwclock() {
    >/etc/rc.d/rc3.d/K00ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    >/etc/rc.d/rc3.d/K00ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    >/etc/rc.d/rc4.d/K00ntpd:sync_hwclock() {
    >/etc/rc.d/rc4.d/K00ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    >/etc/rc.d/rc4.d/K00ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    >/etc/rc.d/rc5.d/K00ntpd:sync_hwclock() {
    >/etc/rc.d/rc5.d/K00ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    >/etc/rc.d/rc5.d/K00ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    >/etc/rc.d/rc6.d/S01reboot:[ -x /sbin/hwclock ] && action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    >/etc/rc.d/rc6.d/K00ntpd:sync_hwclock() {
    >/etc/rc.d/rc6.d/K00ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    >/etc/rc.d/rc6.d/K00ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock
    >/etc/rc.d/init.d/halt:[ -x /sbin/hwclock ] && action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    >/etc/rc.d/init.d/ntpd:sync_hwclock() {
    >/etc/rc.d/init.d/ntpd: action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS
    >/etc/rc.d/init.d/ntpd: [ "$SYNC_HWCLOCK" = "yes" ] && sync_hwclock


    >Note that I do not run ntpd at startup, as I don't have a network connnection,
    >till I run pppd, so the only reference to hwclock that are being run, are those
    >in /etc/rc.d/init.d/halt and rc6.d/S01reboot.


    >--
    >Change nomail.afraid.org to ody.ca to reply by email.
    >(nomail.afraid.org has been set up specifically for
    >use in usenet. Feel free to use it yourself.)


  7. Re: ntpdaemon problem

    On Tue, 20 May 2008 01:58:45 -0400, Unruh wrote:

    > Since chrony, unlike ntp, DOES keep track of both the system clock and the
    > rtc, that information is of use.


    Ok. Took a look at the faq, specifically
    http://chrony.sunsite.dk/faq.php#question_9.2
    " the important thing is to disable hwclock in the shutdown
    procedure."
    and
    "There is no need to remove hwclock from the boot process, as long as chronyd is
    started after it has run."

    So the fix I'm asking for, to call hwclock during the start of rc.sysinit,
    like 2008.0 did, does not affect chrony, while the calling of hwclock
    during shutdown, which currently exists in all Mandriva versions, I've
    seen, must be disabled, (and kept disabled after updates), by the user.

    It's not clear from the website. Can chrony be used on a system where
    the rtc is set to localtime?

    Regards, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  8. Re: ntpdaemon problem

    David W. Hodgins wrote:
    > On Mon, 19 May 2008 21:48:37 -0400, Unruh wrote:
    >
    >Did you at one point have a usb connection to an ethernet device?
    >harddrake2 would have detected that, and created the above script.


    Yes, silly me, I forgot a friend dropped in a couple of days ago
    and plugged in his new USB PDA to show me. This action must have
    created the rndis0 files.

    >Where did you get the idea that it's in Dallas?


    When I want to know what country is allocated a certain IP
    address, I go to:

    http://www.networldmap.com/TryIt.htm?GetLocation

    Both 169.254.2.2 and 169.254.2.1 show they are allocated to
    Dallas.

    >Do you use a pda with opensync? Apparently the pdas use ethernet
    >over usb (hence the usb ethernet device), to sync.


    This one time only as mentioned above. Great little device.

    >Wonder how he got that lease from the 169.254.2.1 dhcp server.


    My friend's PDA of course, never gave it a thought at the time,
    If anyone asked me, I would have said that my router would
    allocate an IP address for as long as it was plugged in.

    Thanks again to all who joined this thread, I now have a good
    understanding of how the clocks are synchronised and the
    workings of a PDA.

    LeoTheLion



  9. Re: ntpdaemon problem

    "David W. Hodgins" writes:



    >> Since chrony, unlike ntp, DOES keep track of both the system clock and the
    >> rtc, that information is of use.


    >Ok. Took a look at the faq, specifically
    >http://chrony.sunsite.dk/faq.php#question_9.2
    >" the important thing is to disable hwclock in the shutdown
    >procedure."
    >and
    >"There is no need to remove hwclock from the boot process, as long as chronyd is
    >started after it has run."


    >So the fix I'm asking for, to call hwclock during the start of rc.sysinit,
    >like 2008.0 did, does not affect chrony, while the calling of hwclock
    >during shutdown, which currently exists in all Mandriva versions, I've
    >seen, must be disabled, (and kept disabled after updates), by the user.


    Agreed. I was trying to think of a reason why Mandriva could have removed
    the call. My reason was not a good one.
    Where is hwclock called in the boot process and how is it called?

    grep -r hwclock /etc/rc.d
    should show everywhere it is called and then you can determine if that
    occurs during bootup and how it is called.


    >It's not clear from the website. Can chrony be used on a system where
    >the rtc is set to localtime?


    Sure. chrony will just record that the rtc is out by 7 hours and take that
    into account when it comes up next time.



    >Regards, Dave Hodgins


    >--
    >Change nomail.afraid.org to ody.ca to reply by email.
    >(nomail.afraid.org has been set up specifically for
    >use in usenet. Feel free to use it yourself.)


  10. Re: ntpdaemon problem

    LeoTheLion writes:

    >David W. Hodgins wrote:
    >> On Mon, 19 May 2008 21:48:37 -0400, Unruh wrote:
    >>
    >>Did you at one point have a usb connection to an ethernet device?
    >>harddrake2 would have detected that, and created the above script.


    >Yes, silly me, I forgot a friend dropped in a couple of days ago
    >and plugged in his new USB PDA to show me. This action must have
    >created the rndis0 files.


    >>Where did you get the idea that it's in Dallas?


    >When I want to know what country is allocated a certain IP
    >address, I go to:


    > http://www.networldmap.com/TryIt.htm?GetLocation


    >Both 169.254.2.2 and 169.254.2.1 show they are allocated to
    >Dallas.


    Just shows how much you can trust that database!





  11. Re: ntpdaemon problem

    On Tue, 20 May 2008 15:04:53 -0400, Unruh wrote:

    > Agreed. I was trying to think of a reason why Mandriva could have removed
    > the call. My reason was not a good one.


    I can't think of any reason either for removing it, or for being so slow
    at putting it back.

    > Where is hwclock called in the boot process and how is it called?
    > grep -r hwclock /etc/rc.d
    > should show everywhere it is called and then you can determine if that
    > occurs during bootup and how it is called.


    As per my prior post, where I posted the full output of the above grep
    command, the only places under /etc/rc.d that refer to hwclock are
    in the reboot, halt, and ntpd scripts. There is no reference in
    rc.sysinit, or any of the startup scripts.

    > Sure. chrony will just record that the rtc is out by 7 hours and take that
    > into account when it comes up next time.


    I think I'll remove ntp, and give it a try. I'll just have to figure out
    a way, to disable the shutdown calls to hwclock, and ensure the method
    either doesn't get undone by an update, or can be automatically redone,
    after an update.

    Regards, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  12. Re: ntpdaemon problem

    "David W. Hodgins" writes:

    >On Tue, 20 May 2008 15:04:53 -0400, Unruh wrote:


    >> Agreed. I was trying to think of a reason why Mandriva could have removed
    >> the call. My reason was not a good one.


    >I can't think of any reason either for removing it, or for being so slow
    >at putting it back.


    >> Where is hwclock called in the boot process and how is it called?
    >> grep -r hwclock /etc/rc.d
    >> should show everywhere it is called and then you can determine if that
    >> occurs during bootup and how it is called.


    >As per my prior post, where I posted the full output of the above grep
    >command, the only places under /etc/rc.d that refer to hwclock are
    >in the reboot, halt, and ntpd scripts. There is no reference in
    >rc.sysinit, or any of the startup scripts.


    >> Sure. chrony will just record that the rtc is out by 7 hours and take that
    >> into account when it comes up next time.


    >I think I'll remove ntp, and give it a try. I'll just have to figure out
    >a way, to disable the shutdown calls to hwclock, and ensure the method
    >either doesn't get undone by an update, or can be automatically redone,
    >after an update.


    I have a script I run after an update which contains

    ed /etc/rc.d/init.d/halt </dev/null 2>&1
    /Syncing hardware clock/s/^/#/
    wq
    EOF


    >Regards, Dave Hodgins


    >--
    >Change nomail.afraid.org to ody.ca to reply by email.
    >(nomail.afraid.org has been set up specifically for
    >use in usenet. Feel free to use it yourself.)


  13. Re: ntpdaemon problem

    On Tue, 20 May 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , LeoTheLion wrote:

    >David W. Hodgins wrote:


    >>Where did you get the idea that it's in Dallas?

    >
    >When I want to know what country is allocated a certain IP
    >address, I go to:
    >
    > http://www.networldmap.com/TryIt.htm?GetLocation
    >
    >Both 169.254.2.2 and 169.254.2.1 show they are allocated to
    >Dallas.


    Someone misunderstood that one big time. Well, let's start here:

    http://www.iana.org/assignments/ipv4-address-space

    where you find

    Prefix Designation Date Whois Status [1] Note

    169/8 Administered by ARIN 1993-05 whois.arin.net LEGACY [6]

    but that note 6 says

    [6] 169.254.0.0/16 reserved for Link Local [RFC3330]

    and if you were to look at RFC3330, you'd find

    169.254.0.0/16 - This is the "link local" block. It is allocated for
    communication between hosts on a single link. Hosts obtain these
    addresses by auto-configuration, such as when a DHCP server may not
    be found.

    and if you looked for Link Local, you'd be referred to RFC3927

    3927 Dynamic Configuration of IPv4 Link-Local Addresses. S. Cheshire,
    B. Aboba, E. Guttman. May 2005. (Format: TXT=83102 bytes) (Status:
    PROPOSED STANDARD)

    Briefly, when ANY computer running this security hole is booted and can't
    access a DHCP server, it reaches between it's legs and grabs a random IP
    address in the range 169.254.0.1 through 169.254.255.254. and then asks
    if anyone else ON THE LOCAL WIRE is using "this" address. If no one
    complains, it uses that. If someone else says "Hey, I'm using that
    address", this computer reaches back up there and grabs another random
    address. Apple developed this technique (called "Rendezvous" or
    "Bonjour") in 1997 for use when two sales-weasels meet in some airport
    and want to trade pr0n. Microsoft saw this a a perfect solution to the
    problem of users so screwing up the DHCP server configuration that even
    windoze wouldn't work. Rather than provide a warning message ("your DHCP
    configuration is screwed"), they adopted this in win98 so that the
    computers could talk locally (remember, microsoft didn't invent
    networking and doesn't understand beyond toy office connections).
    Section 2.7 of RFC3927 explicitly _requires_ that packets to/from
    169.254.0.0/16 must not be forwarded, so the local network is OK, and it
    must be the Internet that is b0rked.

    The more correct way to find locations via IP addresses is to use the
    whois service. Asking the whois server noted in the URL at the top of
    this reply, you get told

    [whois.arin.net]
    OrgName: Internet Assigned Numbers Authority
    OrgID: IANA
    Address: 4676 Admiralty Way, Suite 330
    City: Marina del Rey
    StateProv: CA
    PostalCode: 90292-6695
    Country: US

    NetRange: 169.254.0.0 - 169.254.255.255
    CIDR: 169.254.0.0/16
    NetName: LINKLOCAL
    NetHandle: NET-169-254-0-0-1
    Parent: NET-169-0-0-0-0
    NetType: IANA Special Use
    NameServer: BLACKHOLE-1.IANA.ORG
    NameServer: BLACKHOLE-2.IANA.ORG
    Comment: Please see RFC 3330 for additional information.
    RegDate: 1998-01-27
    Updated: 2002-10-14

    (which is almost identical to the information you get for 127.0.0.1.)
    but the huge problem with this is that this only tells where the
    _organization_ is located, not the actual computer. I'm located near
    Phoenix, Arizona (about 360 miles/600 KM East of Los Angeles) and
    if you were to look up the IP address of the computer I use at work,
    it's registered in New York, but if you traceroute to it, the last
    hop you see before the black hole of the firewall is a connection
    provider just South of San Francisco. But that means nothing because
    the next subnet above my address is in France, and the next one below
    is in Japan (we're a large company). The 'networldmap.com' thinks
    all three are in Boston. Most eye-candy tools put a lot of effort
    into drawing pictures without bothering to check the accuracy of the
    underlying data being displayed.

    Old guy

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2