From owner-freebsd-questions Wed Jan 5 19:47:13 2000 Delivered-To: freebsd-questions@freebsd.org Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by hub.freebsd.org (Postfix) with ESMTP id DF5E115648 for ; Wed, 5 Jan 2000 19:47:03 -0800 (PST) (envelope-from gwarslave@mindspring.com) Received: from gilligan (user-38lcjlt.dialup.mindspring.com [209.86.78.189]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with SMTP id WAA25405 for ; Wed, 5 Jan 2000 22:46:11 -0500 (EST) Message-ID: <005e01bf57f8$55c14a60$0200a8c0@zeist.sweb.com> Reply-To: "Corigan" From: "Corigan" To: Subject: PPP and Netgraph Help.. Date: Wed, 5 Jan 2000 22:44:27 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01BF57CE.6BEF7D40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_005B_01BF57CE.6BEF7D40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Fellow Freebsd question readers, I would like to open up this plea for help first by thanking = brian somers, archie cobb, and julian elischer for some excellent code, = i.e. Netgraph and user-PPP. This code definately worked real well. I = had the netgraph and user-ppp running great together until I cvsup'd one = day and did a make world. I went to bed, woke up, and there was no = connection. So I started looking through my logs to see if I could = find out what happened. Here is what my normal connection looks like - = this is using Netgraph from a recent cvsup on a 3.4-STABLE build with = user-ppp 2.24. After all my trouble occured I went to Brian's web page = and grabbed his 2.26 user-ppp and compiled it and still had the same = results. Here is a log of what usually happens when it connects = properly, and I'll also paste my ppp.conf and options file, etc. after a = log of a good connection and then what happens when I try to connect = after the cvsup. I intiate the command ./ppp -nat -ddial default to = connect and it always worked fine, I tried it without the nat flags of = course to. So here is the good connection: Jan 3 17:22:02 crazytrain ppp[314]: Phase: Using interface: tun0=20 Jan 3 17:22:02 crazytrain ppp[314]: Phase: deflink: Created in closed = state=20 Jan 3 17:22:02 crazytrain ppp[321]: Phase: PPP Started (ddial mode).=20 Jan 3 17:22:02 crazytrain ppp[321]: Phase: bundle: Establish=20 Jan 3 17:22:02 crazytrain ppp[321]: Phase: deflink: closed -> opening=20 Jan 3 17:22:02 crazytrain ppp[321]: Phase: deflink: Connected!=20 Jan 3 17:22:02 crazytrain ppp[321]: Phase: deflink: opening -> dial=20 Jan 3 17:22:02 crazytrain ppp[321]: Phase: deflink: dial -> carrier=20 Jan 3 17:22:03 crazytrain ppp[321]: Phase: Received NGM_PPPOE_SUCCESS = (hook "tun0")=20 Jan 3 17:22:03 crazytrain ppp[321]: Phase: deflink: carrier -> login=20 Jan 3 17:22:03 crazytrain ppp[321]: Phase: deflink: login -> lcp=20 Jan 3 17:22:03 crazytrain ppp[321]: Phase: bundle: Authenticate=20 Jan 3 17:22:03 crazytrain ppp[321]: Phase: deflink: his =3D CHAP 0x05, = mine =3D none=20 Jan 3 17:22:03 crazytrain ppp[321]: Phase: Chap Input: CHALLENGE (16 = bytes from WDSTGACR_IFITL)=20 Jan 3 17:22:03 crazytrain ppp[321]: Phase: Chap Output: RESPONSE = (XXXX@bellsouth.net)=20 Jan 3 17:22:04 crazytrain ppp[321]: Phase: Chap Input: SUCCESS=20 Jan 3 17:22:04 crazytrain ppp[321]: Phase: deflink: lcp -> open=20 Jan 3 17:22:04 crazytrain ppp[321]: Phase: bundle: Network=20 Jan 3 17:22:04 crazytrain ppp[321]: Warning: Add route failed: default = already exists=20 This is normally what happens and when doing an ifconfig afterwards you = could see the ip address bound to tun0 and where it was going, I.E. = 0.0.0.0 ---> 1.1.1.1 But when I woke up the next day and started inspecting my logs I found = this: Jan 4 13:51:25 crazytrain ppp[2068]: Phase: deflink: hangup -> opening=20 Jan 4 13:54:18 crazytrain ppp[291]: Phase: Using interface: tun0=20 Jan 4 13:54:18 crazytrain ppp[291]: Phase: deflink: Created in closed = state=20 Jan 4 13:54:18 crazytrain ppp[293]: Phase: PPP Started (ddial mode).=20 Jan 4 13:54:18 crazytrain ppp[293]: Phase: bundle: Establish=20 Jan 4 13:54:18 crazytrain ppp[293]: Phase: deflink: closed -> opening=20 Jan 4 13:54:18 crazytrain ppp[293]: Phase: deflink: Connected!=20 Jan 4 13:54:18 crazytrain ppp[293]: Phase: deflink: opening -> dial=20 Jan 4 13:54:18 crazytrain ppp[293]: Phase: deflink: dial -> carrier=20 Jan 4 13:54:23 crazytrain ppp[293]: Phase: deflink: Disconnected!=20 Jan 4 13:54:23 crazytrain ppp[293]: Phase: deflink: carrier -> hangup=20 Jan 4 13:54:23 crazytrain ppp[293]: Phase: deflink: Connect time: 5 = secs: 0 octets in, 0 octets out=20 Jan 4 13:54:23 crazytrain ppp[293]: Phase: total 0 bytes/sec, peak 0 = bytes/sec on Tue Jan 4 13:54:23 2000=20 This is what started occuring the morning after. This could mean that = my connection is just down and something is messed on bellsouth's end, = or possibly that Netgraph isn't getting the call from ppp, or netgraph = just isn't recieving NGM_PPPOE_SUCCESS from my bellsouth server. I'm = not actually quite sure how it works. I Have compiled the netgraph code = into the kernel with the options NETGRAPH, options NETGRAPH_PPPOE, and = options NETGRAPH_SOCKET. Like I stated, I'm not quite sure how this = NGM_PPPOE_SUCCESS hook works.. if it is recieved from bellsouth and = their server, or recieved from ppp and it is ppp that isn't calling it. = If user-ppp is the problem in why it isn't grabbing that = NGM_PPPOE_SUCCESS, how can I fix this? I see that there is a = -DNONETGRAPH command in user-ppp that could be the cause of this, but = I'm not quite sure of the legistics. I also went and grabbed the new = user-ppp sources from brian's page and compiled them and tried the same = thing with the new user-ppp 2.26 and had the same results, just it = trying to reconnect over and over again getting that same log as posted = above. Here are my ppp.conf and options files: /etc/ppp/options default: set device PPPoE:mx0 set mru 1492 set mtu 1492 deny pap accept chap set speed sync set cd 5 set authname XXXX@bellsouth.net set authkey xxxxxx enable lqr set redial 0 0 set dial add 0 0 HISADDR ppp.conf looks the same way too, not sure if that was correct or not, = but it was working for quite sometime greatly.. :) I also had = underneath all the options in default an, interactive: section that has = the same information listed as under the default heading. Anyways, if = anybody could help me out and figure out why this stopped connecting it = would be greatly appreciated. It may be bellsouth's side, and it may be = something that I compiled wrong on my side after the cvsup by doing the = make world, that I am not sure of. I am hoping that some of these logs = will let someone get an idea of what is going on so they can possibly = help me on my way to a resolution. It may be something as simple as = editing out the -DNONETGRAPH lines in the Makefile in = /usr/src/usr.sbin/ppp - but I'm not sure what I did the first time = around to make it function correctly. Once again, thanks everybody for = listening and coming together to get this code together. Archie, Brian, = Julian, everyone else, excellent work and thanks from a freebsd user = that can use a PPPoE connection. =20 Matt Thomas Gwarslave@mindspring.com ------=_NextPart_000_005B_01BF57CE.6BEF7D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Fellow Freebsd question readers,
 
       I would like to = open up=20 this plea for help first by thanking brian somers, archie cobb, and = julian=20 elischer for some excellent code, i.e. Netgraph and user-PPP.  This = code=20 definately worked real well.  I had the netgraph and user-ppp = running great=20 together until I cvsup'd one day and did a make world.  I went to = bed, woke=20 up, and there was no connection.   So I started looking = through my=20 logs to see if I could find out what happened.  Here is what my = normal=20 connection looks like - this is using Netgraph from a recent cvsup on a=20 3.4-STABLE build with user-ppp 2.24.  After all my trouble occured = I went=20 to Brian's web page and grabbed his 2.26 user-ppp and compiled it and = still had=20 the same results.  Here is a log of what usually happens when it = connects=20 properly, and I'll also paste my ppp.conf and options file, etc. after a = log of=20 a good connection and then what happens when I try to connect after the=20 cvsup.  I intiate the command ./ppp -nat -ddial default to connect = and it=20 always worked fine, I tried it without the nat flags of course to.  = So here=20 is the good connection:
 
