Only some IPs accessable?

Networking is quiet complex?

After I got my 10 years old pppd-script modified sufficiently
to connect the fixed-wireless-modem, as confirmed by
/var/log/messages reporting:
CHAP authenticated,
<a local IP> allocated,
2 DNSs allocated;
I still wasn't able to: lynx <URL>,
except by:
chroot <an Old Installation> lynx <URL>.

Ie. I used Slackware13 to ppp,
and then switched to the old/proven installation
to fetch http via lynx.
--------
These are my test results under Slackware13:-

First I suspected the DNSs allocated by the ISP:
>Oct 5 18:20:44 labeas pppd[4599]: secondary DNS address 41.164.0.11
but both pinged OK:
> nameserver 41.164.0.11
> 7 packets transmitted, 7 received, 0% packet loss, time 6002ms
---------
Then I used the DNS on a URL:
-> nslookup krugman.blogs.nytimes.com 41.164.0.11 ==
> Server:41.164.0.11
> Address:41.164.0.11#53
>
> Non-authoritative answer:
> krugman.blogs.nytimes.comcanonical name = blog.nytimes.com.
> Name:blog.nytimes.com
> Address: 199.239.137.32
------------
So, then I used *that* IP
-> lynx 199.239.137.32 ==

> Looking up 199.239.137.32 first
> Looking up 199.239.137.32
> Making HTTP connection to 199.239.137.32
> Sending HTTP request.
> HTTP request sent; waiting for response.
> Alert!: Unexpected network read error; connection aborted.
> Can't Access `http://199.239.137.32/'
> Alert!: Unable to access document.
>
> lynx: Can't access startfile
------

