> I have chosen to use the sysctl interface for my initial
> implementation. So far this is working out well, I am reading 4 variables
> about each connection via sysctl. Is sysctl the right way to get this
> information?
Yes, last time I looked at the Web100 project, I thought sysctl w
> I have been looking on this delta. I had been stuck on the handlers of the
> "user requests" ( xxx_usrreq() ) that are deeply different between NetBSD
> and FreeBSD.
The old pr_usrreq routine used to be a big switch statement on the second
parameter, the request type. Now, each case is a
On Mon, 10 Feb 2003, Martin Stiemerling wrote:
> See man getifaddrs:
>
>
>http://www.freebsd.org/cgi/man.cgi?query=getifaddrs&sektion=3&apropos=0&manpath=FreeBSD+4.7-RELEASE
>
> You can obtain l2 addresses with this system call.
I was not aware of the "l2 addresses" limit(?), and the man page do
Le Jeudi 20 Février 2003 00:00, Joseph T. Klein a écrit :
> So how great a delta exists between NetBSD and FreeBSD?
> Can't the NetBSD code be used as a starting point?
I have been looking on this delta. I had been stuck on the handlers of the
"user requests" ( xxx_usrreq() ) that are deeply diff
> It seems like
> several variables are locked for the vast majority of the time in
> tcp_input().
inp, in particular, should be locked the entire time in tcp_input, so you
are always going to have your "could sleep with lock held" problem unless
you add M_NOWAIT to your calls to malloc() or
I have been spending quite a lot of time rooting through the TCP
implementation recently due to my efforts with Web100.
I have been trying to understand the locking strategy in the TCP portions of
the code. I have primarily been looking at tcp_input.c. It seems like
several variables a
So how great a delta exists between NetBSD and FreeBSD?
Can't the NetBSD code be used as a starting point?
Any written guidelines on how interface at the kernel?
Am I just stuck picking through the net* code?
BTW - The corporate IS guys run adelphia.com. They don't listen
to us. We just work here
> Any company which is going to have to modify an operating system to run
> on their routers who ignores an operating system with a reputable network
> stack merely because it lacks in-tree support for a particular protocol
> isn't worth hte money.
I am afraid it is not that simple. By using as m
< said:
> What is involved?
A huge amount of work: converting the ancient netiso code to use
modern kernel programming interfaces, figuring out MP/MT locking,
adding the netiso support back to the protocol-independent parts of
the kernel, fixing all the warnings, translating all of the anti-DoS
c
What is involved?
On Wednesday, February 19, 2003, at 04:28 PM, Garrett Wollman wrote:
< said:
On the other hand the NetBSD folks don't see it as dead weight
Are you volunteering to do all the work (or pay someone else to do
so)?
-GAWollman
--
Joseph T. Klein
Senior Network Engineer/Pee
< said:
> On the other hand the NetBSD folks don't see it as dead weight
Are you volunteering to do all the work (or pay someone else to do
so)?
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
* De: Petri Helenius <[EMAIL PROTECTED]> [ Data: 2003-02-19 ]
[ Subjecte: Re: support of iso networking ]
> > On the other hand the NetBSD folks don't see it as dead weight
> > and systems that may need to talk with core routers that use
> > IS-IS end up on other platforms.
> >
> > Perhaps
I am funded to do the FreeBSD implementation of the Web100[1] kernel
intrumentation set (KIS) and already have a small portion of the KIS
implemented. I have several questions and since I have very little
kernel programming experience I would appreciate any input that the more
experienc
> On the other hand the NetBSD folks don't see it as dead weight
> and systems that may need to talk with core routers that use
> IS-IS end up on other platforms.
>
> Perhaps this is why Arbor uses NetBSD.
>
It should be noted that hardly anything qualifies as "dead weight" on operating
system t
On the other hand the NetBSD folks don't see it as dead weight
and systems that may need to talk with core routers that use
IS-IS end up on other platforms.
Perhaps this is why Arbor uses NetBSD.
On Wednesday, February 19, 2003, at 03:13 PM, Garrett Wollman wrote:
< said:
Has anyone done work
< said:
> Has anyone done work to incorporate the ISO networking code
> into FreeBSD? This has been done for NetBSD. It is a required
> component if one wishes to natively support ISO based protocols
> such as IS-IS.
For the limited value that OSI protocols have today, it is a much
better use of
Hi!
I'm trying to make it easier to use NFS from my desktop with amd.
Using the vanilla /etc/amd.map (tried changing vers to 2) and only
modifying one of the arguments to amd from the default provided by
/etc/defaults/rc.conf, I have the amd running as:
amd -a /var/run/.amd -l syslog /hos
On Wednesday 19 February 2003 05:12, Gokul Poduval wrote:
>
> Audsin wrote:
> > Respected Sir
> >
> > I have made some changes to the
> > /usr/kame/kame/kame/sys/netinet6/tcp6_input.c and
> > /usr/kame/kame/kame/netinet6/sys/tcp6_output.c in FreeBSD 4.4 and iam
> > using Kame snap. I have some que
Sir / Madam
I am doing my research on fragmentation avoidance technique for mip6. I am
using FreeBSD4.4 with kame snap and ethereal to capture packets
I have a query regarding the packet length
If i am correct ,
packet length = IPHdr +extHdr+TCPHdr+TCPOpt+Data
=IPHdr+Rout
A Search on google gave me this. I followed the given procedures with
success.
http://www.freeos.com/articles/3827/
Gokul Poduval
http://www.comp.nus.edu.sg/~gokulpod
Audsin wrote:
Respected Sir
I have made some changes to the
/usr/kame/kame/kame/sys/netinet6/tcp6_input.c and
/usr/kame/kame
Respected Sir
I have made some changes to the
/usr/kame/kame/kame/sys/netinet6/tcp6_input.c and
/usr/kame/kame/kame/netinet6/sys/tcp6_output.c in FreeBSD 4.4 and iam
using Kame snap. I have some queries regarding making the changes active.
Can anyone please tell me the procedure to recompile o
Does FreeBSD prioritize traffic based on TOS and or TCP Flags?
It could be my imagination but it looks like PSH flagged tcp
packets go faster through the network than non-PSH flagged.
We have other routers also (Cisco and Nortel) so it might be them.
-- Sten
To Unsubscribe: send mai
Mike Silbersack wrote:
> On Tue, 18 Feb 2003, Terry Lambert wrote:
> > See:
> >
> > http://www.psc.edu/networking/tcp.html
> >
> > The code is an easy port. The TCP Rate Halving is a much better
> > approach to the same problem. Code for that is also there, and is
> > also an easy port.
>
hi, there!
On Wed, Feb 19, 2003 at 08:35:31AM +0100, Vincent Jardin wrote:
> > > I looked at isisd patches for zebra and it seems that they use
> > > bpf even on NetBSD. Do you know any other netiso consumers?
> >
> > btw I have made patches for zebra port that add WITH_ISISD knob.
> > Anybody ou
24 matches
Mail list logo
