[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: tap(4) interface management
On Wed, May 13, 2009 at 03:03:37PM +0100, Iain Hibbert wrote:
> 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
> 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
> 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
Main Index |
Thread Index |