Networking mostly okay, but cannot access a few sites
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Networking mostly okay, but cannot access a few sites
Using fedora core 2, adsl and pppoe, everything works fine
except that today I noticed I cannot access one site from the
machine, although the windows machine and a redhat 7.3
machine on the same local home network can all access the
site just fine. I assume there are other sites I cannot access
either but I don't know of any offhand.
Is there any idea what this could be? I don't know much
about networking and it is driving me crazy. I tried varying
the MTU on both the router and the machine, temporarily
disabled all firewalls, made sure I was not using ipv6 which
I know has some problems on Fedora, and cold rebooted the
machine, router, and modem.
I cannot even ping the site, with any packet size. Traceroute
will not find a route to it (but this is also true on the RH7.3
machine that can access it). Here is the output of the traceroute
for what it is worth:
traceroute to www3.cohums.ohio-state.edu (140.254.248.27), 30 hops max, 38 byte packets
1 192.168.0.1 (192.168.0.1) 0.608 ms 0.750 ms 0.736 ms
2 64.230.254.8 (64.230.254.8) 9.208 ms 8.635 ms 8.819 ms
3 HSE-Sherbrooke-ppp98632.qc.sympatico.ca (64.230.222.25) 7.536 ms 7.143 ms 7.337 ms
4 HSE-Sherbrooke-ppp98628.qc.sympatico.ca (64.230.222.21) 7.431 ms 7.165 ms 7.320 ms
5 core2-chicago23-pos10-0.in.bellnexxia.net (206.108.103.118) 81.358 ms 194.491 ms 225.567 ms
6 core1-chicago23-srp6-0.in.bellnexxia.net (206.108.103.145) 22.904 ms 17.300 ms 17.386 ms
7 HSE-Sherbrooke-ppp98903.qc.sympatico.ca (64.230.223.42) 17.521 ms 18.005 ms 17.686 ms
8 206.108.108.166 (206.108.108.166) 17.874 ms 17.958 ms 17.777 ms
9 cer-core-01.inet.qwest.net (205.171.139.145) 17.476 ms 17.922 ms 18.169 ms
10 chi-core-02.inet.qwest.net (205.171.205.33) 17.692 ms 18.037 ms 17.893 ms
11 chi-edge-20.inet.qwest.net (205.171.20.182) 18.495 ms 18.210 ms 17.970 ms
12 208.44.132.22 (208.44.132.22) 24.635 ms 24.291 ms 24.215 ms
13 cncnc-r0-ge7-0s381.core.oar.net (199.18.164.49) 23.626 ms 24.111 ms 24.105 ms
14 clmbn-r0-po0-0.core.oar.net (199.18.145.34) 27.385 ms 26.641 ms 27.507 ms
15 clmbo-r0-ge-1-0-0s303.bb.oar.net (199.18.152.49) 32.973 ms 32.049 ms 33.674 ms
16 clmbk-r6-ge-0-1-0s91.bb.oar.net (199.18.22.74) 27.303 ms 27.417 ms 27.822 ms
17 kc2-gig1-3-0.ohio-dmz.net (199.18.22.26) 28.424 ms 28.626 ms 28.406 ms
18 164.107.2.142 (164.107.2.142) 28.656 ms 27.922 ms 28.289 ms
19 164.107.2.154 (164.107.2.154) 28.568 ms 27.669 ms 28.066 ms
20 * * *
21 * * *
It's possible that as a security measure, Ohio State may have the ability to respond to pings and tracert requests turned off or blocked on their network. It's a very common practice. That's why you can't ping it or get a response with tracert. I tried to ping it from here and got no response etither. That doesn't indicate any problem on your network.
Did you try to access the web site with different browsers on the FC2 machine? Maybe from Nautilus, Konqueror, Mozilla or what ever other browser is available on the machine.
You didn't misspell the URL the first time you typed it in, then just select it from the history list every time and therefore always trying to access a misspelled URL? As silly as that may sound, I've done it before.
Originally posted by cowanrl
It's possible that as a security measure, Ohio State may have the ability to respond to pings and tracert requests turned off or blocked on their network. It's a very common practice. That's why you can't ping it or get a response with tracert. I tried to ping it from here and got no response etither. That doesn't indicate any problem on your network.
Right. I subsequently found that the other machines got stuck in the same place with a traceroute. I was misled by the fact that the pings and traceroutes failed only on some Ohio State sites, which matched the ones that I could not access in any other way either.
Quote:
Did you try to access the web site with different browsers on the FC2 machine? Maybe from Nautilus, Konqueror, Mozilla or what ever other browser is available on the machine.
I certainly did, multiple browsers.
Quote:
You didn't misspell the URL the first time you typed it in, then just select it from the history list every time and therefore always trying to access a misspelled URL? As silly as that may sound, I've done it before.
No way! I have been working on this for hours. I have tried zillions of combinations in a zillion different ways. There are also some other urls at Ohio State that I have had the same trouble with. And searching around the internet, I have found another site that someone else on FC2 had the same problem with, and I had it too (again, the other local machines did not).
From what I have read, it may be some kind of problem with MTU after all, although I was pretty sure I was resetting it. Some pages are suggesting that this won't work, and that "MSS Clamping" may be required. My first attempt at trying that with iptables did not have any effect.
It is very frustrating looking around for magic incantations without knowing what is going on. Maybe I am going to have to get a book and study TCP/IP from the ground up.
Thanks for your reply, I hope I get some others...
If you really want to see what's going on, get a packet sniffer such as Ethereal. This will let you look at the packets on the network and see what's happening. Ethereal is available at www.ethereal.com and there are versions for both Windows and Linux.
Of cours, using a packet sniffer requires a pretty good knowledge of TCP/IP so you'll probably want to get that book too. Knowing how to use a packet sniffer can save you hours of frustration when troubleshooting network problems. It's my first tool of choice when I'm faced with problems such as yours.
Originally posted by cowanrl
[B]If you really want to see what's going on, get a packet sniffer such as Ethereal. This will let you look at the packets on the network and see what's happening. Ethereal is available at www.ethereal.com and there are versions for both Windows and Linux.
I was hoping it wouldn't come to that. Okay, I have ethereal on FC but I had to build it from source for RH7.3. It took over an hour to build and had some major hassles.
In any case, the result is that the packet sequences for the RH machine where the problematic site works, and for the FC machine where it doesn't, were absolutely identical up until the packet which did not arrive. And that packet (the first http OKAY packet containing the HTML source) looked totally normal on the machine that worked, just like many other http OKAY packets that were received on the machine that could not access the problematic site.
The packet that failed was large (total size 1440 -- right at the MSS size specified in headers from that site) but packets of the same sime arrived successfully from other sites with the same MSS specified.
I guess I am going to have to give up. I don't see how spending weeks learning TCP/IP in detail is going to guarantee a solution to this. It seems impossible. There is something about the failing packet that causes it not to get through. But that something must be independent of what came previously since it is identical in the case that worked and the case that did not. So how can this be? If the FC system sent something different, then one can see what in principle would cause the failure, but I can't see anything different. I must be missing it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.