kppp works wvdial doesn't for pppd (logs included)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have a working internet connection using kppp over a dedicated dial up
modem (static ip). I want to have a headless setup as my gateway using my
old computer. The problem is that I can't get a working pppd connection using
wvdial.

I'm running RedHat 7.2 on the box, pppd 2.4.1, wvdial 1.41 and kppp 2.0.8

I've included the output of /var/log/ppplog for both connections,
kppprc, /etc/wvdial.conf and the wvdial command. /sbin/route -n 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.

Is it the fact that wvdial is using chap instead of pap for kppp?
#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.

Please excuse the long post.

The output of /var/log/ppplog for kppp is (wrapped) =======================

Jul 15 12:33:31 atlas modprobe: modprobe: Can't locate module ppp0
Jul 15 12:33:31 atlas modprobe: modprobe: Can't locate module ppp0
Jul 15 12:33:31 atlas pppd[1409]: pppd 2.4.1 started by root, uid 0
Jul 15 12:33:31 atlas pppd[1409]: using channel 4
Jul 15 12:33:31 atlas pppd[1409]: Using interface ppp0
Jul 15 12:33:31 atlas pppd[1409]: Connect: ppp0 <--> /dev/ttyS1
Jul 15 12:33:31 atlas pppd[1409]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
<magic 0x2a08573> <pcomp> <accomp>]
Jul 15 12:33:31 atlas pppd[1409]: rcvd [LCP ConfReq id=0x7c <asyncmap 0xa0000>
<auth chap MD5> <magic 0x8de62f0c> <pcomp> <accomp>]
Jul 15 12:33:31 atlas pppd[1409]: sent [LCP ConfNak id=0x7c <auth pap>]
Jul 15 12:33:31 atlas pppd[1409]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0>
<magic 0x2a08573> <pcomp> <accomp>]
Jul 15 12:33:31 atlas pppd[1409]: rcvd [LCP ConfReq id=0x7d <asyncmap 0xa0000>
<auth pap> <magic 0x8de62f0c> <pcomp> <accomp>]
Jul 15 12:33:31 atlas pppd[1409]: sent [LCP ConfAck id=0x7d <asyncmap 0xa0000>
<auth pap> <magic 0x8de62f0c> <pcomp> <accomp>]
Jul 15 12:33:31 atlas pppd[1409]: sent [PAP AuthReq id=0x1 user="username"
password=<hidden>]
Jul 15 12:33:32 atlas pppd[1409]: rcvd [PAP AuthAck id=0x1 ""]
Jul 15 12:33:32 atlas pppd[1409]: sent [IPCP ConfReq id=0x1
<addr 139.130.171.87> <compress VJ 0f 01> <ms-dns1 0.0.0.0>
<ms-dns3 0.0.0.0>]
Jul 15 12:33:32 atlas modprobe: modprobe: Can't locate module ppp-compress-21
Jul 15 12:33:32 atlas modprobe: modprobe: Can't locate module ppp-compress-21
Jul 15 12:33:32 atlas pppd[1409]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15>]
Jul 15 12:33:32 atlas pppd[1409]: rcvd [IPCP ConfReq id=0xdc
<compress VJ 0f 00> <addr 139.130.171.1>]
Jul 15 12:33:32 atlas pppd[1409]: sent [IPCP ConfAck id=0xdc
<compress VJ 0f 00> <addr 139.130.171.1>]
Jul 15 12:33:32 atlas pppd[1409]: rcvd [IPCP ConfNak id=0x1
<ms-dns1 203.50.2.71> <ms-dns3 139.130.4.4>]
Jul 15 12:33:32 atlas pppd[1409]: 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 15 12:33:32 atlas pppd[1409]: rcvd [LCP ProtRej id=0x7e 80 fd 01 01 00 0c
1a 04 78 00 18 04 78 00]
Jul 15 12:33:32 atlas pppd[1409]: 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 15 12:33:32 atlas pppd[1409]: local IP address 139.130.171.87
Jul 15 12:33:32 atlas pppd[1409]: remote IP address 139.130.171.1
Jul 15 12:33:32 atlas pppd[1409]: primary DNS address 203.50.2.71
Jul 15 12:33:32 atlas pppd[1409]: secondary DNS address 139.130.4.4
Jul 15 12:33:32 atlas pppd[1409]: Script /etc/ppp/ip-up started (pid 1414)
Jul 15 12:33:32 atlas pppd[1409]: Script /etc/ppp/ip-up finished (pid 1414),
status = 0x0

