On Fri, Jun 4, 2010 at 11:11 AM, Robert N. M. Watson
<[email protected]> wrote:
>
> On 3 Jun 2010, at 14:09, Ermal Luçi wrote:
>
>> Would it make sense to remove even passing the interface name up and
>> actually send the
>> interface index?
>>
>> That is what we are doing at pfSense and it works quite ok.
>
> I see one important argument for doing this:
>
> - Looking up an interface by number instead of by name has a number of 
> advantages.
> - User programs that already reason about network interfaces by ifindex don't 
> have to take an indirection.
>
> However, it has two important downsides:
>
> - It changes an existing API that a moderate number of applications depend on.
> - Applications that reason about ifnet names now have to take an indirection, 
> which might well mean monitoring routing sockets for interface 
> renames/additions/removals, additional sysctls, etc.
>
> As such, I'm not sure the benefits of replacing the current behavior with the 
> proposed new behavior is worth the cost. An alternative approach might be to 
> add a socket option to set the disposition of the divert socket, defaulting 
> to current behavior but optionally switching to a different interpretation of 
> the sockaddr passed in (i.e., use the ifindex instead when the option is 
> set). Could you say a bit more about why you found this change advantageous 
> in your environment, and whether the socket option approach would be 
> problematic there?

Well the main motivation about it was the limitation on interface name
length that can be stored in sin_zero.

Furthermore speed processing is faster since the interface name does
not have to be reconstructed when diverting a packet.
The patch is here http://tinyurl.com/3a9h5gs

Interface event are not an issue for pfSense architecture since it
controls all the underlying data and i think most of the divert
applications do not care much about interface events apart renaming.
Keeping both options sounds reasonable too.

-- 
Ermal
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "[email protected]"

Reply via email to