arm yourself with RFC1661

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

arm yourself with RFC1661

Peter J. Philipp
Hi,

In this link you complained about kernel pppoe not working:

http://marc.theaimsgroup.com/?l=openbsd-misc&m=116131360627151&w=2

but you're only mentioning that it's "not working".  Can you be a little
bit more specific?  What isn't working?  The PPPoE exchange or the PPP
exchange/authentication?

Take a look at one of my posts to openbsd-tech:

http://marc.theaimsgroup.com/?l=openbsd-tech&m=116082407306482&w=2

Notice lots of packet dumps.  That's what people are looking for so they
can actually see "your" problem and not just guess it.

Let me explain to you how PPPoE works..

First it sends a PADI packet, this is a "Discovery" packet it intitially looks
for PPPoE capable Network Access Servers (NAS).
The NAS replies with a PADO (Offer), there may be multiple NAS's on the same
link offering but for simplicities sake it's only one (your provider).
Then PPPoE sends a PADR (Session request) to the NAS asking for a PPP session
which then replies with a PADS (session confirmation).  This entire exchange
is done with Ethernet frames where the ethernet ident field is set to
0x8863, when the session is confirmed the session packets continue with an
ID of 0x8864 which encapsulate the PPP packets.  All this can be tracked with
RFC 2516.

Now on to the PPP exchange, first PPP starts up with a request for
configuration with Link Control Packets (LCP), things such as MRU/MTU,
Authentication mechanism and other things such as a MAGIC are exchanged.
Once the requested and offered fields are ACK'ed (acknowledged) the
exchange continues with authentication, it sends a PAP or CHAP packet
which then gets confirmed.  At this point only the IP needs to be exchanged
through the IPCP protocol, and once that is finished PPP will continue with
encapsulating IP packets.  This is detailed with RFC 1661.

So you can see by my post to openbsd-tech a bunch of debugging.  One is done
with tcpdump I usually set it with flags '-v -n -i rl1 -e -X -s 200' where
rl1 is my PPPoE interface.  This does a hexdump with appropriate header
interpretation of whatever goes over the ethernet.

You can also set debugging on the pppoe link itself, you do this with:

        ifconfig pppoe0 debug

This logs to kernel log and thus will show up in your syslog messages file.
After turning debugging on your box may feel sluggish due to the intense
writing to log files.  To turn debugging off you type:

        ifconfig pppoe0 -debug

So why don't you do this, while at the same time using RFC1661 as a chart
to understand the PPP exchange, and you'll then see what's going on and
you'll be more informed on exactly what isn't working and can focus on
that instead of saying "it just doesn't work".

Where are the rfc's at?  http://www.rfc-editor.org

Have a good Weekend,

-peter

--
Here my ticker tape .signature #### My name is Peter Philipp #### lynx -dump "http://en.wikipedia.org/w/index.php?title=Pufferfish&oldid=20768394" | sed -n 131,137p #### http://centroid.eu #### So long and thanks for all the fish!!!