The output of non working wvdial is (wrapped) ==============================

Jul 15 12:47:48 atlas pppd[1562]: pppd 2.4.1 started by root, uid 0
Jul 15 12:47:48 atlas pppd[1562]: using channel 7
Jul 15 12:47:48 atlas pppd[1562]: Using interface ppp0
Jul 15 12:47:48 atlas pppd[1562]: Connect: ppp0 <--> /dev/ttyS1
Jul 15 12:47:48 atlas pppd[1562]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
<magic 0x97c3ad94> <pcomp> <accomp>]
Jul 15 12:47:48 atlas pppd[1562]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0>
<magic 0x97c3ad94> <pcomp> <accomp>]
Jul 15 12:47:50 atlas pppd[1562]: rcvd [LCP ConfReq id=0x7a <asyncmap 0xa0000>
<auth chap MD5> <magic 0x8df34066> <pcomp> <accomp>]
Jul 15 12:47:50 atlas pppd[1562]: sent [LCP ConfAck id=0x7a <asyncmap 0xa0000>
<auth chap MD5> <magic 0x8df34066> <pcomp> <accomp>]
Jul 15 12:47:50 atlas pppd[1562]: rcvd [CHAP Challenge id=0xe3
<dc1965fbacafe5a04f440c3e5db7cf33>, name = "chw14.Sydney"]
Jul 15 12:47:50 atlas pppd[1562]: sent [CHAP Response id=0xe3
<0f93322afef2707d603822f1bf34db09>, name = "username"]
Jul 15 12:47:50 atlas pppd[1562]: rcvd [CHAP Success id=0xe3 ""]
Jul 15 12:47:50 atlas pppd[1562]: sent [IPCP ConfReq id=0x1
<addr 139.130.171.87> <compress VJ 0f 01>]
Jul 15 12:47:50 atlas modprobe: modprobe: Can't locate module ppp-compress-21
Jul 15 12:47:50 atlas modprobe: modprobe: Can't locate module ppp-compress-21
Jul 15 12:47:50 atlas pppd[1562]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15>]
Jul 15 12:47:50 atlas pppd[1562]: rcvd [IPCP ConfReq id=0x3b
<compress VJ 0f 00> <addr 139.130.171.1>]
Jul 15 12:47:50 atlas pppd[1562]: sent [IPCP ConfAck id=0x3b
<compress VJ 0f 00> <addr 139.130.171.1>]
Jul 15 12:47:50 atlas pppd[1562]: rcvd [IPCP ConfAck id=0x1
<addr 139.130.171.87> <compress VJ 0f 01>]
Jul 15 12:47:50 atlas pppd[1562]: local IP address 139.130.171.87
Jul 15 12:47:50 atlas pppd[1562]: remote IP address 139.130.171.1
Jul 15 12:47:50 atlas pppd[1562]: Script /etc/ppp/ip-up started (pid 1565)
Jul 15 12:47:50 atlas pppd[1562]: Script /etc/ppp/ip-up finished (pid 1565),
status = 0x0

/etc/wvdial.conf ================================================== =========

[Dialer Defaults]
Modem = /dev/ttyS1
Baud = 57600
Init1 = ATZ
SetVolume = 1
Dial Command = ATDT
;Init4 = ATM1L2
;Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 S11=55 +FCLASS=0
Init2 = ATM1L1
Phone = <phonenumber>
Username = username
Password = password
Force Address = 139.130.171.87
New PPPD = 1

