Bruce M. Simpson wrote:
Debarshi Ray wrote:
...
I was going through the FreeBSD and NetBSD documentation and the
FreeBSD sources of netstat and route. I was suprised to see that while
NetBSD's route implementation has a 'show' command, FreeBSD does not
offer any such thing. Moreover it seems tha
> 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 wante
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
in the (short so far) thread which i am hijacking, the issue came
out of what is a good mechanism for reading the route table from
the kernel, since FreeBSD currently uses /dev/kmem and this is not
always available/easy to use with dynamically changing data structures.
The routing table is only on
Luigi Rizzo wrote:
do you know if any of the *BSD kernels implements some good mechanism
to access a dynamic kernel data structure (e.g. the routing tree/trie,
or even a list or hash table) without the flaws of the two approaches
i indicate above ?
Hahaha. I ran into an isomorphic problem wi
Joining this conversation as someone who's been wrestling with this issue
for some months:
> > This bug was reported around the release of FreeBSD 7, but does not seem
> > to have made any progress.
> >
> > http://bugzilla.quagga.net/show_bug.cgi?id=420
> >
> > Is this because the sockopt.c.dif
On Tue, 2 Sep 2008, Luigi Rizzo wrote:
The real problem is that these data structures are dynamic and potentially
large, so the following approach (used e.g. in ipfw)
enter kernel;
get shared lock on the structure;
navigate through the structure and make a linearized c
On Tue, Sep 02, 2008 at 10:02:10PM +0100, Robert Watson wrote:
>
> On Tue, 2 Sep 2008, Luigi Rizzo wrote:
>
> >The real problem is that these data structures are dynamic and potentially
> >large, so the following approach (used e.g. in ipfw)
> >
> > enter kernel;
> > get shared lock on t
Hi,
Running:
FreeBSD black 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #0: Wed Jun 18
07:33:20 UTC 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
All the latest ports gnome2 and xfce4, output from gdb analysing the
core says:
--8<-
$ gdb -c avahi-d
Robert Watson wrote:
On Tue, 2 Sep 2008, Luigi Rizzo wrote:
The real problem is that these data structures are dynamic and
potentially large, so the following approach (used e.g. in ipfw)
enter kernel;
get shared lock on the structure;
navigate through the structure and make a li
Old Synopsis: ipv6 does not work on carp interfaces
New Synopsis: [carp] ipv6 does not work on carp interfaces [regression]
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Sep 2 22:37:07 UTC 2008
Responsible-Changed-Why:
Over to
Old Synopsis: Still bridge issues - with L2 protocols such as PPPoE
New Synopsis: [if_bridge] Still bridge issues - with L2 protocols such as PPPoE
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Sep 2 22:46:19 UTC 2008
Responsib
Old Synopsis: Unable to send UDP packet via IPv6 socket to IPv4 mapped address
New Synopsis: [udp] Unable to send UDP packet via IPv6 socket to IPv4 mapped
address
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Sep 3 03:18:48 U
The following reply was made to PR kern/127052; it has been noted by GNATS.
From: Eygene Ryabinkin <[EMAIL PROTECTED]>
To: Helge Oldach <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: kern/127052: Still bridge issues - with L2 protocols such as
PPPoE
Date: Wed, 3
14 matches
Mail list logo
