The following reply was made to PR kern/116837; it has been noted by GNATS.
From: Bob Van Zant <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Subject: Re: kern/116837: [tun] [panic] [patch] ifconfig tunX destroy: panic
Date: Thu, 24 Jan 2008 12:40:19 +0530
I applied the patch in the prior com
On Wed, 23 Jan 2008, Andre Oppermann wrote:
OTOH the enforcement of this rule wasn't really there before and it
may be argued that we've got a POLA violation here. A careful reading
That's exactly the point. We were not enforcing timestamps since...
whenever the RFC1323 code went in. Then
Did you talk to the original submitter? Note that FreeBSD's TCP stack
is for use in servers and is not intending as a validating TCP stack.
If you would like it to serve as such you would better served by
tracking down the ANVL tests that FreeBSD fails. Also note that there
is no MUST in the follow
Yousif Hassan wrote:
ifwatchd has not been ported to FreeBSD - does FreeBSD have anything
similar?
Try ports/net/ifstated (from OpenBSD).
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscrib
On Wed, Jan 23, 2008 at 04:50:22PM -0500, Yousif Hassan wrote:
> Net-gurus:
>
> I hope this is the right list to write to regarding this question (feel
> free to redirect me to ports@ if that sounds more appropriate).
>
> I'm looking for a facility to automatically detect network interface
> carr
Net-gurus:
I hope this is the right list to write to regarding this question (feel
free to redirect me to ports@ if that sounds more appropriate).
I'm looking for a facility to automatically detect network interface
carrier state changes (a network cable gets plugged/unplugged; a
laptop's wireles
xingang shi wrote:
One of André Oppermann's paper memtioned that there will be a new routing
table lookup algorithm in FreeBSD 7,
Anyone knows is there any document about this algorithm? Or which part of
the src code is for this function.
I haven't implemented the new routing table lookup code
Mike Silbersack wrote:
silby 2007-11-20 06:56:04 UTC
FreeBSD src repository
Modified files:
sys/netinet tcp_syncache.c
Log:
Comment out the syncache's test which ensures that hosts which negotiate TCP
timestamps in the initial SYN packet actually use them in the r
Synopsis: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000
Responsible-Changed-From-To: freebsd-net->marius
Responsible-Changed-By: marius
Responsible-Changed-When: Wed Jan 23 21:53:19 UTC 2008
Responsible-Changed-Why:
grab
http://www.freebsd.org/cgi/query-pr.cgi?pr=112654
___
Howdy. Looks like SO_LINGER is broken on loopback. Here's the test
case:
0. Install memcached (databases/memcached)
1. Download test_linger.c: fetch
http://sean.chittenden.org/pubfiles/freebsd/test_linger.c
2. Compile: gcc test_linger.c -o test_linger
3. Fire up memcached in a ne
The following reply was made to PR kern/112654; it has been noted by GNATS.
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a
Netfinity 5000
Date: Wed, 23 Jan 2008 16:47:23 +0100
BINGO
Stephen Clark wrote:
Chuck Swiger wrote:
On Jan 22, 2008, at 1:44 PM, Stephen Clark wrote:
does anyone have a program that uses the divert socket to duplicate
an incoming packet so it can be
sent to another address.
Well, I assume you could start with the ipfw "tee" directive and
/usr/src/s
Hi,
If seen a couple of complaints about the message below. I have found the issue
in ypxfr function ypxfrd_get_map. The timeval struct is initialized with a
timeout of 25 usec. Inside libc this will result in a poll timeout of 0, which
will return immediately raising this error. My question
Chuck Swiger wrote:
On Jan 22, 2008, at 1:44 PM, Stephen Clark wrote:
does anyone have a program that uses the divert socket to duplicate
an incoming packet so it can be
sent to another address.
Well, I assume you could start with the ipfw "tee" directive and
/usr/src/sbin/natd ...?
Thanks
On Tue, Jan 22, 2008 at 03:49:05PM -0800, Jack Vogel wrote:
> On Jan 22, 2008 9:40 AM, Patrick Oeschger <[EMAIL PROTECTED]> wrote:
> > maybe i found two issues which are em(4) related...
> > i tested the 6.3-RELEASE on a appliance which has two on-board SFP slots
> > chipset: i82571eb (serdes with
15 matches
Mail list logo
