Date: Fri, 17 Apr 1998 08:40:29 +0200 From: Christoph Kukulies <kuku@gilberto.physik.RWTH-Aachen.DE> To: Doug White <dwhite@resnet.uoregon.edu> Cc: Christoph Kukulies <kuku@gilberto.physik.RWTH-Aachen.DE>, freebsd-questions@freefall.FreeBSD.org Subject: Re: more pppd problems (was Re: rc.serial ?) Message-ID: <19980417084029.34408@gil.physik.rwth-aachen.de> In-Reply-To: <Pine.BSF.3.96.980416112310.6831O-100000@gdi.uoregon.edu>; from Doug White on Thu, Apr 16, 1998 at 12:29:54PM -0700 References: <19980416191000.28927@gil.physik.rwth-aachen.de> <Pine.BSF.3.96.980416112310.6831O-100000@gdi.uoregon.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 16, 1998 at 12:29:54PM -0700, Doug White wrote:
> On Thu, 16 Apr 1998, Christoph Kukulies wrote:
>
> > The modem he has is a :
> >
> > Motorola 3400 Pro
>
> Should be okay.
>
> > Again some logs:
>
> Let's pick this apart.
>
> > Failing site:
> > -------------
> >
> > Problem site: < PPP_FLAGS="57600 mru 1524 modem debug kdebug 4
> > defaultroute crtscts noipdefault asyncmap 20A0000 escape FF"
>
> That looks like way too much detail. You shouldn't have to specify the
> MRU or the asyncmap. What does `noipdefault' do?
noipdefault
Disables the default behaviour when no local IP
address is specified, which is to determine (if
possible) the local IP address from the hostname.
With this option, the peer will have to supply the
local IP address during IPCP negotiation (unless it
specified explicitly on the command line or in an
options file).
Maybe it's a noop here since LOCAL:REMOTE are specified but it's
a suggested in the default ppp-on scripts of linux.
>
> The MRU is also kinda odd.
>
> > OK-site: PPP_FLAGS="38400 mru 1500 modem debug kdebug 0 defaultroute
> > crtscts noipdefault asyncmap 20A0000 escape FF"
>
> Note that difference in MRU here ..
The requested is smaller, so I see no problem or do the MRUs have to match
exactly?
>
> > Apr 16 13:31:13 testuser-rem pppd[302]: rcvd [LCP ConfReq id=0x1 <mru 1524> <asyncmap 0x20a0000> <magic 0xb9beee96> <pcomp> <accomp>]
> > Apr 16 13:31:13 testuser-rem pppd[302]: sent [LCP ConfNak id=0x1 <magic 0x827d2db3>]
> > Apr 16 13:31:13 testuser-rem pppd[302]: rcvd [LCP ConfNak id=0x1 <magic 0x827d2db3>]
> > Apr 16 13:31:13 testuser-rem pppd[302]: sent [LCP ConfReq id=0x2 <mru 1524> <asyncmap 0x20a0000> <magic 0xa955635f> <pcomp> <accomp>]
> > Apr 16 13:31:14 testuser-rem pppd[302]: rcvd [LCP ConfReq id=0x2 <mru 1524> <asyncmap 0x20a0000> <magic 0xa955635f> <pcomp> <accomp>]
> > Apr 16 13:31:14 testuser-rem pppd[302]: sent [LCP ConfNak id=0x2 <magic 0xc59701a4>]
>
> Odd that you receive your own requests, then promptly reject them.
>
> I think this says it all:
>
> > Apr 16 13:31:15 testuser-rem pppd[302]: Serial line is looped back.
>
> Check that your modem and cable configurations are correct.
Note that this is the peer side. I got this 'Serial line is looped back'
also on my Linux system (with an internal modem). So I doubt it's a cable
problem. The log is from the linux user who normally can dial into other sites
without problems.
>
>
> Case two:
>
>
> > Apr 16 13:40:28 testuser-rem pppd[351]: rcvd [LCP ConfReq id=0x4 <mru 1524> <asyncmap 0x20a0000> <magic 0x35323e0a> <pcomp> <accomp>]
> > Apr 16 13:40:28 testuser-rem pppd[351]: sent [LCP ConfNak id=0x4 <magic 0x19f6f7c8>]
> > Apr 16 13:40:28 testuser-rem pppd[351]: rcvd [LCP ConfNak id=0x4 <magic 0x19f6f7c8>]
> > Apr 16 13:40:28 testuser-rem pppd[351]: sent [LCP ConfReq id=0x5 <mru 1524> <asyncmap 0x20a0000> <magic 0xd5d5fd04> <pcomp> <accomp>]
> > Apr 16 13:40:31 testuser-rem pppd[351]: sent [LCP ConfReq id=0x5 <mru 1524> <asyncmap 0x20a0000> <magic 0xd5d5fd04> <pcomp> <accomp>]
> > Apr 16 13:40:34 testuser-rem pppd[351]: sent [LCP ConfReq id=0x5 <mru 1524> <asyncmap 0x20a0000> <magic 0xd5d5fd04> <pcomp> <accomp>]
> > Apr 16 13:40:35 testuser-rem pppd[351]: rcvd [LCP ConfReq id=0x1 <mru 1500> <auth pap> <magic 0x6d8f2eb> <pcomp> <accomp>]
> > Apr 16 13:40:35 testuser-rem pppd[351]: sent [LCP ConfRej id=0x1 <auth pap>]
> > Apr 16 13:40:35 testuser-rem pppd[351]: rcvd [LCP ConfReq id=0x1 <mru 1500> <auth pap> <magic 0x6d8f2eb> <pcomp> <accomp>]
> > Apr 16 13:40:35 testuser-rem pppd[351]: sent [LCP ConfRej id=0x1 <auth pap>]
> > Apr 16 13:40:35 testuser-rem pppd[351]: rcvd [LCP ConfAck id=0x5 <mru 1524> <asyncmap 0x20a0000> <magic 0xd5d5fd04> <pcomp> <accomp>]
> > Apr 16 13:40:35 testuser-rem pppd[351]: rcvd [LCP ConfAck id=0x5 <mru 1524> <asyncmap 0x20a0000> <magic 0xd5d5fd04> <pcomp> <accomp>]
>
> Hm, seemed to get in sync here after rejecting it's own config requests a
> few times.
>
> > Apr 16 13:40:35 testuser-rem pppd[351]: rcvd [LCP ConfReq id=0x1 <mru 1500> <auth pap> <magic 0x6d8f2eb> <pcomp> <accomp>]
> > Apr 16 13:40:35 testuser-rem pppd[351]: sent [LCP ConfRej id=0x1 <auth pap>]
> > Apr 16 13:40:35 testuser-rem pppd[351]: rcvd [LCP ConfReq id=0x2 <mru 1500> <magic 0x6d8f2eb> <pcomp> <accomp>]
> > Apr 16 13:40:35 testuser-rem pppd[351]: sent [LCP ConfAck id=0x2 <mru 1500> <magic 0x6d8f2eb> <pcomp> <accomp>]
> > Apr 16 13:40:35 testuser-rem pppd[351]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
> > Apr 16 13:40:35 testuser-rem pppd[351]: rcvd [LCP TermReq id=0x3]
>
> Looks like it got in gear here (note the new MRU) but ran out of time.
>
> Same for #3.
>
> For the working one:
>
> > Apr 16 13:50:54 testuser-rem pppd[436]: sent [LCP ConfReq id=0x1 <mru 1500> <asyncmap 0x20a0000> <magic 0x21662bd> <pcomp> <accomp>]
> > Apr 16 13:50:54 testuser-rem pppd[436]: rcvd [LCP ConfReq id=0x1 <mru 1524> <asyncmap 0xa0000> <pcomp> <accomp> < 11 04 05 f4> < 13 09 03 00 c0 7b 63 d9 81>]
> > Apr 16 13:50:54 testuser-rem pppd[436]: sent [LCP ConfRej id=0x1 < 11 04 05 f4> < 13 09 03 00 c0 7b 63 d9 81>]
> > Apr 16 13:50:54 testuser-rem pppd[436]: rcvd [LCP ConfAck id=0x1 <mru 1500> <asyncmap 0x20a0000> <magic 0x21662bd> <pcomp> <accomp>]
> > Apr 16 13:50:54 testuser-rem pppd[436]: rcvd [LCP ConfReq id=0x2 <mru 1524> <asyncmap 0xa0000> <pcomp> <accomp>]
> > Apr 16 13:50:54 testuser-rem pppd[436]: sent [LCP ConfAck id=0x2 <mru 1524> <asyncmap 0xa0000> <pcomp> <accomp>]
> > Apr 16 13:50:54 testuser-rem pppd[436]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
> > Apr 16 13:50:54 testuser-rem pppd[436]: rcvd [CCP ConfReq id=0x1 < 11 06 00 01 01 03>]
> > Apr 16 13:50:54 testuser-rem pppd[436]: sent [CCP ConfReq id=0x1]
> > Apr 16 13:50:54 testuser-rem pppd[436]: sent [CCP ConfRej id=0x1 < 11 06 00 01 01 03>]
> > Apr 16 13:50:54 testuser-rem pppd[436]: rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 134.134.179.134
> > Apr 16 13:50:54 testuser-rem pppd[436]: sent [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 134.134.179.134
> > Apr 16 13:50:54 testuser-rem pppd[436]: rcvd [IPCP ConfNak id=0x1 <addr 123.123.3.123>]
> > Apr 16 13:50:54 testuser-rem pppd[436]: sent [IPCP ConfReq id=0x2 <addr 123.123.3.123> <compress VJ 0f 01>]
> > Apr 16 13:50:54 testuser-rem pppd[436]: rcvd [CCP ConfRej id=0x1]
> > Apr 16 13:50:54 testuser-rem pppd[436]: rcvd [IPCP ConfAck id=0x2 <addr 123.123.3.123> <compress VJ 0f 01>]
>
> Looks like it needed to get sync'd up with the remote, but they resolved
> their differences and successfully connected.
>
> > The corresponding logs on the server side during the
> > login trials: (The clocks seem to diverge)
> >
> >
> > Apr 16 14:30:48 agate login: login on ttyd0 as testuser
> > Apr 16 14:30:48 agate testuser: ppplogin.sh started testuser
> > Apr 16 14:30:50 agate testuser: before starting pppd: testuser
> > Apr 16 14:30:51 agate pppd[26396]: pppd 2.2.0 started by testuser, uid 2134
> > Apr 16 14:30:51 agate pppd[26396]: Connect: ppp0 <--> /dev/ttyd0
> > Apr 16 14:30:52 agate pppd[26396]: Modem hangup
> > Apr 16 14:40:02 agate login: login on ttyd0 as testuser
> > Apr 16 14:40:02 agate testuser: ppplogin.sh started testuser
> > Apr 16 14:40:04 agate testuser: before starting pppd: testuser
> > Apr 16 14:40:04 agate pppd[27234]: pppd 2.2.0 started by testuser, uid 2134
> > Apr 16 14:40:04 agate pppd[27234]: Connect: ppp0 <--> /dev/ttyd0
> > Apr 16 14:40:11 agate pppd[27234]: peer refused to authenticate
> > Apr 16 14:40:11 agate pppd[27234]: Connection terminated.
> > Apr 16 14:47:04 agate login: login on ttyd0 as testuser
> > Apr 16 14:47:04 agate testuser: ppplogin.sh started testuser
> > Apr 16 14:47:05 agate testuser: before starting pppd: testuser
> > Apr 16 14:47:06 agate pppd[27265]: pppd 2.2.0 started by testuser, uid 2134
> > Apr 16 14:47:06 agate pppd[27265]: Connect: ppp0 <--> /dev/ttyd0
> > Apr 16 14:47:08 agate pppd[27265]: peer refused to authenticate
> > Apr 16 14:47:09 agate pppd[27265]: Connection terminated.
>
> Need to enable more logging here. Note the pap refusal noted by the
> server.
>
> > /etc/ppp/options: (server side)
> >
> > crtscts # Hardware flow control
> > ###auth login
> > #mru 1524
> > 123.123.12.11:123.123.12.3 # ip's of local and remote hosts
> > netmask 255.255.255.0
> > domain physik.rwth-aachen.de
> > dns1 123.123.12.200
> > dns2 123.123.12.211
> > passive # wait for LCP
> > modem # modem line
> > proxyarp # use ARP proxy routing
> > ###-chap
> > +pap
> ^^^^^^
>
> Pap auth is required...
Isn't it by +pap? So what's wrong with this line?
Thanks for helping.
>
> Doug White | University of Oregon
> Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant
> http://gladstone.uoregon.edu/~dwhite | Computer Science Major
>
>
--
Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980417084029.34408>