I'd argue that DNS clue pushes the firewall out from a packet
inspection thing and into a user-space application inspection thing.
DNS entries in filter rules doesn't work as well in all situations as
you'd like. :)
Adrian
(who has done this, and it doesn't quite work right in all situations
On 09/05/2010 11:47 PM, Adrian Chadd wrote:
I'd argue that DNS clue pushes the firewall out from a packet
inspection thing and into a user-space application inspection thing.
It also opens up an attack vector on your firewall.
Doug
--
Improve the effectiveness of your Internet
Hello,
I tried setup NAT with IPFW, compiled my kernel and I found that there
is very slow connection.
After I disabled NAT and IPFW then speed was increased.
64-bit FreeBSD 9-CURRENT :
With IPFW: 1.2 MB/sec
Without IPFW: 33 MB/sec
my ipfw work with i386 (stable) without speed decreasing:
Peter Reo Molnar wrote:
Hello,
I tried setup NAT with IPFW, compiled my kernel and I found that there
is very slow connection.
After I disabled NAT and IPFW then speed was increased.
64-bit FreeBSD 9-CURRENT :
With IPFW: 1.2 MB/sec
Without IPFW: 33 MB/sec
my ipfw work with i386
TB --- 2010-09-06 10:40:14 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-06 10:40:14 - starting HEAD tinderbox run for mips/mips
TB --- 2010-09-06 10:40:14 - cleaning the object tree
TB --- 2010-09-06 10:40:41 - cvsupping the source tree
TB --- 2010-09-06 10:40:41 -
Ian FREISLICH wrote:
Peter Reo Molnar wrote:
Hello,
I tried setup NAT with IPFW, compiled my kernel and I found that there
is very slow connection.
After I disabled NAT and IPFW then speed was increased.
64-bit FreeBSD 9-CURRENT :
With IPFW: 1.2 MB/sec
Without IPFW: 33
Am 06.09.2010 um 13:08 schrieb Randy Bush:
i never managed to figure out how to convert my pppoe nat config to ipfw
natting.
I did not see a significant improvement going from ppp(8)+9 and ipfw to ppp(8)
and pf+nat. Since ppp(8) already incurs the kernel/userland cost, having it
handle NAT
Hi everyone,
I have put together a slightly improved patch of Pawel's that compiles
correctly and supports booting from ZFS v19 pools.
You can download the patch here:
http://people.freebsd.org/~mm/patches/zfs/head-zfs-v28-20100831.patch
For users who don't want to compile I have created a
on 29/08/2010 12:25 Andriy Gapon said the following:
The below patch is against sources in FreeBSD tree, it should be applied
either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending
on the desired architecture:
http://people.freebsd.org/~avg/intel-cpu-topo.diff
I see
On Mon, Sep 06, 2010 at 03:17:42PM +0300, Andriy Gapon wrote:
on 29/08/2010 12:25 Andriy Gapon said the following:
The below patch is against sources in FreeBSD tree, it should be applied
either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c
depending
on the desired
On sparc64 after updating to r212060, libz.so.5 came up
as old library. I rebuit all ports to use
libz.so.6 instead, but libchk still shows that
Binaries that are linked with: /lib/libz.so.5
/usr/sbin/dtrace
/usr/sbin/lockstat
What did I do wrong that resulted in these 2
programs
on 06/09/2010 15:23 Jeremy Chadwick said the following:
On Mon, Sep 06, 2010 at 03:17:42PM +0300, Andriy Gapon wrote:
on 29/08/2010 12:25 Andriy Gapon said the following:
The below patch is against sources in FreeBSD tree, it should be applied
either to sys/amd64/amd64/mp_machdep.c or
On 6 September 2010 16:50, Anton Shterenlikht me...@bristol.ac.uk wrote:
On sparc64 after updating to r212060, libz.so.5 came up
as old library. I rebuit all ports to use
libz.so.6 instead, but libchk still shows that
Binaries that are linked with: /lib/libz.so.5
/usr/sbin/dtrace
On Fri, Sep 03, 2010 at 11:25:34AM -0700, Pyun YongHyeon wrote:
On Fri, Sep 03, 2010 at 09:42:04AM +0100, Anton Shterenlikht wrote:
On Thu, Sep 02, 2010 at 11:36:03AM -0700, Pyun YongHyeon wrote:
On Thu, Sep 02, 2010 at 06:03:16PM +0100, Anton Shterenlikht wrote:
On Thu, Sep 02, 2010 at
On Mon, Sep 06, 2010 at 05:03:31PM +0400, pluknet wrote:
On 6 September 2010 16:50, Anton Shterenlikht me...@bristol.ac.uk wrote:
On sparc64 after updating to r212060, libz.so.5 came up
as old library. I rebuit all ports to use
libz.so.6 instead, but libchk still shows that
Binaries
Randy Bush wrote:
Ian FREISLICH wrote:
Peter Reo Molnar wrote:
Hello,
I tried setup NAT with IPFW, compiled my kernel and I found that there
is very slow connection.
After I disabled NAT and IPFW then speed was increased.
64-bit FreeBSD 9-CURRENT :
With IPFW: 1.2
on 06/09/2010 16:12 Jeremy Chadwick said the following:
Great, thanks! I'll be testing this out on two separate systems, both
RELENG_8:
- Supermicro X7SBA + Intel C2D E8400 (stepping 10)
- Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6)
I'll make sure to provide what the topology
I'm sure you could coax these scripts to do what you want, but
unless you have more than 50mbps I doubt it's worth the effort.
i live in a first world country. 100/100 for 3250yen/mo (that's about
35usd.
randy
___
freebsd-current@freebsd.org mailing
On Mon, 6 Sep 2010, jhell wrote:
After r210693, these utilities are built for i386 and amd64 only. Thereby
you have stale binaries installed from older sources.
Lol this is the first I have read about this comes as quite the surprise
that its not being built on top of the platform/arch that
On Mon, Sep 06, 2010 at 03:56:01PM +0300, Andriy Gapon wrote:
on 06/09/2010 15:23 Jeremy Chadwick said the following:
On Mon, Sep 06, 2010 at 03:17:42PM +0300, Andriy Gapon wrote:
on 29/08/2010 12:25 Andriy Gapon said the following:
The below patch is against sources in FreeBSD tree, it
on 06/09/2010 19:22 Jeremy Chadwick said the following:
On Mon, Sep 06, 2010 at 04:28:02PM +0300, Andriy Gapon wrote:
on 06/09/2010 16:12 Jeremy Chadwick said the following:
Great, thanks! I'll be testing this out on two separate systems, both
RELENG_8:
- Supermicro X7SBA + Intel C2D
hi there,
i was trying to create a snapshot of my root fs. the commands i used were
1) mksnap_ffs /.snap/snap1
and
2) mount -u -o snapshot /.snap/snap1 /
both command failed with EAGAIN and the following was output to the console:
Sep 6 18:05:56 otaku kernel: fsync: giving up on dirty
Sep
On Mon, Sep 06, 2010 at 04:28:02PM +0300, Andriy Gapon wrote:
on 06/09/2010 16:12 Jeremy Chadwick said the following:
Great, thanks! I'll be testing this out on two separate systems, both
RELENG_8:
- Supermicro X7SBA + Intel C2D E8400 (stepping 10)
- Supermicro X7SBL-LN2 + Intel
2010/9/6 Andriy Gapon a...@freebsd.org:
on 06/09/2010 19:22 Jeremy Chadwick said the following:
On Mon, Sep 06, 2010 at 04:28:02PM +0300, Andriy Gapon wrote:
on 06/09/2010 16:12 Jeremy Chadwick said the following:
Great, thanks! I'll be testing this out on two separate systems, both
Hello,
I would like to ask for feedback on a kernel level stacked cryptographic
filesystem. It has started as Summer Of Code'2009 project and matured a
lot since then. I've recently added support for sparse files and
switched to XTS encryption mode.
I've been using it to encrypt my home
Em 5/9/2010 12:53, Luigi Rizzo escreveu:
On Sat, Sep 04, 2010 at 10:58:44AM -0300, Anderson Eduardo wrote:
Hello developers,
I use the ipfw firewall with many tables and, I would like of able to
use it with name/alias instead of just numbers.
E.g:
lab# ipfw table 1 name lanetwork
Setting
To avoid user and developer confusion, my patch was just a chain of
pjd's patch + pjd's atomic.h fix + my v19 boot patch.
I have removed (= split) the chained patch in my posting and altered my
blog article with updated build instructions that actually just
summarize what has been written on
Sorry for replying to myself, I've realized I put wrong download link:
http://github.com/downloads/glk/pefs/pefs-2010-09-06.tar.gz
On (06/09/2010 21:38), Gleb Kurtsou wrote:
Hello,
I would like to ask for feedback on a kernel level stacked cryptographic
filesystem. It has started as Summer
TB --- 2010-09-07 01:39:25 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-07 01:39:25 - starting HEAD tinderbox run for ia64/ia64
TB --- 2010-09-07 01:39:25 - cleaning the object tree
TB --- 2010-09-07 01:40:08 - cvsupping the source tree
TB --- 2010-09-07 01:40:08 -
TB --- 2010-09-07 03:28:16 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-07 03:28:16 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-09-07 03:28:16 - cleaning the object tree
TB --- 2010-09-07 03:29:01 - cvsupping the source tree
TB --- 2010-09-07 03:29:01 -
30 matches
Mail list logo
