Re: pppd/chat dialup
From: Moe Trin (ibuprofin_at_painkiller.example.tld)
Date: 07/31/04
- Next message: Vilmos Soti: "Re: How to Test Hard Drive Integrity?"
- Previous message: Vilmos Soti: "Re: How to Test Hard Drive Integrity?"
- Maybe in reply to: Bill Unruh: "Re: pppd/chat dialup"
- Next in thread: Dmitry Davletbaev: "Re: pppd/chat dialup"
- Reply: Dmitry Davletbaev: "Re: pppd/chat dialup"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 31 Jul 2004 16:32:08 -0500
In article <2h3gec.5lm.ln@pandora.maginfo.net>, Dmitry Davletbaev wrote:
>> 'noauth' should not be needed unless you have a configuration error
>> elsewhere
>
>I deleted this line.
OK
>There was no loopback in route table and I nave not Ethernet LAN. But now I
>add loopback with 'route add -net 127.0.0.0' (see later).
What distribution? Every one that I've ever worked with set up the
loopback by default.
>When no connection is established:
>
>linux:/etc/ppp # ifconfig
>lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:40 errors:0 dropped:0 overruns:0 frame:0
> TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:2608 (2.5 Kb) TX bytes:2608 (2.5 Kb)
OK, that looks normal.
>linux:/etc/ppp # route
>Kernel IP routing table
>Destination Gateway Genmask Flags Metric Ref Use Iface
There should be a route for the loopback, created by the same boot
script that would have created the loopback interface. I don't think
this is relevant to the problem however.
>Then I connect running 'pppd call mgn-guest' and get:
>
>linux:/etc/ppp # ifconfig
>lo Link encap:Local Loopback
[...]
>ppp0 Link encap:Point-to-Point Protocol
> inet addr:212.57.178.253 P-t-P:212.57.178.254
Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
> RX packets:17 errors:0 dropped:0 overruns:0 frame:0
> TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:1094 (1.0 Kb) TX bytes:866 (866.0 b)
Looks good - no errors. And there are packets going out and back! That
is a good sign.
>linux:/etc/ppp # route
>Kernel IP routing table
>Destination Gateway Genmask Flags Metric Ref Use Iface
>212.57.178.254 * 255.255.255.255 UH 0 0 0 ppp0
>default 212.57.178.254 0.0.0.0 UG 0 0 0 ppp0
Missing the lookback, but otherwise correct.
>linux:/etc/ppp # ping -c 3 212.57.178.254
>PING 212.57.178.254 (212.57.178.254) 56(84) bytes of data.
>>From 212.57.178.254: icmp_seq=1 Destination Port Unreachable
>>From 212.57.178.254 icmp_seq=1 Destination Port Unreachable
>>From 212.57.178.254 icmp_seq=2 Destination Port Unreachable
_PORT_ unreachable - that's a firewall, probably on the peer. To prove
it one way or the other, use tcpdump -n to see what the packets say.
I'm pretty sure your conenction is working.
>--- 212.57.178.254 ping statistics ---
>2 packets transmitted, 0 received, +3 errors, 100% packet loss, time
>1008ms
There is a little more confusion - you said "ping -c 3", yet ping only
reports two transmitted.
>Now I disconnect and connect using Kppp.
>
>linux:/etc/ppp # ifconfig
[...]
>ppp0 Link encap:Point-to-Point Protocol
> inet addr:192.168.4.2 P-t-P:212.57.178.254
Mask:255.255.255.255
OK - first obvious change is that the same host gave you a completely
different IP address. This is OK (my ISP assigns me numbers out of three
very different ranges), but a minor concern is that 192.168.4.2 is a
RFC1918 "Private" address, that would have to be masqueraded to work on
the internet. That isn't your job - it is done on the peer.
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
> RX packets:127 errors:2 dropped:0 overruns:0 frame:0
Two unidentifdied receiving errors. Don't know why.
> TX packets:145 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
> RX bytes:26753 (26.1 Kb) TX bytes:13439 (13.1 Kb)
And data is going in and out of the wire. That is good.
>linux:/etc/ppp # route
>Kernel IP routing table
That looks fine. This does tell you that the connection is working,
because you are able to reach the name server to translate the IP
addresses (as noted, du-254.178.dial.mgn.ru is 212.57.178.254). So
at this point, the ppp link is working normally.
>linux:/etc/ppp # ping -c 3 du-254.178.dial.mgn.ru
>PING du-254.178.dial.mgn.ru (212.57.178.254) 56(84) bytes of data.
>>From du-254.178.dial.mgn.ru (212.57.178.254): icmp_seq=1 Destination
Port Unreachable
Again, _PORT_ unreachable (not "host, or network) - that is a firewall
on the peer.
>As you can see I can not ping du-254.178.dial.mgn.ru (it's a mess for me)
>but there is another host, support.mgn.ru, that I ping successfully and was
>not able to ping when connected using pppd/chat.
support.mgn.ru must not be using a firewall to block pings, while
du-254.178.dial.mgn.ru is rejecting them. Confusing, but not your
problem.
>The only difference between to kinds of connection I can see is that for
>pppd/chat there is no host name in route table (IP number instead) and
>212.57.178.253 address for ppp0 interface while for Kppp connection ppp0
>interface has 192.168.4.2 address. And when I run route command when
>connected using pppd/chat it takes much more time (8-10 seconds).
That is because you can not talk to the nameserver for some reason. If
you use 'route -n' (and ping -n), the answers will come back immediately
because the -n says to not look up the address. Hmmm, in both cases,
_when_ you are connected, does /etc/resolv.conf have the name server data?
Compare the files.
>Hope this information will be usefull for you to help me.
What might help is (assuming pppd version 2.4.1 or 2.4.2) to add a line
to /etc/ppp/options that has the word
dryrun
This should cause ppp to print a list of all options in use.
What my thoughts are is that your 'pppd/chat' connection is actually
working, but you are missing /etc/resolv.conf. This means that you are
not able to find the IP address of support.mgn.ru, and ping that.
[compton ~]$ host support.mgn.ru
support.mgn.ru has address 62.102.136.26
[compton ~]$
)
Can you ping that IP address?
Hope this helps,
Old guy
- Next message: Vilmos Soti: "Re: How to Test Hard Drive Integrity?"
- Previous message: Vilmos Soti: "Re: How to Test Hard Drive Integrity?"
- Maybe in reply to: Bill Unruh: "Re: pppd/chat dialup"
- Next in thread: Dmitry Davletbaev: "Re: pppd/chat dialup"
- Reply: Dmitry Davletbaev: "Re: pppd/chat dialup"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
