[openbeosnetteam] Re: PPP & so on...

Well, I have code for modules ppp and serial_ppp. ppoe should be it's own
module as well. I was going to tackle it next week, but please feel free to
write one :)

There's hook code already in place for calling pppoe on inbound packets in
place in ethernet.c. output shouldn't be hard as you just need to hook the
right input/output and alter the mbuf as you need then pass it on. Should be
easy enough :)

Of course so far my serial writes don't go anywhere :( I'm going to check
the fcs calc I do but it looks about right!

david

----- Original Message -----
From: "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>
To: <openbeosnetteam@xxxxxxxxxxxxx>
Sent: Saturday, May 18, 2002 7:44 PM
Subject: [openbeosnetteam] Re: PPP & so on...


> > > > OK, having read through some of the RFC's, here's what I propose
> > > > we
> > > > do...
> > > >
> > > > I am concerned that we'll be unable to test PPP much without
> > > > suitably
> > > > easy
> > > > test environments beyond a few people who happen to have PPP
> > > > setups.
> > >
> > > Sounds like a decent idea. Of course, a substantial number of
> > > people
> > > have PPP setups, like me, for instance.
> > > > So, we start by adding a serial line module. We should then be
> > > > able
> > > > to write
> > > > a ppp module that can do ppp over serial (RS-232) connections.
> > > > This
> > > > should
> > > > make testing easier.
> > >
> > > Actually, it's a lot easier to start with PPPoE. It requires no
> > > complicated encapsulation, I use, and have code for it. I also have
> > > HDLC code, but (1) it's less robust, and (2) HDLC is a hell of a
> > > lot
> > > more complicated, and I think we should start with the simplest
> > > case
> > > first.
> >
> > True, and PPPoE support will sort of start appearing...
>
> Sounds good :)
>
> > > > Then we do the ppp module, which will require an LCP, IPCP and
> > > > CHAP,
> > > > PAP
> > > > modules to be written.
> > >
> > > Yes.
> > >
> > > > I also propose that we add a pppoe module as this should be
> > > > relatively
> > > > straightforward to do. I see a problem in trying to do too much
> > > > at
> > > > once as
> > > > bugs will creep in and be worked around in one module or another,
> > > > so
> > > > we take
> > > > it a step at a time.
> > > >
> > > > 1. Anyone volunteer to do a simple module that can open a serial
> > > > device and
> > > > read/write to it?
> > > > 2. we do basic PPP encapsulation code.
> > > > 3. we do LCP module
> > > > 4. we add state control to ppp module
> > >
> > > State control is part of LCP.
> >
> > Hmm, well yes and no. PPP needs to know about the state whereas it
> > gets
> > changed by LCP...
>
> Of course, you could let LCP know about the state, and then call things
> itself, but that distinction makes sense.
>
> > > > 5. we add chap module
> > > > 6. we add authentication handling to ppp module
> > >
> > > CHAP *is* a form of authentication. Why are we adding auth *after*
> > > CHAP? Also, where is PAP in all of this? Very, very few services
> > > use
> > > CHAP, you know, so I'm not sure this should be an immediate
> > > priority.
> > > (It's easy enough to do, at least with MD5 CHAP, but PAP is still
> > > infinitely more common)
> >
> > Yes, I mean PAP and CHAP. Why CHAP? A lot of people want it (or at
> > least
> > most people who email want it).
> >
> > The reason is we add the module, then we go back and add hooks to use
> > it. I
> > think it'll be possible to test the PPP stuff outside the server and
> > that's
> > what I intend to do. I don't want to hook into the auth modules until
> > we're
> > sure they work.
>
> Ok, cool. I had thought you didn't intend you do PAP, which would have
> been colossally stupid :P. I think I will hack the ethernet module to
> start playing with PPPoE, and begin building a PPP stack on top of that
> this weekend.
> -Nathan
>
> --
> Fortune Cookie Says:
>
> How come wrong numbers are never busy?
>
>
>

Other related posts: