Subject: Re: Sample (but possibly useful) LKM: fake Ethernet device
To: Manuel Bouyer <bouyer@antioche.eu.org>
From: Neil Ludban <nludban@columbus.rr.com>
List: tech-kern
Date: 11/08/2003 17:36:13
Manuel Bouyer wrote:
> On Fri, Nov 07, 2003 at 05:36:32PM -0500, Neil Ludban wrote:
> 
>>I've done some hacking on tun to support this.  Reading the character
>>device with hexdump(1) was showing correct packets (ping from another
>>window), then the project got sidelined by real work before I could test
>>writes.  I think BPF was working as well.
>>
>>Several options if anybody wants to see this:
>>1) ask and I'll forward source files (from 1.6W)
>>2) I can rename and simplify into an ethernet only version
>>3) take more time and figure out how to rewrite as a generic tun
> 
> 
> Well, tun(4) is probably the right place to put it.
> 
> 
>>The hacked version:
>>- uses minor number to determine if new clone type is IP or ethernet
> 
> 
> I think this should be done from the TUNSLMODE ioctl, or maybe with the
> ifconfig link* flags.

Do you have any examples where it would be correct or easier for the
application to be doing this configuration?  I've always thought of
it as administrative setup, so ifconfig would be used to create the
clone, set the media, and add routes (or brconfig); ifconfig doesn't
support TUNSLMODE.

The application should have a way of confirming the media type (and
might be required to do so to prevent accidents?).

>>- doesn't require super-user privileges (uses device permissions)
> 
> 
> I don't see any reasons to restrict it to super-user.
> Does anyone know why the current tun device restricts access to super-user ?
> 
> 
>>- doesn't delete routes when device is closed
> 
> 
> It probably shouldn't. We just need to turn the interface down.

IMHO the character device is like the wire between a physical NIC and
the switch.  A closed device would be equivalent to no carrier link
status.  It's easy enough to add options to be compatible with the
current tun behaviour.

>>- removed support for ALTQ
> 
> 
> Why ?
> 

IIRC, tun_start was conditionally compiled in only when ALTQ support
was compiled in, and ether_output needed it.  It was easier to remove
than to hope it still worked correctly after modification.  I'll put it
back in when I'm finished.

-Neil