Jan  3 17:22:02 crazytrain ppp[314]: Phase: = Using=20 interface: tun0
Jan  3 17:22:02 crazytrain ppp[314]: Phase: = deflink:=20 Created in closed state
Jan  3 17:22:02 crazytrain ppp[321]: = Phase: PPP=20 Started (ddial mode).
Jan  3 17:22:02 crazytrain ppp[321]: = Phase:=20 bundle: Establish
Jan  3 17:22:02 crazytrain ppp[321]: Phase: = deflink:=20 closed -> opening
Jan  3 17:22:02 crazytrain ppp[321]: = Phase:=20 deflink: Connected!
Jan  3 17:22:02 crazytrain ppp[321]: Phase: = deflink: opening -> dial
Jan  3 17:22:02 crazytrain = ppp[321]: Phase:=20 deflink: dial -> carrier
Jan  3 17:22:03 crazytrain = ppp[321]: Phase:=20 Received NGM_PPPOE_SUCCESS (hook "tun0")
Jan  3 17:22:03 = crazytrain=20 ppp[321]: Phase: deflink: carrier -> login
Jan  3 17:22:03=20 crazytrain ppp[321]: Phase: deflink: login -> lcp
Jan  3 = 17:22:03=20 crazytrain ppp[321]: Phase: bundle: Authenticate
Jan  3 = 17:22:03=20 crazytrain ppp[321]: Phase: deflink: his =3D CHAP 0x05, mine =3D none =
Jan =20 3 17:22:03 crazytrain ppp[321]: Phase: Chap Input: CHALLENGE (16 bytes = from=20 WDSTGACR_IFITL)
Jan  3 17:22:03 crazytrain ppp[321]: Phase: = Chap=20 Output: RESPONSE (XXXX@bellsouth.net)=20
Jan  3 17:22:04 crazytrain ppp[321]: Phase: Chap Input: SUCCESS =
Jan  3 17:22:04 crazytrain ppp[321]: Phase: deflink: lcp -> = open=20
Jan  3 17:22:04 crazytrain ppp[321]: Phase: bundle: Network=20
Jan  3 17:22:04 crazytrain ppp[321]: Warning: Add route failed: = default=20 already exists
 
 
This is normally what happens and when doing an = ifconfig=20 afterwards you could see the ip address bound to tun0 and where it was = going,=20 I.E. 0.0.0.0 ---> 1.1.1.1
But when I woke up the next day and started = inspecting my logs=20 I found this:
 
