On Tue, 23 Dec 2008, Tijl Coosemans wrote:
>> No, the output of this command is still the same. NET_RT_DUMP obtains
>> the entire L3 table and filtering for RTF_GATEWAY non-multicast
>> routes have the same semantics. Those flags never apply to L2 entries.
> Thanks for answering my questions. I've
On Saturday 27 December 2008 13:28:42 Gerald Pfeifer wrote:
> On Tue, 23 Dec 2008, Tijl Coosemans wrote:
>>> No, the output of this command is still the same. NET_RT_DUMP
>>> obtains the entire L3 table and filtering for RTF_GATEWAY
>>> non-multicast routes have the same semantics. Those flags neve
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_
Qing Li wrote:
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 ...
reintroduce it with value 0
then te
On 2008-Dec-27 14:54:34 -0800, Julian Elischer wrote:
>Qing Li wrote:
>> I believe examining the impacts of RTF_LLINFO on the ports
>> was a good exercise even if we have to rejuvenate it.
>
>reintroduce it with value 0
And a comment indicating that the definition of RTF_LLINFO is solely
for bac
Julian Elischer wrote:
Qing Li wrote:
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 ...
reintroduce
