Date: Tue, 11 Jan 2000 01:28:23 +0000 From: Brian Somers <brian@Awfulhak.org> To: "Corigan" <gwarslave@mindspring.com> Cc: freebsd-net@FreeBSD.ORG, brian@hak.lan.Awfulhak.org Subject: Re: PPP And Netgraph Help.. Message-ID: <200001110128.BAA07242@hak.lan.Awfulhak.org> In-Reply-To: Message from "Corigan" <gwarslave@mindspring.com> of "Thu, 06 Jan 2000 15:22:40 EST." <00cb01bf5883$caa2f320$0200a8c0@zeist.sweb.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
The first thing to make sure about is that ppp isn't compiling with
-DNONEGRAPH on the compile line. If it is, then that's the problem.
In -current and -stable, -DNONEGRAPH is no longer the default. The
archive on my web site will use -DNONEGRAPH if it doesn't see
/usr/include/netgraph/ng_pppoe.h.
Assuming ppp still knows about netgraph, try running tcpdump on the
interface - maybe ``tcpdump -e -i xxx not ip''. You should then see
the PPPoE conversation being performed by the netgraph node. You
could also enable debug logging for more info in the ppp log.
Post these results and we can see if anything's obvious - maybe you
now need a service name in the ``set device'' command.
> Sorry For Posting it in freebsd-net, but I have posted it in
> freebsd-questions and got no answer.. Was hoping maybe julian, archie,
> brian, another PPPoE guru may be able to help me out.. :)
>
> 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
> Jan 3 17:22:02 crazytrain ppp[314]: Phase: deflink: Created in closed state
> Jan 3 17:22:02 crazytrain ppp[321]: Phase: PPP Started (ddial mode).
> Jan 3 17:22:02 crazytrain ppp[321]: Phase: bundle: Establish
> Jan 3 17:22:02 crazytrain ppp[321]: Phase: deflink: closed -> opening
> Jan 3 17:22:02 crazytrain ppp[321]: Phase: deflink: Connected!
> Jan 3 17:22:02 crazytrain ppp[321]: Phase: deflink: opening -> dial
> Jan 3 17:22:02 crazytrain ppp[321]: Phase: deflink: dial -> carrier
> Jan 3 17:22:03 crazytrain ppp[321]: Phase: Received NGM_PPPOE_SUCCESS (hook
> "tun0")
> Jan 3 17:22:03 crazytrain ppp[321]: Phase: deflink: carrier -> login
> Jan 3 17:22:03 crazytrain ppp[321]: Phase: deflink: login -> lcp
> Jan 3 17:22:03 crazytrain ppp[321]: Phase: bundle: Authenticate
> Jan 3 17:22:03 crazytrain ppp[321]: Phase: deflink: his = CHAP 0x05, mine =
> none
> Jan 3 17:22:03 crazytrain ppp[321]: Phase: Chap Input: CHALLENGE (16 bytes
> from WDSTGACR_IFITL)
> Jan 3 17:22:03 crazytrain ppp[321]: Phase: Chap Output: RESPONSE
> (XXXX@bellsouth.net)
> Jan 3 17:22:04 crazytrain ppp[321]: Phase: Chap Input: SUCCESS
> Jan 3 17:22:04 crazytrain ppp[321]: Phase: deflink: lcp -> open
> Jan 3 17:22:04 crazytrain ppp[321]: Phase: bundle: Network
> Jan 3 17:22:04 crazytrain ppp[321]: Warning: Add route failed: default
> already exists
>
>
> 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
> Jan 4 13:54:18 crazytrain ppp[291]: Phase: Using interface: tun0
> Jan 4 13:54:18 crazytrain ppp[291]: Phase: deflink: Created in closed state
> Jan 4 13:54:18 crazytrain ppp[293]: Phase: PPP Started (ddial mode).
> Jan 4 13:54:18 crazytrain ppp[293]: Phase: bundle: Establish
> Jan 4 13:54:18 crazytrain ppp[293]: Phase: deflink: closed -> opening
> Jan 4 13:54:18 crazytrain ppp[293]: Phase: deflink: Connected!
> Jan 4 13:54:18 crazytrain ppp[293]: Phase: deflink: opening -> dial
> Jan 4 13:54:18 crazytrain ppp[293]: Phase: deflink: dial -> carrier
> Jan 4 13:54:23 crazytrain ppp[293]: Phase: deflink: Disconnected!
> Jan 4 13:54:23 crazytrain ppp[293]: Phase: deflink: carrier -> hangup
> Jan 4 13:54:23 crazytrain ppp[293]: Phase: deflink: Connect time: 5 secs: 0
> octets in, 0 octets out
> 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
>
> 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.
>
> Matt Thomas
> Gwarslave@mindspring.com
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>
--
Brian <brian@Awfulhak.org> <brian@FreeBSD.org>
<http://www.Awfulhak.org>; <brian@OpenBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@FreeBSD.org.uk>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001110128.BAA07242>