Re: ipfilter(4) needs maintainer

2013-04-12 Thread Rui Paulo
On 2013/04/12, at 22:31, Scott Long wrote: > On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: > >> On 2013/04/11, at 13:18, Gleb Smirnoff wrote: >> >>> Lack of maintainer in a near future would lead to bitrot due to changes >>> in other areas of network stack, kernel APIs, etc. This already happ

Re: ipfilter(4) needs maintainer

2013-04-12 Thread John Hixson
On Fri, Apr 12, 2013 at 11:31:09PM -0600, Scott Long wrote: > > On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: > > > On 2013/04/11, at 13:18, Gleb Smirnoff wrote: > > > >> Lack of maintainer in a near future would lead to bitrot due to changes > >> in other areas of network stack, kernel APIs,

Re: ipfilter(4) needs maintainer

2013-04-12 Thread Scott Long
On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: > On 2013/04/11, at 13:18, Gleb Smirnoff wrote: > >> Lack of maintainer in a near future would lead to bitrot due to changes >> in other areas of network stack, kernel APIs, etc. This already happens, >> many changes during 10.0-CURRENT cycle were

Race condition inside if_detach_internal() leads to a crash while running "jail -r"

2013-04-12 Thread suraj sandhu
I am running FreeBsd 8.2 and hitting this panic: kdb_backtrace() at kdb_backtrace+0x3e panic() at panic+0x479 trap_fatal() at trap_fatal+0x4f4 trap() at trap+0x8fe calltrap() at calltrap+0x8 --- trap 0x9, rip = 0x80518f4d, rsp = 0xff805fa1d9e0, rbp = 0xff805fa1da30 --- raw_input()

Re: ipfilter(4) needs maintainer

2013-04-12 Thread Rui Paulo
On 2013/04/11, at 13:18, Gleb Smirnoff wrote: > Lack of maintainer in a near future would lead to bitrot due to changes > in other areas of network stack, kernel APIs, etc. This already happens, > many changes during 10.0-CURRENT cycle were only compile tested wrt > ipfilter. If we fail to find m

Re: bce(4) on the Dell PE 2950

2013-04-12 Thread Peter Wemm
On Fri, Apr 12, 2013 at 1:56 PM, Sean Bruno wrote: > A note from cluster...@freebsd.org > > It looks like there is some amount of instability or bugginess in some > of the Broadcom firmware(management) on the bce(4) chipeset shipped on > later generations of the Poweredge 2950 from Dell: > > bce0:

Re: bce(4) on the Dell PE 2950

2013-04-12 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 (Added David to Cc) On 04/12/13 13:56, Sean Bruno wrote: > A note from cluster...@freebsd.org > > It looks like there is some amount of instability or bugginess in > some of the Broadcom firmware(management) on the bce(4) chipeset > shipped on late

bce(4) on the Dell PE 2950

2013-04-12 Thread Sean Bruno
A note from cluster...@freebsd.org It looks like there is some amount of instability or bugginess in some of the Broadcom firmware(management) on the bce(4) chipeset shipped on later generations of the Poweredge 2950 from Dell: bce0: Specifically, we've seen that newer (9 and higher) have issu

bge(4) sysctl tuneables -- a blast from the past.

2013-04-12 Thread Sean Bruno
http://markmail.org/message/brpfcifnf2742pff So, these never happened. *sigh* I think they should. Any objections? Sean signature.asc Description: This is a digitally signed message part

Re: panic in tcp_do_segment()

2013-04-12 Thread Peter Holm
On Fri, Apr 12, 2013 at 10:14:40AM -0400, Juan Mojica wrote: Glad I could help. - Peter >I'm a little late to get back to the email thread, but this is great to >hear. Changes look good (assuming the goto drop is changed >dropunlock). Thanks guys. > >On Tue, Apr 9, 2013 at 2:4

Re: IKEv2/IPSEC "Road Warrior" VPN Tunneling?

2013-04-12 Thread Michael Sierchio
On Thu, Apr 11, 2013 at 10:27 PM, Eugene Grosbein wrote: > 12.04.2013 05:31, Karl Denninger пишет: >> Is there a "cookbook" for setting this up? There are examples for >> setting up a tunnel between two fixed-address networks (e.g. a remote >> LAN that needs to be "integrated" with a central LA

Re: panic in tcp_do_segment()

2013-04-12 Thread Juan Mojica
I'm a little late to get back to the email thread, but this is great to hear. Changes look good (assuming the goto drop is changed dropunlock). Thanks guys. On Tue, Apr 9, 2013 at 2:44 PM, Peter Holm wrote: > On Tue, Apr 09, 2013 at 10:35:30AM +0200, Andre Oppermann wrote: > > On 09.04.2013 10

Re: kern/165903: mbuf leak

2013-04-12 Thread Olivier Cochard-Labbé
On Fri, Apr 12, 2013 at 1:54 PM, Gleb Smirnoff wrote: > On Fri, Apr 12, 2013 at 01:45:51PM +0200, Olivier Cochard-Labb? wrote: > O> PR closed too soon ? > > It isn't closed, it is in patched state. This means that problem > is considered solve in the head branch, but not in any stable branch. Ok,

Re: kern/165903: mbuf leak

2013-04-12 Thread Gleb Smirnoff
On Fri, Apr 12, 2013 at 01:45:51PM +0200, Olivier Cochard-Labb? wrote: O> PR closed too soon ? It isn't closed, it is in patched state. This means that problem is considered solve in the head branch, but not in any stable branch. -- Totus tuus, Glebius. __

Re: kern/165903: mbuf leak

2013-04-12 Thread Olivier Cochard-Labbé
Hi, PR closed too soon ? All of our firewalls just migrated to 9.0 firewall (carp + pfsync) hit memory leak problem. Here is some output: Mem: 17M Active, 15M Inact, 1709M Wired, 1392K Cache, 143M Buf, 229M Free => 1709M Wired just for a firewall ? On other machine: # netstat -m 2188812/1278

Re: kern/170081: [fxp] pf/nat/jails not working if checksum offloading is enabled on fxp0

2013-04-12 Thread Johan Broman
The following reply was made to PR kern/170081; it has been noted by GNATS. From: Johan Broman To: bug-follo...@freebsd.org, h.sku...@gmail.com Cc: Subject: Re: kern/170081: [fxp] pf/nat/jails not working if checksum offloading is enabled on fxp0 Date: Fri, 12 Apr 2013 10:30:50 +0200 --001a1