Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Sep 2001 14:43:25 -0400
From:      corigan@mindspring.com
To:        freebsd-questions@freebsd.org
Subject:   PPPoE/userland locking up on incompletion of chap success
Message-ID:  <Springmail.105.1001443405.0.13363800@www.springmail.com>

next in thread | raw e-mail | index | archive | help
Hi This is directed to Brian or possible anybody else who could help me. I have bellsouth.net IFITL.  I have been using netgraph with userland ppp since it has been implemented to handle PPPoE (3.4 I think?). Anyways it has been working great for me for quite awhile.  My connection has really taken a turn for the worse lately (Bellsouth doing what there good at, I would normally say more here but this isn't a flame war.)  And I have noticed my ppp locking up at a certain place and not continuing trying to redial.   This is where it occurs:

Sep 25 14:24:09 zeist ppp[9872]: tun0: Phase: PPP Started (ddial mode). 
Sep 25 14:24:09 zeist ppp[9872]: tun0: Phase: bundle: Establish 
Sep 25 14:24:09 zeist ppp[9872]: tun0: Phase: deflink: closed -> opening 
Sep 25 14:24:09 zeist ppp[9872]: tun0: Phase: deflink: Connected! 
Sep 25 14:24:09 zeist ppp[9872]: tun0: Phase: deflink: opening -> dial 
Sep 25 14:24:09 zeist ppp[9872]: tun0: Phase: deflink: dial -> carrier 
Sep 25 14:24:12 zeist ppp[9872]: tun0: Phase: Received NGM_PPPOE_SUCCESS (hook "tun0") 
Sep 25 14:24:12 zeist ppp[9872]: tun0: Phase: deflink: carrier -> login 
Sep 25 14:24:12 zeist ppp[9872]: tun0: Phase: deflink: login -> lcp 
Sep 25 14:24:12 zeist ppp[9872]: tun0: Phase: bundle: Authenticate 
Sep 25 14:24:12 zeist ppp[9872]: tun0: Phase: deflink: his = CHAP 0x05, mine = none 
Sep 25 14:24:12 zeist ppp[9872]: tun0: Phase: Chap Input: CHALLENGE (16 bytes from XXXXXX_IFITL) 
Sep 25 14:24:12 zeist ppp[9872]: tun0: Phase: Chap Output: RESPONSE (XXXXX@bellsouth.net) 


And it will just sit there for hrs and hrs if I don't manually come and kill the process and try to restart it.  Unofortunatly this is so frequent that I have experienced over 24 hrs of downtime in a whole 5 days, whoopie for my connection! Here is my ppp.conf file: 
default:
 set log Phase Chat IPCP CCP tun command
 set device PPPoE:dc0
 set mru 1492
 set mtu 1492
 deny pap
 accept chap 
 disable lqr
 set timeout 30
 set server +XXXX XXXXXXX
 set speed sync
 set cd 5
 set authname XXXXXXX@bellsouth.net
 set authkey XXXXXX
 set redial 15 28800
 set dial
 add default HISADDR
 disable iface-alias


At one time I had LQR packets on and was getting dropped whenever heavy traffic occured.  I used to not have this problem. Is it possible that disabling the packets is the reason for the hanging of
the ppp?  Like I said it can sit in that state right on Chap Output for hrs.  I wonder if enabling the LQR packets and just setting a high timelimit on them to send to redback swould help this scenario and
atleast get ppp to realize that A) This connection is bunk and is never going to happen cause bellsouth.net is never assigning me an IP and responding and B) try to redial it.  Here is my uname info:

su-2.03# uname -a
FreeBSD zeist.homeip.net 4.4-STABLE FreeBSD 4.4-STABLE #8: Mon Sep 17 05:22:21 EDT 2001 root@zeist.homeip.net:/usr/obj/usr/src/sys/zeist  i386

This has been an occuring problem like I had stated for quite along time.  Anyways, thanks for the excellent work, FreeBSD Owns all and I'm looking forward to figuring out this little tweak to try to get ppp to act a little more friendly towards a poor IFITL connection, lol.  Other then this problem which has been occuring for awhile for me I have had no problems with userland.  Really from what I can tell this of course isn't a problem with userland, just a small tweak of a configuration that may help it act better with networks that don't 
like to assign IP addresses. :)  Hope someone can give me some insight or some info on some directions  I may take to overcome my problem, thank you.

Matt

P.S. Sorry about the cruddy wrap on this email, had to post it from a web form since freebsd doesn't like my mail servers cause the reverse doesn't match the HELO, good security.. :)


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?Springmail.105.1001443405.0.13363800>