Re: tap(4) interface management

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Wed, May 13, 2009 at 03:03:37PM +0100, Iain Hibbert wrote:
> Hi,
>    regarding btpand(8) which uses a tap(4) device to provide Ethernet over
> Bluetooth services, I have been looking at adding some features relating
> to the daemon actively monitoring the interface for various settings
> rather than having them fixed at startup or requiring a config file. Such
> as:
> 
> 1. btpand currently exits in client mode if the connection is lost, but I
>    also wanted it to exit if the interface is marked down locally.
> 
> 2. btpand running as a server registers a service record with the service
>    discovery daemon, including protocols available and subnet masks for
>    IPv4 and IPv6. I want to provide the actual values in use.
> 
> 3. the BNEP protocol has filtering options (mandatory to support) to cut
>    out unwanted ethernet packet types on a limited bandwidth connection.
>    btpand could monitor the address families configured on the tap interface
>    and enable/disable protocols as required.
> 
>   Some of this can be handled as-is with a routing socket (as per attached
> patch) but not quite all as it only notifies changes to the IFF_UP flag
> and interface addresses and I would additionally like to notice changes to
> other flags (IFF_NOARP at least, possibly IFF_LINKn etc later) and the
> interface media settings (which can map to elements in the service
> record).
> 
>   So, I'm thinking of how to get where I'm wanting to be, the options seem
> to be either extending the routing socket to provide additional messages,
> or extending the tap driver to be able to signal changes to its owner.
> 
>   Extending the routing socket is possible although its a global
> interface. A RTM_IFINFO message is currently sent out when interface
> status is changed, but it does contain the entire if_flags field and is
> not only for IFF_UP changes (so, extra messages are not problematic). Its
> fairly simple to emit messages for SIOCSIFFLAGS (as per second attached
> patch) but I haven't found any way to get the media settings this way, it
> would require adding a RTM_MEDIA message type which I haven't looked into.
> 
>   Extending the tap driver would be less invasive but unfortunately the
> tap IO is carried out on a file descriptor so is no way (?) to do out of
> band communication (socket control messages would have been great for
> this), the best I can come up with is to have an ioctl enable (eg) SIGUSR
> to be raised on informational changes and have the daemon check.
> 
> thoughts and suggestions?

I think extending the routing socket isn't a bad idea. This is usefull for
other interfaces than tap, and could be used by other softwares.
Nothing in what you need here looks tap-specific.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--