[Dialer BigPond_Business]
Username = username
Password = password
Phone = <phonenumber>
Area Code = <area code>
Inherits = Modem1
Stupid mode = 1

[Modem1]
Modem = /dev/modem
Baud = 57600
Init1 = ATZ
SetVolume = 1
Dial Command = ATDT
Init4 = ATM1L2

[Modem0]
Modem = /dev/ttyS1
Baud = 57600
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 S11=55 +FCLASS=0

wvdial output ================================================== ===========

- --> WvDial: Internet dialer version 1.41
- --> Initializing modem.
- --> Sending: ATZ
ATZ
OK
- --> Sending: ATM1L1
ATM1L1
OK
- --> Modem initialized.
- --> Sending: ATDT <phonenumber>
- --> Waiting for carrier.
ATDT <phonenumber>
CONNECT 50666/V42BIS
- --> Carrier detected. Waiting for prompt.
~[7f]}#@!}!}8} }9}"}&} }*} } }#}%B#}%}%}&[0e]}3]k}'}"}(}"F.~
- --> PPP negotiation detected.
- --> Starting pppd at Thu Jul 15 13:23:25 2004

kppprc ================================================== ====================

[Account0]
AccountingEnabled=1
AccountingFile=/Australia/Local.rst
Authentication=1
AutoDNS=1
AutoName=0
BeforeConnect=
BeforeDisconnect=
Command=
DNS=
DefaultRoute=1
DisconnectCommand=
Domain=
ExDNSDisabled=0
Gateway=0.0.0.0
IPAddr=0.0.0.0
Name=BPond DIRECT
Password=password
Phonenumber=<phonenumber>
ScriptArguments=
ScriptCommands=
StorePassword=1
SubnetMask=0.0.0.0
TotalBytes=768190089
TotalCosts=95
Username=<username>
VolumeAccountingEnabled=3
pppdArguments=

[Account1]
AccountingEnabled=
AccountingFile=
Authentication=
AutoDNS=
AutoName=
BeforeConnect=
BeforeDisconnect=
Command=
DNS=
DefaultRoute=
DisconnectCommand=
Domain=
ExDNSDisabled=
Gateway=
IPAddr=
Name=
Password=
Phonenumber=
ScriptArguments=
ScriptCommands=
StorePassword=
SubnetMask=
TotalBytes=
TotalCosts=
Username=
VolumeAccountingEnabled=
pppdArguments=

[General]
DefaultAccount=BPond DIRECT
NumberOfAccounts=1
PPPDebug=0
ShowLogWindow=1

[Graph]
Background=255,255,255
Enabled=true
InBytes=0,0,255
OutBytes=255,0,0
Text=0,0,0

[Modem]
AnswerResponse=CONNECT
AnswerString=ATA
BusyResponse=BUSY
ConnectResponse=CONNECT
Device=/dev/modem
DialString=ATDT
EscapeGuardTime=50
EscapeResponse=OK
EscapeString=+++
HangUpResponse=OK
HangupString=+++ATH
InitDelay=50
InitResponse=OK
InitString=ATZ
NoCarrierResponse=NO CARRIER
NoDialToneDetection=ATX3
NoDialToneResp=NO DIALTONE
PreInitDelay=50
RingResponse=RING
UseLockFile=0
VolumeHigh=M1L3
VolumeMedium=M1L1
VolumeOff=M0L0

[WindowPosition]
WindowPositionConWinX=480
WindowPositionConWinY=457
WindowPositionStatWinX=862
WindowPositionStatWinY=0
- --
Cat

http://www.ratrobot.com/java/beginner/ An absolute beginners step by
step guide on how to use java applets.
Thu Jul 15 17:38:38 UTC 2004
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9sEeKHRjYtwQ1QARAp3WAKCFgft0g2LyHMEjveh++I 4Z1PCtdQCg+b6l
KzfF3ybfSdWLZ91yKWyH2xQ=
=3ySd
-----END PGP SIGNATURE-----

