Re: PPPoE and PPPoA as Modem Driver
Re: PPPoE and PPPoA as Modem Driver
- Subject: Re: PPPoE and PPPoA as Modem Driver
- From: Quinn <email@hidden>
- Date: Thu, 31 Jan 2002 18:31:10 +0000
At 11:55 -0500 31/1/02, email@hidden wrote:
Knowing
that we already have a completed USB Ethernet driver, following the
EthernetShim model, it looks like the quickest route (which is what we
want) to getting PPPoE / PPPoA working is to do a modem driver using the
USB SerialShim library. We already have the code for framing/unframing
serial data from the Windows drivers for this prodcut, and we can easily
add/remove the ethernet framing in the modem driver for the PPPoE case.
This would eliminate any learning curve of TPI and DLPI. I accept that
this might not be the approach you would suggest, but do you see any
other technical reasons why it doesn't sound like a reasonably short way
to get a solution way.
Take a look at the software components in each case, with the new
code that you have to write marked with a *.
Option A Option B
-------- --------
Remote Access Remote Access
| |
OT serial shim TPI to DLPI (*)
| |
USB serial shim USB Ethernet shim
| |
USB driver (*) USB driver
The problem with option A is the double shim business. OT shims to
USB serial which shims to your driver. This can get very confusing
very quickly, especially as each shim is essentially a black box:
there's no easy way to debug the shim's operation because you don't
have source for each shim. I was once called in to debug a problem
with an Apple driver structured like this and it wasn't pretty
Architecturally, option B is cleaner. You have good debugging tap
points, both above and below the USB Ethernet shim, which is the only
code you don't have source for. Also, you have some confidence that
the Ethernet driver as a whole is working, so you get to concentrate
on just the TPI to DLPI bit.
I don't want to imply that option A is impossible. I'm sure it can
be done and, given the number of PPPoE implementations out there, I'm
sure it /has/ been done. It's just that I recommend option B. But
hey, I'm not going to revoke your Mac programming licence if you do
it the other way (-:
It also eliminates the requirement of a network configurator and a
port scanner, right?
Yes. However, given the existance of the QTunnel sample (if you
don't have a copy, I can send one along -- it shows an example of how
the configurator, port scanner, configuration helper library, and
STREAMS module work together), I don't consider this to be a big win.
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware