Re: route(4): Adding ROUTE_MSGFILTER socket option

[Roy Marples <roy%marples.name@localhost>]

On 05/04/2017 12:20, Robert Elz wrote:
>     Date:        Wed, 5 Apr 2017 11:00:35 +0100
>     From:        Roy Marples <roy%marples.name@localhost>
>     Message-ID:  <aafd749a-2883-6aef-568f-fc8b6db26e3b%marples.name@localhost>
> 
>   | Comments welcome!
> 
> Looks mostly good to me, with a caveat, and the same / a similar mechanism
> would also be useful for the mobility socket (which is a clone of the
> routing socket) if we ever add the Mobile IP code - and could probably be
> used for generic raw sockets (aka ping and such) with a very similar
> filter function.
> 
> The one issue I have is that ...
> 
> +	/* If the rtm type is filtered out, return a positive. */
> +	if (!(rop->rocb_msgfilter & (1 << rtm->rtm_type)))
> +		return EEXIST;
> 
> doesn't handle the full range of possible rtm_type values in any kind of
> rational way, and if we define it like this now, there's no good way to
> extend the API if rtm_type >= 32 ever gets defined (which as, if I count
> properly, rtm_type's go up to 21 now, is not beyond belief).

Yes, that is a concern I faced as well when porting it.
Right now I chose the same API, just so I can test and validate it works
the same on both OS's.

Also, when NetBSD started it has 11 types. Now it has 21, so that's an
extra 10 in 22 years, so at a rate of 1 every 2 years.

Strictly speaking, the types are beholden to the version so we could
just bump the version and remove the O (ie old) compat vars and bury
them to keep inside 32-bits. Thus would mean re-working how we handle
compat in rtsock though.

> I don't see a need to do a full select() type variable length bitmask, as
> here the aim is to drop trash - if we don't guarantee in the API spec to
> drop all junk (just to always deliver the requested packets - with perhaps
> some more included just by "accident") then this could be ...

Well yes, but the point of the API is that we don't want them by
accident, so we can stop burning needless CPU time in the client.
If avoiding a variable length bitmask is needed then we just need
something similar to poll as it's more efficient than select.

unsigned char rtfilter[] = { RTM_NEWADDR, RTM_DELADDR };

if (setsockopt(routefd, PF_ROUTE, ROUTE_MSGFILTER,
    &rtfilter, sizeof(rtfilter)) == -1)
	err(1, "setsockopt(ROUTE_MSGFILTER)");

Although we probably want to pick a different name option.
How we store that in the kernel is up to us, but the API now allows for
every possible type.

To clear a filter, I would imagine sending a zero or zero length option
would be sufficient.

Roy