Thu, 15 Jul 2004 16:15:35 -0700 tarihinde, Cat dedi ki:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have a working internet connection using kppp over a dedicated dial up
> modem (static ip). I want to have a headless setup as my gateway using my
> old computer. The problem is that I can't get a working pppd connection using
> wvdial.
>
> I'm running RedHat 7.2 on the box, pppd 2.4.1, wvdial 1.41 and kppp 2.0.8
>
> I've included the output of /var/log/ppplog for both connections,
> kppprc, /etc/wvdial.conf and the wvdial command. /sbin/route -n 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.
>
> Is it the fact that wvdial is using chap instead of pap for kppp?
--8<--
> Also the nameservers appear to be set for kppp and not for wvdial.

Bingo!

--8<--

Your problem is that you don't get DNS addresses.

There is nothing wrong in authentication. Kppp initiated pppd doesn't
accept the first suggestion of CHAP, but suggests back PAP instead, and
ISP side accepts it. So kppp authenticates via PAP. OTOH wvdial initiated
pppd accepts the first suggestion, so it authenticates via CHAP. Both
connections are established correctly and got their IP addresses assigned.
You should be able to ping to external IP addresses, I think.

The problem apparently lies in getting DNS addresses dynamically from ISP.
The fact that "route -n" works but "route" hangs also confirms this. Kppp
gets them, but wvdial doesn't. So you must include "usepeerdns" option
either in /etc/ppp/options, or in wvdial.conf (it should have a variable
to set extra pppd parameters but I can't remember its name. It should be
mentioned in wvdial.conf man page)

Alternatively, you can edit /etc/resolv.conf and add 2 lines, i.e.
hardcode the ISP's DNS server addresses, if they are fixed (usually they
are) :

nameserver 12.34.56.78
nameserver 87.65.43.21

HTH
--
Abdullah | aramazan@ |
Ramazanoglu | myrealbox |
________________| D O T cöm |

Sat, 17 Jul 2004 14:36:03 -0400 tarihinde, Cat dedi ki:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Fri, 16 Jul 2004 20:17:03 +0300, Abdullah Ramazanoglu wrote:
>
>> --8<--
>>> Also the nameservers appear to be set for kppp and not for wvdial.
>>
>> Bingo!
>>
>> --8<--
>>
>> Your problem is that you don't get DNS addresses.
> Unfortuately it aint that simple.
>
> ping -n 216.109.127.30
>
> doesn't work with wvdial but does with kppp with identical routing tables.
> I have the nameserver entries in my /etc/resolv.conf
>
> search telstra.net
> nameserver 139.130.4.4
> nameserver 203.50.2.71

When I saw no DNS negotiation in the wvdial logs, I think I plunged into
that prematurely. Well, then could it be a defaultroute issue? From the
logs it is clear that both sides negotiate successfully and your pppd gets
remote and local IP addresses. There is a "defaultroute" parameter to
pppd, which can be given in /etc/ppp/options or wvdial.conf file.

Another common problem regarding defaultroute is when your machine has an
ethernet card an already assigned a default route (to eth0) before pppd
started. Then pppd sometimes adds a defaultroute (to ISP) without deleting
the already established defaultroute (to eth0) first. I guess kppp might
be a bit smarter to detect this situation and delete eth0 defaultroute
itself. I don't remember whether wvdial had such an option somewhere. But
even if it doesn't, you could still handle such an issue by not assigning
a default route to eth0 in the first place. (either/both in the
/etc/sysconfig/network and /etc/sysconfig/network-scripts/ifcfg-eth0)

If it isn't a defaultroute issue, then I can't think of another culprit,
currently.

--
Abdullah | aramazan@ |
Ramazanoglu | myrealbox |
________________| D O T cöm |

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 16 Jul 2004 20:17:03 +0300, Abdullah Ramazanoglu wrote:

> --8<--
>> Also the nameservers appear to be set for kppp and not for wvdial.
>
> Bingo!
>
> --8<--
>
> Your problem is that you don't get DNS addresses.
Unfortuately it aint that simple.

ping -n 216.109.127.30

