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 handli
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: http://people.freebsd.org/~piso/al
Mikhail T. wrote:
However, if I disable just one of the rules below -- 1300, the one
diverting all traffic to natd -- the video works fine... So it is not
any of the other rules, that are the problem, nor is it the remote
server... Why would this happen and how do I solve the problem? Thanks!
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). Thi
Luigi Rizzo wrote:
Ok then we may have a plan:
you could do is implement REASS as an action (not as a microinstruction),
with the following behaviour:
- if the packet is a complete one, the rule behaves as a "count"
(i.e. the firewall continues with the next rule);
- if the packet is a frag
Luigi Rizzo wrote:
Thinking more about it, i believe that calling reass as an explicit
firewall action is useless, because if ip_reass fails due to lack of
all fragments you are back to square one:
what do I do with this fragment ?
AFAIK ip_reass() never fails: if it's the last frag
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 returne
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 tc
On Mon, May 19, 2008 at 05:18:13PM +0300, Oleksandr Samoylyk wrote:
>
> Will it work for any destination?
redirect_port tcp $fooip:666 999
incoming tcp packets destined for port 999 will be redirected to $fooip port
666.
See redirect modes in natd(8) for more info.
--
bye,
P.
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 Thu, Mar 13, 2008 at 09:21:11AM +, Vadim Goncharov wrote:
>
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=80642
>
> Yes, this is useful, but some minor changes are needed, I think. First, rename
> it to "bytelimit" or somewhat. Second, allow this to use tablearg and possibly
> ability to
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 - some_small
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 pat
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
SI_O
On Fri, Feb 29, 2008 at 05:21:35AM +, Vadim Goncharov wrote:
> Hi Paolo Pisati!
>
> On Thu, 28 Feb 2008 16:11:34 +0100; Paolo Pisati wrote about '[patch]
> ipfw_nat as a kld module':
>
> > http://people.freebsd.org/~piso/ipfw_nat_module.patch
> > An
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 t
>
>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
[
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.t
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:
http://wikitest
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.pa
On Fri, Apr 28, 2006 at 03:26:52PM -0400, Corey Smith wrote:
> Daniel Walker wrote:
> >IPTABLES allows for string matching. IPFW does not. I'll
> >have to fire up my Ubuntu to do this.
> >
> This has been brought up before on this list. IPFW does not intend on
> ever supporting string matchi
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 11:44:41AM -0300, Patrick Tracanelli wrote:
> Do you have any special points to make about the testing enviroment? I
> am gonna run it in one prouction box and other testing only boxes,
> should CFLAGS have -g to make any report if needed?
-g is useful for kernel/core dum
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
On Mon, Apr 03, 2006 at 03:13:43PM -0300, Patrick Tracanelli wrote:
> How's the current status of this work within ipfw? Will it be available
> on next releases?
latest release is available here:
http://wikitest.freebsd.org/moin.cgi/PaoloPisati
and adds lsnat, redirect and dynamic address suppo
27 matches
Mail list logo
