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. > 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. ;-} (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.) If there's someone now with the time to make DL_PPP come to life, then please do change it. -- James Carlson 42.703N 71.076W <carls...@workingcode.com> _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