doesn't work with wvdial but does with kppp with identical routing tables.
I have the nameserver entries in my /etc/resolv.conf

search telstra.net
nameserver 139.130.4.4
nameserver 203.50.2.71

Thanks for the reply though.
- --
Cat

http://www.ratrobot.com/writing/brainzilla/ What's the absolute
limit of intelligence in this universe? And why should I turn of the
abflex2000 infomercials long enough to read about it?
Sat Jul 17 18:35:57 UTC 2004
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA+XGOKHRjYtwQ1QARAqbgAKCa9IKtlA3eYplX0zOMTQ rvHxVWHACffXoI
KnVoCGxqAVAfyZvUzGybodk=
=0onT
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 17 Jul 2004 20:05:56 +0300, Abdullah Ramazanoglu wrote:
> When I saw no DNS negotiation in the wvdial logs, I think I plunged into
> that prematurely. Well, then could it be a defaultroute issue? From the
> logs it is clear that both sides negotiate successfully and your pppd gets
> remote and local IP addresses. There is a "defaultroute" parameter to
> pppd, which can be given in /etc/ppp/options or wvdial.conf file.
>
> Another common problem regarding defaultroute is when your machine has an
> ethernet card an already assigned a default route (to eth0) before pppd
> started. Then pppd sometimes adds a defaultroute (to ISP) without deleting
> the already established defaultroute (to eth0) first. I guess kppp might
> be a bit smarter to detect this situation and delete eth0 defaultroute
> itself. I don't remember whether wvdial had such an option somewhere. But
> even if it doesn't, you could still handle such an issue by not assigning
> a default route to eth0 in the first place. (either/both in the
> /etc/sysconfig/network and /etc/sysconfig/network-scripts/ifcfg-eth0)
>
> If it isn't a defaultroute issue, then I can't think of another culprit,
> currently.
Unfortunately I doubt it's that either. I don't have a default route set and
it is set by both kppp and wvdial. '/sbin/route -n > file' then diff shows they
have identical routing tables. Also when I ping the remote IP address I
gave earlier and listen with tcpdump I get exactly the same packets, as far as
I can tell, for both on the correct ppp0 interface. It's just that the remote
host doesn't appear to answer for wvdial.

It's got me stumped too.
- --
Cat

http://www.ratrobot.com/writing/ms/ Wanted Java Developer please email your
resume. Microsoft Word format only. You can't escape Microsoft's empire.
But will breaking it up be enough?
Sun Jul 18 14:35:24 UTC 2004
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA+oqtKHRjYtwQ1QARAkRTAKDNhW6zD7Sn8Y8jvbZGV/024BkeSQCeK7iV
6NERTdMHw7D6c/EwCurW71s=
=WtlY
-----END PGP SIGNATURE-----

Cat <ratrobotspam@yahoo.com> wrote:

> I have a working internet connection using kppp over a dedicated
> dial up modem (static ip). I want to have a headless setup as my
> gateway using my old computer. The problem is that I can't get a
> working pppd connection using wvdial.

> I'm running RedHat 7.2 on the box, pppd 2.4.1, wvdial 1.41 and
> kppp 2.0.8

> I've included the output of /var/log/ppplog for both connections,
> kppprc, /etc/wvdial.conf and the wvdial command. /sbin/route -n
> 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?

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?

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

Kppp appears to be configured to request the DNS server IP addresses:

> AutoDNS=1

There's no sign that wvdial is configured to request them.

> Please excuse the long post.

The long post was the right thing to do. Excuse me for eliding it.

Please be aware that I've never used the pppd dialing/configuration
frontends kppp and wvdial.

It seems peculiar that there was no Protocol-Reject for CCP by wvdial.
There should have been one, just as there was by kppp:

> Jul 15 12:33:32 atlas pppd[1409]: rcvd [LCP ProtRej id=0x7e 80 fd 01 01
> 00 0c 1a 04 78 00 18 04 78 00]

