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 08:01:33 +0000
At 17:06 -0500 30/1/02, email@hidden wrote:
I've been digging through all this documentation on TPI, DLPI, sample
code, etc., to finish the design and implementation specifics for
enabling our USB Ethernet driver (which is really ATM for ADSL) to
support PPPoE and PPPoA. A big source of information is the OT Advanced
Client Programming. However, we just had a design meeting and the
following was brought up. What about taking the route of implementing
the PPPoE and PPPoA support as a modem driver. The ethernet framing
required in the PPPoE case isn't a big deal - but this would eliminate
the whole TPI to DLPI translation that has to be done. Am I missing
something - or would this approach be a much simpler solution?
You can do it this way but, as I mentioned in OTACP, it's not the
approach I recommend. The problem with doing a modem driver (that is
a classic serial driver registered with CRM) is that your driver will
be visible to non-PPP clients. You don't want users opening up
Z-Term and trying to talk to your port because it's not going to work.
TPI to DLPI conversion is actually not that hard. Remember that
you're talking connection-oriented TPI out the top and connectionless
DLPI out the bottom, so you don't need pass through the connection
semantics. In fact, if you look at the list of TPI messages that you
might get from above, the list you have to handle is pretty small,
and many of them are degenerate cases.
o T_BIND_REQ -- Have to handle this, but it's a degenerate case. You
don't need to support listening, and all serial addresses are empty.
o T_CONN_REQ -- Have to handle this.
o T_CONN_RES -- Not relevant because you don't support incoming connections.
o T_DATA_REQ -- Yes. You probably should use a custom CCL to
minimise the amount of AT command set parsing that you have to handle.
o T_DISCON_REQ -- Yes.
o T_EXDATA_REQ -- No, because serial does not support expedited data.
o T_INFO_REQ -- Yes.
o T_OPTMGMT_REQ -- Yes.
o T_ORDREL_REQ -- No, because serial does not support orderly disconnect.
o T_UNBIND_REQ -- Yes, but trivial.
o T_UNITDATA_REQ -- No, because serial is only connection oriented.
o T_ADDR_REQ -- No, because serial does not support addresses.
o T_UREQUEST_REQ,
T_REQUEST_REQ,
T_UREPLY_REQ,
T_REPLY_REQ,
T_CANCELREQUEST_REQ,
T_CANCELREPLY_REQ -- No, because serial does not support transactions.
o T_REGNAME_REQ,
T_DELNAME_REQ,
T_LKUPNAME_REQ -- No, because serial does not support name registration.
The hard part about doing PPPoE is undoing PPPoSerial framing on
outgoing packets and then redoing it on incoming packets. You have
to do this regardless of whether you implement a classic serial
driver or a STREAMS driver (unless you take advantage of
kOTSerialFramingPPP, which I think was introduced in 9.1).
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware