Re: kppp works wvdial doesn't for pppd (logs included)
From: Cat (my.email.address.is_at_on.my.website_ratrobot.com)
Date: 07/19/04
- Next message: Cat: "Re: kppp works wvdial doesn't for pppd (logs included)"
- Previous message: Touched: "See Maggie sucking on Bart Simpson"
- In reply to: Clifford Kite: "Re: kppp works wvdial doesn't for pppd (logs included)"
- Next in thread: Clifford Kite: "Re: kppp works wvdial doesn't for pppd (logs included)"
- Reply: Clifford Kite: "Re: kppp works wvdial doesn't for pppd (logs included)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 19 Jul 2004 11:03:28 -0400
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 18 Jul 2004 10:20:26 -0500, Clifford Kite wrote:
I've included .ppprc and /etc/ppp/options at the end if this (long) post.
>> is the same for both (diff) and /sbin/route hangs and I get no
>> response to ping -n 216.109.127.30 with the wvdial so not just a
>> name server problem.
>
> Does the "no response" mean that ping also hangs, or that is there an
> informational message instead of an Echo-Reply? What message, if any?
>
> If it hangs then for how long? A short time, a few minutes, or forever?
The following command hangs for about 2 minutes before I kill it. with only
the output shown (wrapped)
#ping -n 216.109.127.30
PING 216.109.127.30 (216.109.127.30) from 139.130.171.87 : 56(84) bytes of
data.
The ping command above
# tcpdump -i ppp0
tcpdump: listening on ppp0
10:08:53.931572 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:08:54.930070 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:08:55.930059 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:08:56.930057 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:08:57.930058 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:08:58.930057 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:08:59.930058 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:09:00.930058 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:09:01.930057 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:09:02.930059 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:09:03.930057 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:09:04.930059 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:09:05.930057 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:09:06.930057 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:09:07.930057 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:09:08.930057 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:09:09.930057 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:09:10.930057 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
The packets are being directed to the right interface right? When I repeat with
pppd correctly set up with kppp I get the following.
$ ping -n 216.109.127.30
PING 216.109.127.30 (216.109.127.30) from 139.130.171.87 : 56(84) bytes of
data.
64 bytes from 216.109.127.30: icmp_seq=0 ttl=51 time=440.559 msec
64 bytes from 216.109.127.30: icmp_seq=1 ttl=52 time=429.978 msec
64 bytes from 216.109.127.30: icmp_seq=2 ttl=51 time=429.979 msec
64 bytes from 216.109.127.30: icmp_seq=3 ttl=52 time=429.979 msec
64 bytes from 216.109.127.30: icmp_seq=4 ttl=51 time=439.980 msec
[root@atlas ~]# tcpdump -i ppp0
tcpdump: listening on ppp0
10:23:02.849530 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:23:03.290021 216.109.127.30 > 139.130.171.87: icmp: echo reply (DF)
10:23:03.850096 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:23:04.280019 216.109.127.30 > 139.130.171.87: icmp: echo reply (DF)
10:23:04.850095 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:23:05.280019 216.109.127.30 > 139.130.171.87: icmp: echo reply (DF)
10:23:05.850088 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:23:06.280018 216.109.127.30 > 139.130.171.87: icmp: echo reply (DF)
10:23:06.850088 139.130.171.87 > 216.109.127.30: icmp: echo request (DF)
10:23:07.290018 216.109.127.30 > 139.130.171.87: icmp: echo reply (DF)
> This sounds like a routing problem despite the assertion that the output
> of route -n is the same for both connections. Can you ping the remote
> host IP address, 139.130.171.1?
No I get the same response as above.
/sbin/route with no pppd
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 * 255.255.0.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
/sbin/route -n with wvdial
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
139.130.171.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 139.130.171.1 0.0.0.0 UG 0 0 0 ppp0
/sbin/route hangs for a minute then gives the following output wvdial
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
139.130.171.1 * 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 * 255.255.0.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 139.130.171.1 0.0.0.0 UG 0 0 0 ppp0
/sbin/route for kppp for completeness is as follows.
[root@atlas ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
gw.chw14.Sydney * 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 * 255.255.0.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default gw.chw14.Sydney 0.0.0.0 UG 0 0 0 ppp0
[root@atlas ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
139.130.171.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 139.130.171.1 0.0.0.0 UG 0 0 0 ppp0
>
>> Is it the fact that wvdial is using chap instead of pap for kppp?
>
> I don't know any reason why it should matter whether PAP or CHAP was
> used for authentication. But you could check by adding "refuse-chap"
> to /etc/ppp/options.
>
>> #diff /etc/ppp/chap-secrets /etc/ppp/pap-secrets
>> 1c1
>> < # Secrets for authentication using CHAP
>> - ---
>>> # Secrets for authentication using PAP
>
>> Also the nameservers appear to be set for kppp and not for wvdial.
I probably changed my .ppprc file inbetween attempts the following is the
current output with nameservers set.
Jul 19 10:00:02 atlas pppd[11853]: pppd 2.4.1 started by root, uid 0
Jul 19 10:00:02 atlas pppd[11853]: using channel 11
Jul 19 10:00:02 atlas pppd[11853]: Using interface ppp0
Jul 19 10:00:02 atlas pppd[11853]: Connect: ppp0 <--> /dev/ttyS1
Jul 19 10:00:02 atlas pppd[11853]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
<magic 0x9e4898f9> <pcomp> <accomp>]
Jul 19 10:00:02 atlas pppd[11853]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0>
<magic 0x9e4898f9> <pcomp> <accomp>]
Jul 19 10:00:04 atlas pppd[11853]: rcvd [LCP ConfReq id=0x7f <asyncmap 0xa0000>
<auth chap MD5> <magic 0xa1f36be1> <pcomp> <accomp>]
Jul 19 10:00:04 atlas pppd[11853]: sent [LCP ConfAck id=0x7f <asyncmap 0xa0000>
<auth chap MD5> <magic 0xa1f36be1> <pcomp> <accomp>]
Jul 19 10:00:04 atlas pppd[11853]: rcvd [CHAP Challenge id=0xa1
<19f8cf1cbf9725d64f440c3e8b6ea5a2>, name = "chw14.Sydney"]
Jul 19 10:00:04 atlas pppd[11853]: sent [CHAP Response id=0xa1
<a08338f4e014aef8ffc2b0409e35e53a>, name = "RATROBOT"]
Jul 19 10:00:04 atlas pppd[11853]: rcvd [CHAP Success id=0xa1 ""]
Jul 19 10:00:04 atlas pppd[11853]: sent [IPCP ConfReq id=0x1
<addr 139.130.171.8
7> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jul 19 10:00:04 atlas modprobe: modprobe: Can't locate module ppp-compress-21
Jul 19 10:00:04 atlas modprobe: modprobe: Can't locate module ppp-compress-21
Jul 19 10:00:04 atlas pppd[11853]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15>]
Jul 19 10:00:04 atlas pppd[11853]: rcvd [IPCP ConfReq id=0xd5
<compress VJ 0f 00> <addr 139.130.171.1>]
Jul 19 10:00:04 atlas pppd[11853]: sent [IPCP ConfAck id=0xd5
<compress VJ 0f 00> <addr 139.130.171.1>]
Jul 19 10:00:05 atlas pppd[11853]: rcvd [IPCP ConfNak id=0x1
<ms-dns1 203.50.2.71> <ms-dns3 139.130.4.4>]
Jul 19 10:00:05 atlas pppd[11853]: sent [IPCP ConfReq id=0x2
<addr 139.130.171.87> <compress VJ 0f 01> <ms-dns1 203.50.2.71>
<ms-dns3 139.130.4.4>]
Jul 19 10:00:05 atlas pppd[11853]: rcvd [LCP ProtRej id=0x80 80 fd 01 01 00 0c
1a 04 78 00 18 04 78 00]
Jul 19 10:00:05 atlas pppd[11853]: rcvd [IPCP ConfAck id=0x2
<addr 139.130.171.87> <compress VJ 0f 01> <ms-dns1 203.50.2.71>
<ms-dns3 139.130.4.4>]
Jul 19 10:00:05 atlas pppd[11853]: local IP address 139.130.171.87
Jul 19 10:00:05 atlas pppd[11853]: remote IP address 139.130.171.1
Jul 19 10:00:05 atlas pppd[11853]: primary DNS address 203.50.2.71
Jul 19 10:00:05 atlas pppd[11853]: secondary DNS address 139.130.4.4
Jul 19 10:00:05 atlas pppd[11853]: Script /etc/ppp/ip-up started (pid 11862)
Jul 19 10:00:05 atlas pppd[11853]: Script /etc/ppp/ip-up finished (pid 11862),
status = 0x0
> I'd suggest temporary adding the pppd option "dryrun" to /etc/ppp/options
> and posting the output so we can see exactly what pppd options are used.
Jul 19 09:38:20 atlas pppd[11566]: pppd options in effect:
Jul 19 09:38:20 atlas pppd[11566]: debug^I^I# (from /root/.ppprc)
Jul 19 09:38:20 atlas pppd[11566]: -detach^I^I# (from command line)
Jul 19 09:38:20 atlas pppd[11566]: dryrun^I^I# (from /etc/ppp/options)
Jul 19 09:38:20 atlas pppd[11566]: noauth^I^I# (from /etc/ppp/peers/wvdial)
Jul 19 09:38:20 atlas pppd[11566]: name atlas.mrsean.lnk.telstra.net^I^I#
(from /etc/ppp/peers/wvdial) ^
|
This seems odd -+ this is my subdomain the
rest of the world sees me as
mrsean.lnk.telstra.net. I use NAT for email etc.
Is my hostname set incorrectly?
Jul 19 09:38:20 atlas pppd[11566]: user RATROBOT^I^I# (from command line)
Jul 19 09:38:20 atlas pppd[11566]: usehostname^I^I# (from command line)
Jul 19 09:38:20 atlas pppd[11566]: remotename *^I^I# (from command line)
Jul 19 09:38:20 atlas pppd[11566]: lock^I^I# (from /etc/ppp/options)
Jul 19 09:38:20 atlas pppd[11566]: crtscts^I^I# (from command line)
Jul 19 09:38:20 atlas pppd[11566]: modem^I^I# (from command line)
Jul 19 09:38:20 atlas pppd[11566]: defaultroute^I^I# (from command line)
Jul 19 09:38:20 atlas pppd[11566]: usepeerdns^I^I# (from /root/.ppprc)
Jul 19 09:38:20 atlas pppd[11566]: 139.130.171.87:139.130.171.1^I^I#
(from command line)
Jul 19 09:38:20 atlas pppd[11566]: Exit.
I set 'name mrsean.lnk.telstra.net' in /etc/ppp/options with no effect.
If my hostname is incorrectly set would the remote host drop the packets
on the floor?
I ran /etc/rc.d/init.d/iptables stop before doing the above just incase.
/etc/ppp/options =======================================================
lock
========================================================================
I guess I don't really need usepeerdns as I know the IP addresses but it
makes no differece for kppp or wvdial. Also not setting the IP addresses
explicitly in .ppprc makes no difference for wvdial.
/root/.ppprc ===========================================================
139.130.171.87:139.130.171.1
usepeerdns
defaultroute
debug
========================================================================
I agree that it looks for all the world like a routing problem, I just can't
work out how.
- --
Cat
http://www.ratrobot.com Articles that challenge your ideas about yourself and
the world you live in.
Mon Jul 19 14:43:33 UTC 2004
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA+94VKHRjYtwQ1QARAp/IAJ9vpbv4J+H7Be8n83XSkfy6+LAqXACfWwkZ
qHqM3/5W6z8BP9b6ma7Xs1A=
=8dQI
-----END PGP SIGNATURE-----
- Next message: Cat: "Re: kppp works wvdial doesn't for pppd (logs included)"
- Previous message: Touched: "See Maggie sucking on Bart Simpson"
- In reply to: Clifford Kite: "Re: kppp works wvdial doesn't for pppd (logs included)"
- Next in thread: Clifford Kite: "Re: kppp works wvdial doesn't for pppd (logs included)"
- Reply: Clifford Kite: "Re: kppp works wvdial doesn't for pppd (logs included)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