Although the <old proven system> which fetches http,
if I `chroot` to it, has different DNSs in /etc/*;
which I think I set manually, years ago,
and that is setup for a different ISP,
than this new wireless one,
it seems that DNS is *NOT* the problem.

Let's try, via
`chroot <oldSystem> lynx 199.239.137.32`
== Alert!: Unexpected network read error; connection aborted.

See if, in same session, can do:
`chroot <oldSystem> lynx http://krugman.blogs.nytimes.com`
== OK.
------
-> chroot /mnt/p6 lynx http://199.239.137.32

Looking up 199.239.137.32
199.239.137.32
Making HTTP connection to 199.239.137.32
Sending HTTP request.
HTTP request sent; waiting for response.
Alert!: Unexpected network read error; connection aborted.
Can't Access `http://199.239.137.32/'
Alert!: Unable to access document.

lynx: Can't access startfile
--------
This one is very confusing:-
-> lynx 184.106.20.99 ==
Posterous - 404 - The page you requested could not be found (p1 of 2)
[posterous-small.png]
*
* Login
* Get your own Space >

Sorry, we couldnt find what you were asking for.
---------------
So 184.106.20.99 arrived at the correct location,
but not other `lynx <IPs>`

Can someone please advise.

BTW, I've never confirmed this Slackware13 installation
as being setup for inet, since I was not able to previously
connect linux to the wireless-modem, and used FC1 at another
location on a dial-up.

== Chris Glur.

NoHtmlMailsPlease <(E-Mail Removed)> wrote:
> Networking is quiet complex?
>
> > Alert!: Unexpected network read error; connection aborted.
> == Alert!: Unexpected network read error; connection aborted.
> Alert!: Unexpected network read error; connection aborted.

> Can someone please advise.
>
> BTW, I've never confirmed this Slackware13 installation
> as being setup for inet, since I was not able to previously
> connect linux to the wireless-modem, and used FC1 at another
> location on a dial-up.

you don't have software related problems, this is hardware related,
check your cables first

check if you have got an IP with: ifconfig

check your routing: route
there is a default route?
Destination 0.0.0.0

reachable nameserver in /etc/resolv.conf?
(seems to be ok for both of your slackware installations)

root@sif: /etc # ping -c10 www.google.com
PING www.l.google.com (74.125.39.105) 56(84) bytes of data.
64 bytes from fx-in-f105.1e100.net (74.125.39.105): icmp_seq=1 ttl=55 time=47.0 ms
64 bytes from fx-in-f105.1e100.net (74.125.39.105): icmp_seq=2 ttl=55 time=46.2 ms
64 bytes from fx-in-f105.1e100.net (74.125.39.105): icmp_seq=3 ttl=55 time=47.1 ms
64 bytes from fx-in-f105.1e100.net (74.125.39.105): icmp_seq=4 ttl=55 time=46.6 ms
64 bytes from fx-in-f105.1e100.net (74.125.39.105): icmp_seq=5 ttl=55 time=47.0 ms
64 bytes from fx-in-f105.1e100.net (74.125.39.105): icmp_seq=6 ttl=55 time=46.7 ms
64 bytes from fx-in-f105.1e100.net (74.125.39.105): icmp_seq=7 ttl=55 time=46.8 ms
64 bytes from fx-in-f105.1e100.net (74.125.39.105): icmp_seq=8 ttl=55 time=47.0 ms
64 bytes from fx-in-f105.1e100.net (74.125.39.105): icmp_seq=9 ttl=55 time=48.1 ms
64 bytes from fx-in-f105.1e100.net (74.125.39.105): icmp_seq=10 ttl=55 time=46.8 ms

--- www.l.google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 46.213/46.965/48.147/0.520 ms

e.g. 100 transmitted pings, how much are lost?


root@sif: /etc # traceroute www.google.com
traceroute: Warning: www.google.com has multiple addresses; using
74.125.39.103
traceroute to www.l.google.com (74.125.39.103), 30 hops max, 38 byte
packets
1 speedport.baldar.de (192.168.0.234) 0.765 ms 0.371 ms 0.494 ms
2 217.0.116.148 (217.0.116.148) 105.937 ms 40.831 ms 40.442 ms
3 217.0.74.58 (217.0.74.58) 43.468 ms 42.234 ms 43.199 ms
4 217.239.39.22 (217.239.39.22) 44.231 ms 43.581 ms 88.910 ms
5 80.150.170.42 (80.150.170.42) 44.945 ms 80.150.170.38 (80.150.170.38) 44.387 ms 80.150.170.34 (80.150.170.34) 45.216 ms
6 72.14.238.46 (72.14.238.46) 44.178 ms 72.14.238.44 (72.14.238.44)
43.602 ms 72.14.238.46 (72.14.238.46) 50.175 ms
7 72.14.236.68 (72.14.236.68) 45.675 ms 45.871 ms 44.654 ms
8 209.85.254.118 (209.85.254.118) 44.705 ms 44.669 ms 45.440 ms
9 * 209.85.249.162 (209.85.249.162) 51.393 ms *
10 fx-in-f103.1e100.net (74.125.39.103) 45.965 ms 44.872 ms 45.979 ms

I expect you to find lost packages or unusual delays,
sometimes hardware is realy broken

network in your lan is ok? you can ping an access point,
or another computer without problems?


cu Frank

--
"now for the happy time between the moment the lie is told
and the moment it is found out" -- Homer Simpson

NoHtmlMailsPlease <(E-Mail Removed)> wrote:
> After I got my 10 years old pppd-script modified sufficiently
> to connect the fixed-wireless-modem, as confirmed by
> /var/log/messages reporting:
> CHAP authenticated,
> <a local IP> allocated,
> 2 DNSs allocated;
> I still wasn't able to: lynx <URL>,

> First I suspected the DNSs allocated by the ISP:
>Oct 5 18:20:44 labeas pppd[4599]: secondary DNS address 41.164.0.11
> but both pinged OK:

Ping shows connectivity, so that's good (but bear in mind that lack of
ping does not prove lack of connectivity).

> Then I used the DNS on a URL:
> -> nslookup krugman.blogs.nytimes.com 41.164.0.11 ==

Being slightly picky: krugman.blogs.nytimes.com isn't a URL, it's a
domain. (The URL form would be http://krugman.blogs.nytimes.com/)


> -> lynx 199.239.137.32 ==

You can't guarantee that replacing a domain with an IP address like that
will work these days, due to virtual hosting configurations (multiple
websites sharing the same IP address). In fact, when I try that exact
command here it also fails.

If you really want to bypass DNS lookups (although you've proven they're
working) you're going to need to pop the IP address in your hosts file.


> -> lynx 184.106.20.99 ==

Where did you get this 184... address from?


> So 184.106.20.99 arrived at the correct location,
> but not other `lynx <IPs>`

This is due to the use of virtual hosting. Basically, you can't do that
that and expect it to work. You *must* be prepared to use domain names
in the domain name component of your URL, e.g. http://www.roaima.co.uk/
instead of http://188.222.203.136/


Personally, I think I'd go back to basics and ignore lynx initially -
it's confusing you and therefore muddying the water.

1. Can you ping your assigned DNS servers? (Yes)
2. Can you resolve hosts from at least one of the assigned DNS servers? (Yes)

3. Has your /etc/resolv.conf been updated with these DNS servers?

I suspect the answer to #3 is "no", in which case you just need to update
your ppp configuration to tell it to do so. However, in case it's yes
I've provided the following additional suggestions -

4. Can you ping 188.222.203.136?

5. Can you ping test.www.roaima.co.uk?

6. If you "lynx http://test.www.roaima.co.uk/", do you get my test page?

If yes then I'd say that the networking layer is fine. Otherwise,
exclude DNS and try again -

7. Add this line to your /etc/hosts file:

188.222.203.136 test.www.roaima.co.uk

Then, when you "lynx http://test.www.roaima.co.uk/" do you get my test
page this time?

If the answer to this is no, then it's time to start digging really
seriously into files such as /etc/nsswitch.conf (what does the "files"
line read as?) and possibly checking your networking libraries.

Chris

>>>>> Chris Davies <chris-(E-Mail Removed)> writes:
>>>>> NoHtmlMailsPlease <(E-Mail Removed)> wrote:

[…]

>> So 184.106.20.99 arrived at the correct location, but not other
>> `lynx <IPs>`

> This is due to the use of virtual hosting. Basically, you can't do
> that that and expect it to work. You *must* be prepared to use domain
> names in the domain name component of your URL,
> e.g. http://www.roaima.co.uk/ instead of http://188.222.203.136/

When using GNU Wget, there's the --header= option:

--cut: (wget) HTTP Options --
`--header=HEADER-LINE'
Send HEADER-LINE along with the rest of the headers in each HTTP
request. The supplied header is sent as-is, which means it must
contain name and value separated by colon, and must not contain
newlines.

[…]

As of Wget 1.10, this option can be used to override headers
otherwise generated automatically. This example instructs Wget to
connect to localhost, but to specify `foo.bar' in the `Host'
header:

wget --header="Host: foo.bar" http://localhost/
--cut: (wget) HTTP Options --

It's my opinion that it'd be an improvement for Lynx to support
a similar feature.

[…]

> If yes then I'd say that the networking layer is fine. Otherwise,
> exclude DNS and try again -

> 7. Add this line to your /etc/hosts file:

> 188.222.203.136 test.www.roaima.co.uk

> Then, when you "lynx http://test.www.roaima.co.uk/" do you get my
> test page this time?

> If the answer to this is no, then it's time to start digging really
> seriously into files such as /etc/nsswitch.conf (what does the
> "files" line read as?)

I believe that it should read “the ‘hosts’ line� instead. Like:

$ grep -E -- ^hosts /etc/nsswitch.conf
hosts: files dns
$

> and possibly checking your networking libraries.

--
FSF associate member #7257

Ivan Shmakov <(E-Mail Removed)> wrote:
> When using GNU Wget, there's the --header= option:

Yes. I'd tried that myself while composing my suggestions and couldn't
get it to work on the nytimes.com site. I'm pretty sure this /should/
have worked, but didn't:

wget -S -O- --no-proxy --header='Host: krugman.blogs.nytimes.com' http://199.239.137.32


> > If the answer to this is no, then it's time to start digging really
> > seriously into files such as /etc/nsswitch.conf (what does the
> > "files" line read as?)

> I believe that it should read “the ‘hosts’ line� instead. Like:

> $ grep -E -- ^hosts /etc/nsswitch.conf
> hosts: files dns

Yes, you're correct. Thank you for picking up that silly mistake of
mine. Hopefully the OP will see this in time.

Chris

"Chris Davies" <chris-(E-Mail Removed)> wrote in message
news(E-Mail Removed)...
> NoHtmlMailsPlease <(E-Mail Removed)> wrote:
>> After I got my 10 years old pppd-script modified sufficiently
>> to connect the fixed-wireless-modem, as confirmed by
>> /var/log/messages reporting:
>> CHAP authenticated,
>> <a local IP> allocated,
>> 2 DNSs allocated;
>> I still wasn't able to: lynx <URL>,
>
>> First I suspected the DNSs allocated by the ISP:
>>Oct 5 18:20:44 labeas pppd[4599]: secondary DNS address 41.164.0.11
>> but both pinged OK:
>
[snip]

> Personally, I think I'd go back to basics and ignore lynx initially -
> it's confusing you and therefore muddying the water.
>
> 1. Can you ping your assigned DNS servers? (Yes)
> 2. Can you resolve hosts from at least one of the assigned DNS servers?
> (Yes)
>
> 3. Has your /etc/resolv.conf been updated with these DNS servers?
>
> I suspect the answer to #3 is "no", in which case you just need to update
> your ppp configuration to tell it to do so. However, in case it's yes
> I've provided the following additional suggestions -
>
> 4. Can you ping 188.222.203.136?
>
> 5. Can you ping test.www.roaima.co.uk?
>
> 6. If you "lynx http://test.www.roaima.co.uk/", do you get my test page?
>
> If yes then I'd say that the networking layer is fine. Otherwise,
> exclude DNS and try again -
>
> 7. Add this line to your /etc/hosts file:
>
> 188.222.203.136 test.www.roaima.co.uk
>
> Then, when you "lynx http://test.www.roaima.co.uk/" do you get my test
> page this time?
>
> If the answer to this is no, then it's time to start digging really
> seriously into files such as /etc/nsswitch.conf (what does the "files"
> line read as?) and possibly checking your networking libraries.
==================== 2nd test log ===============
-> wget -V == GNU Wget 1.11.4

3,1-> ping -c9 188.222.203.136 ==
--- 188.222.203.136 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8012ms
rtt min/avg/max/mdev = 502.310/515.514/531.036/9.126 ms

3,2-> ping -c9 test.www.roaima.co.uk ==
ping: unknown host test.www.roaima.co.uk

4,1-> traceroute www.google.com ==
traceroute: unknown host www.google.com

4,2-> lynx http://test.www.roaima.co.uk/ == ...
Unable to locate remote host test.www.roaima.co.uk.

----------> add: "188.222.203.136 test.www.roaima.co.uk" to /etc/hosts
3,1-> lynx http://test.www.roaima.co.uk/ ==
Test page - test.www.roaima.co.uk

This is a test page to prove vHost connectivity to test.www.roaima.co.uk.
If you had
used an IP address instead of the name you would not have arrived here.

===> DN Service is failing ??
-> cat /etc/ppp/resolv.conf ==
nameserver 41.160.0.36
nameserver 41.164.0.11
====> these are dynamically provided by this new/ISP2

3,1-> ping -c9 41.160.0.36 == 0% packet loss,
3,2-> ping -c9 41.164.0.11 == 0% packet loss,

==> see DNS:IP for old/proven/working installation
-> cat /mnt/p6/etc/ppp/resolv.conf ==
nameserver 168.210.2.2
nameserver 196.14.239.2

4,1-> ping -c9 196.14.239.2 == 0% packet loss,

==> Does new/unproven/IPS2's DNS KNOW: krugman.blogs.nytimes.com/
4,2 -> nslookup krugman.blogs.nytimes.com/ 41.164.0.11 ==
Server: 41.164.0.11
Address: 41.164.0.11#53
** server can't find krugman.blogs.nytimes.com/: NXDOMAIN

==> Does old/proven/IPS1's DNS KNOW: krugman.blogs.nytimes.com/
4,3 -> nslookup krugman.blogs.nytimes.com/ 196.14.239.2 ==
Server: 196.14.239.2
Address: 196.14.239.2#53
** server can't find krugman.blogs.nytimes.com/: NXDOMAIN

==> BTW the way I *DO* get <krugman> on this new/suspected-unconfigured
Slak13 is:
-> chroot /mnt/p6 lynx krugman.blogs.nytimes.com
==> where /mnt/p6 is the old/proven <Mandrake Installation>.

== TIA

NoHtmlMailsPlease wrote:
>
[loads of DNS related BS goes here]

What's that to do with Slackware ?

-rasp




--
I'm in the news chair and I don't know anything.
-Michael Caine @ Chris Moyles 29.9.2010

"NoHtmlMailsPlease" <(E-Mail Removed)> wrote:
> ==> see DNS:IP for old/proven/working installation
> -> cat /mnt/p6/etc/ppp/resolv.conf ==
> nameserver 168.210.2.2
> nameserver 196.14.239.2

You have two DNS servers there which used to work fine.

> ==> Does old/proven/IPS1's DNS KNOW: krugman.blogs.nytimes.com/
> 4,3 -> nslookup krugman.blogs.nytimes.com/ 196.14.239.2 ==
> Server: 196.14.239.2
> Address: 196.14.239.2#53
> ** server can't find krugman.blogs.nytimes.com/: NXDOMAIN

Ok, so 196.14.239.2 seems to be broken, but what about 168.210.2.2?

> ==> BTW the way I *DO* get <krugman> on this new/suspected-unconfigured
> Slak13 is:
> -> chroot /mnt/p6 lynx krugman.blogs.nytimes.com

So at least one of the DNS servers in your old resolv.conf seems to be
working.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc123(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

Ralph Spitzner <(E-Mail Removed)> wrote:
> What's that to do with Slackware ?

Since the OP's running slackware, maybe they thought that the problem
they're having *might* be a distro-related issue? Just a thought.

Chris

>> 3. Has your /etc/resolv.conf been updated with these DNS servers?

NoHtmlMailsPlease <(E-Mail Removed)> wrote:
> -> cat /etc/ppp/resolv.conf ==
> nameserver 41.160.0.36
> nameserver 41.164.0.11
> ====> these are dynamically provided by this new/ISP2

But what about /etc/resolv.conf (not /etc/ppp/resolv.conf)? It's *this*
file that gets used by the system for name resolution.

The /etc/ppp/resolv.conf file contains the values derived via ppp, which
may or may not be relevant. So it's optional whether they get installed
into the true resolv.conf. In my distro (Debian, not Slackware TBH),
the ppp "up" script installs /etc/ppp/resolv.conf into /etc/resolv.conf.

It may be that this scripting is broken or doesn't exist, or perhaps
you could get away with a simple "ln -fs /etc/ppp/resolv.conf
/etc/resolv.conf".

Chris