Jan  4 13:51:25 crazytrain ppp[2068]: Phase: = deflink:=20 hangup -> opening
Jan  4 13:54:18 crazytrain ppp[291]: = Phase: Using=20 interface: tun0
Jan  4 13:54:18 crazytrain ppp[291]: Phase: = deflink:=20 Created in closed state
Jan  4 13:54:18 crazytrain ppp[293]: = Phase: PPP=20 Started (ddial mode).
Jan  4 13:54:18 crazytrain ppp[293]: = Phase:=20 bundle: Establish
Jan  4 13:54:18 crazytrain ppp[293]: Phase: = deflink:=20 closed -> opening
Jan  4 13:54:18 crazytrain ppp[293]: = Phase:=20 deflink: Connected!
Jan  4 13:54:18 crazytrain ppp[293]: Phase: = deflink: opening -> dial
Jan  4 13:54:18 crazytrain = ppp[293]: Phase:=20 deflink: dial -> carrier
Jan  4 13:54:23 crazytrain = ppp[293]: Phase:=20 deflink: Disconnected!
Jan  4 13:54:23 crazytrain ppp[293]: = Phase:=20 deflink: carrier -> hangup
Jan  4 13:54:23 crazytrain = ppp[293]:=20 Phase: deflink: Connect time: 5 secs: 0 octets in, 0 octets out =
Jan  4=20 13:54:23 crazytrain ppp[293]: Phase:  total 0 bytes/sec, peak 0 = bytes/sec=20 on Tue Jan  4 13:54:23 2000
 
