http://people.freebsd.org/~piso/libalias_mbuf.diff
this patch makes libalias able to handle mbuf: TOS, big MTU, much
less copy-around, etcetc.
I encourage people to test it, since i would like to commit it soon.
Known issues:
-documentation was not updated
-i didn't convert the fragment
Mikhail T. wrote:
Great pointer! As a matter of fact, all I had to comment out was the
/lib/libalias_smedia.so...
Now, what's wrong with it? Does not disabling this plugin mean, the
hosts on the LAN can't access RTSP streams? Thanks! Yours,
try this patch:
Luigi Rizzo wrote:
Can you put a description in the manpage especially on the
assumptions and side effects of the reass option ?
E.g. as i read it,
+ you need to make sure that the fragments are not dropped before
the 'reass' (so you cannot rely on port numbers to decide
accept or deny).
Alex Dupre wrote:
Luigi Rizzo ha scritto:
it is not related to dynamic rules, but to the fact that
that the firewall is called before reassembling packets.
The info (port numbers especially) is not available
in the fragments so the firewall cannot do anything.
The only solution would be to call
Evgenii Davidov wrote:
tell me please:
does kernel nat in ipfw have a memory leak like ng_nat+libalias:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/115526
?
i haven't tested it yet
i've never been able to reproduce that bug: i resemble there was a
memory leak/a resource was never
On Sun, May 18, 2008 at 09:51:26PM +0300, Oleksandr Samoylyk wrote:
Hello freebsd-ipfw,
I'd like to make smtp port rewriting for any destination by means of ipfw.
With iptables I just used this rule in order to achieve this functionality:
iptables -t nat -A PREROUTING -i ppp+ -p tcp
On Sat, Mar 22, 2008 at 10:49:21PM -0400, Robert Huff wrote:
(I am not subscribed; please CC: me.)
I have been told that for 7.0+, network address translation
involving ipfw no longer uses natd(8).
Is this so?
If it is, where do I find documentation on the new
On Sun, Mar 02, 2008 at 03:58:50PM +0100, Luigi Rizzo wrote:
The SI_ORDER_* definitions in /sys/sys/kernel.h are enumerated on a
large range, so if the existing code does not have races,
you can safely move the non-leaf modules
(such as ipfw,ko in your case) to (SI_ORDER_ANY -
Hi,
i just found out that depending on a KLD doesn't imply any
initialization order, thus depending on a lock initialized in the ipfw
init path is _really_ a bad idea from another KLD init path (see
ip_fw_nat.c::ipfw_nat_init()).
A fix would be to move ipfw init priority from SI_ORDER_ANY to
On Sun, Mar 02, 2008 at 03:49:39PM +0100, Paolo Pisati wrote:
Hi,
i just found out that depending on a KLD doesn't imply any
initialization order, thus depending on a lock initialized in the ipfw
init path is _really_ a bad idea from another KLD init path (see
ip_fw_nat.c::ipfw_nat_init
Here is the patch against HEAD:
http://people.freebsd.org/~piso/ipfw_nat_module.patch
Any objection if i commit it?
bye,
P.
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail
I'm having a bit of trouble backporting 7.x to 6.x, 6.2 Release
specifically. Before I continue down this road, in the name of not
re-inventing the wheel twice, does anyone already have a current patch
which will work on 6.2 ? Thank You!
AFAIK no.
--
bye,
P.
On Wed, Sep 05, 2007 at 09:41:50PM -0500, Chris Bowman (Home) wrote:
I was recently testing the in kernel nat patch, which is an absolutely
wonderful addition in my opinion. I have however run into one issue, when
for example I do the following :
ipfw nat 10 config ip 2.2.2.2
[snip]
On Mon, Jul 03, 2006 at 01:42:36AM +1000, Vini Engel wrote:
Paolo Pisati said the following on 15/05/06 08:05:
Released a new revision of my libalias+ipfw work as a
patchset for 6.x, get it here:
http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz
fixed the checksum
Released a new revision of my libalias+ipfw work as a
patchset for 6.x, get it here:
http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz
fixed the checksum corruption occurring to redirected/generated traffic
to/by a local interface on the nat box.
For more info:
Nenad Gavrilovic wrote:
Paolo Pisati wrote:
I just released a new revision of my libalias+ipfw work as a patchset
for 6.x, get it here:
http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz
To apply it:
cp libalias_ipfw.patch /usr/src
cd /usr/src
patch -p3 libalias_ipfw.patch
I just released a new revision of my libalias+ipfw work as a
patchset for 6.x, get it here:
http://mercurio.srv.dsi.unimi.it/~pisati/libalias/libalias-6.x.tgz
To apply it:
cp libalias_ipfw.patch /usr/src
cd /usr/src
patch -p3 libalias_ipfw.patch
then you have to recompile install:
kernel,
On Tue, Apr 04, 2006 at 10:09:37AM -0300, Patrick Tracanelli wrote:
Hello Paolo,
Thanks for the kind reply. I will try it on i386 and amd64.
Is http://ubi8.imc.pi.cnr.it/~flag/libalias/libalias.tgz the latest tar
ball? I did not find the mentioned README file there, I had to look at
it
18 matches
Mail list logo
