>>>>> "Michal" == Michal Ostrowski <mostrows@xxxxxxxxxxxxxxxxx> writes:
Michal> Henner Eisen writes:
>> ppp connections would be set up like this:
>>
>> - pppd creates socket corresponding to ppp carrier, e.g. PPP
>> over ethernet: s = socket(PF_PACKET,SOCK_PACKET,ETH_P_PPPOE);
Michal> The problem here is that you need to use bind and/or
Michal> connect (regardless of where negotiation is performed),
Michal> and you need to do with a sockaddr that is not compatible
Michal> with PF_PACKET. It is this need for an addressing scheme
Michal> which is unique to PPPoE that made me go with PF_PPPOE.
Michal> Modifying PF_PACKET to make exceptions and support
Michal> "protocols" that have different addressing schemes would
Michal> be rather grotesque.
Yes, I agree. I think I have to clarify my arguments, because I never
wanted to suggest hacking PF_PACKET in such a way:
The design in mind was the following:
:
user space :
:
:
+------+ : +-------+ ppp protocol
| pppd | - /dev/ppp - | ppp | proper
+------+ : +-------+
| : |
| : |
socket | : +-----------+ ppp over X
...interface =========== .....: | encap X | frame encapsulation
| +-----------+ protocol
| |
+----------+------------+
|
|
+-----------------+
| carrier |
| protocol |
| PF_X |
+-----------------+ kernel space
`Carrier protocol' denotes the protocol that carries the (encapsulated)
ppp packets (not some low/physical layer stuff).
With the generic ppp module in 2.3.x, we've got already the ppp protocol
module. With the various PF_X as implemented in /usr/src/linux/net/*
we've also got the implementation of several carrier protocols as well.
What's missing is a generic method of processing the ppp frame
encapsulation protocol contents and a generic mechanism to connect such
an encapsulation protocol engine to the upper layer of the carrier protocol.
For all socket of type SOCK_PACKET and SOCK_SEQ_PACKET, the latter
can probably be implementeted in a generic manner. (Most SOCK_PACKET
and SOCK_SEQPACKET implementations share a single poll method,
and it seems that all sockets which use
/usr/src/linux/net/core/datagram.c::datagram_poll() could be
attached to a ppp frame encapsulation protocol generically as well).
There is nothing special about PF_PACKET. PF_PACKET would be treated in
the same (generic) manner as any other carrier protocol family.
Now my PF_PACKET socket example was not a request for hacking into
PF_PACKET for supporting a protocol which SOCK_PACKET was not designed for.
All the PPPoE specific stuff would reside in the ppp frame encpasulation
protocol.
It was really an example that even PPPoE fits the
'ppp over socket' paradigm very well by using the low layer PF_PACKET
protocol family. Of course, as PPPoE uses a more complex encapsulation then
most other ppp flavors. But this only implies that implementing
the PPPoE frame encapsulation requires more work. It does not require any
dirty hacks to PF_PACKET.
Michal> with PF_PACKET. It is this need for an addressing scheme
Michal> which is unique to PPPoE that made me go with PF_PPPOE.
Yes, good point, you've conviced me! (But only as far as PPPeE is
concerned :-). As PPPoE frame encapsulation requires
session-id-based [de]multiplexing, it is rasonnable to create a new
protocol family. Providing different sockets for different sessions
also preserves the point-to-point sematics which ppp assumes.
Note that this still fits in the generic 'ppp over socket' paradigm.
The only difference is where the ppp frame encapsulation is processed.
With PF_PACKET, PPPoE requires to implement a non-zero ppp frame
encapsulation protocol engine, but can use an existing protocol family.
With PF_PPPOE, it requires implementing that new protocol family
which does the encapsulation stuff by itsself. The 'encap X' box becomes
a zero layer in that case.
I'm still very uncomforatable with the idea of creating a new protocol
family for every existing protocol serving as a carrier connection.
The frame encapsulation is essentially a zero layer for most protocols.
It does not provide any service to the ppp layer proper. The reason
why they exist at all was to maintain compatibility with other
(non-ppp) protocols. E.g. sync ppp (async as well) encapsulation prepends an
HDLC address and UI control field to the ppp frame. This allows to use
existing transmission hardware (and to re-use software) which relies on the
presence of HDLC headers. From ppp's point of view, this frame encapsulation
protocol is logically a zero layer. Thus, ppp peers ususally negotiate
to compress (remove) those headers if they know that the headers are not
needed for reasons outside the scope of ppp (and the logical zero layer
layer becomes a physical one).
My summary:
PF_PPPOE: o.k.
PF_PPPOx: not o.k. (only o.k. if multiplexing above an existing carrier
protocol is needed. Maybe the latter case could be
handled by a generic PF_PPPOX for every such protocol).
Henner
|