On 03/18/11 07:40 AM, James Carlson wrote:
Garrett D'Amore wrote:
On Thu, 2011-03-17 at 17:05 -0700, Erik Nordmark wrote:
On 3/17/11 2:37 PM, River Tarnell wrote:
I believe the fix is for sppp (or sppptun) to mark the packet as IFT_PPP
rather than IFT_ETHER. This would cause ip_mdata_to_mhi to ignore it
entirely, and since at this point the PPPoE frame cannot be multicast or
broadcast, there would be no loss of functionality.
Yes, a driver which doesn't use Ethernet headers shouldn't claim to be
an Ethernet in the dl_info_ack.
Erik
Agreed 100%. What we see is this *appears* to be done for the benefit
of snoop, but I'd love to hear from Jim Carlson or someone else familiar
with the code.
Sigh.
Yes, it came that way from the open source, and we discussed changing it
-- at some length.
The reason the open source code was originally written that way was that
the Solaris IP stack had no decent support for point-to-point links. It
generally assumed everything was either Ethernet or FDDI. And the
assumptions ran all over the system. For instance, snoop assumed every
DLPI device was Ethernet-like and would drop core without that header in
place. And there were several system daemons that had built in
knowledge of DLPI. Faking it was easier than rewriting the world --
especially when the authors of the PPP code didn't have access to the
Solaris source and couldn't fix its problems.
Since PPP is in fact a datalink type, we (the Vector project team that
ported in ANU PPP) attempted to do the Right Thing and get DL_PPP
through the Open Group as an addition to DLPI. I think our
representative at the time was Andrew Gollan. We failed to get
consensus because IBM's engineers claimed that PPP wasn't a datalink,
and that we should be using DL_ASYNC or something else to represent the
underlying hardware type. We disagreed, but it died there.
(For what it's worth, the confusion between datalink type and hardware
type is rife within DLPI. The DL_* values include many never-used
options for different off-brand flavors of Ethernet.)
Anyway, I ran out of steam on this. With 20/20 hindsight, I should have
just implemented the right thing and ignored the nonsense going on at
that almost perfectly useless standards group -- and the nearly certain
static I would have gotten from our internal review boards. Ignoring a
standards body is no small thing, but sometimes necessary. And I admit
I completely chickened out.
Likewise, I remember those discussions and have the same recollection.
The context is a bit different now, as we've defined a number of private
DLPI datalink-types in order to seamlessly implement other "datalinks"
such as IP tunnels without having to argue DLPI philosophy with other
vendors (see DL_IPV4 and DL_IPv6). A DL_PPP could simply be defined in
that private range.
My gut instinct here is it would be better to define DL_PPP and have the
PPP use it. Modifying snoop to support such would take two additional
lines in a table in snoop_ether.c, since we already have support
interpreting PPP headers (for PPPoE) in the code...
What are we missing?
Nothing but the history. Yes, having real-life support for
point-to-point links was one of the things I wanted to work on when I
was at Sun, but never got the chance because there was always some
crisis that was higher priority. ;-}
Indeed.
(I think others who have looked at it have felt that doing this wasn't
as important as rewriting "sppp" to use the MAC layer. I have no real
opinion about that. But the last time I looked at that code, it was
also very Ethernet-centric and would have required a good bit of work.
Perhaps Clearview and others have fixed this.)
Yes, I did a bit of work as part of Clearview to implement a pluggable
MAC-type framework in GLDv3 to facilitate the definition of new
MAC-types. This turned out to be quite useful in easily introducing new
WiFi and Infiniband drivers.
If there's someone now with the time to make DL_PPP come to life, then
please do change it.
This could be done in two stages. Making sppp use DL_PPP (and making
changes to consumers of the driver to understand DL_PPP) could be done
independently from migrating the driver to GLDv3. I say that because
the cost of the former is likely less than the latter, and the latter
isn't necessarily required to address the immediate issues brought up
here. The GLDv3 work goes beyond simply creating a PPP MAC-type plugin
for the MAC layer. The use of STREAMS is heavily baked in to the kernel
PPP implementation and the plumbing of PPP links, and investigation
needs to be done to see how much of the use of STREAMS can be replaced
or adapted to interact cleanly with GLDv3. My opinion (not having
scoped the work in detail) is that this would be a small project.
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