This is what started occuring the morning = after.  This=20 could mean that my connection is just down and something is messed on=20 bellsouth's end, or possibly that Netgraph isn't getting the call from = ppp, or=20 netgraph just isn't recieving NGM_PPPOE_SUCCESS from my bellsouth = server. =20 I'm not actually quite sure how it works.  I Have compiled the = netgraph=20 code into the kernel with the options NETGRAPH, options =20 NETGRAPH_PPPOE, and options  NETGRAPH_SOCKET.  Like I stated, = I'm not=20 quite sure how this NGM_PPPOE_SUCCESS hook works.. if it is recieved = from=20 bellsouth and their server, or recieved from ppp and it is ppp that = isn't=20 calling it.  If user-ppp is the problem in why it isn't grabbing = that=20 NGM_PPPOE_SUCCESS, how can I fix this?  I see that there is a = -DNONETGRAPH=20 command in user-ppp that could be the cause of this, but I'm not quite = sure of=20 the legistics.  I also went and grabbed the new user-ppp sources = from=20 brian's page and compiled them and tried the same thing with the new = user-ppp=20 2.26 and had the same results, just it trying to reconnect over and over = again=20 getting that same log as posted above.  Here are my ppp.conf and = options=20 files:
 
/etc/ppp/options
 
default:
 set device PPPoE:mx0
 set = mru=20 1492
 set mtu 1492
 deny pap
 accept = chap
 set=20 speed sync
 set cd 5
 set authname XXXX@bellsouth.net
&= nbsp;set=20 authkey xxxxxx
 enable lqr
 set redial 0 = 0
 set=20 dial
 add 0 0 HISADDR
 
ppp.conf looks the same way too, not sure if that = was correct=20 or not, but it was working for quite sometime greatly.. :)  I also = had=20 underneath all the options in default an, interactive: section that has = the same=20 information listed as under the default heading.  Anyways, if = anybody could=20 help me out and figure out why this stopped connecting it would be = greatly=20 appreciated.  It may be bellsouth's side, and it may be something = that I=20 compiled wrong on my side after the cvsup by doing the make world, that = I am not=20 sure of.  I am hoping that some of these logs will let someone get = an idea=20 of what is going on so they can possibly help me on my way to a=20 resolution.    It may be something as simple as editing = out the=20 -DNONETGRAPH lines in the Makefile in /usr/src/usr.sbin/ppp - but I'm = not sure=20 what I did the first time around to make it function correctly.  = Once=20 again, thanks everybody for listening and coming together to get this = code=20 together.  Archie, Brian, Julian, everyone else, excellent work and = thanks=20 from a freebsd user that can use a PPPoE connection. 
 
Matt Thomas
Gwarslave@mindspring.com
 
 
------=_NextPart_000_005B_01BF57CE.6BEF7D40-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message