atom feed18 messages in org.freebsd.freebsd-netRe: reading routing table
FromSent OnAttachments
Debarshi RaySep 1, 2008 5:06 am 
Bruce M. SimpsonSep 1, 2008 5:53 am 
Bruce M. SimpsonSep 1, 2008 6:01 am 
Debarshi RaySep 1, 2008 6:18 am 
Debarshi RaySep 1, 2008 6:23 am 
Bruce M. SimpsonSep 1, 2008 6:34 am 
Debarshi RaySep 1, 2008 8:15 am 
Julian ElischerSep 2, 2008 12:00 am 
Debarshi RaySep 2, 2008 12:17 am 
Robert WatsonSep 2, 2008 2:19 am 
Luigi RizzoSep 2, 2008 3:48 am 
Bruce M. SimpsonSep 2, 2008 7:55 am 
Robert WatsonSep 2, 2008 2:01 pm 
Luigi RizzoSep 2, 2008 2:28 pm 
Julian ElischerSep 2, 2008 3:10 pm 
Debarshi RaySep 18, 2008 1:01 am 
Bruce M. SimpsonSep 18, 2008 2:59 pm 
Julian ElischerSep 18, 2008 4:57 pm 
Subject:Re: reading routing table
From:Robert Watson (rwat@FreeBSD.org)
Date:Sep 2, 2008 2:19:32 am
List:org.freebsd.freebsd-net

On Tue, 2 Sep 2008, Debarshi Ray wrote:

unfortunatly netstat -rn uses /dev/kmem

Yes. I also found that FreeBSD's route(8) implementation does not have an equivalent of 'netstat -r'. NetBSD and GNU/Linux implementations have such an option. Any reason for this? Is it because you did not want to muck with /dev/kmem in route(8) and wanted it to work with PF_ROUTE only? I have not yet gone through NetBSD's route(8) code though.

Usually the "reason" for things like this is that no one has written the code to do otherwise :-). PF_ROUTE is probably not a good mechanism for any bulk data transfer due to the constraints of being a datagram socket, although doing it via an interated dump rather than a simple dump operation would probably work. Sysctl is generally a better interface for monitoring for various reasona, although it also has limitations. Maintaining historic kmem support is important, since it is also the code used for interpreting core dumps, and we don't want to lose support for that.

Robert N M Watson Computer Laboratory University of Cambridge