The connection (remote) host was the same in each case. Moreover, rare
is the ISP that uses any CCP except the bastardized and patented MPPC,
the part of MS-PPC that actually does compression. For wvdial the ISP
seems to just ignore the CCP request. Hmm.., well the ISP could ignore
the request if it was broken when it arrived at the ISP, or it never
got there.

Another peculiar thing is that wvdial appears to be configured for a
fixed IP address but kppp does not:

wvdial:
> Force Address = 139.130.171.87

kppp:
> IPAddr=0.0.0.0

Yet the log shows kppp requests the same IP address as wvdial does and
_without_ first negotiating it, which is what I would expect if it is
not configured. Do you know why this is?

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.

Whatever the problem, it is very subtle or else obfuscated by the pppd
frontends.

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/

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

Cat <my.email.address.is@on.my.website_ratrobot.com> wrote:
> On Sun, 18 Jul 2004 10:20:26 -0500, Clifford Kite wrote:

>> 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?

Possibly. I've begun to suspect the PPP implementation at the ISP is
part of the problem, and that the ISP fails to authenticate you even
though it says authentication was successful and the physical link
is established.

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

>From man pppd:

usehostname
Enforce the use of the hostname (with domain name
appended, if given) as the name of the local system
for authentication purposes (overrides the name
option). This option is not normally needed since
the name option is privileged.

I'm not clear about the meaning of what is said in the ()'s. What has
to be sent to the ISP as the user identifier depends on what the ISP
must receive for CHAP authentication. Ordinarily it's the same for CHAP
as for PAP, RATROBOT here.

I'd first try removing the usehostname option (probably by reconfiguring
wvdial) and commenting out the "name atlas.mrsean.lnk.telstra.net" option
in /etc/ppp/wvdial.conf. If RATROBOT is used to identify you for CHAP as
well as PAP then the connection should still succeed and work correctly.

The chap-secrets file should contain a line similar to

RATROBOT * TheSecret

Note that some people believe that a * should appear as a fourth field,
but I doubt that it's necessary.

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

What strikes me as strange about the dryrun output is that there is no
"call wvdial" option - which is needed for pppd to obtain options from
/etc/ppp/peers/wvdial.

> 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?

Maybe. The ISP's PPP implementation could be broken, saying CHAP
authentication succeeded, but not terminating the link as it should
and instead just rendering it useless by dropping them on the floor.
The failure to ping the PPP peer (ISP connection host) IP address and
receive a reply suggests that is happening. If you can ping the peer's
IP address when connected with kppp then it must be what's happening.

> I ran /etc/rc.d/init.d/iptables stop before doing the above just incase.

Good idea.

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* In my book, the first poster to resort to personal abuse in a Usenet
debate loses by default. - Rod Smith */

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 19 Jul 2004 10:03:28 -0500, Clifford Kite wrote:
> Possibly. I've begun to suspect the PPP implementation at the ISP is
> part of the problem, and that the ISP fails to authenticate you even
> though it says authentication was successful and the physical link
> is established.
BINGO! My username was in all capital letters when I used it in lowercase it
succeeded.

> Maybe. The ISP's PPP implementation could be broken, saying CHAP
> authentication succeeded, but not terminating the link as it should
> and instead just rendering it useless by dropping them on the floor.
> The failure to ping the PPP peer (ISP connection host) IP address and
> receive a reply suggests that is happening. If you can ping the peer's
> IP address when connected with kppp then it must be what's happening.
Exactly what was happening. The multiple layers in the PPP implementation makes
it that bit harder to spot the error, but you were right on the money.

Thanks a lot for the help.
- --
Cat

http://www.ratrobot.com/java/menu/ Simple menu applet that lets you
set colors,fonts and use it with a tiled background. It is completely FREE
for any use.
Thu Jul 22 17:45:32 UTC 2004
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA//08KHRjYtwQ1QARAuZFAKCULWBN0wUH4QPpEMgdNunMKzCDGgCd Hc+X
7BbV9ZCNSDX7neTySKKGD6w=
=eNI4
-----END PGP SIGNATURE-----