From owner-freebsd-questions Thu Apr 16 23:36:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA10471 for freebsd-questions-outgoing; Thu, 16 Apr 1998 23:36:44 -0700 (PDT) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from gilberto.physik.RWTH-Aachen.DE (gilberto.physik.rwth-aachen.de [137.226.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA10415 for ; Fri, 17 Apr 1998 06:36:30 GMT (envelope-from kuku@gilberto.physik.RWTH-Aachen.DE) Received: (from kuku@localhost) by gilberto.physik.RWTH-Aachen.DE (8.8.8/8.8.7) id IAA09514; Fri, 17 Apr 1998 08:40:29 +0200 (MEST) (envelope-from kuku) Message-ID: <19980417084029.34408@gil.physik.rwth-aachen.de> Date: Fri, 17 Apr 1998 08:40:29 +0200 From: Christoph Kukulies To: Doug White Cc: Christoph Kukulies , freebsd-questions@freefall.FreeBSD.org Subject: Re: more pppd problems (was Re: rc.serial ?) References: <19980416191000.28927@gil.physik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from Doug White on Thu, Apr 16, 1998 at 12:29:54PM -0700 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 ] > > Apr 16 13:31:13 testuser-rem pppd[302]: sent [LCP ConfNak id=0x1 ] > > Apr 16 13:31:13 testuser-rem pppd[302]: rcvd [LCP ConfNak id=0x1 ] > > Apr 16 13:31:13 testuser-rem pppd[302]: sent [LCP ConfReq id=0x2 ] > > Apr 16 13:31:14 testuser-rem pppd[302]: rcvd [LCP ConfReq id=0x2 ] > > Apr 16 13:31:14 testuser-rem pppd[302]: sent [LCP ConfNak id=0x2 ] > > 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 ] > > Apr 16 13:40:28 testuser-rem pppd[351]: sent [LCP ConfNak id=0x4 ] > > Apr 16 13:40:28 testuser-rem pppd[351]: rcvd [LCP ConfNak id=0x4 ] > > Apr 16 13:40:28 testuser-rem pppd[351]: sent [LCP ConfReq id=0x5 ] > > Apr 16 13:40:31 testuser-rem pppd[351]: sent [LCP ConfReq id=0x5 ] > > Apr 16 13:40:34 testuser-rem pppd[351]: sent [LCP ConfReq id=0x5 ] > > Apr 16 13:40:35 testuser-rem pppd[351]: rcvd [LCP ConfReq id=0x1 ] > > Apr 16 13:40:35 testuser-rem pppd[351]: sent [LCP ConfRej id=0x1 ] > > Apr 16 13:40:35 testuser-rem pppd[351]: rcvd [LCP ConfReq id=0x1 ] > > Apr 16 13:40:35 testuser-rem pppd[351]: sent [LCP ConfRej id=0x1 ] > > Apr 16 13:40:35 testuser-rem pppd[351]: rcvd [LCP ConfAck id=0x5 ] > > Apr 16 13:40:35 testuser-rem pppd[351]: rcvd [LCP ConfAck id=0x5 ] > > 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 ] > > Apr 16 13:40:35 testuser-rem pppd[351]: sent [LCP ConfRej id=0x1 ] > > Apr 16 13:40:35 testuser-rem pppd[351]: rcvd [LCP ConfReq id=0x2 ] > > Apr 16 13:40:35 testuser-rem pppd[351]: sent [LCP ConfAck id=0x2 ] > > Apr 16 13:40:35 testuser-rem pppd[351]: sent [IPCP ConfReq id=0x1 ] > > 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 ] > > Apr 16 13:50:54 testuser-rem pppd[436]: rcvd [LCP ConfReq id=0x1 < 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 ] > > Apr 16 13:50:54 testuser-rem pppd[436]: rcvd [LCP ConfReq id=0x2 ] > > Apr 16 13:50:54 testuser-rem pppd[436]: sent [LCP ConfAck id=0x2 ] > > Apr 16 13:50:54 testuser-rem pppd[436]: sent [IPCP ConfReq id=0x1 ] > > 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 > Apr 16 13:50:54 testuser-rem pppd[436]: sent [IPCP ConfAck id=0x1 > Apr 16 13:50:54 testuser-rem pppd[436]: rcvd [IPCP ConfNak id=0x1 ] > > Apr 16 13:50:54 testuser-rem pppd[436]: sent [IPCP ConfReq id=0x2 ] > > 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 ] > > 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