Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Aug 2004 11:42:37 +0900
From:      Pyun YongHyeon <yongari@kt-is.co.kr>
To:        Roderick van Domburg <r.s.a.vandomburg@student.utwente.nl>
Cc:        freebsd-sparc64@freebsd.org
Subject:   Re: Does ip6fw work for you on sparc64?
Message-ID:  <20040803024237.GA4564@kt-is.co.kr>
In-Reply-To: <410E3C0F.20403@student.utwente.nl>
References:  <410E3C0F.20403@student.utwente.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 02, 2004 at 03:05:19PM +0200, Roderick van Domburg wrote:
 > Hello everybody,
 > 
 > Does ip6fw work for any sparc64 owners? It hasn't been working correctly 
 > for me for as long as I can remember. Behavior is very erratic: allow 
 > ipv6 works, but allow {tcp|udp} doesn't. Such rules do show up in the 
 > traffic counter, but really don't allow any traffic passing it at all.
 > 

I have no experience on ip6fw(i386/sparc64). Hence don't know
current ip6fw status on sparc64. However if you can live
with other solutions, I'd like to recommend pf.

Though not in FreeBSD sparc64, pf was heavily tested on sparc64
and IPv6 environments in OpenBSD. The only drawback of pf against
ipfw is operations in bridged environments. State tracking, one
of the most powerful feature of pf, doesn't work in bridged
environments. This is not pf's fault. ATM, our bridge(4) doesn't
allow pf/ipf see outgoing packets in bridge environmets.
(hence ipf can't create state too.)
Just making stateful inspection for pf/ipf is trivial one but I
want more complete patch for bridge(4) in order to have pf's IP
reassemble capability work in bridged setup.

If my memory serve right, the last consensus with Luigi was
"fix after ipfw's pfil conversion".

Best regards,
Pyun YongHyeon
-- 
Pyun YongHyeon <http://www.kr.freebsd.org/~yongari>;



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040803024237.GA4564>