• Frustrated that I don't UNDERSTAND why my network times out

    From billy@110:110/2002 to All on Tue Oct 8 03:32:15 2013
    Why can't I connect (via port 80 or any port) to a certain web site?

    For more than a year I've had the same problem, and, it's NOT
    the way I'm running traceroute! (e.g., it's not ICMP vs TCP, etc.).
    It's also not that the server I'm pinging is down, or slow.

    There's something wrong with "my" home networking setup.
    But what?

    I just want to UNDERSTAND the problem. That's it.
    It makes NO sense what I've been seeing over the past year.

    Basically, for months at a time, I can't connect to centos.org
    and, for months at a time, I can connect to the web site.

    When I can't connect, traceroute (ICMP or TCP) fails to connect;
    when I can connect, traceroute also connects.

    So, it isn't HOW I'm running traceroute, as traceroute is telling
    me exactly what Firefox is telling me.

    This happens for months at a time, and has happened about five
    times in the past two years.

    I change NOTHING (not my router firewall, not my computer firewall,
    not my networking setup, etc.) in the interim.

    When this happens, I switch to TOR, and I can EASILY connect to
    centos.org via the proxy Firefox - so there's nothing wrong with
    my firewall or with my home broadband router (as far as I can tell).

    When I can't connect, I ask my NEIGHBORS who "can" get to centos.org
    to show me their traceroute, and it looks the same as mine except
    for the fact that their times are slightly faster and they get
    past that last hop - whereas mine dies at the penultimate hop.

    So, THAT would implicate something on "my" side (but what?).

    I switch to Knoppix 7, and I get the same result.
    I go to a Windows PC, and I get the same result.
    So, it's NOT the PC!

    If I knew how to get around my router, I would, but it has
    all the setup for the ISP (it's a WISP, not cable or DSL).

    My question?

    How can I debug WHY (for months at a time), I can't get to a web site?

    Here's a traceroute run just now:
    knoppix@Microknoppix:~$ traceroute www.centos.org
    traceroute to www.centos.org (72.232.194.162), 30 hops max, 60 byte
    packets
    1 192.168.1.1 (192.168.1.1) 2.835 ms 2.809 ms 20.293 ms
    2 REDACTED_WISP.net (xxx.xxx.xxx.xxx) 20.280 ms 20.265 ms 20.248
    ms
    3 10.50.0.1 (10.50.0.1) 29.973 ms 29.959 ms 29.943 ms
    4 10.25.0.1 (10.25.0.1) 39.067 ms 42.759 ms 42.745 ms
    5 10.20.0.1 (10.20.0.1) 82.295 ms 82.280 ms 82.265 ms
    6 10.0.0.1 (10.0.0.1) 122.956 ms 159.675 ms 159.654 ms
    7 69.36.226.193 (69.36.226.193) 198.537 ms 201.445 ms 201.433 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 201.423 ms 201.412 ms
    201.388 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 201.377 ms 201.361
    ms 201.346 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 239.215 ms 239.185 ms 239.171 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 239.137 ms 239.122
    ms 239.061 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 239.030 ms 123.544 ms
    178.276 ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 178.261 ms 178.264 ms 178.231 ms
    14 border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 178.234 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 178.187 ms border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 178.199 ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 178.171 ms
    178.139 ms 178.123 ms
    16 * * *
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *

    I know, from two years of experiencing this, that the hop after the
    last hop showing resuls "is" Centos.org! So, when it works, it gets to
    the last hop; but when it dies, it always dies at just before the last
    hop. But why?

    Can you help me UNDERSTAND why/how this situation can be happening?
    Note: All other web sites work just fine.

    NOTE: I already know that YOU will be able to access this same site
    with much lower ping times (you're not on a WISP either) - but that
    doesn't help ME figure out what the problem is.

    Is there freeware extant to help me UNDERSTAND why this happens to me?

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From Gary R. Schmidt@1:0/0 to All on Tue Oct 8 04:37:04 2013
    On 8/10/2013 2:32 PM, billy wrote:
    Why can't I connect (via port 80 or any port) to a certain web site?
    [SNIP]

    There is no freeware, or any sort of software available to you, that can
    help with your problem.

    There is a "black hole" between you and centos.org.

    Packets go in, but do not come out, that's what the traceroute is
    telling you.

    Contact your ISP, and provide them with the traceroute, they then need
    to pass that to their (various) upstream connections to get the problem solved.

    I would assume that the problem lies with "pnap.net", who- or what-ever
    they are, but they probably won't talk to you.

    Your WISP appears to be connecting to "layer42" (69.36.226.193) as their gateway to the internet, again, they won't talk to you, but your ISP
    should be able to get them off their arses.

    Cheers,
    Gary B-)

    --
    When men talk to their friends, they insult each other.
    They don't really mean it.
    When women talk to their friends, they compliment each other.
    They don't mean it either.

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From David Hough@110:110/2002 to All on Tue Oct 8 06:30:22 2013
    billy wrote:

    Why can't I connect (via port 80 or any port) to a certain web site?

    For more than a year I've had the same problem, and, it's NOT
    the way I'm running traceroute! (e.g., it's not ICMP vs TCP, etc.).
    It's also not that the server I'm pinging is down, or slow.

    There's something wrong with "my" home networking setup.
    But what?

    Is it an MTU/fragmentation issue? (Check out ping -M)

    Dave


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: the bus stop (110:110/2002@linuxnet)
  • From Chris Davies@110:110/2002 to All on Tue Oct 8 18:32:42 2013
    Reply-To: chris@roaima.co.uk

    In comp.os.linux.networking David Hough <noone$$@llondel.org> wrote:
    billy wrote:
    Why can't I connect (via port 80 or any port) to a certain web site?

    Is it an MTU/fragmentation issue? (Check out ping -M)

    This is exactly what I would have suggested. Data packets have a maximum
    size dependent on the transport layer carrying them. The default size is typically 1500 for ethernet, and a little less for connections running
    over PPP and/or VPN. Some long distance WAN links can have even lower
    maximum packet sizes. If a packet cannot be transmitted in its entirety,
    it can be split (fragmented) unless the sender has specified that it
    must not be split. If it can't be split then the sender is responsible
    for transmitted the data in smaller sized packets, but obviously the
    sender needs to be informed that the packet size must be reduced. If
    there's a dubious firewall somewhere between you and the target -
    one that (incorrectly) eats the ICMP fragmentation request packets -
    then your sender can't realise that it needs to reduce the packet size,
    and such packets inevitably get dropped.

    You can test this with ping -M, as David Hough has suggested. You can
    also reduce your own MTU and see whether this "fixes" the problem. Try "ifconfig eth0 mtu 1400", and experiment with different values.

    Chris

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Roaima. Harrogate, North Yorkshire, UK (110:110/2002@linuxnet)
  • From Tauno Voipio@110:110/2002 to All on Tue Oct 8 20:16:05 2013
    On 8.10.13 9:32 , Chris Davies wrote:
    In comp.os.linux.networking David Hough <noone$$@llondel.org> wrote:
    billy wrote:
    Why can't I connect (via port 80 or any port) to a certain web site?

    Is it an MTU/fragmentation issue? (Check out ping -M)

    This is exactly what I would have suggested. Data packets have a maximum
    size dependent on the transport layer carrying them. The default size is typically 1500 for ethernet, and a little less for connections running
    over PPP and/or VPN. Some long distance WAN links can have even lower
    maximum packet sizes. If a packet cannot be transmitted in its entirety,
    it can be split (fragmented) unless the sender has specified that it
    must not be split. If it can't be split then the sender is responsible
    for transmitted the data in smaller sized packets, but obviously the
    sender needs to be informed that the packet size must be reduced. If
    there's a dubious firewall somewhere between you and the target -
    one that (incorrectly) eats the ICMP fragmentation request packets -
    then your sender can't realise that it needs to reduce the packet size,
    and such packets inevitably get dropped.

    You can test this with ping -M, as David Hough has suggested. You can
    also reduce your own MTU and see whether this "fixes" the problem. Try "ifconfig eth0 mtu 1400", and experiment with different values.

    Chris


    TCP should be able to find a suitable segment size, but it needs
    an ICMP message for the functionality. There are sysadmins killing
    all ICMP, in an attempt to hide from ICMP echo (ping). This could
    be the cause here.

    --

    Tauno Voipio


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Wed Oct 9 17:39:49 2013
    On Tue, 08 Oct 2013 23:16:05 +0300, Tauno Voipio wrote:

    TCP should be able to find a suitable segment size, but it needs
    an ICMP message for the functionality. There are sysadmins killing
    all ICMP, in an attempt to hide from ICMP echo (ping). This could
    be the cause here.

    What I don't understand is whether the web browser, which is the
    problem observed, is using ICMP or TCP.

    Q: What is the web browser using? (ICMP? TCP?)


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Wed Oct 9 17:41:36 2013
    On Wed, 09 Oct 2013 15:16:33 +0300, Tauno Voipio wrote:

    If a sysadmin has killed the whole ICMP somewhere in the path,
    there is little you can do, except whine to him.

    Traceroute is not of much help here.

    Just so I understand, are you saying that the web
    (i.e., http://centos.org) is using ICMP?


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From Mike Easter@1:0/0 to All on Wed Oct 9 18:28:22 2013
    billy wrote:
    Tauno Voipio wrote:

    TCP should be able to find a suitable segment size, but it needs
    an ICMP message for the functionality. There are sysadmins killing
    all ICMP, in an attempt to hide from ICMP echo (ping). This could
    be the cause here.

    What I don't understand is whether the web browser, which is the
    problem observed, is using ICMP or TCP.

    Q: What is the web browser using? (ICMP? TCP?)

    TCP. But the 'process' involves TCP/IP.

    It would be of value for you to learn about the protocols.

    http://en.wikipedia.org/wiki/Internet_protocol_suite

    The article breaks down the different layers of the suite.

    But your 'breakdown' is more than just the browser, so you should also understand the protocols used by your tools of investigation.

    Standard ping = ICMP (also there is UDP pinger)
    traceroute and tracert also can come in 'flavors' ICMP, UDP, and TCP

    Some hop obstructions or 'holes' are related to protocol.


    --
    Mike Easter

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From billy@110:110/2002 to All on Wed Oct 9 18:44:58 2013
    On Wed, 09 Oct 2013 08:58:25 -0300, nemesis wrote:

    Check your wireless router settings also DSL settings. If it does not void your ISP contract, reset them (backup settings first) to default and reinstall the backdoors, I mean, reflash the firmware <paranoid times>.
    You have root on them, right ?

    I have the basic Netgear home broadband router, just like most of you do,
    and, yes, I have admin as I set it up years ago. Bear in mind that nothing changes on the router that I know of, when this problem comes and goes
    (for months). But, if there was a particular setting on that router that
    causes this, I'd love to know what it would be, as mine is set up mostly
    at default settings (wpa2-psk encryption).

    The one thing I have that most of you do not have is I have another
    radio and antenna on my roof since there are no wires or cables going
    into my house that contain Internet service (too far from the switch
    for DSL).

    For you, that 'thing' on my roof would be the "modem' and for all intents
    and purposes, it's the same setup you have, only I get to log into my receiver/transmitter and see what its settings are.

    Again, I set it up myself, so, I'm admin there also, and, again, nothing
    has changed in the two years time that it was set up.

    Meanwhile, the ability to connect by the web to centos.org has come
    and gone over time.

    So, while there *could* be a setting in either radio, I wouldn't know
    where to look since both are set up in the normal configuration for
    a standard WISP setup.

    PS: Where is Jeff Liebermann when you need him! :)

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Wed Oct 9 18:52:49 2013
    On Wed, 09 Oct 2013 11:28:22 -0700, Mike Easter wrote:

    Q: What is the web browser using? (ICMP? TCP?)

    TCP. But the 'process' involves TCP/IP.

    Hi Mike,

    So, if the web browser is what is failing, and if the
    debug commands using TCP also fail, what value is there
    in everyone saying that ICMP is dropped?

    What does ICMP have to do with the web browser failing?

    That is, why is everyone suggesting I test ICMP when the
    failure of the web browser is the problem I'm trying to
    test?

    I don't understand why ICMP has 'anything' directly to do
    with the web browser failing (other than ICMP also fails).


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From Chris Davies@110:110/2002 to All on Wed Oct 9 18:27:40 2013
    Reply-To: chris@roaima.co.uk

    In comp.os.linux.networking billy <billy@is.invalid> wrote:
    Chris Davies wrote:
    You can also reduce your own MTU and see whether this "fixes"
    the problem. Try "ifconfig eth0 mtu 1400", and experiment

    I set my packet size on my laptop to a low value:
    # ifconfig wlan0 mtu 500

    That's a good starting point, yes. Now you need to see whether your web
    browser can access centos.org. If it does, increase the MTU until it
    breaks and then back it off a little.

    If it still can't access centos.org, even though you've got your MTU
    down at 500 then the chances are that this suggestion is inappropriate
    for your situation.

    Chris

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Roaima. Harrogate, North Yorkshire, UK (110:110/2002@linuxnet)
  • From Chris Davies@110:110/2002 to All on Wed Oct 9 18:22:48 2013
    Reply-To: chris@roaima.co.uk

    In comp.os.linux.networking billy <billy@is.invalid> wrote:
    Just so I understand, are you saying that the web
    (i.e., http://centos.org) is using ICMP?

    Yes and no.

    The data for a website is carried over TCP. The control commands
    (e.g. "slow down you're filling up the pipe", or "that packet's waayyy
    too big; make it smaller") are sent over ICMP. Pings and some traceroute programs also use ICMP, but they use a different ICMP message type.

    A competently configured firewall might be set up to block ICMP ping
    requests. But there's no way that same firewall should be completely
    and naively blocking all ICMP packets.

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Roaima. Harrogate, North Yorkshire, UK (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Wed Oct 9 14:26:36 2013
    Gary R. Schmidt wrote:

    There is a "black hole" between you and centos.org.
    Packets go in, but do not come out
    I would assume that the problem lies with "pnap.net",
    Your WISP appears to be connecting to "layer42" (69.36.226.193)

    All this makes perfect sense, except ...

    Except my neighbors, on the same WISP, can get to centos.org.

    So, it must be something in 'my' setup; but where?

    More specifically, how do I diagnose to pinpoint where?


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From Tauno Voipio@110:110/2002 to All on Wed Oct 9 19:47:22 2013
    On 9.10.13 9:52 , billy wrote:
    On Wed, 09 Oct 2013 11:28:22 -0700, Mike Easter wrote:

    Q: What is the web browser using? (ICMP? TCP?)

    TCP. But the 'process' involves TCP/IP.

    Hi Mike,

    So, if the web browser is what is failing, and if the
    debug commands using TCP also fail, what value is there
    in everyone saying that ICMP is dropped?

    What does ICMP have to do with the web browser failing?

    That is, why is everyone suggesting I test ICMP when the
    failure of the web browser is the problem I'm trying to
    test?

    I don't understand why ICMP has 'anything' directly to do
    with the web browser failing (other than ICMP also fails).


    PLEASE do get a text on TCP, read and understand it.
    It explains the usage.

    ICMP is a helper protocol inside the TCP/IP protocol suite.
    TCP uses ICMP to detect a suitable segment (transmission
    block) size.

    Your web browser needs UDP for name resolution, TCP for
    page transfer and ICMP to help TCP work, and all run
    using IP.

    Can you ping the target from your computer?

    It works perfectly from here:

    - --- clip clip ---

    tauno-voipios-macbook-pro-2:~ tauno$ ping centos.org
    PING centos.org (72.232.194.162): 56 data bytes
    64 bytes from 72.232.194.162: icmp_seq=0 ttl=52 time=161.925 ms
    64 bytes from 72.232.194.162: icmp_seq=1 ttl=52 time=164.736 ms
    c64 bytes from 72.232.194.162: icmp_seq=2 ttl=52 time=161.303 ms
    64 bytes from 72.232.194.162: icmp_seq=3 ttl=52 time=165.196 ms
    64 bytes from 72.232.194.162: icmp_seq=4 ttl=52 time=165.483 ms
    ^C

    - --- clip clip ---

    I can also access the web site with a browser.

    --

    Tauno Voipio

    --

    Tauno Voipio


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From unruh@1:0/0 to All on Wed Oct 9 19:51:42 2013
    On 2013-10-09, billy <billy@is.invalid> wrote:
    On Wed, 09 Oct 2013 11:28:22 -0700, Mike Easter wrote:

    Q: What is the web browser using? (ICMP? TCP?)

    TCP. But the 'process' involves TCP/IP.

    Hi Mike,

    So, if the web browser is what is failing, and if the
    debug commands using TCP also fail, what value is there
    in everyone saying that ICMP is dropped?

    What does ICMP have to do with the web browser failing?

    That is, why is everyone suggesting I test ICMP when the
    failure of the web browser is the problem I'm trying to
    test?

    I don't understand why ICMP has 'anything' directly to do
    with the web browser failing (other than ICMP also fails).

    BEcause you were also worried about the problem of traceroute failing
    and/or ping failing.

    You could try
    telnet centos.com 80
    (or whatever the address is)
    to see if there is any response
    (QUIT should get you out)

    eg
    info:0.0[unruh]>telnet centos.com 80
    Trying 87.106.187.200...
    Connected to centos.com (87.106.187.200).
    Escape character is '^]'.
    QUIT
    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
    <html><head>
    <title>501 Method Not Implemented</title>
    </head><body>
    <h1>Method Not Implemented</h1>
    <p>QUIT to /index.html not supported.<br />

    </body></html>
    Connection closed by foreign host.





    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From unruh@1:0/0 to All on Wed Oct 9 19:58:49 2013
    On 2013-10-09, billy <billy@is.invalid> wrote:
    On Wed, 09 Oct 2013 08:58:25 -0300, nemesis wrote:

    Check your wireless router settings also DSL settings. If it does not void >> your ISP contract, reset them (backup settings first) to default and
    reinstall the backdoors, I mean, reflash the firmware <paranoid times>.
    You have root on them, right ?

    I have the basic Netgear home broadband router, just like most of you do, and, yes, I have admin as I set it up years ago. Bear in mind that nothing changes on the router that I know of, when this problem comes and goes
    (for months). But, if there was a particular setting on that router that causes this, I'd love to know what it would be, as mine is set up mostly
    at default settings (wpa2-psk encryption).

    You have connection to the web. That is not the problem since you say
    you can connect to other places. There is something about centos.org
    that is behaving weirdly. Now it could be something on your end, and it
    is almost certainly something on their end. They may have decided that
    you are a pain in the ass and blackballed you (I have no idea why), or
    it might be some sort of technical incompatibility between you and them.
    The only way to clear it up is to talk to them about it. If you cannot
    then I cannot see how you are going to figure it out.
    Note you could take your computer with you to some other place which
    connects to the web in some other way than your microwave link and see
    if that works there.


    The one thing I have that most of you do not have is I have another
    radio and antenna on my roof since there are no wires or cables going
    into my house that contain Internet service (too far from the switch
    for DSL).

    For you, that 'thing' on my roof would be the "modem' and for all intents
    and purposes, it's the same setup you have, only I get to log into my receiver/transmitter and see what its settings are.

    Again, I set it up myself, so, I'm admin there also, and, again, nothing
    has changed in the two years time that it was set up.

    Meanwhile, the ability to connect by the web to centos.org has come
    and gone over time.

    So, while there *could* be a setting in either radio, I wouldn't know
    where to look since both are set up in the normal configuration for
    a standard WISP setup.

    PS: Where is Jeff Liebermann when you need him! :)

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From billy@110:110/2002 to All on Wed Oct 9 10:43:45 2013
    David Hough wrote:

    Is it an MTU/fragmentation issue? (Check out ping -M)

    While I definitely value the help, part of why I am
    frustrated is that I don't UNDERSTAND the problem, and,
    as such, I consider ping a diagnostic tool.

    The point being, the ping isn't the problem (it's just
    one way of showing the problem).

    So, even if I get the ping to work, it still does nothing
    to solve the problem (although it may explain a bit).

    Since the problem manifests itself in the inability to
    connect via port 80 (i.e., the web), I have previously
    doubted the way I'm running ping has anything to do with it.

    To me, in my simple mind, trying to get the ping to work is
    sort of like having an engine misfire, and then I try all
    sorts of options on my voltmeter to get it to give me a
    good reading.

    Whether or not I get a good reading on the voltmeter, I
    still have the misfire.

    Back to the specifics, whether or not I get a good reading
    on the ping, I still have the web failing to connect.

    I'm not saying ping isn't a great DIAGNOSTIC tool.

    I'm just asking how a ping -M is going to help me UNDERSTAND
    why I can't connect via the web to centos.org?

    Nonetheless, in the next post, I'll post my ping results
    (in the hope that it helps to UNDERSTAND what's going on!).

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Wed Oct 9 10:51:14 2013
    David Hough wrote:

    Is it an MTU/fragmentation issue? (Check out ping -M)

    I'm not sure what an MTU fragmentation issue is, but, if it
    is related to helping to EXPLAIN why I can't connect via the
    web to centos.org, I'll be glad to run *any* diagnostic procedure!

    Here's the traceroute -M results:

    # traceroute -M icmp www.centos.org
    traceroute to www.centos.org (72.232.194.162), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 2.836 ms 2.828 ms 2.827 ms
    2 MY_WISP_IP_REDACTED (xxx.xxx.xxx.xxx) 2.835 ms 5.766 ms 5.768 ms
    3 10.50.0.1 (10.50.0.1) 12.510 ms 12.509 ms 16.000 ms
    4 10.25.0.1 (10.25.0.1) 18.880 ms 18.878 ms 18.875 ms
    5 10.20.0.1 (10.20.0.1) 31.081 ms 31.335 ms 34.052 ms
    6 10.0.0.1 (10.0.0.1) 34.050 ms 18.724 ms 28.518 ms
    7 69.36.226.193 (69.36.226.193) 28.488 ms 28.064 ms 28.043 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 28.025 ms 47.434 ms 47.413 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 47.394 ms 30.086 ms 30.064 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 80.031 ms 60.416 ms 70.204 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 70.189 ms 120.949 ms 120.925 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 120.893 ms 75.048 ms 75.028 ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 75.009 ms 68.640 ms 101.778 ms
    14 border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 101.762 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 77.155 ms 87.903
    ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 87.889 ms 120.374 ms 123.342 ms
    16 * * *
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *
    #

    Does any of that help diagnose WHY this one IP address times out on
    port 80 for months on end (and then works just fine for months)?



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Wed Oct 9 10:54:26 2013
    Chris Davies wrote:

    the sender is responsible for transmitted the
    data in smaller sized packets

    Hi Chris,
    I posted my "traceroute -M centos.org" results
    because I truly want to UNDERSTAND what is going
    on.

    If the problem is that my packets are too large,
    how does one control that in a web browser?

    The ping is merely my diagnostic tool.

    The *real* problem is that, for months at a time, I
    can't connect (via any web browser not on TOR) to:
    http://centos.org

    With TOR, I can connect easily - so it's not the
    Centos site itself.

    QUESTION: How do I control packet size in Firefox?



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From nemesis@110:110/2002 to All on Wed Oct 9 11:14:16 2013
    On Wed, 09 Oct 2013 10:51:14 +0000, billy wrote:

    David Hough wrote:

    Is it an MTU/fragmentation issue? (Check out ping -M)

    I'm not sure what an MTU fragmentation issue is, but, if it
    is related to helping to EXPLAIN why I can't connect via the
    web to centos.org, I'll be glad to run *any* diagnostic procedure!

    Here's the traceroute -M results:

    Just boot from a freeware live CD and do it from there. If it traceroutes,
    it's your OS config. If not, something in your hardware/network.
    Simple is sometimes easier.
    HTH

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Wed Oct 9 11:09:27 2013
    Chris Davies wrote:

    You can test this with ping -M, as David Hough has suggested. You can
    also reduce your own MTU and see whether this "fixes" the problem. Try "ifconfig eth0 mtu 1400", and experiment with different values.

    Hi Chris,

    I appreciate your help as I'm trying to UNDERSTAND the problem,
    which is that, for months on end, I can't connect via the web
    to http://centos.org where a traceroute shows that the penultimate
    connection is dropping me. (So I am forced to use TOR and all
    works fine - albeit slowly.)

    Then, for months at a time, I *can* connect to centos.org,
    where the traceroute shows the connection going through.

    Googling for what an MTU is, I see it's the max size of a packet:
    http://en.wikipedia.org/wiki/Maximum_transmission_unit

    Ethernet has an MTU limit, it appears, of 1500 bytes, so I can
    see why you're suggesting 1400 bytes.

    I don't have much ethernet in the picture though, as I'm on
    a laptop connected by WiFi to my home broadband router which
    itself is wired by POE to a rooftop antenna which goes over
    WiFi about five miles to the WISP antenna where I lose control.

    So, I assume you would want me to modify that command:
    ifconfig eth0 mtu 1400
    To:
    "ifconfig wlan0 mtu 1400

    Here's what ifconfig just reported:
    # ifconfig
    eth0 Link encap:Ethernet HWaddr 00:a0:00:3a:4f:23
    UP BROADCAST MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
    Interrupt:11 Memory:f2600000-f2620000

    wlan0 Link encap:Ethernet HWaddr 00:a0:00:6a:9b:3d
    inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:267437 errors:0 dropped:0 overruns:0 frame:0
    TX packets:167343 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:311152648 (296.7 MiB) TX bytes:29413063 (28.0 MiB)

    So I ran the following:
    # ifconfig wlan0 mtu 1400
    # ifconfig wlan0
    wlan0 Link encap:Ethernet HWaddr 00:a0:00:6a:9b:3d
    inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1400 Metric:1
    RX packets:267437 errors:0 dropped:0 overruns:0 frame:0
    TX packets:167343 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:311152648 (296.7 MiB) TX bytes:29413063 (28.0 MiB)

    And, then I tried to connect via Firefox to centos.org, but it still
    timed out.

    Should I change the mtu even further down, say, to 1000 so that
    Firefox can connect to http://www.centos.org?

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From p-0''0-h the cat (ES)@110:110/2002 to All on Wed Oct 9 11:24:19 2013
    On Wed, 9 Oct 2013 08:14:16 -0300, nemesis <nemesis@home.it> wrote:

    On Wed, 09 Oct 2013 10:51:14 +0000, billy wrote:

    David Hough wrote:

    Is it an MTU/fragmentation issue? (Check out ping -M)

    I'm not sure what an MTU fragmentation issue is, but, if it
    is related to helping to EXPLAIN why I can't connect via the
    web to centos.org, I'll be glad to run *any* diagnostic procedure!

    Here's the traceroute -M results:

    Just boot from a freeware live CD and do it from there. If it traceroutes,
    it's your OS config. If not, something in your hardware/network.
    Simple is sometimes easier.
    HTH

    Too easy. You could also try Windows post Vista. It dynamically
    calculates the maximum MTU I believe, unless you sod with the registry.

    --
    p-0.0-h the cat

    Internet Terrorist, Mass sock puppeteer, Agent provocateur, Gutter rat,
    Devil incarnate, Linux user#666, BaStarD hacker, Resident evil, Monkey Boy, Certifiable criminal, Spineless cowardly scum, textbook Psychopath,
    the SCOURGE, l33t p00h d3 tr0ll, p00h == lam3r, p00h == tr0ll, troll infme, the OVERCAT [The BEARPAIR are dead, and we are its murderers], lowlife troll, shyster [pending approval by STATE_TERROR], cripple, sociopath, kook,
    smug prick, smartarse, arsehole, moron, idiot, imbecile, snittish scumbag, liar, and shill.

    Honorary SHYSTER and FRAUD awarded for services to Haberdashery.
    By Appointment to God Frank-Lin.



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: ACF's purry underbelly (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Wed Oct 9 11:18:19 2013
    Chris Davies wrote:

    You can also reduce your own MTU and see whether this "fixes"
    the problem. Try "ifconfig eth0 mtu 1400", and experiment

    Bearing in mind, the problem is that I'm trying to understand
    *why* my web traffic is not connecting to centos.org, I'll try
    any suggested diagnostic procedure using whatever tools I have
    at hand.

    I set my packet size on my laptop to a low value:
    # ifconfig wlan0 mtu 500

    And, then ran the traceroute:
    # traceroute -M icmp centos.org
    traceroute to centos.org (72.232.194.162), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 5.042 ms 5.029 ms 5.017 ms
    2 WISP_IP_REDACTED (xxx.xxx.xxx.xxx) 5.022 ms 8.227 ms 8.227 ms
    3 10.50.0.1 (10.50.0.1) 13.820 ms 23.623 ms 25.771 ms
    4 10.25.0.1 (10.25.0.1) 25.767 ms 30.879 ms 30.877 ms
    5 10.20.0.1 (10.20.0.1) 44.616 ms 46.995 ms 46.992 ms
    6 10.0.0.1 (10.0.0.1) 52.204 ms 27.862 ms 31.134 ms
    7 69.36.226.193 (69.36.226.193) 35.862 ms 50.007 ms 49.971 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 49.951 ms 74.962 ms 77.875 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 77.857 ms 25.678 ms 25.643 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 71.468 ms 91.228 ms 95.624 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 155.916 ms 85.719 ms 101.926 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 95.461 ms 97.164 ms 103.047 ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 103.028 ms 63.041 ms 107.573 ms
    14 border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 107.556 ms 70.772 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 70.744
    ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 70.725 ms 89.757 ms 89.726 ms
    16 * * * <=== from experience, I know this is centos.org
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *

    BTW, I know that, in the case above, hop 16 is centos.org because I've asked neighbors in the past (who are on the same WISP) to run a traceroute, and, every few months, I can connect - so I can see it on my own laptop.


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Wed Oct 9 11:27:09 2013
    nemesis wrote:

    Just boot from a freeware live CD and do it from there.
    If it traceroutes, it's your OS config.
    If not, something in your hardware/network.

    I'm all for a DIAGNOSTIC approach, since what I'm trying
    to figure out is WHY the Internet fails me on just one
    web site.

    I just tried it from Knoppix and it is the same result
    (see below for the details).

    I also have tried it from other PC's on the network,
    running Windows XP and Windows 7, and the same thing
    occurs.

    I also run it via TOR on both Windows & Linux, and it
    works fine.

    So, its clearly not the PC itself.
    It's in the network - but WHERE?

    Anyway, here are the Knoppix results:
    root@Microknoppix:/# uname -a
    Linux Microknoppix 3.6.11-64 #10 SMP PREEMPT Wed Dec 19 23:51:48 CET 2012 x86_64 GNU/Linux

    root@Microknoppix:/# ifconfig wlan0 mtu 300

    root@Microknoppix:/# traceroute -M icmp centos.org
    traceroute to centos.org (72.232.194.162), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 2.932 ms 2.929 ms 2.928 ms
    2 WISP_IP_REDACTED (xxx.xxx.xxx.xxx) 5.683 ms 5.683 ms 5.680 ms
    3 10.50.0.1 (10.50.0.1) 20.479 ms 20.477 ms 20.474 ms
    4 10.25.0.1 (10.25.0.1) 20.469 ms 30.272 ms 33.014 ms
    5 10.20.0.1 (10.20.0.1) 33.009 ms 36.190 ms 36.187 ms
    6 10.0.0.1 (10.0.0.1) 36.182 ms 16.332 ms 39.405 ms
    7 69.36.226.193 (69.36.226.193) 39.377 ms 20.721 ms 23.093 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 23.066 ms 16.977 ms 16.947 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 16.917 ms 12.782 ms 18.611 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 69.341 ms 119.252 ms 119.222 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 116.010 ms 84.054 ms 84.022 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 83.978 ms 53.016 ms 52.987 ms 13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 56.341 ms 53.502 ms 59.458 ms
    14 border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 59.430 ms 58.240 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 61.422 ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 61.383 ms 54.510 ms 54.494 ms
    16 * * * <== centos.org is here
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *
    root@Microknoppix:/#





    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From nemesis@110:110/2002 to All on Wed Oct 9 11:42:13 2013
    On Wed, 09 Oct 2013 12:24:19 +0100, p-0''0-h the cat (ES) wrote:

    On Wed, 9 Oct 2013 08:14:16 -0300, nemesis <nemesis@home.it> wrote:

    On Wed, 09 Oct 2013 10:51:14 +0000, billy wrote:

    David Hough wrote:

    Is it an MTU/fragmentation issue? (Check out ping -M)

    I'm not sure what an MTU fragmentation issue is, but, if it
    is related to helping to EXPLAIN why I can't connect via the
    web to centos.org, I'll be glad to run *any* diagnostic procedure!

    Here's the traceroute -M results:

    Just boot from a freeware live CD and do it from there. If it traceroutes,
    it's your OS config. If not, something in your hardware/network.
    Simple is sometimes easier.
    HTH

    Too easy. You could also try Windows post Vista. It dynamically
    calculates the maximum MTU I believe, unless you sod with the registry.

    I tried that once. The "freeware live Vista CD" I downloaded tracerouted
    all the way to China before it went back to the US. Took ages. Trust me,
    too easy is sometimes also faster.
    ;)

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From nemesis@110:110/2002 to All on Wed Oct 9 11:58:25 2013
    On Wed, 09 Oct 2013 11:27:09 +0000, billy wrote:

    nemesis wrote:

    Just boot from a freeware live CD and do it from there.
    If it traceroutes, it's your OS config.
    If not, something in your hardware/network.

    I'm all for a DIAGNOSTIC approach, since what I'm trying
    to figure out is WHY the Internet fails me on just one
    web site.

    I just tried it from Knoppix and it is the same result
    (see below for the details).

    I also have tried it from other PC's on the network,
    running Windows XP and Windows 7, and the same thing
    occurs.

    I also run it via TOR on both Windows & Linux, and it
    works fine.

    So, its clearly not the PC itself.
    It's in the network - but WHERE?

    Check your wireless router settings also DSL settings. If it does not void
    your ISP contract, reset them (backup settings first) to default and
    reinstall the backdoors, I mean, reflash the firmware <paranoid times>.
    You have root on them, right ?

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From Tauno Voipio@110:110/2002 to All on Wed Oct 9 12:16:33 2013
    On 9.10.13 2:18 , billy wrote:
    Chris Davies wrote:

    You can also reduce your own MTU and see whether this "fixes"
    the problem. Try "ifconfig eth0 mtu 1400", and experiment

    Bearing in mind, the problem is that I'm trying to understand
    *why* my web traffic is not connecting to centos.org, I'll try
    any suggested diagnostic procedure using whatever tools I have
    at hand.

    I set my packet size on my laptop to a low value:
    # ifconfig wlan0 mtu 500

    And, then ran the traceroute:
    # traceroute -M icmp centos.org
    traceroute to centos.org (72.232.194.162), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 5.042 ms 5.029 ms 5.017 ms
    2 WISP_IP_REDACTED (xxx.xxx.xxx.xxx) 5.022 ms 8.227 ms 8.227 ms
    3 10.50.0.1 (10.50.0.1) 13.820 ms 23.623 ms 25.771 ms
    4 10.25.0.1 (10.25.0.1) 25.767 ms 30.879 ms 30.877 ms
    5 10.20.0.1 (10.20.0.1) 44.616 ms 46.995 ms 46.992 ms
    6 10.0.0.1 (10.0.0.1) 52.204 ms 27.862 ms 31.134 ms
    7 69.36.226.193 (69.36.226.193) 35.862 ms 50.007 ms 49.971 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 49.951 ms 74.962 ms 77.875
    ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 77.857 ms 25.678 ms
    25.643 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 71.468 ms 91.228 ms
    95.624 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 155.916 ms 85.719 ms
    101.926 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 95.461 ms 97.164 ms 103.047
    ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 103.028 ms 63.041 ms
    107.573 ms
    14 border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 107.556 ms 70.772
    ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 70.744
    ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 70.725 ms 89.757 ms
    89.726 ms
    16 * * * <=== from experience, I know this is centos.org
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *

    BTW, I know that, in the case above, hop 16 is centos.org because I've asked neighbors in the past (who are on the same WISP) to run a traceroute, and, every few months, I can connect - so I can see it on my own laptop.

    Get a goot text on TCP/IP protocols and learn how TCP does it.
    There is an ICMP message 'fragmentation needed but DF bit is on'.
    The segment auto-sizing is an essential part of TCP.

    If a sysadmin has killed the whole ICMP somewhere in the path,
    there is little you can do, except whine to him.

    Traceroute is not of much help here.

    --

    Tauno Voipio


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Bit Twister@110:110/2002 to All on Wed Oct 9 12:23:23 2013
    On Wed, 09 Oct 2013 11:18:19 +0000, billy wrote:
    And, then ran the traceroute:
    # traceroute -M icmp centos.org
    traceroute to centos.org (72.232.194.162), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 5.042 ms 5.029 ms 5.017 ms

    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 70.725 ms 89.757 ms
    89.726 ms
    16 * * * <=== from experience, I know this is centos.org
    17 * * *

    You might try
    traceroute -I centos.org

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Wed Oct 9 13:57:04 2013
    On Wed, 09 Oct 2013 12:24:19 +0100, p-0''0-h the cat (ES) wrote:

    Too easy. You could also try Windows post Vista.
    It dynamically calculates the maximum MTU I believe,
    unless you sod with the registry.

    I'm all for any diagnostic procedure, so, here's the result from
    Windows 7 trace route:

    Microsoft Windows [Version 6.1.7601]
    Copyright (c) 2009 Microsoft Corporation. All rights reserved.

    C:\Users\billy>traceroute -M icmp www.centos.org
    'traceroute' is not recognized as an internal or external command,
    operable program or batch file.

    C:\Users\billy>tracert www.centos.org

    Tracing route to www.centos.org [72.232.194.162] over a maximum of 30 hops:

    1 <1 ms <1 ms <1 ms 192.168.1.1
    2 2 ms 1 ms 1 ms REDACTED_WISP_IP [xxx.xxx.xxx.xxx]
    3 6 ms 2 ms 5 ms 10.50.0.1
    4 5 ms 9 ms 4 ms 10.25.0.1
    5 6 ms 13 ms 5 ms 10.20.0.1
    6 28 ms 18 ms 10 ms 10.0.0.1
    7 10 ms 19 ms 19 ms 69.36.226.193
    8 48 ms 49 ms 26 ms vl2.core1.scl.layer42.net [69.36.225.129]
    9 15 ms 8 ms 9 ms 216.156.84.141.ptr.us.xo.net [216.156.84.141]
    10 60 ms 60 ms 57 ms 207.88.14.233.ptr.us.xo.net [207.88.14.233]
    11 62 ms 54 ms 60 ms vb15.rar3.dallas-tx.us.xo.net [207.88.12.45]
    12 69 ms 65 ms 72 ms 207.88.14.34.ptr.us.xo.net [207.88.14.34]
    13 73 ms 53 ms 98 ms 207.88.185.74.ptr.us.xo.net [207.88.185.74]
    14 57 ms 54 ms 54 ms border1.pc2-bbnet2.dal004.pnap.net [216.52.191.81]
    15 51 ms 75 ms 50 ms layered-11.border1.dal004.pnap.net [63.251.44.74]
    16 * * * Request timed out.
    17 * * * Request timed out.
    18 * * * Request timed out.
    19 * * * Request timed out.
    20 * * * Request timed out.
    21 * * * Request timed out.
    22 * * * Request timed out.
    23 * * * Request timed out.
    24 * * * Request timed out.
    25 * * * Request timed out.
    26 * * * Request timed out.
    27 * * * Request timed out.
    28 * * * Request timed out.
    29 * * * Request timed out.
    30 * * * Request timed out.

    Trace complete.

    C:\Users\billy>

    At this point, we know:
    1. Neither Linux nor Windows can get to http://centos.org
    2. TOR has no problem getting to http://centos.org
    3. Traceroute shows that the penultimate hop is killing packets

    But why?


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From p-0''0-h the cat (ES)@110:110/2002 to All on Wed Oct 9 14:09:11 2013
    On Wed, 9 Oct 2013 13:57:04 +0000 (UTC), billy <billy@is.invalid> wrote:

    On Wed, 09 Oct 2013 12:24:19 +0100, p-0''0-h the cat (ES) wrote:

    Too easy. You could also try Windows post Vista.
    It dynamically calculates the maximum MTU I believe,
    unless you sod with the registry.

    I'm all for any diagnostic procedure, so, here's the result from
    Windows 7 trace route:

    Microsoft Windows [Version 6.1.7601]
    Copyright (c) 2009 Microsoft Corporation. All rights reserved.

    C:\Users\billy>traceroute -M icmp www.centos.org
    'traceroute' is not recognized as an internal or external command,
    operable program or batch file.

    C:\Users\billy>tracert www.centos.org

    Tracing route to www.centos.org [72.232.194.162] over a maximum of 30 hops:

    1 <1 ms <1 ms <1 ms 192.168.1.1
    2 2 ms 1 ms 1 ms REDACTED_WISP_IP [xxx.xxx.xxx.xxx]
    3 6 ms 2 ms 5 ms 10.50.0.1
    4 5 ms 9 ms 4 ms 10.25.0.1
    5 6 ms 13 ms 5 ms 10.20.0.1
    6 28 ms 18 ms 10 ms 10.0.0.1
    7 10 ms 19 ms 19 ms 69.36.226.193
    8 48 ms 49 ms 26 ms vl2.core1.scl.layer42.net [69.36.225.129]
    9 15 ms 8 ms 9 ms 216.156.84.141.ptr.us.xo.net [216.156.84.141] 10 60 ms 60 ms 57 ms 207.88.14.233.ptr.us.xo.net [207.88.14.233]
    11 62 ms 54 ms 60 ms vb15.rar3.dallas-tx.us.xo.net [207.88.12.45] 12 69 ms 65 ms 72 ms 207.88.14.34.ptr.us.xo.net [207.88.14.34]
    13 73 ms 53 ms 98 ms 207.88.185.74.ptr.us.xo.net [207.88.185.74]
    14 57 ms 54 ms 54 ms border1.pc2-bbnet2.dal004.pnap.net
    [216.52.191.81]
    15 51 ms 75 ms 50 ms layered-11.border1.dal004.pnap.net
    [63.251.44.74]
    16 * * * Request timed out.
    17 * * * Request timed out.
    18 * * * Request timed out.
    19 * * * Request timed out.
    20 * * * Request timed out.
    21 * * * Request timed out.
    22 * * * Request timed out.
    23 * * * Request timed out.
    24 * * * Request timed out.
    25 * * * Request timed out.
    26 * * * Request timed out.
    27 * * * Request timed out.
    28 * * * Request timed out.
    29 * * * Request timed out.
    30 * * * Request timed out.

    Trace complete.

    C:\Users\billy>

    At this point, we know:
    1. Neither Linux nor Windows can get to http://centos.org
    2. TOR has no problem getting to http://centos.org
    3. Traceroute shows that the penultimate hop is killing packets

    But why?

    Email the technical contact at pnap.net with your findings

    Registrant:
    Internap Network Services Corporation
    Domain Administrator
    One Ravinia Drive Suite 1300
    Atlanta, GA 30346
    US
    Email: noc@internap.com

    Registrar Name....: CORPORATE DOMAINS, INC.
    Registrar Whois...: whois.corporatedomains.com
    Registrar Homepage: www.cscprotectsbrands.com

    Domain Name: pnap.net

    Created on..............: Thu, Jun 20, 1996
    Expires on..............: Thu, Jun 19, 2014
    Record last updated on..: Sat, Jun 15, 2013

    Administrative Contact:
    Internap Network Services Corporation
    Domain Administrator
    One Ravinia Drive Suite 1300
    Atlanta, GA 30346
    US
    Phone: +1.4043029870
    Email: bgowder@internap.com

    Technical Contact:
    Internap Network Services Corporation
    Domain Administrator
    One Ravinia Drive Suite 1300
    Atlanta, GA 30346
    US
    Phone: +1.8778434662
    Email: noc@internap.com

    DNS Servers:

    ns-a.pnap.net
    ns-b.pnap.net
    ns-c.pnap.net
    ns-d.pnap.net

    --
    p-0.0-h the cat

    Internet Terrorist, Mass sock puppeteer, Agent provocateur, Gutter rat,
    Devil incarnate, Linux user#666, BaStarD hacker, Resident evil, Monkey Boy, Certifiable criminal, Spineless cowardly scum, textbook Psychopath,
    the SCOURGE, l33t p00h d3 tr0ll, p00h == lam3r, p00h == tr0ll, troll infme, the OVERCAT [The BEARPAIR are dead, and we are its murderers], lowlife troll, shyster [pending approval by STATE_TERROR], cripple, sociopath, kook,
    smug prick, smartarse, arsehole, moron, idiot, imbecile, snittish scumbag, liar, and shill.

    Honorary SHYSTER and FRAUD awarded for services to Haberdashery.
    By Appointment to God Frank-Lin.



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: ACF's purry underbelly (110:110/2002@linuxnet)
  • From unruh@1:0/0 to All on Wed Oct 9 16:17:42 2013

    He asks you to do ping -M ... and you do traceroute -M ...
    They are different programs and -M means different things to them. Why
    in the world would you do traceroute -M when asked to do ping -M?

    (man ping
    man traceroute)
    traceroute is NOT ping.


    On 2013-10-09, billy <billy@is.invalid> wrote:
    David Hough wrote:

    Is it an MTU/fragmentation issue? (Check out ping -M)

    I'm not sure what an MTU fragmentation issue is, but, if it
    is related to helping to EXPLAIN why I can't connect via the
    web to centos.org, I'll be glad to run *any* diagnostic procedure!

    Here's the traceroute -M results:

    # traceroute -M icmp www.centos.org
    traceroute to www.centos.org (72.232.194.162), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 2.836 ms 2.828 ms 2.827 ms
    2 MY_WISP_IP_REDACTED (xxx.xxx.xxx.xxx) 2.835 ms 5.766 ms 5.768 ms
    3 10.50.0.1 (10.50.0.1) 12.510 ms 12.509 ms 16.000 ms
    4 10.25.0.1 (10.25.0.1) 18.880 ms 18.878 ms 18.875 ms
    5 10.20.0.1 (10.20.0.1) 31.081 ms 31.335 ms 34.052 ms
    6 10.0.0.1 (10.0.0.1) 34.050 ms 18.724 ms 28.518 ms
    7 69.36.226.193 (69.36.226.193) 28.488 ms 28.064 ms 28.043 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 28.025 ms 47.434 ms 47.413
    ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 47.394 ms 30.086 ms
    30.064 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 80.031 ms 60.416 ms
    70.204 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 70.189 ms 120.949 ms
    120.925 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 120.893 ms 75.048 ms 75.028
    ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 75.009 ms 68.640 ms
    101.778 ms
    14 border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 101.762 ms
    border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 77.155 ms 87.903
    ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 87.889 ms 120.374 ms
    123.342 ms
    16 * * *
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *
    #

    Does any of that help diagnose WHY this one IP address times out on
    port 80 for months on end (and then works just fine for months)?



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From billy@110:110/2002 to All on Wed Oct 9 20:42:49 2013
    On Wed, 09 Oct 2013 19:51:42 +0000, unruh wrote:

    I don't understand why ICMP has 'anything' directly to do`
    with the web browser failing (other than ICMP also fails).

    BEcause you were also worried about the problem of
    traceroute failing and/or ping failing.

    This is very true.

    Maybe it's my fault for bringing up traceroute & ping
    in the first place; but they're the only freeware tools
    for debugging the network that I know of.

    Clearly they're doing the *same* thing as the web is,
    which is they're all dying at the penultimate hop
    before www.centos.org

    I did say, in my very first post, that I was pretty sure
    the problem had nothing to do with the *way* I was running
    the tools (since the problem is independent of those tools).

    You could try
    telnet centos.com 80

    $ telnet www.centos.org 80
    Trying 72.232.194.162... <==== it hangs here for a minute or two
    telnet: connect to address 72.232.194.162: Connection timed out

    The problem is that NOTHING will connect to www.centos.org
    that comes from me. If I use TOR, everything works fine.

    THAT is what I'm trying to debug.
    But, I don't know how.


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From Rick Jones@110:110/2002 to All on Wed Oct 9 20:44:48 2013

    The protocols layer and in some cases intertwine. What you call "the
    web" sits on top of a protocol called HTTP (HyperText Transfer
    Protocol). HTTP makes use of the services of TCP (Transmission
    Control Protocol). TCP makes use of IP (Internet Protocol). IP will
    make use of whatever link-layer protocol is available in its
    sitaution. For your end systems that will be "Ethernet" protocol over
    your WiFi connection.

    HTTP
    TCP
    IP
    Ethernet/WiFi/whatnot

    Within/alongside IP is ICMP (Internet Control Message Protocol). ICMP
    is used to provide some "Hey, you should know this" kinds of messages
    back to traffic sources.

    So, simplifying a bit, when you try to access www.centos.org from your
    web browser, the browser will generate an HTTP message the browswer
    wants to get to HTTP at www.centos.org. That HTTP message will be
    handed-off to TCP to transmit in one or more TCP segments to TCP at www.centos.org (segment = what a packet is called in the context of
    TCP). The TCP segment(s) will be handed off to IP, which will
    encapsulate them in one or more IP datagrams (datagram = what a packet
    is called in the context of IP) destined to the IP address of
    www.centos.org. IP will then hand its datagrams to the "data link"
    layer (eg Ethernet etc) which will do its encapsulation. It will then
    go across the data link destined for IP at the "next hop" where the
    data-link layer message will decapsulate the IP datagram and hand it
    to IP at that hop. IP at that hop will then decide what to do with
    the datagram, which is being sent to the/an IP address for
    www.centos.org. There will probably be another "next hop" and so on
    until the traffic arrives at www.centos.org. IP at www.centos.org
    will then decapsulate the TCP segment from the IP datagram, and TCP
    will decapsulate the HTTP message and hand it to the HTTP server.

    The HTTP response will flow back to you via a similar mechanism.

    Those different lines you see in the output of traceroute are the
    "next hops" along the way from your system to www.centos.org.

    Now, the data links at all those next hops may have different limits
    for how large a packet they can transmit. If an IP datagram arrives
    at a "next hop" (aka an IP router), and IP there determines that where
    it needs to be sent-out next is over a data link with a packet size
    smaller than the IP datagram it needs to send, IP decides to send back
    to the traffic's source an ICMP message saying "Hey, the datagram you
    sent is too large for me to send, you should send smaller IP
    datagrams" (There is more to it than this, but I'm simplifying).

    There are other sorts of ICMP "Hey!" messages. One of them is
    "Maximum Hop Count Reached" - that is the ICMP message that (default) traceroute relies upon receiving. In the header of an IP datagram
    there is a field called the "TTL" (Time To Live) which is really a
    maximum hop count. As the IP datagram passes through an IP router,
    the router decrements the count by one, and when it hits zero, that IP
    is supposed to send back an ICMP message that says "Hey! The datagram
    you sent had its maximum hop count expire before it reached its
    destination." Traceroute works by sending an IP datagram over and
    over again, with the TTL increased by one each time.

    Ping sends a different sort of ICMP message, one that says "Please
    tell me that you got this" - more formally known as an ICMP Echo
    Request. The destination IP will send an ICMP Echo Response back to
    the originator when it receives one.

    Now, all these things I've described rely on ICMP messages making it
    back to the source of the IP/ICMP datagram triggering them. But some
    network administrators feel that allowing (certain) ICMP traffic to
    pass represents a security vulnerablity, so they block ICMP traffic.

    If ICMP traffic is blocked at a point part-way between you and
    www.centos.org, you will see the traceroute "stop" (those '*' lines
    starting indicating there was no response with the TTL set to that
    many hops). You will also not have ping "work" - it won't see any
    ICMP Echo Reply messages.

    If TCP tries to send a TCP segment that was carried in an IP datagram
    which needed to be fragmented somewhere in the middle there, then when
    it goes to send traffic it will appear to disappear - it hits an IP
    router (next hop) that tried to send it but couldn't and the "Hey!"
    message that IP router tried to send back was blocked.

    Now, by default, ping and traceroute do not send very large IP
    datagrams, so the chances of those packets arriving at a next hop
    where fragmentation is needed is pretty small.

    Also, not all TCP segments are the same size - the TCP segments used
    to setup a TCP connection for example are pretty small. That is what
    was behind some of the "try telnet www.centos.org 80" suggestions -
    that is an old school way to just try establishing a TCP connection
    but not actually send any data on it. Those TCP segments will be
    small.

    Why try that? (Or for that matter the pings or traceroutes with
    options set to send larger packets) Because it is how one tries to see
    if 'the problem" centers on packets which are too large arriving at a
    small data link somewhere, or simply a routing issue somewhere in the
    middle of the Internet. If the "telnet www.centos.org 80" establishes
    the TCP connection, you can assume that it isn't a routing issue. In
    that case, a/the remedy is to ensure that TCP at your system and TCP
    at the system(s) to which you are connecting never try to send TCP
    segments which become IP datagrams which are too large to send without fragmentation. One can do that by shrinking the MTU of the network
    interface of your system. When TCP establishes a connection, part of
    that is exchanging with the other side (eg www.centos.org) the Maximum
    Segment Size (MSS) for the connection. There are several inputs to
    that exchange, one of which is the MTU of your local interface. The
    smallest MSS (your's or that of www.centos.org) is the one that will
    be used for traffic in both directions.

    Now, if the telnet www.centos.org 80 does not succeed, that means
    there is some sort of routing issue. That was already partially
    suggested by the ping and traceroute "failures" you've already
    reported (if memory serves) but since the ICMP traffic on which they
    rely can be blocked, their failure is not conclusive.

    What sort of routing issue might it be? Well, one could be that there
    is a simply problem at or after one of those next hops you see in the traceroute output. That is why some have suggested you lookup the
    information about who runs those and contact them.

    It is possible that your source IP has been "black listed" for some
    reason or other - either at/past the ISP responsible for the last
    "next hop" you see in traceroute or perhaps even at www.centos.org.
    Perhaps at one point the IP address you have from your ISP was
    involved in something considered nefarious or anti-social.

    That you could still get to www.centos.org using TOR would remain
    consistent with your IP address (the one being assigned to your home
    gateway by your ISP) being blacklisted because the entire point of TOR
    (as I understand it) is to hid your actual IP address. It does that
    by adding some additional layers to the top of what I mentioned
    above. (As I understand it, I don't actually have any practical
    experience with TOR).

    rick jones
    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    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...

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: the Unofficial HP (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Wed Oct 9 20:50:34 2013
    On Wed, 09 Oct 2013 22:47:22 +0300, Tauno Voipio wrote:

    Your web browser needs UDP for name resolution, TCP for
    page transfer and ICMP to help TCP work, and all run
    using IP.
    Can you ping the target from your computer?
    It works perfectly from here:

    I know it works for you as it works for everyone but me.
    1. ping fails every time on www.centos.org
    2. traceroute shows the penultimate hop is where it dies
    It makes no sense.

    And, it works for my neighbor, who is on the same WISP.
    He says my times are longer than his, which is the only delta.

    The only thing my neighbor could think of was maybe my
    transit times are so long that packets are discarded
    at some point.

    I'll bet your transit times are much better than mine, right?

    Does *that* transit-time theory make any sense?


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From ~BD~@1:0/0 to All on Wed Oct 9 21:09:27 2013
    billy wrote:
    On Wed, 09 Oct 2013 19:51:42 +0000, unruh wrote:

    I don't understand why ICMP has 'anything' directly to do`
    with the web browser failing (other than ICMP also fails).

    BEcause you were also worried about the problem of
    traceroute failing and/or ping failing.

    This is very true.

    Maybe it's my fault for bringing up traceroute & ping
    in the first place; but they're the only freeware tools
    for debugging the network that I know of.

    Clearly they're doing the *same* thing as the web is,
    which is they're all dying at the penultimate hop
    before www.centos.org

    I did say, in my very first post, that I was pretty sure
    the problem had nothing to do with the *way* I was running
    the tools (since the problem is independent of those tools).

    You could try
    telnet centos.com 80

    $ telnet www.centos.org 80
    Trying 72.232.194.162... <==== it hangs here for a minute or two
    telnet: connect to address 72.232.194.162: Connection timed out

    The problem is that NOTHING will connect to www.centos.org
    that comes from me. If I use TOR, everything works fine.

    THAT is what I'm trying to debug.
    But, I don't know how.

    Have you been in touch here as suggested by Pooh?

    Technical Contact:
    Internap Network Services Corporation
    Domain Administrator
    One Ravinia Drive Suite 1300
    Atlanta, GA 30346
    US
    Phone: +1.8778434662
    Email: noc@internap.com

    If not, WHY not?

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From billy@110:110/2002 to All on Wed Oct 9 21:18:40 2013
    On Wed, 09 Oct 2013 19:22:48 +0100, Chris Davies wrote:

    The data for a website is carried over TCP. The control commands
    (e.g. "slow down you're filling up the pipe", or "that packet's waayyy
    too big; make it smaller") are sent over ICMP. Pings and some traceroute programs also use ICMP, but they use a different ICMP message type.

    A competently configured firewall might be set up to block ICMP ping requests. But there's no way that same firewall should be completely
    and naively blocking all ICMP packets.

    Thanks for that explanation.

    What I gather is that the "problem" isn't how I'm running ping
    or traceroute. The network problem is something more abstract.

    Here's what I know:
    - I seem to be the only one with this problem.
    - It does NOT happen when I go to my neighbor's house using my PC.
    - The problem comes and goes (and stays for months).
    - Nothing gets past the hop before centos.org.
    - I can't go around that penultimate router without using Tor.
    - Since TOR works on all the PCs in the house, it's not the PCs.
    and
    - It's not how I'm running the web, traceroute, or ping.

    Since the problem seems to be at the penultimate hop, is there
    any way, other than TOR, to get around that hop (from my own
    home network)?

    Are there public proxies I can set up for Firefox?






    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Wed Oct 9 21:21:31 2013
    On Wed, 09 Oct 2013 19:27:40 +0100, Chris Davies wrote:

    If it still can't access centos.org, even though you've got your MTU
    down at 500 then the chances are that this suggestion is inappropriate
    for your situation.

    The MTU setting made no difference to the web situation.
    The ONLY things that seem to work are:
    a) Go to my neighbor's wireless setup
    b) Use TOR

    It's almost as if my IP address is being blocked by
    that penultimate router.

    Is that possible?


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Wed Oct 9 21:23:08 2013
    On Wed, 09 Oct 2013 19:58:49 +0000, unruh wrote:

    There is something about centos.org
    that is behaving weirdly. Now it could be something on your end, and it
    is almost certainly something on their end. They may have decided that
    you are a pain in the ass and blackballed you (I have no idea why), or
    it might be some sort of technical incompatibility between you and them.

    I have long ago written to the Centos.org sysadmins, and they confirm
    there is nothing wrong with my IP address or login account.

    (The login works fine and no, there's no reason for them to have
    blackballed me.)

    If it were *that* simple, I wouldn't be asking for networking
    advice here ... :)

    This is not a simple one.


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Wed Oct 9 21:27:02 2013
    On Wed, 09 Oct 2013 19:58:49 +0000, unruh wrote:

    Note you could take your computer with you to some other place which
    connects to the web in some other way than your microwave link and see
    if that works there.

    It's not the computer because that same computer works fine at
    the library and at Starbucks and at a neighbor's house.

    The ONLY thing I can think of that's different is
    a) My IP address (it's static)
    b) My home broadband router (standard setup)
    c) My WISP radio (standard setup)

    But, all of this is local.

    The problem actually seems to occur way down at hop #15,
    which is beyond my control (far beyond my control).

    Is there any way to go around that hop #15?


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From unruh@1:0/0 to All on Wed Oct 9 21:30:23 2013
    On 2013-10-09, Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
    On 9.10.13 9:52 , billy wrote:
    On Wed, 09 Oct 2013 11:28:22 -0700, Mike Easter wrote:

    Q: What is the web browser using? (ICMP? TCP?)

    TCP. But the 'process' involves TCP/IP.

    Hi Mike,

    So, if the web browser is what is failing, and if the
    debug commands using TCP also fail, what value is there
    in everyone saying that ICMP is dropped?

    What does ICMP have to do with the web browser failing?

    That is, why is everyone suggesting I test ICMP when the
    failure of the web browser is the problem I'm trying to
    test?

    I don't understand why ICMP has 'anything' directly to do
    with the web browser failing (other than ICMP also fails).


    PLEASE do get a text on TCP, read and understand it.
    It explains the usage.

    ICMP is a helper protocol inside the TCP/IP protocol suite.
    TCP uses ICMP to detect a suitable segment (transmission
    block) size.

    Your web browser needs UDP for name resolution, TCP for
    page transfer and ICMP to help TCP work, and all run
    using IP.

    But he has stated that they all work on other web sites. Only on
    centos.org do they fail, apparently.


    Can you ping the target from your computer?

    He says he cannot, although he keeps showing the output of traceroute
    rather than ping.


    It works perfectly from here:

    --- clip clip ---

    tauno-voipios-macbook-pro-2:~ tauno$ ping centos.org
    PING centos.org (72.232.194.162): 56 data bytes
    64 bytes from 72.232.194.162: icmp_seq=0 ttl=52 time=161.925 ms
    64 bytes from 72.232.194.162: icmp_seq=1 ttl=52 time=164.736 ms
    c64 bytes from 72.232.194.162: icmp_seq=2 ttl=52 time=161.303 ms
    64 bytes from 72.232.194.162: icmp_seq=3 ttl=52 time=165.196 ms
    64 bytes from 72.232.194.162: icmp_seq=4 ttl=52 time=165.483 ms
    ^C

    --- clip clip ---

    I can also access the web site with a browser.

    Yes, he also says that his neighbors have no problem either. So it is
    something peculiar to the interaction between his machine and that
    particular site. -- eg firewall on centos which rejects him. Firewall on
    his side which rejects the far response. (probably he should make sure
    that all firewalls are disabled and try to contact them, just to rule
    out the firewall on his machines.)



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From unruh@1:0/0 to All on Wed Oct 9 21:36:40 2013
    On 2013-10-09, billy <billy@is.invalid> wrote:

    You could try
    telnet centos.com 80

    $ telnet www.centos.org 80
    Trying 72.232.194.162... <==== it hangs here for a minute or two
    telnet: connect to address 72.232.194.162: Connection timed out

    The problem is that NOTHING will connect to www.centos.org
    that comes from me. If I use TOR, everything works fine.

    Well, a firewall might be rejecting you or the reply.
    Switch off all firewalls-- on your machine, your router, etc to see if
    that might be the problem.

    (switch them on again after the test)



    THAT is what I'm trying to debug.
    But, I don't know how.


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From unruh@1:0/0 to All on Wed Oct 9 21:38:37 2013
    ["Followup-To:" header set to comp.os.linux.networking.]
    On 2013-10-09, billy <billy@is.invalid> wrote:
    On Wed, 09 Oct 2013 19:58:49 +0000, unruh wrote:

    There is something about centos.org
    that is behaving weirdly. Now it could be something on your end, and it
    is almost certainly something on their end. They may have decided that
    you are a pain in the ass and blackballed you (I have no idea why), or
    it might be some sort of technical incompatibility between you and them.

    I have long ago written to the Centos.org sysadmins, and they confirm
    there is nothing wrong with my IP address or login account.

    (The login works fine and no, there's no reason for them to have
    blackballed me.)

    What do you mean "the login works fine"? You told us you could not
    connect in any way to that machine? Was that wrong?


    If it were *that* simple, I wouldn't be asking for networking
    advice here ... :)

    It is really hard to give help if information supplied is missing or
    wrong.


    This is not a simple one.


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From unruh@1:0/0 to All on Wed Oct 9 21:46:19 2013
    On 2013-10-09, Rick Jones <rick.jones2@hp.com> wrote:

    The protocols layer and in some cases intertwine. What you call "the
    web" sits on top of a protocol called HTTP (HyperText Transfer
    Protocol). HTTP makes use of the services of TCP (Transmission
    Control Protocol). TCP makes use of IP (Internet Protocol). IP will
    make use of whatever link-layer protocol is available in its
    sitaution. For your end systems that will be "Ethernet" protocol over
    your WiFi connection.

    HTTP
    TCP
    IP
    Ethernet/WiFi/whatnot

    Within/alongside IP is ICMP (Internet Control Message Protocol). ICMP
    is used to provide some "Hey, you should know this" kinds of messages
    back to traffic sources.

    So, simplifying a bit, when you try to access www.centos.org from your
    web browser, the browser will generate an HTTP message the browswer

    Well, no. He tried
    telnet centos.org 80
    which generates no HTTP message. Just a bare connection request.
    It fails.


    wants to get to HTTP at www.centos.org. That HTTP message will be
    handed-off to TCP to transmit in one or more TCP segments to TCP at www.centos.org (segment = what a packet is called in the context of
    TCP). The TCP segment(s) will be handed off to IP, which will
    encapsulate them in one or more IP datagrams (datagram = what a packet
    is called in the context of IP) destined to the IP address of
    www.centos.org. IP will then hand its datagrams to the "data link"
    layer (eg Ethernet etc) which will do its encapsulation. It will then
    go across the data link destined for IP at the "next hop" where the
    data-link layer message will decapsulate the IP datagram and hand it
    to IP at that hop. IP at that hop will then decide what to do with
    the datagram, which is being sent to the/an IP address for
    www.centos.org. There will probably be another "next hop" and so on
    until the traffic arrives at www.centos.org. IP at www.centos.org
    will then decapsulate the TCP segment from the IP datagram, and TCP
    will decapsulate the HTTP message and hand it to the HTTP server.

    The HTTP response will flow back to you via a similar mechanism.

    Those different lines you see in the output of traceroute are the
    "next hops" along the way from your system to www.centos.org.

    Now, the data links at all those next hops may have different limits
    for how large a packet they can transmit. If an IP datagram arrives
    at a "next hop" (aka an IP router), and IP there determines that where
    it needs to be sent-out next is over a data link with a packet size
    smaller than the IP datagram it needs to send, IP decides to send back
    to the traffic's source an ICMP message saying "Hey, the datagram you
    sent is too large for me to send, you should send smaller IP
    datagrams" (There is more to it than this, but I'm simplifying).

    He sent really small packets.
    ping is I believe 80 bytes.
    And they are not rejecting ping packets (I just checked.)



    There are other sorts of ICMP "Hey!" messages. One of them is
    "Maximum Hop Count Reached" - that is the ICMP message that (default) traceroute relies upon receiving. In the header of an IP datagram
    there is a field called the "TTL" (Time To Live) which is really a
    maximum hop count. As the IP datagram passes through an IP router,
    the router decrements the count by one, and when it hits zero, that IP
    is supposed to send back an ICMP message that says "Hey! The datagram
    you sent had its maximum hop count expire before it reached its
    destination." Traceroute works by sending an IP datagram over and
    over again, with the TTL increased by one each time.

    Ping sends a different sort of ICMP message, one that says "Please
    tell me that you got this" - more formally known as an ICMP Echo
    Request. The destination IP will send an ICMP Echo Response back to
    the originator when it receives one.

    Now, all these things I've described rely on ICMP messages making it
    back to the source of the IP/ICMP datagram triggering them. But some
    network administrators feel that allowing (certain) ICMP traffic to
    pass represents a security vulnerablity, so they block ICMP traffic.

    Except they do not. They come back to me with no trouble. They come back
    to his neighbour with no trouble.


    If ICMP traffic is blocked at a point part-way between you and www.centos.org, you will see the traceroute "stop" (those '*' lines
    starting indicating there was no response with the TTL set to that
    many hops). You will also not have ping "work" - it won't see any
    ICMP Echo Reply messages.

    Yup, but why only to him?



    If TCP tries to send a TCP segment that was carried in an IP datagram
    which needed to be fragmented somewhere in the middle there, then when
    it goes to send traffic it will appear to disappear - it hits an IP
    router (next hop) that tried to send it but couldn't and the "Hey!"
    message that IP router tried to send back was blocked.

    Now, by default, ping and traceroute do not send very large IP
    datagrams, so the chances of those packets arriving at a next hop
    where fragmentation is needed is pretty small.

    Also, not all TCP segments are the same size - the TCP segments used
    to setup a TCP connection for example are pretty small. That is what
    was behind some of the "try telnet www.centos.org 80" suggestions -
    that is an old school way to just try establishing a TCP connection
    but not actually send any data on it. Those TCP segments will be
    small.

    And they failed as well, so I think we can eliminate packet size as an
    issue.



    Why try that? (Or for that matter the pings or traceroutes with
    options set to send larger packets) Because it is how one tries to see
    if 'the problem" centers on packets which are too large arriving at a
    small data link somewhere, or simply a routing issue somewhere in the
    middle of the Internet. If the "telnet www.centos.org 80" establishes
    the TCP connection, you can assume that it isn't a routing issue. In
    that case, a/the remedy is to ensure that TCP at your system and TCP
    at the system(s) to which you are connecting never try to send TCP
    segments which become IP datagrams which are too large to send without fragmentation. One can do that by shrinking the MTU of the network
    interface of your system. When TCP establishes a connection, part of
    that is exchanging with the other side (eg www.centos.org) the Maximum Segment Size (MSS) for the connection. There are several inputs to
    that exchange, one of which is the MTU of your local interface. The
    smallest MSS (your's or that of www.centos.org) is the one that will
    be used for traffic in both directions.

    Now, if the telnet www.centos.org 80 does not succeed, that means
    there is some sort of routing issue. That was already partially
    suggested by the ping and traceroute "failures" you've already
    reported (if memory serves) but since the ICMP traffic on which they
    rely can be blocked, their failure is not conclusive.

    So, why does the route up to the last hop work, but not that last hop?
    And why does it work for everyone else. It is really really hard to see
    it as a routing issue.




    What sort of routing issue might it be? Well, one could be that there
    is a simply problem at or after one of those next hops you see in the traceroute output. That is why some have suggested you lookup the information about who runs those and contact them.

    It is possible that your source IP has been "black listed" for some
    reason or other - either at/past the ISP responsible for the last
    "next hop" you see in traceroute or perhaps even at www.centos.org.
    Perhaps at one point the IP address you have from your ISP was
    involved in something considered nefarious or anti-social.

    That you could still get to www.centos.org using TOR would remain
    consistent with your IP address (the one being assigned to your home
    gateway by your ISP) being blacklisted because the entire point of TOR
    (as I understand it) is to hid your actual IP address. It does that
    by adding some additional layers to the top of what I mentioned
    above. (As I understand it, I don't actually have any practical
    experience with TOR).

    Yes, I does look like a firewall issue, but he claims that centos claims
    that there is no such issue.



    rick jones

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From unruh@1:0/0 to All on Wed Oct 9 21:47:36 2013
    On 2013-10-09, billy <billy@is.invalid> wrote:
    On Wed, 09 Oct 2013 19:27:40 +0100, Chris Davies wrote:

    If it still can't access centos.org, even though you've got your MTU
    down at 500 then the chances are that this suggestion is inappropriate
    for your situation.

    The MTU setting made no difference to the web situation.
    The ONLY things that seem to work are:
    a) Go to my neighbor's wireless setup
    b) Use TOR

    It's almost as if my IP address is being blocked by
    that penultimate router.

    Is that possible?

    Of course it is possible.



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From unruh@1:0/0 to All on Wed Oct 9 22:15:28 2013
    On 2013-10-09, billy <billy@is.invalid> wrote:
    On Wed, 09 Oct 2013 19:58:49 +0000, unruh wrote:

    Note you could take your computer with you to some other place which
    connects to the web in some other way than your microwave link and see
    if that works there.

    It's not the computer because that same computer works fine at
    the library and at Starbucks and at a neighbor's house.

    The ONLY thing I can think of that's different is
    a) My IP address (it's static)
    b) My home broadband router (standard setup)
    c) My WISP radio (standard setup)

    But, all of this is local.

    The problem actually seems to occur way down at hop #15,
    which is beyond my control (far beyond my control).

    Is there any way to go around that hop #15?

    For you? No. Get in touch with them.



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Mike Easter@1:0/0 to All on Wed Oct 9 22:51:29 2013
    billy wrote:
    Mike Easter wrote:

    Q: What is the web browser using? (ICMP? TCP?)

    TCP. But the 'process' involves TCP/IP.

    Hi Mike,

    So, if the web browser is what is failing, and if the
    debug commands using TCP also fail, what value is there
    in everyone saying that ICMP is dropped?

    What does ICMP have to do with the web browser failing?

    That is, why is everyone suggesting I test ICMP when the
    failure of the web browser is the problem I'm trying to
    test?

    Personally when I'm troubleshooting something I take into account the
    fact that some hops handle ICMP, UDP, and TCP differently. One of my preferred tools for testing access to a server is Steve Gibson's IDServe
    which runs under windows or WINE in linux and doesn't require
    installation in either.

    For this target I would be using TCP port 80 on/at the webserver at
    centos. The tool shows my system resolving the IP and connecting to the webserver there.

    Initiating server query ...
    Looking up IP address for domain: www.centos.org
    The IP address for the domain is: 72.232.194.162
    Connecting to the server on standard HTTP port: 80
    [Connected] Requesting the server's default page.
    The server returned the following response headers:
    [redact html from the centos Apache server]
    Query complete.

    I don't understand why ICMP has 'anything' directly to do
    with the web browser failing (other than ICMP also fails).

    From the other info you've posted here, your system when not reaching
    centos on port 80 TCP IDServe would show you resolving the name but not connecting, which IDServe interprets as the server being stealthed or
    not online, so its use wouldn't add anything to this particular
    problem's solution; but I mention it as an indication that 'typically' I
    don't use an ICMP tool to test some TCP-related server issues.


    --
    Mike Easter

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Mike Easter@1:0/0 to All on Wed Oct 9 23:14:24 2013
    billy wrote:

    (The login works fine and no, there's no reason for them to have
    blackballed me.)

    Login? Are you talking about login here?

    https://www.centos.org/user.php

    The difference between http and https protocols is the layering of http
    over the SSL/TLS protocol and the other difference is the use of port
    443 instead of 80.

    Or perhaps you are talking about logging in to some other server - the
    centos forums are at https centos as well.

    The bugs.centos server login is at a different IP 83.149.86.133


    --
    Mike Easter

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From unruh@1:0/0 to All on Thu Oct 10 00:15:44 2013
    On 2013-10-09, Mike Easter <MikeE@ster.invalid> wrote:
    billy wrote:
    Mike Easter wrote:

    Q: What is the web browser using? (ICMP? TCP?)

    TCP. But the 'process' involves TCP/IP.

    Hi Mike,

    So, if the web browser is what is failing, and if the
    debug commands using TCP also fail, what value is there
    in everyone saying that ICMP is dropped?

    What does ICMP have to do with the web browser failing?

    That is, why is everyone suggesting I test ICMP when the
    failure of the web browser is the problem I'm trying to
    test?

    Personally when I'm troubleshooting something I take into account the
    fact that some hops handle ICMP, UDP, and TCP differently. One of my preferred tools for testing access to a server is Steve Gibson's IDServe which runs under windows or WINE in linux and doesn't require
    installation in either.

    For this target I would be using TCP port 80 on/at the webserver at
    centos. The tool shows my system resolving the IP and connecting to the webserver there.

    Which was why I suggested
    telnet centos.org 80
    but that did not return anything for him. Everyone else in the world has
    no trouble connecting but he does and he wants to know why.


    Initiating server query ...
    Looking up IP address for domain: www.centos.org
    The IP address for the domain is: 72.232.194.162
    Connecting to the server on standard HTTP port: 80
    [Connected] Requesting the server's default page.
    The server returned the following response headers:
    [redact html from the centos Apache server]
    Query complete.

    I don't understand why ICMP has 'anything' directly to do
    with the web browser failing (other than ICMP also fails).

    From the other info you've posted here, your system when not reaching centos on port 80 TCP IDServe would show you resolving the name but not connecting, which IDServe interprets as the server being stealthed or
    not online, so its use wouldn't add anything to this particular
    problem's solution; but I mention it as an indication that 'typically' I don't use an ICMP tool to test some TCP-related server issues.



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From billy@110:110/2002 to All on Thu Oct 10 00:19:59 2013
    unruh wrote:

    Which was why I suggested
    telnet centos.org 80
    but that did not return anything for him.
    Everyone else in the world has
    no trouble connecting but he does and he wants to know why.

    That's a perfect summary!
    I can't imagine that I'm singled out in this world for not
    connecting, for months at a time, to centos.org (it happened
    with one other web site - but it was so long ago that I've
    forgotten which it was).

    One question I have is WHICH site is dropping my packets?

    Is it the last site that returns traceroute values?
    Os is it the first site that has all asterisks?

    # traceroute -M icmp www.centos.org
    traceroute to www.centos.org (72.232.194.162), 30 hops max, 60 byte
    packets
    1 192.168.1.1 (192.168.1.1) 2.840 ms 2.832 ms 2.829 ms
    2 MYIPADDRESS (xxx.xxx.xxx.xxx) 2.827 ms 5.830 ms 5.834 ms
    3 10.50.0.1 (10.50.0.1) 9.369 ms 14.568 ms 14.566 ms
    4 10.25.0.1 (10.25.0.1) 14.562 ms 18.614 ms 18.610 ms
    5 10.20.0.1 (10.20.0.1) 79.603 ms 83.180 ms 83.177 ms
    6 10.0.0.1 (10.0.0.1) 454.682 ms 251.479 ms 251.450 ms
    7 69.36.226.193 (69.36.226.193) 251.420 ms 402.683 ms 402.652 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 402.624 ms 397.148 ms
    397.127 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 397.107 ms 284.336
    ms 284.314 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 287.164 ms 153.090 ms 162.910 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 162.878 ms 156.560
    ms 156.544 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 156.516 ms 2751.856 ms 2751.839 ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 2586.242 ms 97.179 ms 97.152 ms
    14 border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 97.123 ms border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 74.418 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 87.348 ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 87.329 ms
    65.781 ms 120.012 ms
    16 * * *
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *
    #

    Is it hop 15 or 16 above which is dropping my packets?





    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Thu Oct 10 00:30:08 2013
    Mike Easter wrote:

    Login? Are you talking about login here?
    https://www.centos.org/user.php

    All I do, on TOR, is type 'http://www.centos.org' or "centos.org",
    and it gives me a screen where I can enter in my login and password
    and it logs me in. On Firefox, I do the same, when everything is
    working.

    Then, for months at a time, I can't even connect to www.centos.org
    or to 'centos.org' - getting the standard "connection timed out"
    message.

    When I run a traceroute (any type of traceroute), the result is
    that the last hop before centos.org is the last hop that returns
    anything. The centos.org hop is asterisked out.

    There's absolutely nothing wrong with my login (I easily log in
    with TOR, and I have an old thread asking THEM what's going on,
    and they don't know either).

    So, I 'think' it's the ISP that they use.

    I remember having a similar problem with telephones not being able
    to call certain numbers, and, we found out it was a routing thing
    at the Ooma headquarters. Nobody on the planet could call these
    specific numbers, one of whom was a relative of mine so I knew that
    the number existed. Yet, nobody could call the number from VOIP.

    Same kind of idea seems to be here. Some router somewhere is very
    badly set up.

    The funny thing, is that I'm the only one with the problem.
    Worse yet, there are no debugging tools for when a router is
    dropping packets. That's the saddest part.

    I've been trying to solve this for two years running.
    Or, at least understand how it could possibly happen.


    The bugs.centos server login is at a different IP 83.149.86.133

    When I point my browser to http://83.149.86.133 I get the message:
    Forbidden
    You don't have permission to access / on this server.
    Apache/2.2.3 (CentOS) Server at 83.149.86.133 Port 80

    # telnet 83.149.86.133 80
    Trying 83.149.86.133...
    Connected to 83.149.86.133.
    Escape character is '^]'.
    HEAD HTTP/1.0
    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
    <html><head>
    <title>400 Bad Request</title>
    </head><body>
    <h1>Bad Request</h1>
    <p>Your browser sent a request that this server could not
    understand.<br />


    <address>Apache/2.2.3 (CentOS) Server at mirror.centos.org Port
    80</address>
    </body></html>
    Connection closed by foreign host.

    # traceroute -M icmp 83.149.86.133
    # traceroute -M icmp 83.149.86.133
    traceroute to 83.149.86.133 (83.149.86.133), 30 hops max, 60 byte
    packets
    1 192.168.1.1 (192.168.1.1) 3.423 ms 3.405 ms 6.261 ms
    2 MY_WISP_ADDRESS (xx.xx.xx.xx) 9.844 ms 9.842 ms 9.839 ms
    3 10.50.0.1 (10.50.0.1) 15.284 ms 139.930 ms 139.937 ms
    4 10.25.0.1 (10.25.0.1) 148.735 ms 148.734 ms 148.729 ms
    5 10.20.0.1 (10.20.0.1) 164.306 ms 169.567 ms 169.564 ms
    6 10.0.0.1 (10.0.0.1) 344.049 ms 70.997 ms 189.575 ms
    7 69.36.226.193 (69.36.226.193) 189.531 ms 34.070 ms 136.902 ms
    8 vl2.core2.scl.layer42.net (69.36.225.130) 139.000 ms 47.370 ms
    133.156 ms
    9 xe3-4.core1.mpt.layer42.net (69.36.239.110) 133.125 ms 35.300 ms
    61.929 ms
    10 any2ix.coresite.com (206.223.143.213) 73.838 ms 32.061 ms 94.368
    ms
    11 te5-2.msc2.wdc.leaseweb.net (217.20.125.40) 155.304 ms 99.444 ms 109.215 ms
    12 * * *
    13 31.31.32.5 (31.31.32.5) 260.392 ms 220.540 ms 229.781 ms
    14 ten5-4.sbp-sr2.leaseweb.net (85.17.100.202) 229.737 ms 166.166 ms 243.165 ms
    15 centos.yourname.nl (83.149.86.133) 239.189 ms 176.139 ms 194.943
    ms

    So, I have absolutely no problem getting to this site.
    But, why would I have a problem getting to centos.org?

    Could it be that anything after 15 hops fails no matter what?
    To test, do you know of a site that would be more than 15 hops
    away from San Francisco, CA?

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Thu Oct 10 00:33:04 2013
    Mike Easter wrote:

    I mention it as an indication that 'typically' I
    don't use an ICMP tool to test some TCP-related server issues.

    I'm beginning to wonder if anything after about 15 hops is
    dropping the connection for me?

    Could it be that the path to centos.org just happens to be
    longer than any other path I've tried?

    The path to the centos bug server you gave me worked fine, but
    it only took 15 hops.

    Do you have a way for me to pick somewhere far far away from
    San Francisco CA to see if it's simply the long path that is
    causing the problem (i.e., more than 16 hops)?


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Thu Oct 10 00:35:11 2013
    unruh wrote:

    Is there any way to go around that hop #15?
    For you? No. Get in touch with them.

    I will contact them at the email addresses already posted
    and ask them if they're periodically doing something nasty
    to my IP address for months at a time (like putting me on a
    blacklist or something).

    I'll report back if/when they respond.


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Thu Oct 10 00:39:41 2013
    unruh wrote:

    So, why does the route up to the last hop work, but not that last
    hop?
    And why does it work for everyone else. It is really really hard to
    see
    it as a routing issue.

    Everything you said is right on the money.
    It's frustratingly hard to figure out.

    The only two ideas "I" can come up with are:
    1. Someone is blocking me (but I can't imagine why)
    2. The path is too long for something (but I don't know what).

    In the first case, I'm not sure if the blocker would be the
    15th hop (which returns packets) not forwarding them on to
    the Centos server or if it's the 16th hop (the Centos server)
    not responding back. Is there a way to tell?

    In the second case, it would be useful to test a similarly
    long (at least 16 hops) path. Or, maybe there's a way to slow
    down my pings so that I can reproduce the problem in fewer hops?


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Thu Oct 10 00:47:44 2013
    unruh wrote:

    Yes, I does look like a firewall issue, but he claims
    that centos claims that there is no such issue.

    I understand and agree with your use of "claims", as you
    don't know what I've been told.

    I can google for the public thread where I asked them
    (and they responded in email privately also) and point
    you to that. It was about six months to a year ago.

    Gimme a minute to find it (Google will find it but I won't
    be able to open it up - but you should be able to).

    OK. Found it with Google on CentOS.org
    Title: What can I do to UNDERSTAND why www.centos.org fails for me
    Date: MaMar 1, 2013 - 12 posts - ‎4 authors

    Of course, I can't "go" to that URL (since it's on CentOS.org)
    but it looks like it's mirrored here:
    linuxreference.com/modules/newbb/viewtopic.php?topic_id=41677&forum=55

    Hey! Guess what? I can't get to "linuxreference.com" either!
    Just like centos.org, it goes to asterisks on the 16th hop!

    I'm getting tired of redacting my IP address, so I'm letting it
    show here. I hope I don't regret that! :)

    # traceroute -M icmp linuxreference.com
    traceroute to linuxreference.com (72.232.194.162), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 2.851 ms 2.836 ms 2.839 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 5.849 ms 5.849 ms
    5.846 ms
    3 10.50.0.1 (10.50.0.1) 5.845 ms 19.117 ms 19.115 ms
    4 10.25.0.1 (10.25.0.1) 19.111 ms 19.108 ms 26.045 ms
    5 10.20.0.1 (10.20.0.1) 58.291 ms 60.735 ms 60.733 ms
    6 10.0.0.1 (10.0.0.1) 70.816 ms 10.336 ms 15.323 ms
    7 69.36.226.193 (69.36.226.193) 15.291 ms 77.227 ms 140.765 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 148.204 ms 32.072 ms
    32.025 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 35.854 ms 82.604 ms 137.427 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 137.395 ms 77.731 ms
    86.088 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 92.609 ms 105.335 ms 105.305 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 105.262 ms 130.219 ms
    145.768 ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 145.746 ms 66.089 ms
    83.514 ms
    14 border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 83.485 ms border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 75.311 ms 75.275
    ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 75.241 ms
    68.198 ms 85.547 ms
    16 * * *
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From Mike Easter@1:0/0 to All on Thu Oct 10 01:02:34 2013
    billy wrote:
    Mike Easter wrote:

    The bugs.centos server login is at a different IP 83.149.86.133

    When I point my browser to http://83.149.86.133 I get the message:
    Forbidden
    You don't have permission to access / on this server.
    Apache/2.2.3 (CentOS) Server at 83.149.86.133 Port 80

    When you are trying to access a webserver, you should aim at its name,
    not its IP address for general purposes. One webserver might serve many names. The bugs front page is at: http://bugs.centos.org/main_page.php

    login is at
    http://bugs.centos.org/login_page.php?return=%2Fmain_page.php%3F

    # telnet 83.149.86.133 80

    My browser pointed at that IP gives me a forbidden page instead of the bugs.centos front door..

    http://83.149.86.133
    Forbidden
    You don't have permission to access / on this server.
    Apache/2.2.3 (CentOS) Server at 83.149.86.133 Port 80

    Some webservers which serve only one front page will give you that page,
    but some will not serve you the page when addressed the IP way.

    That 'rule' does not apply to such as mailservers and news servers who
    don't care about the name vs the IP, except that the name is 'better' in
    the sense that the name might have more than one IP.

    <h1>Bad Request</h1>
    <p>Your browser sent a request that this server could not
    understand.<br />

    # traceroute -M icmp 83.149.86.133

    15 centos.yourname.nl (83.149.86.133) 239.189 ms

    So, I have absolutely no problem getting to this site.
    But, why would I have a problem getting to centos.org?

    bugs.centos.org is at a different place than centos.org but they have
    the same nameservice.

    Could it be that anything after 15 hops fails no matter what?
    To test, do you know of a site that would be more than 15 hops
    away from San Francisco, CA?

    I don't think that is a useful theory.


    --
    Mike Easter

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From billy@110:110/2002 to All on Thu Oct 10 00:58:00 2013
    unruh wrote:

    Yes, I does look like a firewall issue, but he claims
    that centos claims that there is no such issue.

    I can google just fine, so I found the original request way
    back in March on the Centos site (I subsequently got an email
    from the admins saying there's nothing wrong with my IP address).

    Here's what Google says the Centos article URL is: https://www.centos.org/modules/newbb/print.php?form=1&topic_id=43977&forum=58&o rder=ASC&start=0

    It's looking more and more like anything longer than about 15
    hops is dying for me. At least that's a preliminary guess.

    Notice I can get to this Centos mirror just fine:
    http://www.spinics.net/lists/centos/msg133862.html

    When I traceroute to it, I see a MUCH SHORTER route!

    # traceroute -M icmp www.spinics.net
    traceroute to www.spinics.net (66.135.57.166), 30 hops max, 60 byte
    packets
    1 192.168.1.1 (192.168.1.1) 2.849 ms 2.835 ms 2.831 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 2.855 ms 5.644 ms
    5.642 ms
    3 10.50.0.1 (10.50.0.1) 10.434 ms 10.432 ms 10.428 ms
    4 10.25.0.1 (10.25.0.1) 11.707 ms 15.285 ms 15.284 ms
    5 10.20.0.1 (10.20.0.1) 15.280 ms 19.197 ms 19.193 ms
    6 10.0.0.1 (10.0.0.1) 66.277 ms 60.195 ms 113.259 ms
    7 69.36.226.193 (69.36.226.193) 103.422 ms 213.710 ms 235.362 ms
    8 vl2.core2.scl.layer42.net (69.36.225.130) 235.334 ms 251.949 ms
    251.924 ms
    9 xe3-4.core1.mpt.layer42.net (69.36.239.110) 255.382 ms 134.485 ms 134.458 ms
    10 peer1.com.any2ix.coresite.com (206.223.143.79) 149.430 ms *
    180.892 ms
    11 10ge.xe-2-3-0.lax-600w-sbcor-2.peer1.net (216.187.124.121) 180.882
    ms 226.325 ms 226.300 ms
    12 10ge-ten1-2.dal-eqx-cor-1.peer1.net (216.187.88.131) 240.823 ms
    156.853 ms *
    13 * 10ge-xe-2-3-0.sat-8500v-sbcor-1.peer1.net (216.187.124.39)
    106.930 ms 106.903 ms
    14 10ge.xe-0-0-1.sat-8500v-sbdis-1.peer1.net (216.187.124.66) 106.884
    ms 141.148 ms 190.401 ms
    15 www.spinics.net (66.135.57.166) 131.264 ms 74.009 ms 83.791 ms



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Thu Oct 10 01:05:47 2013
    unruh wrote:

    he also says that his neighbors have no problem either.

    IIRC, when I had asked my neighbors, they had fewer hops to
    the same destination - so - I'm beginning to wonder if it's
    the sheer number of hops (or the time involved); but that's
    just a guess.

    I'd be glad to post traceroute or ping results to ANY server
    you suggest, so we can compare with you.

    I'll also ask a neighbor to send me his traceroutes and
    post them when/if I get them.

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Thu Oct 10 01:07:20 2013
    ~BD~ wrote:

    Have you been in touch here as suggested by Pooh?

    Technical Contact:
    Internap Network Services Corporation
    Domain Administrator
    One Ravinia Drive Suite 1300
    Atlanta, GA 30346
    US
    Phone: +1.8778434662
    Email: noc@internap.com

    If not, WHY not?

    I have sent all the email addresses on that list an email.
    I will write back if/when they respond.
    I don't have high hopes that they will - but - they might.

    I gave them the unedited traceroute results just like I gave you.

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Thu Oct 10 01:09:22 2013
    unruh wrote:

    Can you ping the target from your computer?

    He says he cannot, although he keeps showing the output of traceroute
    rather than ping.

    The ping is useless. Either that or I'm using it wrong.

    Here's the cut and paste for the pings on Knoppix:
    # ping -M icmp centos.org
    ping: wrong value for -M: do, dont, want are valid ones.

    # ping --help
    ping: invalid option -- '-'
    Usage: ping [-LRUbdfnqrvVaAD] [-c count] [-i interval] [-w deadline]
    [-p pattern] [-s packetsize] [-t ttl] [-I interface]
    [-M pmtudisc-hint] [-m mark] [-S sndbuf]
    [-T tstamp-options] [-Q tos] [hop1 ...] destination

    # # ping www.centos.org
    PING www.centos.org (72.232.194.162) 56(84) bytes of data.

    ^C
    - --- www.centos.org ping statistics ---
    286 packets transmitted, 0 received, 100% packet loss, time 285212ms

    (strangely it took minutes to time out on Knoppix so I killed it).




    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From Rick Jones@110:110/2002 to All on Thu Oct 10 01:24:19 2013
    Now, if the telnet www.centos.org 80 does not succeed, that means
    there is some sort of routing issue. That was already partially
    suggested by the ping and traceroute "failures" you've already
    reported (if memory serves) but since the ICMP traffic on which they
    rely can be blocked, their failure is not conclusive.

    So, why does the route up to the last hop work, but not that last hop?
    And why does it work for everyone else. It is really really hard to see
    it as a routing issue.

    I was, perhaps, being overly simplistic in my use of terms. I was
    lumping-in "classic" routing issues like loops and what not in with
    things like deliberate blacklisting.

    Yes, I does look like a firewall issue, but he claims that centos
    claims that there is no such issue.

    Anywhere between that 15th hop in the traceroute and centos.org I
    would think.

    That it comes and goes for months at a time has me wondering about the
    rate at which his ISP might be changing his assigned IP address (the
    one his gateway gets), and whether or not the "blackouts" correlated
    with that. That would require having kept a log of the noticed start
    and end of the blackouts and a log of the IP assigned by the ISP.

    rick jones
    --
    a wide gulf separates "what if" from "if only"
    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...

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: the Unofficial HP (110:110/2002@linuxnet)
  • From Rick Jones@110:110/2002 to All on Thu Oct 10 01:30:20 2013
    In comp.os.linux.networking billy <billy@is.invalid> wrote:
    Everything you said is right on the money.
    It's frustratingly hard to figure out.

    The only two ideas "I" can come up with are:
    1. Someone is blocking me (but I can't imagine why)

    They may not be blocking "you" specifically, but the IP address you
    have from your ISP.

    2. The path is too long for something (but I don't know what).

    In the first case, I'm not sure if the blocker would be the
    15th hop (which returns packets) not forwarding them on to
    the Centos server or if it's the 16th hop (the Centos server)
    not responding back. Is there a way to tell?

    Only by asking the 15th hop and getting a response. Basically, as
    frustrating as it is, in this matter you will be dependent on the
    kindness of strangers at the ISP(s) at/beyond that 15th hop.

    In the second case, it would be useful to test a similarly
    long (at least 16 hops) path. Or, maybe there's a way to slow
    down my pings so that I can reproduce the problem in fewer hops?

    Hop count to reach a given server depends on topology of the Internet
    not the rate at which you are issuing either pings or traceroute
    packets. To make a possibly lame analogy, driving from NY to LA you
    will go trough the same intermediate cities along the highway no
    matter how fast you drive.

    rick jones
    --
    firebug n, the idiot who tosses a lit cigarette out his car window
    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...

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: the Unofficial HP (110:110/2002@linuxnet)
  • From Rick Jones@110:110/2002 to All on Thu Oct 10 01:37:17 2013
    Mike Easter <MikeE@ster.invalid> wrote:
    billy wrote:

    Could it be that anything after 15 hops fails no matter what?
    To test, do you know of a site that would be more than 15 hops
    away from San Francisco, CA?

    I don't think that is a useful theory.

    It does seem unlikely, but if there is something capping the TTL at 15
    or 0xF I suppose that could explain it. Though in that case I would
    expect it to be all the time not months-on/months-off. Unless there
    was something else causing his traffic to go through different kit
    somewhere along the way.

    Perhaps some servers in Europe or Asia would be > 15 hops.

    rick jones
    --
    firebug n, the idiot who tosses a lit cigarette out his car window
    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...

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: the Unofficial HP (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Thu Oct 10 01:32:01 2013
    Rick Jones wrote:

    They may not be blocking "you" specifically,
    but the IP address you have from your ISP.

    Understood.

    The last time this happened, last March, I searched
    all the blacklist servers I could find, an my IP
    address was NOT in any of them.


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From David W. Hodgins@110:110/2002 to All on Thu Oct 10 02:25:27 2013
    On Wed, 09 Oct 2013 21:32:01 -0400, billy <billy@is.invalid> wrote:

    Rick Jones wrote:
    They may not be blocking "you" specifically,
    but the IP address you have from your ISP.

    Understood.
    The last time this happened, last March, I searched
    all the blacklist servers I could find, an my IP
    address was NOT in any of them.

    I've been following the thread. Given the traceroute output, my
    understanding is that your isp is giving your system an RFC1918
    address, within 10.*.*.*, which means the website will be seeing
    all connections from all customers of your isp as coming from the
    same ip address. It could well be that their automated software is
    blocking any ip address that is trying to make too many
    connections, in a given time frame, and keeping the address in the
    block list, for a specified amount of time. This may not be obvious
    to an admin of centos.org, without digging through the logs.

    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.)

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From unruh@1:0/0 to All on Thu Oct 10 03:17:08 2013
    On 2013-10-10, Rick Jones <rick.jones2@hp.com> wrote:
    Mike Easter <MikeE@ster.invalid> wrote:
    billy wrote:

    Could it be that anything after 15 hops fails no matter what?
    To test, do you know of a site that would be more than 15 hops
    away from San Francisco, CA?

    I don't think that is a useful theory.

    It does seem unlikely, but if there is something capping the TTL at 15
    or 0xF I suppose that could explain it. Though in that case I would
    expect it to be all the time not months-on/months-off. Unless there
    was something else causing his traffic to go through different kit
    somewhere along the way.

    Perhaps some servers in Europe or Asia would be > 15 hops.

    No It depends maily on the endpoints, not the distance.


    rick jones

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From billy@110:110/2002 to All on Thu Oct 10 03:48:24 2013
    David W. Hodgins wrote:

    Given the traceroute output, my
    understanding is that your isp is giving your system an RFC1918
    address, within 10.*.*.*, which means the website will be seeing
    all connections from all customers of your isp as coming from the
    same ip address.

    I think I understand what you're saying, because, in effect, it's
    what our home broadband routers do. Right?

    For example, the home broadband router has an IP address where
    all the computers behind it look, to the outside, as the IP
    address of the router.

    Are you saying that the exit node of the WISP, which is 10.0.0.1
    in the traceroute below, is what they're blocking?

    traceroute -M icmp google.com
    traceroute to google.com (74.125.239.135), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 2.841 ms 2.826 ms 2.823 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 6.188 ms 6.188 ms
    6.186 ms
    3 10.50.0.1 (10.50.0.1) 6.186 ms 8.402 ms 12.673 ms
    4 10.25.0.1 (10.25.0.1) 12.669 ms 12.666 ms 12.663 ms
    5 10.20.0.1 (10.20.0.1) 20.944 ms 59.871 ms 59.875 ms
    6 10.0.0.1 (10.0.0.1) 177.035 ms 77.696 ms 77.672 ms
    7 69.36.226.193 (69.36.226.193) 77.655 ms 22.190 ms 82.922 ms
    8 vl2.core2.scl.layer42.net (69.36.225.130) 134.102 ms 64.071 ms
    125.261 ms
    9 eqixsj-google-gige.google.com (206.223.116.21) 125.244 ms 52.387
    ms 52.368 ms
    10 216.239.49.170 (216.239.49.170) 52.340 ms 79.126 ms 82.842 ms
    11 66.249.95.31 (66.249.95.31) 82.825 ms 72.917 ms 72.886 ms
    12 nuq05s02-in-f7.1e100.net (74.125.239.135) 56.810 ms 17.257 ms
    22.447 ms


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From unruh@1:0/0 to All on Thu Oct 10 05:10:21 2013
    On 2013-10-10, billy <billy@is.invalid> wrote:
    David W. Hodgins wrote:

    Given the traceroute output, my
    understanding is that your isp is giving your system an RFC1918
    address, within 10.*.*.*, which means the website will be seeing
    all connections from all customers of your isp as coming from the
    same ip address.

    I think I understand what you're saying, because, in effect, it's
    what our home broadband routers do. Right?

    For example, the home broadband router has an IP address where
    all the computers behind it look, to the outside, as the IP
    address of the router.

    Are you saying that the exit node of the WISP, which is 10.0.0.1
    in the traceroute below, is what they're blocking?

    No. It had better not be 10.0.0.1 since that would not route in the
    outside world at all. It would not even get to the first hop, never mind
    15 since nothing would know where to send the packet (there are millions
    of systems with that address in the world). The exit node or something
    further up the chain had better have a routable address.


    traceroute -M icmp google.com
    traceroute to google.com (74.125.239.135), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 2.841 ms 2.826 ms 2.823 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 6.188 ms 6.188 ms 6.186 ms
    3 10.50.0.1 (10.50.0.1) 6.186 ms 8.402 ms 12.673 ms
    4 10.25.0.1 (10.25.0.1) 12.669 ms 12.666 ms 12.663 ms
    5 10.20.0.1 (10.20.0.1) 20.944 ms 59.871 ms 59.875 ms
    6 10.0.0.1 (10.0.0.1) 177.035 ms 77.696 ms 77.672 ms

    So all of the above are non-routable addresses. (ie, they cannot be
    routed on the public internet, but can be on a private net).
    That 10.0.0.1 is the address of that router as seen from inside, rather
    than the address it presents the world.
    It is really strange to get a public address and then get a bunch of
    private addresses.

    7 69.36.226.193 (69.36.226.193) 77.655 ms 22.190 ms 82.922 ms
    8 vl2.core2.scl.layer42.net (69.36.225.130) 134.102 ms 64.071 ms 125.261 ms
    9 eqixsj-google-gige.google.com (206.223.116.21) 125.244 ms 52.387
    ms 52.368 ms
    10 216.239.49.170 (216.239.49.170) 52.340 ms 79.126 ms 82.842 ms
    11 66.249.95.31 (66.249.95.31) 82.825 ms 72.917 ms 72.886 ms
    12 nuq05s02-in-f7.1e100.net (74.125.239.135) 56.810 ms 17.257 ms
    22.447 ms


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From ~BD~@1:0/0 to All on Thu Oct 10 06:41:33 2013
    billy wrote:
    ~BD~ wrote:

    Have you been in touch here as suggested by Pooh?

    Technical Contact:
    Internap Network Services Corporation
    Domain Administrator
    One Ravinia Drive Suite 1300
    Atlanta, GA 30346
    US
    Phone: +1.8778434662
    Email: noc@internap.com

    If not, WHY not?

    I have sent all the email addresses on that list an email.
    I will write back if/when they respond.
    I don't have high hopes that they will - but - they might.

    I gave them the unedited traceroute results just like I gave you.

    Good luck, Billy! :-)

    I can just *feeeeeel* your frustration. Maddening, for sure!

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From p-0''0-h the cat (ES)@110:110/2002 to All on Thu Oct 10 08:15:51 2013
    On Thu, 10 Oct 2013 00:35:11 +0000, billy <billy@is.invalid> wrote:

    unruh wrote:

    Is there any way to go around that hop #15?
    For you? No. Get in touch with them.

    I will contact them at the email addresses already posted
    and ask them if they're periodically doing something nasty
    to my IP address for months at a time (like putting me on a
    blacklist or something).

    Yeah, that'll get their back up. Just be polite and present the results
    of your tests. Wide area networking is an altogether different game. I
    wouldn't tell them their job, because you'll be wrong.


    I'll report back if/when they respond.

    --
    p-0.0-h the cat

    Internet Terrorist, Mass sock puppeteer, Agent provocateur, Gutter rat,
    Devil incarnate, Linux user#666, BaStarD hacker, Resident evil, Monkey Boy, Certifiable criminal, Spineless cowardly scum, textbook Psychopath,
    the SCOURGE, l33t p00h d3 tr0ll, p00h == lam3r, p00h == tr0ll, troll infme, the OVERCAT [The BEARPAIR are dead, and we are its murderers], lowlife troll, shyster [pending approval by STATE_TERROR], cripple, sociopath, kook,
    smug prick, smartarse, arsehole, moron, idiot, imbecile, snittish scumbag, liar, and shill.

    Honorary SHYSTER and FRAUD awarded for services to Haberdashery.
    By Appointment to God Frank-Lin.



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: ACF's purry underbelly (110:110/2002@linuxnet)
  • From Chris Davies@110:110/2002 to All on Thu Oct 10 09:31:38 2013
    Reply-To: chris@roaima.co.uk

    In comp.os.linux.networking billy <billy@is.invalid> wrote:
    2. The path is too long for something (but I don't know what).

    That's another good theory. Each time a packet goes through a router, its
    "TTL" (Time To Live) is decremented. When it reaches zero the packet is discarded. The reasoning behind this is that it handles looping routes
    safely. The downside is that if the target is further away from you than
    the initial TTL you can't reach it.

    You can check your default TTL with this command:

    cat /proc/sys/net/ipv4/ip_default_ttl

    On my system it returns 64. You can change the value (as root, of course)
    by using echo to write a different value to it:

    sudo -s # become root
    echo 128 > /proc/sys/net/ipv4/ip_default_ttl

    Chris

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Roaima. Harrogate, North Yorkshire, UK (110:110/2002@linuxnet)
  • From unruh@1:0/0 to All on Thu Oct 10 17:37:04 2013
    On 2013-10-10, Chris Davies <chris-usenet@roaima.co.uk> wrote:
    In comp.os.linux.networking billy <billy@is.invalid> wrote:
    2. The path is too long for something (but I don't know what).

    That's another good theory. Each time a packet goes through a router, its "TTL" (Time To Live) is decremented. When it reaches zero the packet is discarded. The reasoning behind this is that it handles looping routes safely. The downside is that if the target is further away from you than
    the initial TTL you can't reach it.

    You can check your default TTL with this command:

    cat /proc/sys/net/ipv4/ip_default_ttl

    On my system it returns 64. You can change the value (as root, of course)
    by using echo to write a different value to it:

    sudo -s # become root
    echo 128 > /proc/sys/net/ipv4/ip_default_ttl

    Chris

    But surely his chain does not take 64 sec to reach the far end (assuming
    I am reading that correctly). That would be absurd. But I guess changing
    that default does not harm much. On the other hand, somewhere down the
    route that ttl could be changed by one of the other links in the chain.

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From billy@110:110/2002 to All on Thu Oct 10 20:03:54 2013
    Rick Jones wrote:

    Perhaps some servers in Europe or Asia would be > 15 hops.

    As additional datapoints, my neighbors on the same WISP to run
    the same traceroutes as I did.

    They get through.

    Here are the details from one neighbor, with her IP address
    redacted for privacy.

    NEIGHBOR #1:

    C:\Windows\system32>tracert centos.org

    Tracing route to centos.org [72.232.194.162]
    over a maximum of 30 hops:

    1 <1 ms <1 ms <1 ms REDACTED_IP.ridgewireless.net
    [xx.xx.xx.xx]
    2 3 ms 1 ms 1 ms 10.50.0.1
    3 9 ms 5 ms 31 ms 10.25.0.1
    4 5 ms 11 ms 13 ms 10.20.0.1
    5 33 ms 28 ms 25 ms 10.0.0.1
    6 68 ms 70 ms 62 ms 69.36.226.193
    7 40 ms 13 ms 66 ms vl2.core1.scl.layer42.net
    [69.36.225.129]
    8 14 ms 6 ms 12 ms 216.156.84.141.ptr.us.xo.net
    [216.156.84.141]
    9 86 ms 85 ms 87 ms 207.88.14.233.ptr.us.xo.net
    [207.88.14.233]
    10 81 ms 63 ms 62 ms vb15.rar3.dallas-tx.us.xo.net
    [207.88.12.45]
    11 58 ms 59 ms 60 ms 207.88.14.34.ptr.us.xo.net
    [207.88.14.34]
    12 61 ms 55 ms 99 ms 207.88.185.74.ptr.us.xo.net
    [207.88.185.74]
    13 117 ms 112 ms 65 ms border1.pc2-bbnet2.dal004.pnap.net [216.52.191.81]
    14 98 ms 53 ms 54 ms layered-11.border1.dal004.pnap.net [63.251.44.74]
    15 * * * Request timed out.
    16 63 ms 54 ms 58 ms www.centos.org [72.232.194.162]

    Trace complete.

    C:\Windows\system32>


    C:\Windows\system32>tracert linuxreference.com

    Tracing route to linuxreference.com [72.232.194.162]
    over a maximum of 30 hops:

    1 <1 ms <1 ms <1 ms REDACTED_IP.ridgewireless.net
    [xx.xx.xx.xx]
    2 7 ms 5 ms 1 ms 10.50.0.1
    3 2 ms 3 ms 2 ms 10.25.0.1
    4 5 ms 5 ms 11 ms 10.20.0.1
    5 38 ms 15 ms 32 ms 10.0.0.1
    6 61 ms 83 ms 86 ms 69.36.226.193
    7 37 ms 80 ms 47 ms vl2.core1.scl.layer42.net
    [69.36.225.129]
    8 15 ms 15 ms 10 ms 216.156.84.141.ptr.us.xo.net
    [216.156.84.141]
    9 84 ms 150 ms 70 ms 207.88.14.233.ptr.us.xo.net
    [207.88.14.233]
    10 132 ms 70 ms 64 ms vb15.rar3.dallas-tx.us.xo.net
    [207.88.12.45]
    11 83 ms 163 ms 124 ms 207.88.14.34.ptr.us.xo.net
    [207.88.14.34]
    12 59 ms 79 ms 91 ms 207.88.185.74.ptr.us.xo.net
    [207.88.185.74]
    13 177 ms * 81 ms border1.pc1-bbnet1.dal004.pnap.net [216.52.191.19]
    14 102 ms 84 ms 63 ms layered-11.border1.dal004.pnap.net [63.251.44.74]
    15 * * * Request timed out.
    16 52 ms 59 ms 64 ms www.centos.org [72.232.194.162]

    Trace complete.

    C:\Windows\system32>

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Thu Oct 10 20:06:29 2013
    billy wrote:

    Here are the details from one neighbor, with her IP address
    redacted for privacy.

    Here are details from a second neighbor, on the same WISP.

    % traceroute www.centos.org
    traceroute to www.centos.org (72.232.194.162), 64 hops max, 52 byte
    packets
    1 192.168.1.1 (192.168.1.1) 1.461 ms 0.955 ms 0.848 ms
    2 IP_REDACTED.ridgewireless.net (xx.xx.xx.xx) 1.584 ms 1.642 ms
    1.191 ms
    3 10.50.0.1 (10.50.0.1) 19.264 ms 15.133 ms 22.613 ms
    4 10.25.0.1 (10.25.0.1) 24.238 ms 11.541 ms 23.235 ms
    5 10.20.0.1 (10.20.0.1) 274.715 ms 175.756 ms 164.049 ms
    6 utm9s (10.0.0.1) 179.232 ms 170.025 ms 112.407 ms
    7 69.36.226.193 (69.36.226.193) 237.651 ms 279.127 ms 131.729 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 229.883 ms 212.336 ms
    262.883 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 320.652 ms 181.714
    ms 319.745 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 410.173 ms 410.476 ms 314.872 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 453.813 ms 297.798
    ms 380.139 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 384.894 ms 428.511 ms
    451.605 ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 384.011 ms 356.507 ms 290.830 ms
    14 border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 445.664 ms
    border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 234.716 ms
    258.429 ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 354.172 ms
    445.370 ms 146.977 ms
    16 * * *
    17 www.centos.org (72.232.194.162) 285.244 ms !Z 180.605 ms !Z
    149.697 ms !Z
    %


    Both neighbors make it to Centos.org in about the same number
    of hops that mine fails at.

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Thu Oct 10 20:21:47 2013
    Chris Davies wrote:

    You can check your default TTL with this command:
    cat /proc/sys/net/ipv4/ip_default_ttl
    On my system it returns 64.
    sudo -s # become root
    echo 128 > /proc/sys/net/ipv4/ip_default_ttl

    This is a great detective idea!

    On Knoppix, my TTL is set, by default, to 64 also:
    $ cat /proc/sys/net/ipv4/ip_default_ttl
    ==> 64
    If I understand it correctly, that's 64 routers, right?
    I only seem to be going through 1/4 that many routers,
    yet, mine fails to complete the route.

    Still, it seems useful to increase the number & try again.
    I can't modify the Knoppix TTL since it's on a DVD so I
    will try it with another operating system and report back.



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Fri Oct 11 00:40:42 2013
    Thad Floryan wrote:

    Here (Silicon Valley over Comcast's High Speed Internet)
    a 'ping centos.org' and a ping 'www.centos.org' both
    resolve to 85.12.30.227

    A fortuituous circumstance has occurred.
    I can now connect to centos.org, via the web, ping, traceroute, etc!
    I do NOT know what changed.
    Here's what happened in the interim:
    1. I wrote to the related sysadmins (I did not receive a response)
    2. I changed my MTU (but it made no difference)
    3. I changed machines (Win7, Centos, & Knoppix) which made no difference
    4. I changed the TTL which also made no difference

    Yet, look below. The route is completely different!
    # ping www.centos.org
    PING www.centos.org (85.12.30.227) 56(84) bytes of data.
    64 bytes from 85.12.30.227: icmp_req=1 ttl=44 time=236 ms
    64 bytes from 85.12.30.227: icmp_req=2 ttl=44 time=165 ms
    64 bytes from 85.12.30.227: icmp_req=3 ttl=44 time=164 ms
    64 bytes from 85.12.30.227: icmp_req=4 ttl=44 time=169 ms
    64 bytes from 85.12.30.227: icmp_req=5 ttl=44 time=180 ms
    ^C
    - --- www.centos.org ping statistics ---
    6 packets transmitted, 5 received, 16% packet loss, time 5043ms
    rtt min/avg/max/mdev = 164.682/183.212/236.535/27.238 ms

    # telnet www.centos.org 80
    Trying 85.12.30.227...
    Connected to www.centos.org.
    Escape character is '^]'.
    HEAD / HTTP/1.0

    HTTP/1.1 200 OK
    Server: nginx/0.8.55
    Date: Fri, 11 Oct 2013 00:45:11 GMT
    Content-Type: text/html; charset=ISO-8859-1
    Connection: close
    X-Powered-By: PHP/4.3.9
    Set-Cookie: PHPSESSID=2170e308a49222dbe637c509e5c60702; path=/
    Expires: Mon, 26 Jul 1997 05:00:00 GMT
    Cache-Control: private, no-cache
    Pragma: no-cache

    Connection closed by foreign host.


    # traceroute -M icmp www.centos.org
    traceroute to www.centos.org (85.12.30.227), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 2.834 ms 2.827 ms 2.831 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 2.836 ms 2.834 ms 5.724 ms
    3 10.50.0.1 (10.50.0.1) 9.067 ms 17.504 ms 17.501 ms
    4 10.25.0.1 (10.25.0.1) 17.497 ms 24.062 ms 24.060 ms
    5 10.20.0.1 (10.20.0.1) 33.210 ms 33.209 ms 33.207 ms
    6 10.0.0.1 (10.0.0.1) 42.110 ms 27.157 ms 95.411 ms
    7 69.36.226.193 (69.36.226.193) 126.784 ms 17.564 ms 83.245 ms
    8 vl2.core2.scl.layer42.net (69.36.225.130) 83.220 ms 25.765 ms 75.471 ms
    9 xe-0-0-0-22.r07.snjsca04.us.bb.gin.ntt.net (140.174.21.101) 92.593 ms 17.517 ms 57.495 ms
    10 te0-4-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.10.49) 61.049 ms te0-7-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.11.85)
    50.591 ms 98.951 ms
    11 be2000.ccr21.sjc01.atlas.cogentco.com (154.54.6.105) 101.595 ms be2047.ccr22.sjc01.atlas.cogentco.com (154.54.5.113)
    25.443 ms be2000.ccr21.sjc01.atlas.cogentco.com (154.54.6.105) 31.126 ms
    12 be2164.ccr21.sfo01.atlas.cogentco.com (154.54.28.33) 31.098 ms be2167.mpd22.sfo01.atlas.cogentco.com (154.54.28.77) 23.081
    ms be2164.ccr21.sfo01.atlas.cogentco.com (154.54.28.33) 106.955 ms
    13 be2132.ccr21.mci01.atlas.cogentco.com (154.54.30.54) 121.000 ms be2135.mpd22.mci01.atlas.cogentco.com (154.54.6.34)
    125.153 ms be2132.ccr21.mci01.atlas.cogentco.com (154.54.30.54) 125.125 ms
    14 be2156.ccr21.ord01.atlas.cogentco.com (154.54.6.86) 125.095 ms be2159.mpd22.ord01.atlas.cogentco.com (154.54.24.82) 98.844
    ms be2156.ccr21.ord01.atlas.cogentco.com (154.54.6.86) 98.816 ms
    15 be2079.ccr21.yyz02.atlas.cogentco.com (154.54.27.182) 108.449 ms 104.541 ms be2140.ccr22.bos01.atlas.cogentco.com
    (154.54.43.186) 118.863 ms
    16 be2091.ccr22.ymq02.atlas.cogentco.com (154.54.44.98) 118.831 ms be2090.ccr21.ymq02.atlas.cogentco.com (154.54.30.206)
    105.995 ms te0-1-0-1.ccr22.lpl01.atlas.cogentco.com (154.54.42.106) 173.380 ms
    17 te0-5-0-6.ccr22.lpl01.atlas.cogentco.com (154.54.87.57) 165.254 ms be2183.ccr22.ams03.atlas.cogentco.com (154.54.58.70)
    181.351 ms te0-4-0-6.ccr21.lpl01.atlas.cogentco.com (154.54.44.202) 191.954 ms
    18 be2183.ccr22.ams03.atlas.cogentco.com (154.54.58.70) 203.543 ms te0-3-0-12.mag21.ams03.atlas.cogentco.com (154.54.78.213)
    176.249 ms be2183.ccr22.ams03.atlas.cogentco.com (154.54.58.70) 179.087 ms
    19 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 182.827 ms te0-3-0-12.mag21.ams03.atlas.cogentco.com (154.54.78.213) 179.250
    ms 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 193.421 ms
    20 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 176.902 ms 85.12.30.227 (85.12.30.227) 164.817 ms
    10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 217.757 ms

    I'm not sure why the traaceroute is much longer, and, it stopped
    before Centos.org, but, the proof is in the taste of the pudding
    in that a Firefox connection to http://www.centos.org works all
    of a sudden.

    Q: What changed?

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Fri Oct 11 00:57:34 2013
    Chris Davies wrote:

    You can modify the value for the duration of the session
    because it's held in the kernel, in memory.

    I'm not sure what changed, but, now I can reach Centos.org!

    I'm also not sure what the bangX is (!X), but, I can now easily
    connect to Centos.org.

    I don't think I permanently changed anything.
    This trace below, for example, is on Knoppix, after a fresh
    reboot, so, none of the TTL changes would take effect:

    $ su root
    # cat /proc/sys/net/ipv4/ip_default_ttl
    64

    # ifconfig wlan0 | grep MTU
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

    $ traceroute www.centos.org
    traceroute to www.centos.org (85.12.30.227), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 2.833 ms 2.808 ms 4.232 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 24.856 ms 24.843 ms 24.827 ms
    3 10.50.0.1 (10.50.0.1) 31.589 ms 31.571 ms 31.555 ms
    4 10.25.0.1 (10.25.0.1) 38.395 ms 38.382 ms 38.368 ms
    5 10.20.0.1 (10.20.0.1) 459.405 ms 459.371 ms 459.358 ms
    6 10.0.0.1 (10.0.0.1) 478.430 ms 122.002 ms 121.984 ms
    7 69.36.226.193 (69.36.226.193) 128.186 ms 128.170 ms 128.155 ms
    8 vl2.core2.scl.layer42.net (69.36.225.130) 144.227 ms 144.216 ms 144.201 ms
    9 xe-0-0-0-22.r07.snjsca04.us.bb.gin.ntt.net (140.174.21.101) 128.082 ms 128.058 ms 128.042 ms
    10 te0-7-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.11.85) 128.026 ms 128.012 ms 128.006 ms
    11 be2047.ccr22.sjc01.atlas.cogentco.com (154.54.5.113) 127.980 ms be2000.ccr21.sjc01.atlas.cogentco.com (154.54.6.105) 127.964
    ms 182.368 ms
    12 be2167.mpd22.sfo01.atlas.cogentco.com (154.54.28.77) 182.351 ms be2164.ccr21.sfo01.atlas.cogentco.com (154.54.28.33) 142.475
    ms 198.711 ms
    13 be2135.mpd22.mci01.atlas.cogentco.com (154.54.6.34) 239.809 ms be2134.mpd21.mci01.atlas.cogentco.com (154.54.6.38) 239.778 ms be2135.mpd22.mci01.atlas.cogentco.com (154.54.6.34) 239.767 ms
    14 be2157.ccr22.ord01.atlas.cogentco.com (154.54.6.118) 251.841 ms 251.817 ms be2158.mpd21.ord01.atlas.cogentco.com
    (154.54.7.130) 251.807 ms
    15 be2080.ccr22.yyz02.atlas.cogentco.com (154.54.42.6) 267.756 ms be2081.ccr21.yyz02.atlas.cogentco.com (154.54.42.10) 267.730 ms be2140.ccr22.bos01.atlas.cogentco.com (154.54.43.186) 267.722 ms
    16 te0-4-0-1.ccr21.lpl01.atlas.cogentco.com (154.54.44.198) 322.941 ms te0-2-0-1.ccr22.lpl01.atlas.cogentco.com (154.54.0.210)
    322.907 ms be2092.ccr21.ymq02.atlas.cogentco.com (154.54.25.26) 142.921 ms
    17 be2184.mpd21.ams03.atlas.cogentco.com (154.54.37.69) 322.880 ms 322.865 ms be2185.mpd22.ams03.atlas.cogentco.com
    (154.54.37.105) 339.005 ms
    18 te0-3-0-3.mag21.ams03.atlas.cogentco.com (154.54.78.210) 338.983 ms be2183.ccr22.ams03.atlas.cogentco.com (154.54.58.70)
    338.955 ms te0-7-0-12.mag21.ams03.atlas.cogentco.com (154.54.76.202) 338.947 ms
    19 te0-7-0-18.mag21.ams03.atlas.cogentco.com (154.54.76.213) 338.936 ms te0-7-0-6.mag21.ams03.atlas.cogentco.com (154.54.76.198)
    338.912 ms te0-7-0-4.mag21.ams03.atlas.cogentco.com (154.54.76.138) 338.873 ms
    20 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 335.208 ms 338.830 ms 338.806 ms
    21 85.12.30.227 (85.12.30.227) 335.141 ms !X 229.087 ms !X 229.051 ms !X

    # telnet www.centos.org 80
    Trying 85.12.30.227...
    Connected to www.centos.org.
    Escape character is '^]'.
    HEAD / HTTP/1.0

    HTTP/1.1 200 OK
    Server: nginx/0.8.55
    Date: Fri, 11 Oct 2013 01:02:27 GMT
    Content-Type: text/html; charset=ISO-8859-1
    Connection: close
    X-Powered-By: PHP/4.3.9
    Set-Cookie: PHPSESSID=077a08159b3f653d8b2322a77f34806c; path=/
    Expires: Mon, 26 Jul 1997 05:00:00 GMT
    Cache-Control: private, no-cache
    Pragma: no-cache

    Connection closed by foreign host.

    # ping www.centos.org
    PING www.centos.org (85.12.30.227) 56(84) bytes of data.
    64 bytes from 85.12.30.227: icmp_req=1 ttl=44 time=182 ms
    64 bytes from 85.12.30.227: icmp_req=2 ttl=44 time=267 ms
    ^C
    - --- www.centos.org ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1008ms
    rtt min/avg/max/mdev = 182.493/224.922/267.351/42.429 ms
    root@Microknoppix:~# ping centos.org
    PING centos.org (85.12.30.227) 56(84) bytes of data.
    64 bytes from 85.12.30.227: icmp_req=1 ttl=44 time=187 ms
    64 bytes from 85.12.30.227: icmp_req=2 ttl=44 time=162 ms
    64 bytes from 85.12.30.227: icmp_req=3 ttl=44 time=179 ms
    64 bytes from 85.12.30.227: icmp_req=4 ttl=44 time=235 ms
    ^C
    - --- centos.org ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3019ms
    rtt min/avg/max/mdev = 162.922/191.276/235.687/27.093 ms



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Fri Oct 11 01:07:04 2013
    billy wrote:

    I'm not sure what changed, but, now I can reach Centos.org!

    But, interestingly, I still can not reach linuxreference.com.

    Note: This site is meaningless to me, so, it's just of interest
    but it has no practical significance since it's not a site
    I often rely upon.

    But, here is the trace, with centos.org working, linuxreference.com
    does not.


    # traceroute -M icmp linuxreference.com
    traceroute to linuxreference.com (72.232.194.162), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 3.642 ms 3.637 ms *
    2 * * *
    3 * * *
    4 * * *
    5 * * *
    6 * 10.0.0.1 (10.0.0.1) 131.604 ms 131.542 ms
    7 69.36.226.193 (69.36.226.193) 131.534 ms 131.531 ms 131.533 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 131.519 ms 131.520 ms
    131.517 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 131.514 ms 131.509 ms 131.506 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 331.912 ms 329.009 ms 334.690 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 331.876 ms 331.874 ms 124.878 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 118.154 ms 149.195 ms
    188.104 ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 188.093 ms 173.788 ms 173.766 ms
    14 border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 173.749 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 68.081 ms 138.710 ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 155.481 ms 155.470
    ms 155.461 ms
    16 * * *
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Fri Oct 11 01:18:12 2013
    unruh wrote:

    Everything in /proc is a fake filesystem,
    it is NOT on the hard disk or dvd or anything.
    It is a look into the kernel which is of course
    in memory. Just do as he says.

    Ah, I see what I did wrong.

    I had tried to edit the file in vi but I got a "Fsync failed"
    red-text error using 'vi' on that file as root in Knoppix:

    knoppix@Microknoppix:~$ su root
    root@Microknoppix:/home/knoppix# cd /proc/sys/net/ipv4 root@Microknoppix:/proc/sys/net/ipv4# cat ip_default_ttl
    64
    root@Microknoppix:/proc/sys/net/ipv4# vi !$
    vi ip_default_ttl
    (here I changed the 64 to 128)
    (then I hit wq!)
    (and got the error below)
    "ip_default_ttl"
    "ip_default_ttl" E667: Fsync failed
    Press ENTER or type command to continue
    # cat ip_default_ttl
    64

    But, simply echoing to the file DOES change it! root@Microknoppix:/proc/sys/net/ipv4# echo "128" > ip_default_ttl root@Microknoppix:/proc/sys/net/ipv4# cat ip_default_ttl
    128

    So, you were right!
    My mistake.




    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Fri Oct 11 01:40:04 2013
    Below (sorry for the top post) is the old traceroute from yesterday on Microknoppix.

    Here is the new traceroute from a few seconds ago.
    The route is entirely different!
    Since *UNDERSTANDING* is what we're after, can you give me
    insight into *how* all of a sudden, the route is so very different
    (and why it works now)?

    Who decides what route my packets will take?

    knoppix@Microknoppix:~$ traceroute www.centos.org
    traceroute to www.centos.org (85.12.30.227), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 2.940 ms 2.915 ms 5.895 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 23.983 ms 23.970 ms 23.953 ms
    3 10.50.0.1 (10.50.0.1) 23.935 ms 23.920 ms 23.905 ms
    4 10.25.0.1 (10.25.0.1) 33.716 ms 33.701 ms 33.687 ms
    5 10.20.0.1 (10.20.0.1) 113.640 ms 127.266 ms 127.251 ms
    6 10.0.0.1 (10.0.0.1) 155.135 ms 198.034 ms 198.014 ms
    7 69.36.226.193 (69.36.226.193) 77.534 ms 88.951 ms 88.940 ms
    8 vl2.core2.scl.layer42.net (69.36.225.130) 101.711 ms 101.700 ms 107.203 ms
    9 xe-0-0-0-22.r07.snjsca04.us.bb.gin.ntt.net (140.174.21.101) 111.422 ms 111.419 ms 111.404 ms
    10 te0-7-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.11.85) 111.376 ms te0-4-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.10.49)
    111.352 ms te0-7-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.11.85) 111.341 ms
    11 be2047.ccr22.sjc01.atlas.cogentco.com (154.54.5.113) 111.324 ms 111.311 ms be2000.ccr21.sjc01.atlas.cogentco.com
    (154.54.6.105) 111.251 ms
    12 be2165.ccr22.sfo01.atlas.cogentco.com (154.54.28.65) 111.238 ms be2166.mpd21.sfo01.atlas.cogentco.com (154.54.28.69) 58.660 ms be2165.ccr22.sfo01.atlas.cogentco.com (154.54.28.65) 66.012 ms
    13 be2132.ccr21.mci01.atlas.cogentco.com (154.54.30.54) 168.366 ms be2135.mpd22.mci01.atlas.cogentco.com (154.54.6.34) 168.350 ms be2133.ccr22.mci01.atlas.cogentco.com (154.54.30.66) 165.709 ms
    14 be2159.mpd22.ord01.atlas.cogentco.com (154.54.24.82) 168.316 ms 168.300 ms be2158.mpd21.ord01.atlas.cogentco.com
    (154.54.7.130) 168.285 ms
    15 be2079.ccr21.yyz02.atlas.cogentco.com (154.54.27.182) 139.555 ms 133.671 ms be2138.ccr22.bos01.atlas.cogentco.com
    (154.54.43.202) 155.781 ms
    16 be2090.ccr21.ymq02.atlas.cogentco.com (154.54.30.206) 139.505 ms te0-3-0-1.ccr21.lpl01.atlas.cogentco.com (154.54.31.230)
    208.018 ms te0-4-0-3.ccr22.lpl01.atlas.cogentco.com (154.54.44.190) 208.007 ms
    17 te0-5-0-6.ccr21.lpl01.atlas.cogentco.com (154.54.87.65) 211.696 ms be2182.ccr21.ams03.atlas.cogentco.com (154.54.77.245)
    226.780 ms te0-4-0-6.ccr22.lpl01.atlas.cogentco.com (154.54.44.214) 211.705 ms
    18 be2185.mpd22.ams03.atlas.cogentco.com (154.54.37.105) 229.203 ms te0-0-0-4.mag21.ams03.atlas.cogentco.com (154.54.76.190)
    310.294 ms be2185.mpd22.ams03.atlas.cogentco.com (154.54.37.105) 310.272 ms
    19 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 305.393 ms te0-0-0-12.mag21.ams03.atlas.cogentco.com (154.54.76.134) 310.218 ms 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 305.367 ms
    20 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 305.344 ms 305.321 ms 310.147 ms
    21 85.12.30.227 (85.12.30.227) 305.263 ms !X 305.254 ms !X 205.255 ms !X knoppix@Microknoppix:~$



    root@Microknoppix:/# traceroute -M icmp centos.org
    traceroute to centos.org (72.232.194.162), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 2.932 ms 2.929 ms 2.928 ms
    2 WISP_IP_REDACTED (xxx.xxx.xxx.xxx) 5.683 ms 5.683 ms 5.680 ms
    3 10.50.0.1 (10.50.0.1) 20.479 ms 20.477 ms 20.474 ms
    4 10.25.0.1 (10.25.0.1) 20.469 ms 30.272 ms 33.014 ms
    5 10.20.0.1 (10.20.0.1) 33.009 ms 36.190 ms 36.187 ms
    6 10.0.0.1 (10.0.0.1) 36.182 ms 16.332 ms 39.405 ms
    7 69.36.226.193 (69.36.226.193) 39.377 ms 20.721 ms 23.093 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 23.066 ms 16.977 ms 16.947
    ms 9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 16.917 ms 12.782 ms 18.611 ms 10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 69.341 ms
    119.252 ms 119.222 ms 11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 116.010 ms 84.054 ms 84.022 ms 12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 83.978 ms 53.016 ms 52.987 ms 13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 56.341 ms 53.502 ms 59.458
    ms 14 border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 59.430 ms
    58.240 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 61.422 ms 15
    layered-11.border1.dal004.pnap.net (63.251.44.74) 61.383 ms 54.510 ms 54.494 ms 16 * * * <== centos.org is here 17 * * * 18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *
    root@Microknoppix:/#


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From Thomas Keusch@110:110/2002 to All on Fri Oct 11 01:50:18 2013
    On 2013-10-11, billy <billy@is.invalid> wrote:
    Thad Floryan wrote:

    Here (Silicon Valley over Comcast's High Speed Internet)
    a 'ping centos.org' and a ping 'www.centos.org' both
    resolve to 85.12.30.227

    A fortuituous circumstance has occurred.
    I can now connect to centos.org, via the web, ping, traceroute, etc!
    I do NOT know what changed.
    Here's what happened in the interim:
    1. I wrote to the related sysadmins (I did not receive a response)
    2. I changed my MTU (but it made no difference)
    3. I changed machines (Win7, Centos, & Knoppix) which made no difference
    4. I changed the TTL which also made no difference

    Yet, look below. The route is completely different!
    # ping www.centos.org
    PING www.centos.org (85.12.30.227) 56(84) bytes of data.
    64 bytes from 85.12.30.227: icmp_req=1 ttl=44 time=236 ms
    [...]
    Q: What changed?

    You're now talking to another IP, i.e. probably another system. Someone
    in this thread noted that the other IP was with Akamai. Probably some
    remains of a torn down accelleration setup? Who knows.

    Best regards
    Thomas

    --

    * Freelance Linux & BSD Systemengineer // IT Consultant *
    -=- Homepage: http://www.bsd-solutions-duesseldorf.de -=-

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: /dev/null Boring Headers Inc. (110:110/2002@linuxnet)
  • From nemesis@110:110/2002 to All on Fri Oct 11 02:03:13 2013
    On Fri, 11 Oct 2013 01:40:04 +0000, billy wrote:

    Below (sorry for the top post) is the old traceroute from yesterday on Microknoppix.

    Here is the new traceroute from a few seconds ago.
    The route is entirely different!
    Since *UNDERSTANDING* is what we're after, can you give me
    insight into *how* all of a sudden, the route is so very different
    (and why it works now)?

    Who decides what route my packets will take?

    The guy at 67.218.118.85. He probably lives nearby. Kick his a%&.

    --
    I am a troll


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Fri Oct 11 03:24:53 2013
    Thomas Keusch wrote:

    You're now talking to another IP,
    i.e. probably another system.
    Someone in this thread noted that the other IP was
    with Akamai.
    Probably some remains of a torn down accelleration setup?
    Who knows.

    If I understand you correctly, what you're saying is that
    yesterday, Centos.org was hosted on 72.232.194.162 while,
    today, it's hosted on 85.12.30.227.

    For some reason, I couldn't get to 72.232.194.162 yesterday,
    while my neighbors could get to it; but, today, I only need
    to get to 85.12.30.227, which works fine for me.

    I just tried pinging 72.232.194.162, and it fails to return.

    A traceroute to that same IP address still fails today.

    # traceroute -M icmp 72.232.194.162
    traceroute to 72.232.194.162 (72.232.194.162), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 2.849 ms 2.839 ms 2.839 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 8.476 ms 8.477 ms 8.474 ms
    3 10.50.0.1 (10.50.0.1) 8.468 ms 15.442 ms 15.442 ms
    4 10.25.0.1 (10.25.0.1) 62.623 ms 62.631 ms 62.629 ms
    5 10.20.0.1 (10.20.0.1) 68.657 ms 68.654 ms 68.652 ms
    6 10.0.0.1 (10.0.0.1) 99.906 ms 36.198 ms 45.997 ms
    7 69.36.226.193 (69.36.226.193) 45.960 ms 22.838 ms 39.756 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 39.747 ms 21.573 ms 25.054 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 25.035 ms 43.099 ms 43.074 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 101.938 ms 74.301 ms 76.448 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 76.430 ms 108.260 ms 108.219 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 108.186 ms 60.969 ms 65.956 ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 70.441 ms 124.382 ms 126.699 ms
    14 border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 126.680 ms border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81)
    69.193 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 69.171 ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 69.140 ms 97.227 ms 102.727 ms
    16 * * *
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *

    So, I guess all that changed is that Centos.org moved servers, and, well,
    the original server (of yesterday) was unreachable by me, but most of you
    (and my neighbors) could reach it.

    At least this moving of servers can explain why my ability to reach
    the server comes and goes - but - what I still don't get is why I couldn't
    (and can't) reach the old server and all of you guys could.

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From unruh@1:0/0 to All on Fri Oct 11 04:11:59 2013
    On 2013-10-11, billy <billy@is.invalid> wrote:
    Below (sorry for the top post) is the old traceroute from yesterday on Microknoppix.

    Here is the new traceroute from a few seconds ago.
    The route is entirely different!
    Since *UNDERSTANDING* is what we're after, can you give me
    insight into *how* all of a sudden, the route is so very different
    (and why it works now)?

    Who decides what route my packets will take?

    Each router looks for a next hop to send the packet on to, each has a
    default route to send it on if it does not know where it is. Thus, the
    route is dynamic and determined on the fly-- it was purposely designed
    that way so that if a nuclear war takes out Dallas, the packets go via Minneapolis instead, automatically.



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From billy@110:110/2002 to All on Fri Oct 11 04:19:51 2013
    unruh wrote:

    the route is dynamic and determined on the fly

    I do not disagree, since, in theory, that's how the Internet
    was designed (redundancy).

    However, in my experience here, all the traceroutes were
    the same path, time after time after time after time.

    It is only when centos.org changed servers (between yesterday
    and today) that the path taken was drastically different.

    Even so, the *new* path is the same time after time.

    So, it's not as dynamic as one might presume.
    In fact, it's pretty static.

    Of course, if one of the routers were to be taken out,
    then I'm sure it would route around them - but barring
    that, the route sure *appears* to be static to me.

    PS: Do you think the NSA is stealing my packets? :)


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Fri Oct 11 04:25:50 2013
    billy wrote:

    Of course, if one of the routers were to be taken out,
    then I'm sure it would route around them - but barring
    that, the route sure appears to be static to me.

    This gives me an idea...

    It seems that, when I try to traceroute to the old
    Centos.org site of yesterday (72.232.194.162), there
    is this last router, from whence my packets never
    go any further:
    layered-11.border1.dal004.pnap.net (63.251.44.74)

    Now, if I ping that router, everything seems fine:
    $ ping 63.251.44.74
    PING 63.251.44.74 (63.251.44.74) 56(84) bytes of data.
    64 bytes from 63.251.44.74: icmp_req=1 ttl=238 time=62.0 ms
    64 bytes from 63.251.44.74: icmp_req=2 ttl=238 time=63.1 ms
    64 bytes from 63.251.44.74: icmp_req=3 ttl=238 time=72.0 ms
    ^C
    - --- 63.251.44.74 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2014ms
    rtt min/avg/max/mdev = 62.017/65.710/72.006/4.478 ms

    A traceroute works fine also:
    # traceroute -M icmp 63.251.44.74
    traceroute to 63.251.44.74 (63.251.44.74), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 2.850 ms 2.835 ms 2.834 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 2.882 ms 2.881 ms 5.680 ms
    3 10.50.0.1 (10.50.0.1) 12.477 ms 14.800 ms 14.797 ms
    4 10.25.0.1 (10.25.0.1) 20.777 ms 23.605 ms 23.601 ms
    5 10.20.0.1 (10.20.0.1) 41.385 ms 144.151 ms 146.952 ms
    6 10.0.0.1 (10.0.0.1) 619.953 ms 306.464 ms 306.448 ms
    7 69.36.226.193 (69.36.226.193) 306.421 ms 364.905 ms 364.883 ms
    8 vl2.core2.scl.layer42.net (69.36.225.130) 364.865 ms 266.085 ms 266.063 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 266.044 ms 345.147 ms 346.288 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 366.961 ms 634.262 ms 667.273 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 667.264 ms 457.518 ms 461.442 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 529.257 ms 520.364 ms 520.332 ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 520.314 ms 444.251 ms 485.246 ms
    14 border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 615.351 ms border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81)
    444.807 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 462.102 ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 73.068 ms 65.315 ms *

    My key confusion is below:
    Q: How can I tell if the problem getting to the old Centos server
    is due to this router? Or to the next router in line?




    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From unruh@1:0/0 to All on Fri Oct 11 04:45:29 2013
    On 2013-10-11, billy <billy@is.invalid> wrote:
    unruh wrote:

    the route is dynamic and determined on the fly

    I do not disagree, since, in theory, that's how the Internet
    was designed (redundancy).

    However, in my experience here, all the traceroutes were
    the same path, time after time after time after time.

    It is only when centos.org changed servers (between yesterday
    and today) that the path taken was drastically different.

    Even so, the *new* path is the same time after time.

    So, it's not as dynamic as one might presume.
    In fact, it's pretty static.

    Yes, and then because something changes, suddenly it is different.


    Of course, if one of the routers were to be taken out,
    then I'm sure it would route around them - but barring
    that, the route sure *appears* to be static to me.

    PS: Do you think the NSA is stealing my packets? :)

    Probably. They are missing so many packets that they need to collect all
    the ones they can.



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Richard Kettlewell@110:110/2002 to All on Fri Oct 11 07:56:36 2013
    billy <billy@is.invalid> writes:
    Chris Davies wrote:

    You can modify the value for the duration of the session because it's
    held in the kernel, in memory.

    I'm not sure what changed, but, now I can reach Centos.org!

    I'm also not sure what the bangX is (!X), but, I can now easily
    connect to Centos.org.

    !X is mentioned in the documentation...

    --
    http://www.greenend.org.uk/rjk/

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Anjou (110:110/2002@linuxnet)
  • From Richard Kettlewell@110:110/2002 to All on Fri Oct 11 08:00:57 2013
    billy <billy@is.invalid> writes:
    So, it's not as dynamic as one might presume.
    In fact, it's pretty static.

    Of course, if one of the routers were to be taken out,
    then I'm sure it would route around them - but barring
    that, the route sure *appears* to be static to me.

    Dynamic does not mean “changes every time”. At a given moment the
    chances are that the best route to a given destination is the same as
    the previous time a packet traversed it.

    --
    http://www.greenend.org.uk/rjk/

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Anjou (110:110/2002@linuxnet)
  • From dyrmak@110:110/2002 to All on Fri Oct 11 08:50:22 2013
    En 62 lignes billy a crit
    dans news:l37rd6$bac$1@speranza.aioe.org
    le vendredi, 11 octobre 2013 05:24:53:


    So, I guess all that changed is that Centos.org moved servers, and, well, the original server (of yesterday) was unreachable by me, but most of you (and my neighbors) could reach it.

    At least this moving of servers can explain why my ability to reach
    the server comes and goes - but - what I still don't get is why I couldn't (and can't) reach the old server and all of you guys could.

    Could it be DNS problem you are having on your own ?
    When the problem occurs http://@IP might give confirmation.
    If your router is mtu-modifiable lower it to 150 thereabouts
    along with your network card and see what happens.

    dyrmak
    --
    Slo s que nada s
    ++++ --- ++++
    Linux operating system
    ++++ --- ++++

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: make it mine (110:110/2002@linuxnet)
  • From p-0''0-h the cat (ES)@110:110/2002 to All on Fri Oct 11 09:17:47 2013
    On Fri, 11 Oct 2013 01:40:04 +0000, billy <billy@is.invalid> wrote:

    Below (sorry for the top post) is the old traceroute from yesterday on >Microknoppix.

    Here is the new traceroute from a few seconds ago.
    The route is entirely different!
    Since *UNDERSTANDING* is what we're after, can you give me
    insight into *how* all of a sudden, the route is so very different
    (and why it works now)?

    Well if you emailed that guy I expect he either sorted it out or
    forwarded it to the person who could. If not God intervened.

    Routes are decided by static entries and entries made by dynamic routing protocols on each router.

    http://en.wikipedia.org/wiki/Routing

    Who decides what route my packets will take?

    The owner of the router, sorta in consultation with their neighbours.

    --
    p-0.0-h the cat

    Internet Terrorist, Mass sock puppeteer, Agent provocateur, Gutter rat,
    Devil incarnate, Linux user#666, BaStarD hacker, Resident evil, Monkey Boy, Certifiable criminal, Spineless cowardly scum, textbook Psychopath,
    the SCOURGE, l33t p00h d3 tr0ll, p00h == lam3r, p00h == tr0ll, troll infme, the OVERCAT [The BEARPAIR are dead, and we are its murderers], lowlife troll, shyster [pending approval by STATE_TERROR], cripple, sociopath, kook,
    smug prick, smartarse, arsehole, moron, idiot, imbecile, snittish scumbag, liar, and shill.

    Honorary SHYSTER and FRAUD awarded for services to Haberdashery.
    By Appointment to God Frank-Lin.



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: ACF's purry underbelly (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Fri Oct 11 14:23:05 2013
    p-0''0-h the cat (ES) wrote:

    Well if you emailed that guy I expect he either sorted it out or
    forwarded it to the person who could. If not God intervened.

    Unfortunately, the short respit is over. This morning, I again, can
    no longer connect to the (new) centos.org. Sigh ...
    I just wish I understood this better ...

    $ traceroute centos.org
    traceroute to centos.org (85.12.30.227), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 7.301 ms 7.275 ms 7.258 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 20.126 ms 20.113
    ms 20.096 ms
    3 10.50.0.1 (10.50.0.1) 25.566 ms 25.551 ms 28.360 ms
    4 10.25.0.1 (10.25.0.1) 33.868 ms 36.207 ms 36.192 ms
    5 10.20.0.1 (10.20.0.1) 38.464 ms 38.448 ms 38.431 ms
    6 10.0.0.1 (10.0.0.1) 38.416 ms 118.426 ms 118.412 ms
    7 69.36.226.193 (69.36.226.193) 118.388 ms 33.867 ms 62.402 ms
    8 vl2.core2.scl.layer42.net (69.36.225.130) 62.387 ms 65.348 ms
    65.333 ms
    9 xe-0-0-0-22.r07.snjsca04.us.bb.gin.ntt.net (140.174.21.101) 65.319
    ms 65.304 ms 70.705 ms
    10 te0-4-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.10.49) 70.708 ms 70.685 ms te0-7-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.11.85)
    70.653 ms
    11 be2047.ccr22.sjc01.atlas.cogentco.com (154.54.5.113) 70.638 ms
    70.623 ms be2000.ccr21.sjc01.atlas.cogentco.com (154.54.6.105) 33.395
    ms
    12 be2165.ccr22.sfo01.atlas.cogentco.com (154.54.28.65) 33.378 ms be2166.mpd21.sfo01.atlas.cogentco.com (154.54.28.69) 33.363 ms be2165.ccr22.sfo01.atlas.cogentco.com (154.54.28.65) 51.255 ms
    13 be2135.mpd22.mci01.atlas.cogentco.com (154.54.6.34) 119.248 ms be2134.mpd21.mci01.atlas.cogentco.com (154.54.6.38) 119.241 ms be2132.ccr21.mci01.atlas.cogentco.com (154.54.30.54) 119.227 ms
    14 be2158.mpd21.ord01.atlas.cogentco.com (154.54.7.130) 119.220 ms be2157.ccr22.ord01.atlas.cogentco.com (154.54.6.118) 119.191 ms be2156.ccr21.ord01.atlas.cogentco.com (154.54.6.86) 119.177 ms
    15 be2080.ccr22.yyz02.atlas.cogentco.com (154.54.42.6) 136.953 ms be2139.ccr21.bos01.atlas.cogentco.com (154.54.43.178) 136.938 ms be2079.ccr21.yyz02.atlas.cogentco.com (154.54.27.182) 136.908 ms
    16 te0-2-0-3.ccr21.lpl01.atlas.cogentco.com (154.54.85.214) 192.925
    ms be2090.ccr21.ymq02.atlas.cogentco.com (154.54.30.206) 136.885 ms be2091.ccr22.ymq02.atlas.cogentco.com (154.54.44.98) 136.870 ms
    17 be2185.mpd22.ams03.atlas.cogentco.com (154.54.37.105) 194.858 ms be2182.ccr21.ams03.atlas.cogentco.com (154.54.77.245) 194.846 ms be2184.mpd21.ams03.atlas.cogentco.com (154.54.37.69) 194.831 ms
    18 be2183.ccr22.ams03.atlas.cogentco.com (154.54.58.70) 196.838 ms
    196.794 ms te0-3-0-3.mag21.ams03.atlas.cogentco.com (154.54.78.210)
    196.791 ms
    19 te0-3-0-0.mag21.ams03.atlas.cogentco.com (154.54.78.206) 199.738
    ms te0-7-0-10.mag21.ams03.atlas.cogentco.com (154.54.76.209) 212.950
    ms te0-7-0-6.mag21.ams03.atlas.cogentco.com (154.54.76.198) 221.482 ms
    20 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 212.901 ms 212.874
    ms 212.868 ms
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Fri Oct 11 14:26:03 2013
    dyrmak wrote:

    Could it be DNS problem you are having on your own ?
    When the problem occurs http://@IP might give confirmation.
    If your router is mtu-modifiable lower it to 150 thereabouts
    along with your network card and see what happens.

    DNS? Hmmm... would switching DNS servers affect the route taken?
    I'll try that, but, putting the IP address in the URL does not help.

    For example, http://85.12.30.227/ does the same thing as does http://www.centos.org as does http://centos.org




    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Fri Oct 11 14:30:44 2013
    Richard Kettlewell wrote:

    Dynamic does not mean “changes every time”.
    At a given moment the chances are that the best route
    to a given destination is the same as the previous time

    I can't disagree with you at all.

    From *my* experience, the route is pretty much static, and,
    when it fails, it pretty much fails at the same point for
    hours, days, or months at a time.

    For example, my traceroute two days ago to the old centos.org
    at 72.232.194.162 failed around hop 15, while last night a
    traceroute (and all other tests) worked fine to the new Centos.org
    at 85.12.30.227, yet, inexplicably, today, that same test failed!

    Here's a traceroute yesterday that worked and one that failed
    today, all to the same IP address!

    WORKED YESTERDAY:
    knoppix@Microknoppix:~$ traceroute www.centos.org
    traceroute to www.centos.org (85.12.30.227), 30 hops max, 60 byte
    packets
    1 192.168.1.1 (192.168.1.1) 2.940 ms 2.915 ms 5.895 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 23.983 ms 23.970
    ms 23.953 ms
    3 10.50.0.1 (10.50.0.1) 23.935 ms 23.920 ms 23.905 ms
    4 10.25.0.1 (10.25.0.1) 33.716 ms 33.701 ms 33.687 ms
    5 10.20.0.1 (10.20.0.1) 113.640 ms 127.266 ms 127.251 ms
    6 10.0.0.1 (10.0.0.1) 155.135 ms 198.034 ms 198.014 ms
    7 69.36.226.193 (69.36.226.193) 77.534 ms 88.951 ms 88.940 ms
    8 vl2.core2.scl.layer42.net (69.36.225.130) 101.711 ms 101.700
    ms 107.203 ms
    9 xe-0-0-0-22.r07.snjsca04.us.bb.gin.ntt.net
    (140.174.21.101) 111.422 ms 111.419 ms 111.404 ms
    10 te0-7-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.11.85) 111.376
    ms te0-4-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.10.49)
    111.352 ms te0-7-0-32.ccr21.sjc03.atlas.cogentco.com
    (154.54.11.85) 111.341 ms
    11 be2047.ccr22.sjc01.atlas.cogentco.com (154.54.5.113) 111.324
    ms 111.311 ms be2000.ccr21.sjc01.atlas.cogentco.com
    (154.54.6.105) 111.251 ms
    12 be2165.ccr22.sfo01.atlas.cogentco.com (154.54.28.65) 111.238 ms be2166.mpd21.sfo01.atlas.cogentco.com (154.54.28.69) 58.660 ms be2165.ccr22.sfo01.atlas.cogentco.com (154.54.28.65) 66.012 ms
    13 be2132.ccr21.mci01.atlas.cogentco.com (154.54.30.54) 168.366 ms be2135.mpd22.mci01.atlas.cogentco.com (154.54.6.34) 168.350 ms be2133.ccr22.mci01.atlas.cogentco.com (154.54.30.66) 165.709 ms
    14 be2159.mpd22.ord01.atlas.cogentco.com (154.54.24.82) 168.316
    ms 168.300 ms be2158.mpd21.ord01.atlas.cogentco.com
    (154.54.7.130) 168.285 ms
    15 be2079.ccr21.yyz02.atlas.cogentco.com (154.54.27.182) 139.555
    ms 133.671 ms be2138.ccr22.bos01.atlas.cogentco.com
    (154.54.43.202) 155.781 ms
    16 be2090.ccr21.ymq02.atlas.cogentco.com (154.54.30.206) 139.505 ms te0-3-0-1.ccr21.lpl01.atlas.cogentco.com (154.54.31.230)
    208.018 ms te0-4-0-3.ccr22.lpl01.atlas.cogentco.com
    (154.54.44.190) 208.007 ms
    17 te0-5-0-6.ccr21.lpl01.atlas.cogentco.com (154.54.87.65) 211.696 ms be2182.ccr21.ams03.atlas.cogentco.com (154.54.77.245)
    226.780 ms te0-4-0-6.ccr22.lpl01.atlas.cogentco.com
    (154.54.44.214) 211.705 ms
    18 be2185.mpd22.ams03.atlas.cogentco.com (154.54.37.105) 229.203 ms te0-0-0-4.mag21.ams03.atlas.cogentco.com (154.54.76.190)
    310.294 ms be2185.mpd22.ams03.atlas.cogentco.com
    (154.54.37.105) 310.272 ms
    19 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 305.393 ms te0-0-0-12.mag21.ams03.atlas.cogentco.com (154.54.76.134) 310.218 ms 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 305.367 ms
    20 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 305.344 ms 305.321
    ms 310.147 ms
    21 85.12.30.227 (85.12.30.227) 305.263 ms !X 305.254 ms !X 205.255
    ms !X
    knoppix@Microknoppix:~$

    FAILED TODAY:
    knoppix@Microknoppix:~$ traceroute centos.org
    traceroute to centos.org (85.12.30.227), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 6.125 ms 6.094 ms 6.077 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 33.527 ms 33.515
    ms 33.499 ms
    3 10.50.0.1 (10.50.0.1) 33.485 ms 39.686 ms 47.348 ms
    4 10.25.0.1 (10.25.0.1) 82.142 ms 82.128 ms 82.113 ms
    5 10.20.0.1 (10.20.0.1) 101.802 ms 101.787 ms 101.771 ms
    6 10.0.0.1 (10.0.0.1) 111.627 ms 52.710 ms 52.672 ms
    7 69.36.226.193 (69.36.226.193) 52.637 ms 25.633 ms 25.613 ms
    8 vl2.core2.scl.layer42.net (69.36.225.130) 25.599 ms 25.584 ms
    32.306 ms
    9 xe-0-0-0-22.r07.snjsca04.us.bb.gin.ntt.net (140.174.21.101) 36.545
    ms 36.530 ms 36.515 ms
    10 te0-7-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.11.85) 36.477 ms te0-4-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.10.49) 36.463 ms te0-7-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.11.85) 36.433 ms
    11 be2000.ccr21.sjc01.atlas.cogentco.com (154.54.6.105) 36.442 ms
    36.427 ms 17.909 ms
    12 be2164.ccr21.sfo01.atlas.cogentco.com (154.54.28.33) 26.295 ms be2166.mpd21.sfo01.atlas.cogentco.com (154.54.28.69) 26.279 ms be2167.mpd22.sfo01.atlas.cogentco.com (154.54.28.77) 31.666 ms
    13 be2135.mpd22.mci01.atlas.cogentco.com (154.54.6.34) 81.979 ms be2134.mpd21.mci01.atlas.cogentco.com (154.54.6.38) 81.949 ms be2135.mpd22.mci01.atlas.cogentco.com (154.54.6.34) 81.943 ms
    14 be2159.mpd22.ord01.atlas.cogentco.com (154.54.24.82) 91.739 ms
    110.049 ms be2156.ccr21.ord01.atlas.cogentco.com (154.54.6.86) 110.039
    ms
    15 be2140.ccr22.bos01.atlas.cogentco.com (154.54.43.186) 118.042 ms be2080.ccr22.yyz02.atlas.cogentco.com (154.54.42.6) 112.212 ms be2137.ccr21.bos01.atlas.cogentco.com (154.54.43.194) 118.011 ms
    16 te0-2-0-1.ccr21.lpl01.atlas.cogentco.com (154.54.31.190) 185.107
    ms te0-0-0-1.ccr21.lpl01.atlas.cogentco.com (154.54.31.170) 185.082 ms 185.048 ms
    17 te0-3-0-6.ccr21.lpl01.atlas.cogentco.com (154.54.6.142) 191.782 ms be2184.mpd21.ams03.atlas.cogentco.com (154.54.37.69) 204.548 ms te0-5-0-4.ccr22.lpl01.atlas.cogentco.com (154.54.87.53) 191.749 ms
    18 te0-7-0-0.mag21.ams03.atlas.cogentco.com (154.54.76.170) 191.771
    ms 199.379 ms be2184.mpd21.ams03.atlas.cogentco.com (154.54.37.69)
    199.369 ms
    19 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 199.355 ms 199.325
    ms te0-0-0-4.mag21.ams03.atlas.cogentco.com (154.54.76.190) 207.195 ms
    20 * * 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 188.627 ms
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *
    knoppix@Microknoppix:~$


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Fri Oct 11 14:32:03 2013
    ein wrote:

    Have you tired https://www.centos.org/ ?

    Yes. I had mentioned it earlier, but, I have an old thread there
    on the same topic, and I also contacted the gmane centos group
    and I contacted the web sysadmins.

    They're all saying that it works for them ...

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Fri Oct 11 14:41:30 2013
    billy wrote:

    They're all saying that it works for them ...

    BTW, I have resigned myself to the conclusion that, in a cynical
    way, "the Internet doesn't really work", since it arbitrarily
    works for 99% of the sites I want to connect to, but, I know of
    two that it just is flaky on.
    centos.org <== which I do care about
    linuxreference.com <== which I don't care about

    The sheer capriciousness of the results is what's killing me because
    it makes no sense for the Internet to not work.

    The entire thing was designed to work - and this indicates that
    (for me, for a few sites), it's just not working.

    Makes no sense - and that's what is killing me inside, eating me
    up.

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Fri Oct 11 14:43:51 2013
    nemesis wrote:

    The guy at 67.218.118.85.
    He probably lives nearby. Kick his a¨%&¨¨.

    That's me! :)

    Anyway, the problem is back, and shown below.

    If I had a better DIAGNOSTIC TOOL, I'd feel better with the data.
    It's not the MTU, the TTL, the DNS server, the operating system,
    etc.

    I just wish I had a better diagnostic tool than traceroute...

    knoppix@Microknoppix:~$ traceroute !$
    traceroute centos.org
    traceroute to centos.org (85.12.30.227), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 6.125 ms 6.094 ms 6.077 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 33.527 ms 33.515
    ms 33.499 ms
    3 10.50.0.1 (10.50.0.1) 33.485 ms 39.686 ms 47.348 ms
    4 10.25.0.1 (10.25.0.1) 82.142 ms 82.128 ms 82.113 ms
    5 10.20.0.1 (10.20.0.1) 101.802 ms 101.787 ms 101.771 ms
    6 10.0.0.1 (10.0.0.1) 111.627 ms 52.710 ms 52.672 ms
    7 69.36.226.193 (69.36.226.193) 52.637 ms 25.633 ms 25.613 ms
    8 vl2.core2.scl.layer42.net (69.36.225.130) 25.599 ms 25.584 ms
    32.306 ms
    9 xe-0-0-0-22.r07.snjsca04.us.bb.gin.ntt.net (140.174.21.101) 36.545
    ms 36.530 ms 36.515 ms
    10 te0-7-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.11.85) 36.477 ms te0-4-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.10.49) 36.463 ms te0-7-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.11.85) 36.433 ms
    11 be2000.ccr21.sjc01.atlas.cogentco.com (154.54.6.105) 36.442 ms
    36.427 ms 17.909 ms
    12 be2164.ccr21.sfo01.atlas.cogentco.com (154.54.28.33) 26.295 ms be2166.mpd21.sfo01.atlas.cogentco.com (154.54.28.69) 26.279 ms be2167.mpd22.sfo01.atlas.cogentco.com (154.54.28.77) 31.666 ms
    13 be2135.mpd22.mci01.atlas.cogentco.com (154.54.6.34) 81.979 ms be2134.mpd21.mci01.atlas.cogentco.com (154.54.6.38) 81.949 ms be2135.mpd22.mci01.atlas.cogentco.com (154.54.6.34) 81.943 ms
    14 be2159.mpd22.ord01.atlas.cogentco.com (154.54.24.82) 91.739 ms
    110.049 ms be2156.ccr21.ord01.atlas.cogentco.com (154.54.6.86) 110.039
    ms
    15 be2140.ccr22.bos01.atlas.cogentco.com (154.54.43.186) 118.042 ms be2080.ccr22.yyz02.atlas.cogentco.com (154.54.42.6) 112.212 ms be2137.ccr21.bos01.atlas.cogentco.com (154.54.43.194) 118.011 ms
    16 te0-2-0-1.ccr21.lpl01.atlas.cogentco.com (154.54.31.190) 185.107
    ms te0-0-0-1.ccr21.lpl01.atlas.cogentco.com (154.54.31.170) 185.082 ms 185.048 ms
    17 te0-3-0-6.ccr21.lpl01.atlas.cogentco.com (154.54.6.142) 191.782 ms be2184.mpd21.ams03.atlas.cogentco.com (154.54.37.69) 204.548 ms te0-5-0-4.ccr22.lpl01.atlas.cogentco.com (154.54.87.53) 191.749 ms
    18 te0-7-0-0.mag21.ams03.atlas.cogentco.com (154.54.76.170) 191.771
    ms 199.379 ms be2184.mpd21.ams03.atlas.cogentco.com (154.54.37.69)
    199.369 ms
    19 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 199.355 ms 199.325
    ms te0-0-0-4.mag21.ams03.atlas.cogentco.com (154.54.76.190) 207.195 ms
    20 * * 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 188.627 ms
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *
    knoppix@Microknoppix:~$
    knoppix@Microknoppix:~$ traceroute linuxreference.com
    traceroute to linuxreference.com (72.232.194.162), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 2.834 ms 2.810 ms 9.836 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 19.635 ms 19.625
    ms 19.610 ms
    3 10.50.0.1 (10.50.0.1) 46.754 ms 46.748 ms 46.730 ms
    4 10.25.0.1 (10.25.0.1) 51.077 ms 51.065 ms 51.051 ms
    5 10.20.0.1 (10.20.0.1) 53.594 ms 53.583 ms 53.574 ms
    6 10.0.0.1 (10.0.0.1) 53.548 ms 37.843 ms 37.816 ms
    7 69.36.226.193 (69.36.226.193) 35.370 ms 35.323 ms 37.883 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 37.878 ms 37.863 ms
    37.847 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 37.832 ms 59.609 ms 59.597 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 112.224 ms 112.214 ms 104.915 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 104.885 ms 104.859
    ms 104.813 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 101.385 ms 133.165 ms
    133.144 ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 111.137 ms 111.135 ms 111.097 ms
    14 border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 111.084 ms border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 111.070 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 114.155 ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 114.144 ms
    114.133 ms 114.110 ms
    16 * * *
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *
    knoppix@Microknoppix:~$

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From billy@110:110/2002 to All on Fri Oct 11 14:48:40 2013
    unruh wrote:

    Yes, and then because something changes, suddenly it is different.

    You just gave me a diagnostic idea!
    You guys have modems, but I have a transceiver instead of a modem.
    I can log into the radio on the roof and let it run the traceroute!
    That way, my entire house is eliminated as a variable!

    Here's the traceroute just now from the radio:
    RADIO: traceroute centos.org
    # Host IP Responses
    1 10.50.0.1 9.148 ms 6.287 ms 1.944 ms
    2 10.25.0.1 12.735 ms 9.051 ms 10.880 ms
    3 10.20.0.1 16.225 ms 56.871 ms 14.400 ms
    4 10.0.0.1 53.791 ms 40.530 ms 12.047 ms
    5 69.36.226.193 19.931 ms 72.111 ms
    30.576 ms
    6 69.36.225.129 21.656 ms 32.959 ms
    20.087 ms
    7 140.174.21.101 15.294 ms 20.615 ms
    18.735 ms
    8 154.54.11.85 18.116 ms 8.769 ms
    16.054 ms
    9 154.54.5.113 13.920 ms 14.242 ms
    15.359 ms
    10 154.54.28.33 18.270 ms 14.705 ms
    20.000 ms
    11 154.54.30.66 76.472 ms 81.262 ms
    66.369 ms
    12 154.54.6.86 82.061 ms 86.454 ms 102.949 ms
    13 154.54.42.10 92.515 ms 94.962 ms
    99.695 ms
    14 154.54.44.106 94.444 ms 169.748 ms
    110.654 ms
    15 154.54.6.142 178.136 ms 166.632 ms
    200.960 ms
    16 154.54.37.234 178.396 ms 227.571 ms
    182.961 ms
    17 154.54.76.198 253.605 ms 197.191 ms
    214.669 ms
    18 85.12.30.227 170.040 ms !C 193.573
    ms 192.897 ms

    Huh? It made it through? Let me run a quick traceroute on the laptop!
    $ traceroute centos.org
    traceroute to centos.org (85.12.30.227), 30 hops max, 60 byte packets
    1 192.168.1.1 (192.168.1.1) 7.298 ms 7.264 ms 7.247 ms
    2 67-218-118-85.ridgewireless.net (67.218.118.85) 20.239 ms 20.227
    ms 20.210 ms
    3 10.50.0.1 (10.50.0.1) 23.845 ms 23.830 ms 23.814 ms
    4 10.25.0.1 (10.25.0.1) 37.873 ms 37.860 ms 37.844 ms
    5 10.20.0.1 (10.20.0.1) 37.829 ms 40.619 ms 40.597 ms
    6 10.0.0.1 (10.0.0.1) 56.534 ms 134.350 ms 134.330 ms
    7 69.36.226.193 (69.36.226.193) 134.315 ms 97.897 ms 97.878 ms
    8 vl2.core2.scl.layer42.net (69.36.225.130) 97.869 ms 97.845 ms
    97.834 ms
    9 xe-0-0-0-22.r07.snjsca04.us.bb.gin.ntt.net (140.174.21.101)
    102.205 ms 97.803 ms 102.171 ms
    10 te0-7-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.11.85) 97.761 ms 102.118 ms te0-4-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.10.49)
    102.104 ms
    11 be2000.ccr21.sjc01.atlas.cogentco.com (154.54.6.105) 102.098 ms be2047.ccr22.sjc01.atlas.cogentco.com (154.54.5.113) 102.081 ms be2000.ccr21.sjc01.atlas.cogentco.com (154.54.6.105) 68.723 ms
    12 be2165.ccr22.sfo01.atlas.cogentco.com (154.54.28.65) 68.708 ms be2167.mpd22.sfo01.atlas.cogentco.com (154.54.28.77) 68.693 ms be2165.ccr22.sfo01.atlas.cogentco.com (154.54.28.65) 128.983 ms
    13 be2134.mpd21.mci01.atlas.cogentco.com (154.54.6.38) 138.168 ms
    138.156 ms be2135.mpd22.mci01.atlas.cogentco.com (154.54.6.34) 144.404
    ms
    14 be2158.mpd21.ord01.atlas.cogentco.com (154.54.7.130) 160.871 ms be2157.ccr22.ord01.atlas.cogentco.com (154.54.6.118) 160.858 ms be2156.ccr21.ord01.atlas.cogentco.com (154.54.6.86) 160.827 ms
    15 be2139.ccr21.bos01.atlas.cogentco.com (154.54.43.178) 167.524 ms be2080.ccr22.yyz02.atlas.cogentco.com (154.54.42.6) 160.809 ms be2081.ccr21.yyz02.atlas.cogentco.com (154.54.42.10) 160.785 ms
    16 be2091.ccr22.ymq02.atlas.cogentco.com (154.54.44.98) 167.479 ms be2092.ccr21.ymq02.atlas.cogentco.com (154.54.25.26) 167.456 ms be2090.ccr21.ymq02.atlas.cogentco.com (154.54.30.206) 167.431 ms
    17 te0-5-0-6.ccr21.lpl01.atlas.cogentco.com (154.54.87.65) 235.370 ms te0-5-0-6.ccr22.lpl01.atlas.cogentco.com (154.54.87.57) 235.330 ms be2183.ccr22.ams03.atlas.cogentco.com (154.54.58.70) 235.329 ms
    18 te0-0-0-10.mag21.ams03.atlas.cogentco.com (154.54.37.234) 225.581
    ms be2185.mpd22.ams03.atlas.cogentco.com (154.54.37.105) 225.554 ms be2183.ccr22.ams03.atlas.cogentco.com (154.54.58.70) 215.695 ms
    19 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 215.661 ms te0-3-0-15.mag21.ams03.atlas.cogentco.com (154.54.78.217) 225.499 ms 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 215.632 ms
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *

    Hmmm... so maybe it "is" my home broadband router (netgear standard
    stuff).

    Let me try with the linuxreference site...


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From ~BD~@1:0/0 to All on Fri Oct 11 15:11:54 2013
    billy wrote:
    nemesis wrote:

    The guy at 67.218.118.85.
    He probably lives nearby. Kick his a%&.

    That's me! :)

    Anyway, the problem is back, and shown below.

    If I had a better DIAGNOSTIC TOOL, I'd feel better with the data.
    It's not the MTU, the TTL, the DNS server, the operating system,
    etc.

    I just wish I had a better diagnostic tool than traceroute...

    Oh dear! I thought you'd cracked it Billy!

    Have you ever 'played' with .... http://nmap.org/ ?

    I've no idea if it will help you .... but you might find it fun! ;-)

    Please advise.






    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From unruh@1:0/0 to All on Fri Oct 11 16:03:48 2013
    On 2013-10-11, billy <billy@is.invalid> wrote:
    dyrmak wrote:

    Could it be DNS problem you are having on your own ?
    When the problem occurs http://@IP might give confirmation.
    If your router is mtu-modifiable lower it to 150 thereabouts
    along with your network card and see what happens.

    DNS? Hmmm... would switching DNS servers affect the route taken?
    I'll try that, but, putting the IP address in the URL does not help.

    A red herring. The dns simply translates names to IP addresses. It does
    not do anything else and certainly does not alter routes (unless the
    address changes).



    For example, http://85.12.30.227/ does the same thing as does http://www.centos.org as does http://centos.org




    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Tauno Voipio@110:110/2002 to All on Fri Oct 11 18:34:05 2013
    On 11.10.13 5:26 , billy wrote:
    dyrmak wrote:

    Could it be DNS problem you are having on your own ?
    When the problem occurs http://@IP might give confirmation.
    If your router is mtu-modifiable lower it to 150 thereabouts
    along with your network card and see what happens.

    DNS? Hmmm... would switching DNS servers affect the route taken?
    I'll try that, but, putting the IP address in the URL does not help.

    For example, http://85.12.30.227/ does the same thing as does http://www.centos.org as does http://centos.org


    No, but you're talking of two different IP addresses,
    and IP addresses are the only things routing cares
    about.

    When you supply the name of a website, it gets translated
    to an IP address by DNS. If you get two different IP's,
    it is quite natural that they may have different routes,
    and only one of the sites responds.

    Many Web servers do also care of the name of the target
    site supplied also in the HTTP protocol headers. This
    is how there can be many websites under the same IP.

    --

    -Tauno


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From petrus bitbyter@1:0/0 to All on Fri Oct 11 20:17:06 2013

    "billy" <billy@is.invalid> schreef in bericht news:l2vumu$4bj$1@speranza.aioe.org...
    Why can't I connect (via port 80 or any port) to a certain web site?

    For more than a year I've had the same problem, and, it's NOT
    the way I'm running traceroute! (e.g., it's not ICMP vs TCP, etc.).
    It's also not that the server I'm pinging is down, or slow.

    There's something wrong with "my" home networking setup.
    But what?

    I just want to UNDERSTAND the problem. That's it.
    It makes NO sense what I've been seeing over the past year.

    Basically, for months at a time, I can't connect to centos.org
    and, for months at a time, I can connect to the web site.

    When I can't connect, traceroute (ICMP or TCP) fails to connect;
    when I can connect, traceroute also connects.

    So, it isn't HOW I'm running traceroute, as traceroute is telling
    me exactly what Firefox is telling me.

    This happens for months at a time, and has happened about five
    times in the past two years.

    I change NOTHING (not my router firewall, not my computer firewall,
    not my networking setup, etc.) in the interim.

    When this happens, I switch to TOR, and I can EASILY connect to
    centos.org via the proxy Firefox - so there's nothing wrong with
    my firewall or with my home broadband router (as far as I can tell).

    When I can't connect, I ask my NEIGHBORS who "can" get to centos.org
    to show me their traceroute, and it looks the same as mine except
    for the fact that their times are slightly faster and they get
    past that last hop - whereas mine dies at the penultimate hop.

    So, THAT would implicate something on "my" side (but what?).

    I switch to Knoppix 7, and I get the same result.
    I go to a Windows PC, and I get the same result.
    So, it's NOT the PC!

    If I knew how to get around my router, I would, but it has
    all the setup for the ISP (it's a WISP, not cable or DSL).

    My question?

    How can I debug WHY (for months at a time), I can't get to a web site?

    Here's a traceroute run just now:
    knoppix@Microknoppix:~$ traceroute www.centos.org
    traceroute to www.centos.org (72.232.194.162), 30 hops max, 60 byte
    packets
    1 192.168.1.1 (192.168.1.1) 2.835 ms 2.809 ms 20.293 ms
    2 REDACTED_WISP.net (xxx.xxx.xxx.xxx) 20.280 ms 20.265 ms 20.248
    ms
    3 10.50.0.1 (10.50.0.1) 29.973 ms 29.959 ms 29.943 ms
    4 10.25.0.1 (10.25.0.1) 39.067 ms 42.759 ms 42.745 ms
    5 10.20.0.1 (10.20.0.1) 82.295 ms 82.280 ms 82.265 ms
    6 10.0.0.1 (10.0.0.1) 122.956 ms 159.675 ms 159.654 ms
    7 69.36.226.193 (69.36.226.193) 198.537 ms 201.445 ms 201.433 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 201.423 ms 201.412 ms
    201.388 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 201.377 ms 201.361
    ms 201.346 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 239.215 ms 239.185 ms 239.171 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 239.137 ms 239.122
    ms 239.061 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 239.030 ms 123.544 ms
    178.276 ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 178.261 ms 178.264 ms 178.231 ms
    14 border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 178.234 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 178.187 ms border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 178.199 ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 178.171 ms
    178.139 ms 178.123 ms
    16 * * *
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *

    I know, from two years of experiencing this, that the hop after the
    last hop showing resuls "is" Centos.org! So, when it works, it gets to
    the last hop; but when it dies, it always dies at just before the last
    hop. But why?

    Can you help me UNDERSTAND why/how this situation can be happening?
    Note: All other web sites work just fine.

    NOTE: I already know that YOU will be able to access this same site
    with much lower ping times (you're not on a WISP either) - but that
    doesn't help ME figure out what the problem is.

    Is there freeware extant to help me UNDERSTAND why this happens to me?



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From billy@110:110/2002 to All on Fri Oct 11 20:19:12 2013
    unruh wrote:

    The dns simply translates names to IP addresses.
    It does not do anything else and certainly does
    not alter routes (unless the address changes).

    To update, the only small victory I can report is that, for
    some reason, the RADIO on the roof (which is equivalent to
    your DSL/Cable modem) *can* ping & traceroute to centos.org
    but the computers in the house can not.

    That would imply it's the Netgear WNDR router, but, I updated
    it to the latest firmware and looked at all the settings, and
    changed a few (e.g., the MTU) but it didn't have any positive
    effect.
    a. I can't access centos.org from any computer by any method.
    b. I *can* ping/traceroute centos.org from the rooftop radio.

    What gets me is that the Netgear WNDR router is pretty much
    set up just like anyone would have set it up for a home. I left
    everything at the defaults other than what absolutely had to
    be changed to give it WPA2-PSK and a static IP address for
    the radio (which the WISP gives me).

    Is there any particular setting you think I should check on the
    Netgear WNDR3200 router that might be the culprit?


    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From unruh@1:0/0 to All on Fri Oct 11 20:38:08 2013
    On 2013-10-11, billy <billy@is.invalid> wrote:
    unruh wrote:

    The dns simply translates names to IP addresses.
    It does not do anything else and certainly does
    not alter routes (unless the address changes).

    To update, the only small victory I can report is that, for
    some reason, the RADIO on the roof (which is equivalent to
    your DSL/Cable modem) *can* ping & traceroute to centos.org
    but the computers in the house can not.

    That would imply it's the Netgear WNDR router, but, I updated
    it to the latest firmware and looked at all the settings, and
    changed a few (e.g., the MTU) but it didn't have any positive
    effect.
    a. I can't access centos.org from any computer by any method.
    b. I *can* ping/traceroute centos.org from the rooftop radio.

    What gets me is that the Netgear WNDR router is pretty much
    set up just like anyone would have set it up for a home. I left
    everything at the defaults other than what absolutely had to
    be changed to give it WPA2-PSK and a static IP address for
    the radio (which the WISP gives me).

    Is there any particular setting you think I should check on the
    Netgear WNDR3200 router that might be the culprit?


    Well, I do not know if you can do it on your router, but you could try a tcpdump at the router of the packet sent to centos.or when you ping it
    from your machine and when you ping it from your router to see what the difference is. Of course, your router might not have tcpdump capability,
    but comparing those would seem to me to be the only way.

    You could capture a ping packet, say, from your computer and post it (I
    believe it is only 80 bytes long) and maybe someone can see something
    funny in it. I cannot.

    centos does respond to pings, I have tried it.



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From petrus bitbyter@1:0/0 to All on Fri Oct 11 20:42:06 2013

    "billy" <billy@is.invalid> schreef in bericht news:l2vumu$4bj$1@speranza.aioe.org...
    Why can't I connect (via port 80 or any port) to a certain web site?

    For more than a year I've had the same problem, and, it's NOT
    the way I'm running traceroute! (e.g., it's not ICMP vs TCP, etc.).
    It's also not that the server I'm pinging is down, or slow.

    There's something wrong with "my" home networking setup.
    But what?

    I just want to UNDERSTAND the problem. That's it.
    It makes NO sense what I've been seeing over the past year.

    Basically, for months at a time, I can't connect to centos.org
    and, for months at a time, I can connect to the web site.

    When I can't connect, traceroute (ICMP or TCP) fails to connect;
    when I can connect, traceroute also connects.

    So, it isn't HOW I'm running traceroute, as traceroute is telling
    me exactly what Firefox is telling me.

    This happens for months at a time, and has happened about five
    times in the past two years.

    I change NOTHING (not my router firewall, not my computer firewall,
    not my networking setup, etc.) in the interim.

    When this happens, I switch to TOR, and I can EASILY connect to
    centos.org via the proxy Firefox - so there's nothing wrong with
    my firewall or with my home broadband router (as far as I can tell).

    When I can't connect, I ask my NEIGHBORS who "can" get to centos.org
    to show me their traceroute, and it looks the same as mine except
    for the fact that their times are slightly faster and they get
    past that last hop - whereas mine dies at the penultimate hop.

    So, THAT would implicate something on "my" side (but what?).

    I switch to Knoppix 7, and I get the same result.
    I go to a Windows PC, and I get the same result.
    So, it's NOT the PC!

    If I knew how to get around my router, I would, but it has
    all the setup for the ISP (it's a WISP, not cable or DSL).

    My question?

    How can I debug WHY (for months at a time), I can't get to a web site?

    Here's a traceroute run just now:
    knoppix@Microknoppix:~$ traceroute www.centos.org
    traceroute to www.centos.org (72.232.194.162), 30 hops max, 60 byte
    packets
    1 192.168.1.1 (192.168.1.1) 2.835 ms 2.809 ms 20.293 ms
    2 REDACTED_WISP.net (xxx.xxx.xxx.xxx) 20.280 ms 20.265 ms 20.248
    ms
    3 10.50.0.1 (10.50.0.1) 29.973 ms 29.959 ms 29.943 ms
    4 10.25.0.1 (10.25.0.1) 39.067 ms 42.759 ms 42.745 ms
    5 10.20.0.1 (10.20.0.1) 82.295 ms 82.280 ms 82.265 ms
    6 10.0.0.1 (10.0.0.1) 122.956 ms 159.675 ms 159.654 ms
    7 69.36.226.193 (69.36.226.193) 198.537 ms 201.445 ms 201.433 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 201.423 ms 201.412 ms
    201.388 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 201.377 ms 201.361
    ms 201.346 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 239.215 ms 239.185 ms 239.171 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 239.137 ms 239.122
    ms 239.061 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 239.030 ms 123.544 ms
    178.276 ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 178.261 ms 178.264 ms 178.231 ms
    14 border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 178.234 ms border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 178.187 ms border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 178.199 ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 178.171 ms
    178.139 ms 178.123 ms
    16 * * *
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *

    I know, from two years of experiencing this, that the hop after the
    last hop showing resuls "is" Centos.org! So, when it works, it gets to
    the last hop; but when it dies, it always dies at just before the last
    hop. But why?

    Can you help me UNDERSTAND why/how this situation can be happening?
    Note: All other web sites work just fine.

    NOTE: I already know that YOU will be able to access this same site
    with much lower ping times (you're not on a WISP either) - but that
    doesn't help ME figure out what the problem is.

    Is there freeware extant to help me UNDERSTAND why this happens to me?

    Reading all I can of this thread (maybe not all because off my newsserver is not 100% reliable) I followed the diving into the routing and the protocol. AFAIS one cause has been overlooked so far: An intermittend hardware error.
    To me all results so far point in that direction. Suspect is all hardware between your computer and WISP. Shortest way to find out is exchanging all parts of it one at a time, including cables and power supplies. The logic behind it looks like obvious to me. All that equipment is similar to that of your neighbours but the latter has no problem. Your computer has no problem when using it too. So your equipment itself or the place or way it has been installed may cause that peculiar problem.

    petrus bitbyter



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From unruh@1:0/0 to All on Thu Oct 10 21:04:16 2013
    On 2013-10-10, billy <billy@is.invalid> wrote:
    Chris Davies wrote:

    You can check your default TTL with this command:
    cat /proc/sys/net/ipv4/ip_default_ttl
    On my system it returns 64.
    sudo -s # become root
    echo 128 > /proc/sys/net/ipv4/ip_default_ttl

    This is a great detective idea!

    On Knoppix, my TTL is set, by default, to 64 also:
    $ cat /proc/sys/net/ipv4/ip_default_ttl
    64
    If I understand it correctly, that's 64 routers, right?
    I only seem to be going through 1/4 that many routers,
    yet, mine fails to complete the route.

    Still, it seems useful to increase the number & try again.
    I can't modify the Knoppix TTL since it's on a DVD so I
    will try it with another operating system and report back.

    Sure you can. Just as he says. Everything in /proc is a fake filesystem,
    it is NOT on the hard disk or dvd or anything. It is a look into the
    kernel which is of course in memory. Just do as he says.




    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From ps56k@110:110/2002 to All on Thu Oct 10 21:34:50 2013
    Your basic problem in this entire discussion
    is that you have no concept of the very basics in networking -
    called - a protocol stack -

    Here is the TCP/IP version -

    Application (like email, browser, etc)
    Transport (specify ports on computers)
    Internet (addressing & routing)
    Link (physical)

    The browser lives at the very top - as an Application
    and has NO knowledge of ANY protocol issues at the lower layers.
    So, to keep asking about how the fix the browser is meaningless.

    The lower layers are where TCP (Transport Control Protocol)
    and the IP (Internet Protocol) address live.

    Next - is the physical and link.... this is the magic of "transmit" and "receive" -

    SO - some routers and website might turn of their responses to ICMP messages (ping/echo etc)
    and it might appear they are not responding to those tools - but in fact - they are "ignoring" them.

    On the topic of MTU (the size of the packets transmitted)
    I have never had a website not respond,
    but have had probs with a school system called Blackboard
    that would not function properly on a DSL line
    due to a MTU being less than the Blackboard required value of 1500.

    WEIRD -
    I can ping and traceroute to --> centos.org
    but it does NOT reply to my browser request ??

    This page cannot be displayed due to an internal error.

    If you are the administrator of this site, please visit the Xoops Troubleshooting Page for assistance.

    Error [Xoops]: Unable to connect to database in file class/database/databasefactory.php line 34




    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: me (110:110/2002@linuxnet)
  • From ps56k@110:110/2002 to All on Thu Oct 10 21:41:59 2013
    it times out - done -

    http://mxtoolbox.com/SuperTool.aspx?action=http%3acentos.org&run=networktools#




    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: me (110:110/2002@linuxnet)
  • From Mike Easter@1:0/0 to All on Thu Oct 10 22:16:02 2013
    ps56k wrote:
    it times out - done -


    http://mxtoolbox.com/SuperTool.aspx?action=http%3acentos.org&run=networktools#

    Presently centos.org is down for everyone

    http://www.downforeveryoneorjustme.com/centos.org It's not just you! http://centos.org looks down from here.

    http://www.isup.me/www.centos.org It's not just you!
    http://www.centos.org looks down from here.


    That has not been the case for the duration of this thread.




    --
    Mike Easter

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Mike Easter@1:0/0 to All on Thu Oct 10 22:18:00 2013
    Mike Easter wrote:

    Presently centos.org is down for everyone

    Initiating server query ...
    Looking up IP address for domain: www.centos.org
    The IP address for the domain is: 85.12.30.227
    Connecting to the server on standard HTTP port: 80
    The port is closed, so our connection attempt was refused.
    Query complete.

    --
    Mike Easter

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Thomas Keusch@110:110/2002 to All on Thu Oct 10 22:32:44 2013
    On 2013-10-09, billy <billy@is.invalid> wrote:
    Gary R. Schmidt wrote:

    There is a "black hole" between you and centos.org.
    Packets go in, but do not come out
    I would assume that the problem lies with "pnap.net",
    Your WISP appears to be connecting to "layer42" (69.36.226.193)

    All this makes perfect sense, except ...

    Except my neighbors, on the same WISP, can get to centos.org.

    So, it must be something in 'my' setup; but where?

    More specifically, how do I diagnose to pinpoint where?


    Does your firewall block ICMP coming from the outside?
    If yes, stop doing that, and research PMTUD.

    Best regards
    Thomas


    --

    * Freelance Linux & BSD Systemengineer // IT Consultant *
    -=- Homepage: http://www.bsd-solutions-duesseldorf.de -=-

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: /dev/null Boring Headers Inc. (110:110/2002@linuxnet)
  • From unruh@1:0/0 to All on Thu Oct 10 22:40:28 2013
    On 2013-10-10, ps56k <pschuman_no5pam_m3@interserv.com> wrote:
    Your basic problem in this entire discussion
    is that you have no concept of the very basics in networking -
    called - a protocol stack -

    He may not have, but it is irrelevant. He is not able to connect. Can
    you give him the cause? Can you suggest how he fix it? It is like if you brought me your car to fix and I told you that you had no concept of the
    basics of the Standard Model of particle phyics as if such knowledge
    would help you fix your car.


    WEIRD -
    I can ping and traceroute to --> centos.org
    but it does NOT reply to my browser request ??

    And you now call this weird. I thought you had an intimate knowledge of
    the protocol layers. Why is this weird?

    Note that I have absolutely no trouble connecting to centos.org.





    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Chris Davies@110:110/2002 to All on Thu Oct 10 23:00:09 2013
    Reply-To: chris@roaima.co.uk

    In comp.os.linux.networking ps56k <pschuman_no5pam_m3@interserv.com> wrote:
    On the topic of MTU (the size of the packets transmitted)
    I have never had a website not respond,

    I have.

    Chris

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Roaima. Harrogate, North Yorkshire, UK (110:110/2002@linuxnet)
  • From Chris Davies@110:110/2002 to All on Thu Oct 10 23:03:01 2013
    Reply-To: chris@roaima.co.uk

    billy <billy@is.invalid> wrote:
    On Knoppix, my TTL is set, by default, to 64 also:
    $ cat /proc/sys/net/ipv4/ip_default_ttl
    64
    If I understand it correctly, that's 64 routers, right?

    Yes, which should be plenty.


    I only seem to be going through 1/4 that many routers,
    yet, mine fails to complete the route.

    Bang goes another theory.


    I can't modify the Knoppix TTL since it's on a DVD so I
    will try it with another operating system and report back.

    You can modify the value for the duration of the session because it's
    held in the kernel, in memory.

    Chris

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Roaima. Harrogate, North Yorkshire, UK (110:110/2002@linuxnet)
  • From Chris Davies@110:110/2002 to All on Thu Oct 10 23:01:51 2013
    Reply-To: chris@roaima.co.uk

    unruh <unruh@invalid.ca> wrote:
    On 2013-10-10, Chris Davies <chris-usenet@roaima.co.uk> wrote:
    You can check your default TTL with this command:
    cat /proc/sys/net/ipv4/ip_default_ttl

    But surely his chain does not take 64 sec to reach the far end (assuming
    I am reading that correctly).

    It's not a DNS TTL, it's a hop count. 64 hops is the maximum distance
    packets from my system can reach.


    that default does not harm much. On the other hand, somewhere down the
    route that ttl could be changed by one of the other links in the chain.

    Each hop decrements the value by one until it hits zero.
    Chris

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Roaima. Harrogate, North Yorkshire, UK (110:110/2002@linuxnet)
  • From ps56k@110:110/2002 to All on Thu Oct 10 23:27:43 2013
    this is an interesting discussion -
    you mean like -
    please fix my car - the lugnuts don't fit into the key slot - so I can't
    start it -
    "different layers" - but guess I'll just keep throwing tech words around...

    weird - yup -
    it times out from my network - and other "online testing sites" -
    so... ????

    Ping - centos.org - 85.12.30.227 --> Amsterdam
    Ping - www.centos.org - 72.232.194.162 ---> ????

    So, where does the - 72.232.194.162 come from ??
    vs my DNS lookup is showing 85.12.30.227 ??

    2 NS1.LAYEREDTECH.COM 72.232.1.236
    AUTH 0 ms Received 1 Answers , rcode=
    PTR: PointerName=www.centos.org,

    cname:www.centos.org
    Lookup failed after 1 name server timed out or responded non-authoritatively

    -----------
    Here's his traceroute run:
    knoppix@Microknoppix:~$ traceroute www.centos.org
    traceroute to www.centos.org (72.232.194.162), 30 hops max, 60 byte

    ----------
    HopCount IP Address HostName
    1 208.123.79.34 net208-123-79-34.static-customer.corenap.com
    2 198.252.182.180 aus-core-10-v12.corenap.com
    3 24.155.184.106 xe-0-0-2-509.AUSTTXMIM002.aggr09.austtx.grandecom.net
    4 24.155.121.76 xe-0-0-0-0.aggr08.austtx.grandecom.net
    5 4.30.74.53 ae5-868.edge9.Dallas1.Level3.net
    6 4.69.145.200 ae-4-90.edge3.Dallas1.Level3.net
    7 4.71.170.6 LAYERED-TEC.edge3.Dallas1.Level3.net
    8 * * * * * *
    9 72.232.194.162 www.centos.org


    ---------

    their TCP/IP world seems messed up somewhere within their DNS records -







    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: me (110:110/2002@linuxnet)
  • From Thad Floryan@110:110/2002 to All on Thu Oct 10 23:49:23 2013
    On 10/10/2013 4:27 PM, ps56k wrote:
    [...]

    Ping - centos.org - 85.12.30.227 --> Amsterdam
    Ping - www.centos.org - 72.232.194.162 ---> ????

    So, where does the - 72.232.194.162 come from ??
    vs my DNS lookup is showing 85.12.30.227 ??
    [...]

    Here (Silicon Valley over Comcast's High Speed Internet)
    a 'ping centos.org' and a ping 'www.centos.org' both
    resolve to 85.12.30.227

    a 'whois 72.232.194.162' reveals it's Akamai, a worldwide
    service for faster Internet used by all the majors: Google,
    fecebook, etc. per:


    NetRange: 172.224.0.0 - 172.239.255.255
    CIDR: 172.224.0.0/12
    OriginAS:
    NetName: AKAMAI
    NetHandle: NET-172-224-0-0-1
    Parent: NET-172-0-0-0-0
    NetType: Direct Assignment
    RegDate: 2013-03-15
    Updated: 2013-03-15
    Ref: http://whois.arin.net/rest/net/NET-172-224-0-0-1

    OrgName: Akamai Technologies, Inc.
    OrgId: AT-80
    Address: 8 Cambridge Center
    Address: MS 926-G
    City: Cambridge
    StateProv: MA
    PostalCode: 02142
    Country: US
    RegDate: 2011-10-19
    Updated: 2012-01-26
    Ref: http://whois.arin.net/rest/org/AT-80

    OrgAbuseHandle: MHA379-ARIN
    OrgAbuseName: Hannigan, Martin
    OrgAbusePhone: +1-617-444-2535
    OrgAbuseEmail: ip-admin@akamai.com
    OrgAbuseRef: http://whois.arin.net/rest/poc/MHA379-ARIN

    OrgTechHandle: MHA379-ARIN
    OrgTechName: Hannigan, Martin
    OrgTechPhone: +1-617-444-2535
    OrgTechEmail: ip-admin@akamai.com
    OrgTechRef: http://whois.arin.net/rest/poc/MHA379-ARIN

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: ThadLABS (110:110/2002@linuxnet)
  • From unruh@1:0/0 to All on Fri Oct 11 21:16:59 2013
    On 2013-10-11, petrus bitbyter <petrus.bitbyter@hotmail.com> wrote:

    "billy" <billy@is.invalid> schreef in bericht news:l2vumu$4bj$1@speranza.aioe.org...
    Why can't I connect (via port 80 or any port) to a certain web site?

    For more than a year I've had the same problem, and, it's NOT
    the way I'm running traceroute! (e.g., it's not ICMP vs TCP, etc.).
    It's also not that the server I'm pinging is down, or slow.

    There's something wrong with "my" home networking setup.
    But what?

    I just want to UNDERSTAND the problem. That's it.
    It makes NO sense what I've been seeing over the past year.

    Basically, for months at a time, I can't connect to centos.org
    and, for months at a time, I can connect to the web site.

    When I can't connect, traceroute (ICMP or TCP) fails to connect;
    when I can connect, traceroute also connects.

    So, it isn't HOW I'm running traceroute, as traceroute is telling
    me exactly what Firefox is telling me.

    This happens for months at a time, and has happened about five
    times in the past two years.

    I change NOTHING (not my router firewall, not my computer firewall,
    not my networking setup, etc.) in the interim.

    When this happens, I switch to TOR, and I can EASILY connect to
    centos.org via the proxy Firefox - so there's nothing wrong with
    my firewall or with my home broadband router (as far as I can tell).

    When I can't connect, I ask my NEIGHBORS who "can" get to centos.org
    to show me their traceroute, and it looks the same as mine except
    for the fact that their times are slightly faster and they get
    past that last hop - whereas mine dies at the penultimate hop.

    So, THAT would implicate something on "my" side (but what?).

    I switch to Knoppix 7, and I get the same result.
    I go to a Windows PC, and I get the same result.
    So, it's NOT the PC!

    If I knew how to get around my router, I would, but it has
    all the setup for the ISP (it's a WISP, not cable or DSL).

    My question?

    How can I debug WHY (for months at a time), I can't get to a web site?

    Here's a traceroute run just now:
    knoppix@Microknoppix:~$ traceroute www.centos.org
    traceroute to www.centos.org (72.232.194.162), 30 hops max, 60 byte
    packets
    1 192.168.1.1 (192.168.1.1) 2.835 ms 2.809 ms 20.293 ms
    2 REDACTED_WISP.net (xxx.xxx.xxx.xxx) 20.280 ms 20.265 ms 20.248
    ms
    3 10.50.0.1 (10.50.0.1) 29.973 ms 29.959 ms 29.943 ms
    4 10.25.0.1 (10.25.0.1) 39.067 ms 42.759 ms 42.745 ms
    5 10.20.0.1 (10.20.0.1) 82.295 ms 82.280 ms 82.265 ms
    6 10.0.0.1 (10.0.0.1) 122.956 ms 159.675 ms 159.654 ms
    7 69.36.226.193 (69.36.226.193) 198.537 ms 201.445 ms 201.433 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 201.423 ms 201.412 ms
    201.388 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 201.377 ms 201.361
    ms 201.346 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 239.215 ms 239.185 ms
    239.171 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 239.137 ms 239.122
    ms 239.061 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 239.030 ms 123.544 ms
    178.276 ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 178.261 ms 178.264 ms
    178.231 ms
    14 border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 178.234 ms
    border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 178.187 ms
    border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 178.199 ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 178.171 ms
    178.139 ms 178.123 ms
    16 * * *
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *

    I know, from two years of experiencing this, that the hop after the
    last hop showing resuls "is" Centos.org! So, when it works, it gets to
    the last hop; but when it dies, it always dies at just before the last
    hop. But why?

    Can you help me UNDERSTAND why/how this situation can be happening?
    Note: All other web sites work just fine.

    NOTE: I already know that YOU will be able to access this same site
    with much lower ping times (you're not on a WISP either) - but that
    doesn't help ME figure out what the problem is.

    Is there freeware extant to help me UNDERSTAND why this happens to me?

    Reading all I can of this thread (maybe not all because off my newsserver is not 100% reliable) I followed the diving into the routing and the protocol. AFAIS one cause has been overlooked so far: An intermittend hardware error. To me all results so far point in that direction. Suspect is all hardware between your computer and WISP. Shortest way to find out is exchanging all parts of it one at a time, including cables and power supplies. The logic behind it looks like obvious to me. All that equipment is similar to that of your neighbours but the latter has no problem. Your computer has no problem when using it too. So your equipment itself or the place or way it has been installed may cause that peculiar problem.


    It is hard for me to see how a hardware error could cause troubles with
    ONLY centos.org. Remember that he says that he can browse almost all
    other web sites, even during the months that he cannot browse
    centos.org. It is really really hard to imagine some hardware error that
    would be that selective in its application, and furthermore one that
    allowed the packets to reach the penultimate link on a long chain and
    then fail on that final link.

    He has certainly been aware of your possibility, but has no idea how
    that could explain the symptoms. Perhaps you could explain how, even in
    the wildest of scenarios, this could explain his symptoms.
    And if it does, how he could figure our WHAT is wrong.



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From p-0''0-h the cat (ES)@110:110/2002 to All on Fri Oct 11 21:46:09 2013
    On Fri, 11 Oct 2013 14:23:05 +0000, billy <billy@is.invalid> wrote:

    Well if you emailed that guy I expect he either sorted it out or
    forwarded it to the person who could. If not God intervened.

    Unfortunately, the short respit is over. This morning, I again, can
    no longer connect to the (new) centos.org. Sigh ...
    I just wish I understood this better ...

    Forget trying to understand something not under your control. Focus on contacting people who can help you.

    Just put the domain name of the owner of the last router that replied
    into

    www.checkdomain.com and email the technical contact with the traceroutes
    and brief synopsis of the issues.

    Someone will sort it out in the end. That's their job.

    Registration Service Provided By: DICODE

    Domain Name: BASEIP.COM

    Registration Date: 19-Jan-2011
    Expiration Date: 19-Jan-2014

    Status:LOCKED
    Note: This Domain Name is currently Locked.
    This feature is provided to protect against fraudulent
    acquisition of the domain name,
    as in this status the domain name cannot be transferred or
    modified.

    Name Servers:
    ns1.baseip.com
    ns2.baseip.com


    Registrant Contact Details:
    Base IP B.V.
    T.A. Westervoorde (10815) (tim@baseip.com)
    Zweedsestraat 8A28
    Deventer
    Overijssel,7418 BG
    NL
    Tel. +31.857733066

    Administrative Contact Details:
    Base IP B.V.
    T.A. Westervoorde (10815) (tim@baseip.com)
    Zweedsestraat 8A28
    Deventer
    Overijssel,7418 BG
    NL
    Tel. +31.857733066

    Technical Contact Details:
    Base IP B.V.
    T.A. Westervoorde (10815) (tim@baseip.com)
    Zweedsestraat 8A28
    Deventer
    Overijssel,7418 BG
    NL
    Tel. +31.857733066

    Billing Contact Details:
    Base IP B.V.
    T.A. Westervoorde (10815) (tim@baseip.com)
    Zweedsestraat 8A28
    Deventer
    Overijssel,7418 BG
    NL
    Tel. +31.857733066

    --
    p-0.0-h the cat

    Internet Terrorist, Mass sock puppeteer, Agent provocateur, Gutter rat,
    Devil incarnate, Linux user#666, BaStarD hacker, Resident evil, Monkey Boy, Certifiable criminal, Spineless cowardly scum, textbook Psychopath,
    the SCOURGE, l33t p00h d3 tr0ll, p00h == lam3r, p00h == tr0ll, troll infme, the OVERCAT [The BEARPAIR are dead, and we are its murderers], lowlife troll, shyster [pending approval by STATE_TERROR], cripple, sociopath, kook,
    smug prick, smartarse, arsehole, moron, idiot, imbecile, snittish scumbag, liar, and shill.

    Honorary SHYSTER and FRAUD awarded for services to Haberdashery.
    By Appointment to God Frank-Lin.



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: ACF's purry underbelly (110:110/2002@linuxnet)
  • From David W. Hodgins@110:110/2002 to All on Fri Oct 11 22:15:53 2013
    On Fri, 11 Oct 2013 17:16:59 -0400, unruh <unruh@invalid.ca> wrote:

    It is hard for me to see how a hardware error could cause troubles with
    ONLY centos.org. Remember that he says that he can browse almost all
    other web sites, even during the months that he cannot browse
    centos.org. It is really really hard to imagine some hardware error that would be that selective in its application, and furthermore one that
    allowed the packets to reach the penultimate link on a long chain and
    then fail on that final link.

    This reminds me of a problem I encountered with a system using a
    RTL8111/8168B PCI Express Gigabit Ethernet controller.

    Every once in a while, it would stop connecting to some sites, while
    still working for other sites, and I could still use ssh to access
    the system.

    My nephew suggested rebooting the system. I explained, this was a
    linux system, and wouldn't make any difference. After arguing a bit,
    I rebooted it to show him, it wouldn't matter. To my surprise, it did
    clear the problem.

    That system is using a 50ft cable to connect to the router. My current
    guess, is that some packet is getting mangled, some of the time, and
    when it does, the only way to clear the problem, is to reset the pci
    device, by rebooting the system.

    Restarting the network is not enough. The system has to actually be
    rebooted. I suggested changing the wiring, and moving the router
    so a shorter cable could be used, but the owner has chosen to just
    reboot the system, whenever this happens, typically about every
    other week. This has been going on for a couple of years now, with
    multiple kernel updates during that time, and no change in behaviour.

    So there are cases where a hardware problem will affect some sites,
    but not others. Without disassembling the firmware, I have no
    idea what the nic is doing, so I can only confirm the observed
    results.

    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.)

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From petrus bitbyter@1:0/0 to All on Sun Oct 13 00:04:29 2013

    "unruh" <unruh@invalid.ca> schreef in bericht news:fVZ5u.50812$K71.48483@fx21.iad...
    On 2013-10-11, petrus bitbyter <petrus.bitbyter@hotmail.com> wrote:

    "billy" <billy@is.invalid> schreef in bericht
    news:l2vumu$4bj$1@speranza.aioe.org...
    Why can't I connect (via port 80 or any port) to a certain web site?

    For more than a year I've had the same problem, and, it's NOT
    the way I'm running traceroute! (e.g., it's not ICMP vs TCP, etc.).
    It's also not that the server I'm pinging is down, or slow.

    There's something wrong with "my" home networking setup.
    But what?

    I just want to UNDERSTAND the problem. That's it.
    It makes NO sense what I've been seeing over the past year.

    Basically, for months at a time, I can't connect to centos.org
    and, for months at a time, I can connect to the web site.

    When I can't connect, traceroute (ICMP or TCP) fails to connect;
    when I can connect, traceroute also connects.

    So, it isn't HOW I'm running traceroute, as traceroute is telling
    me exactly what Firefox is telling me.

    This happens for months at a time, and has happened about five
    times in the past two years.

    I change NOTHING (not my router firewall, not my computer firewall,
    not my networking setup, etc.) in the interim.

    When this happens, I switch to TOR, and I can EASILY connect to
    centos.org via the proxy Firefox - so there's nothing wrong with
    my firewall or with my home broadband router (as far as I can tell).

    When I can't connect, I ask my NEIGHBORS who "can" get to centos.org
    to show me their traceroute, and it looks the same as mine except
    for the fact that their times are slightly faster and they get
    past that last hop - whereas mine dies at the penultimate hop.

    So, THAT would implicate something on "my" side (but what?).

    I switch to Knoppix 7, and I get the same result.
    I go to a Windows PC, and I get the same result.
    So, it's NOT the PC!

    If I knew how to get around my router, I would, but it has
    all the setup for the ISP (it's a WISP, not cable or DSL).

    My question?

    How can I debug WHY (for months at a time), I can't get to a web site?

    Here's a traceroute run just now:
    knoppix@Microknoppix:~$ traceroute www.centos.org
    traceroute to www.centos.org (72.232.194.162), 30 hops max, 60 byte
    packets
    1 192.168.1.1 (192.168.1.1) 2.835 ms 2.809 ms 20.293 ms
    2 REDACTED_WISP.net (xxx.xxx.xxx.xxx) 20.280 ms 20.265 ms 20.248
    ms
    3 10.50.0.1 (10.50.0.1) 29.973 ms 29.959 ms 29.943 ms
    4 10.25.0.1 (10.25.0.1) 39.067 ms 42.759 ms 42.745 ms
    5 10.20.0.1 (10.20.0.1) 82.295 ms 82.280 ms 82.265 ms
    6 10.0.0.1 (10.0.0.1) 122.956 ms 159.675 ms 159.654 ms
    7 69.36.226.193 (69.36.226.193) 198.537 ms 201.445 ms 201.433 ms
    8 vl2.core1.scl.layer42.net (69.36.225.129) 201.423 ms 201.412 ms
    201.388 ms
    9 216.156.84.141.ptr.us.xo.net (216.156.84.141) 201.377 ms 201.361
    ms 201.346 ms
    10 207.88.14.233.ptr.us.xo.net (207.88.14.233) 239.215 ms 239.185 ms
    239.171 ms
    11 vb15.rar3.dallas-tx.us.xo.net (207.88.12.45) 239.137 ms 239.122
    ms 239.061 ms
    12 207.88.14.34.ptr.us.xo.net (207.88.14.34) 239.030 ms 123.544 ms
    178.276 ms
    13 207.88.185.74.ptr.us.xo.net (207.88.185.74) 178.261 ms 178.264 ms
    178.231 ms
    14 border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 178.234 ms
    border1.pc1-bbnet1.dal004.pnap.net (216.52.191.19) 178.187 ms
    border1.pc2-bbnet2.dal004.pnap.net (216.52.191.81) 178.199 ms
    15 layered-11.border1.dal004.pnap.net (63.251.44.74) 178.171 ms
    178.139 ms 178.123 ms
    16 * * *
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    21 * * *
    22 * * *
    23 * * *
    24 * * *
    25 * * *
    26 * * *
    27 * * *
    28 * * *
    29 * * *
    30 * * *

    I know, from two years of experiencing this, that the hop after the
    last hop showing resuls "is" Centos.org! So, when it works, it gets to
    the last hop; but when it dies, it always dies at just before the last
    hop. But why?

    Can you help me UNDERSTAND why/how this situation can be happening?
    Note: All other web sites work just fine.

    NOTE: I already know that YOU will be able to access this same site
    with much lower ping times (you're not on a WISP either) - but that
    doesn't help ME figure out what the problem is.

    Is there freeware extant to help me UNDERSTAND why this happens to me?

    Reading all I can of this thread (maybe not all because off my newsserver >> is
    not 100% reliable) I followed the diving into the routing and the
    protocol.
    AFAIS one cause has been overlooked so far: An intermittend hardware
    error.
    To me all results so far point in that direction. Suspect is all hardware
    between your computer and WISP. Shortest way to find out is exchanging
    all
    parts of it one at a time, including cables and power supplies. The logic
    behind it looks like obvious to me. All that equipment is similar to that >> of
    your neighbours but the latter has no problem. Your computer has no
    problem
    when using it too. So your equipment itself or the place or way it has
    been
    installed may cause that peculiar problem.


    It is hard for me to see how a hardware error could cause troubles with
    ONLY centos.org. Remember that he says that he can browse almost all
    other web sites, even during the months that he cannot browse
    centos.org. It is really really hard to imagine some hardware error that would be that selective in its application, and furthermore one that
    allowed the packets to reach the penultimate link on a long chain and
    then fail on that final link.

    He has certainly been aware of your possibility, but has no idea how
    that could explain the symptoms. Perhaps you could explain how, even in
    the wildest of scenarios, this could explain his symptoms.
    And if it does, how he could figure our WHAT is wrong.



    Well, I agree. It's very hard see how it may happen. Nevertheless, the impossible never happens and hard to see is not impossible. In a situation like this I'd want to rule out the possibillity that the error is caused by
    my own equipment somehow. It's not only the pure hardware I think about. I consider the firmware a part of the hardware in this equipment. I have some experience maintaining computer equipment and I several times saw unexplainable errors disapear by exchanging parts or equipment that seem to have nothing to do with it.

    *If* the cause of the problem has been located in this part of the path, there's a question left that may be next to impossible to answer: How does
    it happen? As the OP mentioned that's the most frustrating part of the problem.

    petrus bitbyter



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From ps56k@110:110/2002 to All on Sun Oct 13 19:34:57 2013
    weird - yup -
    it times out from my network - and other "online testing sites" -
    so... ????

    Ping - centos.org - 85.12.30.227 --> Amsterdam location
    Ping - www.centos.org - 72.232.194.162 ---> ????

    So, where does the - 72.232.194.162 come from ??
    vs my DNS lookup is showing 85.12.30.227 ??

    2 NS1.LAYEREDTECH.COM 72.232.1.236
    AUTH 0 ms Received 1 Answers , rcode=
    PTR: PointerName=www.centos.org,

    cname:www.centos.org
    Lookup failed after 1 name server timed out or responded non-authoritatively

    -----------
    Here's his traceroute run:
    knoppix@Microknoppix:~$ traceroute www.centos.org
    traceroute to www.centos.org (72.232.194.162), 30 hops max, 60 byte

    ----------
    HopCount IP Address HostName
    1 208.123.79.34 net208-123-79-34.static-customer.corenap.com
    2 198.252.182.180 aus-core-10-v12.corenap.com
    3 24.155.184.106 xe-0-0-2-509.AUSTTXMIM002.aggr09.austtx.grandecom.net
    4 24.155.121.76 xe-0-0-0-0.aggr08.austtx.grandecom.net
    5 4.30.74.53 ae5-868.edge9.Dallas1.Level3.net
    6 4.69.145.200 ae-4-90.edge3.Dallas1.Level3.net
    7 4.71.170.6 LAYERED-TEC.edge3.Dallas1.Level3.net
    8 * * * * * *
    9 72.232.194.162 www.centos.org


    ---------

    their TCP/IP world seems messed up somewhere within their DNS records -



    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: me (110:110/2002@linuxnet)
  • From Mike Easter@1:0/0 to All on Sun Oct 13 21:27:13 2013
    ps56k wrote:
    weird - yup -
    it times out from my network - and other "online testing sites" -
    so... ????

    Ping - centos.org - 85.12.30.227 --> Amsterdam location

    That is the correct IP.

    Ping - www.centos.org - 72.232.194.162 ---> ????

    That is not the correct IP resolution according to google's DNS.

    That is, www.centos.org resolves to 85.12.30.227 but 85.12.30.227 does
    not rDNS to www.centos.org

    However, 72.232.194.162 rDNS to www.centos.org which does not resolve to 72.232.194.162

    their TCP/IP world seems messed up somewhere within their DNS records -

    The DNSreport on centos.org says the MX, SOA, WWW, are all OK but the
    Parent nameservice fails on one dns report but not another.

    Parent Failed Parent nameservers centos.org Your NS records at the
    parent server are:

    Failed Nameservers for domain in DNS centos.org Your NS records at your
    nameservers are:

    However, my dig worked OK showing ns1, ns3, & ns4.centos.org and their
    IPs and all 3 nameservers produced the MXes etc.

    The report at mxtoolbox said the ns at the parent was OK, but then the information said it was not. I don't understand this inconsistency in
    the parent DNS status for centos.org.



    --
    Mike Easter

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Rick Jones@110:110/2002 to All on Mon Oct 14 19:20:44 2013
    billy <billy@is.invalid> wrote:
    From *my* experience, the route is pretty much static, and, when it
    fails, it pretty much fails at the same point for hours, days, or
    months at a time.

    A terminology suggestion that might help when speaking with
    knowledgable nitpickers (I'm a nitpicker, but cannot claim extensive
    routing knowledge :) Rather than call it "static" call it "stable."
    In network-geek-speek a "static" route is one that is, for lack of a
    better term "hard wired" in the configuration router/endsystem, rather
    than one determined automagically via a routing protocol.

    rick jones
    --
    oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
    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...

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: the Unofficial HP (110:110/2002@linuxnet)
  • From Scott Hemphill@1:0/0 to All on Mon Oct 14 20:47:16 2013
    Reply-To: hemphill@alumni.caltech.edu

    billy <billy@is.invalid> writes:

    Below (sorry for the top post) is the old traceroute from yesterday on Microknoppix.

    Here is the new traceroute from a few seconds ago.
    The route is entirely different!
    Since *UNDERSTANDING* is what we're after, can you give me
    insight into *how* all of a sudden, the route is so very different
    (and why it works now)?

    Who decides what route my packets will take?

    knoppix@Microknoppix:~$ traceroute www.centos.org
    traceroute to www.centos.org (85.12.30.227), 30 hops max, 60 byte packets

    [snip first routing]

    root@Microknoppix:/# traceroute -M icmp centos.org
    traceroute to centos.org (72.232.194.162), 30 hops max, 60 byte packets

    [snip second routing]

    It's not the routing, it's the destination. Do you see the IP addresses
    in each of the above two routes? The first one works, and the second
    one doesn't.

    The question is why do you get two different IP addresses for the name "centos.org"? The answer is probably that the name resolution (DNS) is
    screwed up somewhere. You can get around this by editing /etc/hosts by inserting the following line:

    85.12.30.22 www.centos.org centos.org

    This temporary fix will only work as long as they don't change their IP
    address (again?). Why did it work for TOR? Because they use different
    name servers than you do.

    To address some of the other things mentioned in this thread: pings and traceroutes can be blocked at any point along the route. Successful
    pings and traceroutes that go all the way to the destination tell you a
    lot, but ping failures and traceroutes that don't go all the way don't
    tell you so much. They do not indicate a problem along the route, or at
    the destination.

    Also, the suggestion of too large an MTU wasn't a bad one. It can cause
    the symptoms you were seeing, but I think you've proven that it is not
    your problem. I haven't seen MTU issues in a long time, though.

    Scott
    --
    Scott Hemphill hemphill@alumni.caltech.edu
    "This isn't flying. This is falling, with style." -- Buzz Lightyear

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From ps56k@110:110/2002 to All on Thu Oct 17 19:58:39 2013

    "Mike Easter" <MikeE@ster.invalid> wrote in message news:bc0hheFn2mtU1@mid.individual.net...
    ps56k wrote:
    weird - yup -
    it times out from my network - and other "online testing sites" -
    so... ????

    Ping - centos.org - 85.12.30.227 --> Amsterdam location

    That is the correct IP.

    Ping - www.centos.org - 72.232.194.162 ---> ????

    That is not the correct IP resolution according to google's DNS.

    That is, www.centos.org resolves to 85.12.30.227 but 85.12.30.227 does not rDNS to www.centos.org

    However, 72.232.194.162 rDNS to www.centos.org which does not resolve to 72.232.194.162

    their TCP/IP world seems messed up somewhere within their DNS records -

    The DNSreport on centos.org says the MX, SOA, WWW, are all OK but the
    Parent nameservice fails on one dns report but not another.

    Parent Failed Parent nameservers centos.org Your NS records at the parent server are:

    Failed Nameservers for domain in DNS centos.org Your NS records at your nameservers are:

    However, my dig worked OK showing ns1, ns3, & ns4.centos.org and their IPs and all 3 nameservers produced the MXes etc.

    The report at mxtoolbox said the ns at the parent was OK, but then the information said it was not. I don't understand this inconsistency in the parent DNS status for centos.org.


    YEAH - this is one weird DNS situation -
    I'd like to find out what eventually turns out to be the problem with the
    DNS,
    but this discussion is all over the map with various tangents regarding the orig problem.




    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: me (110:110/2002@linuxnet)