RE: HEADSUP: arp-v2 has been committed

Right now I am also a bit leaning towards reintroducing
the RTF_LLINFO flag bit. This is mainly due to the recent
discovery of the "route" command issued with the
"-iface/-interface" option, which conflicts with the
way how "arp" and "ndp" is handled in the kernel.

I renamed this flag bit to RTF_LLDATA because only the
"arp" and "ndp" commands need it.

> 
> I didn't want to speak up because I'm no authority in this 
> area and in the end I'm OK with any outcome, but personnaly I 
> find special-casing {NET_RT_FLAGS,0} to retrieve the L2 
> entries a bit odd.
>

As I've indicated previously, a few ports already have the
#ifdef RTF_LLINFO block around the sysctl() setup code. 
Perhaps it's because these ports (such as Wine) run on OS
that does not support RTF_LLINFO (e.g. Linux?) ?

>
> Surely, letting {NET_RT_FLAGS,RTF_LLINFO} 
> return L2 entries is exactly the same to implement, is far 
> more descriptive, is fully backwards compatible and 
> compatible with other sysctl operating systems like the other 
> BSDs and Mac OS X, which helps portability.
> 

I believe all of the affected ports have been updated to 
include the conditional blocks around RTF_LLINFO. So 
there is still a level of compatibility, right ?

>
> AFAIK, the other use of RTF_LLINFO was to filter out L2 
> entries from the entire L2+L3 routing table to obtain just 
> the L3 entries. Because the L2 and L3 table have been 
> separated this filtering isn't needed anymore, but what harm 
> would it do to reintroduce RTF_LLINFO? The filtering code 
> would become a useless no-op, but you'd stay fully 
> compatible, again both backwards and with other operating systems.
> 
> I just think that removing RTF_LLINFO was a bit too 
> aggressive an optimisation with little advantage and too many 
> disadvantages and I'd like to see it return.
> 

I believe examining the impacts of RTF_LLINFO on the ports 
was a good exercise even if we have to rejuvenate it.

I hope we could reach a consensus soon now that we have more 
input from the ports developers.

Please provide your input ...

-- Qing