Hi,
I have created an IPFW2 rule set on a router (no NAT).
In one of the rules I wanted to pass packets originating
from the local host (i.e. non-routed) out through a
specific interface, i.e. packets that have _not_ been
received on some interface.
The manual page ipfw(8) says that "recv any" ma
Please, explain more clearly, what u want to do?
P.S. looks very strange "out not recv any xmit"
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vladone <[EMAIL PROTECTED]> wrote:
> Please, explain more clearly, what u want to do?
What exactly was unclear in my description?
> P.S. looks very strange "out not recv any xmit"
It's perfectly valid syntax according to ipfw(8).
"out not recv any xmit dc0" consists of three options
(i.e. mat
Oliver Fromme wrote:
> However, the problem is that the second option is being
> ignored, and I would like to know why, and how to work-
> around the bug.
>
Would this work?:
# ipfw add pass ip from me to $N out xmit xl0
--
Sten Daniel Sørsdal
___
f
ok, so the problem is the following: when i implemented ipfw2
i thought that 'recv any' or 'xmit any' were effectively NOPs
so the parser erroneously removes them, together with any 'not' prefix
(which is processed before).
To fix this one should
- patch the function ipfw2.c:fill_iface()
so that
I dont understand u! If have an rule for filter traffic incoming to
server, why put options for "incoming" and "not outgoing"?
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail
On Tuesday 02 August 2005 14:46, Oliver Fromme wrote:
> > P.S. looks very strange "out not recv any xmit"
>
> It's perfectly valid syntax according to ipfw(8).
(1+1-1)/1 also ... ;)
>
> 1. "out" --> match only outgoing packets.
>
> 2. "not recv any" --> match packets that haven't been
>rec
Sten Daniel Sørsdal <[EMAIL PROTECTED]> wrote:
> Oliver Fromme wrote:
> > However, the problem is that the second option is being
> > ignored, and I would like to know why, and how to work-
> > around the bug.
>
> Would this work?:
>
> # ipfw add pass ip from me to $N out xmit xl0
No. I
* Oliver Fromme <[EMAIL PROTECTED]> [2005-08-03 10:25 +0200]:
> Sten Daniel Sørsdal <[EMAIL PROTECTED]> wrote:
> > Oliver Fromme wrote:
> > > However, the problem is that the second option is being
> > > ignored, and I would like to know why, and how to work-
> > > around the bug.
> >
> > Wo
Luigi Rizzo <[EMAIL PROTECTED]> wrote:
> ok, so the problem is the following: when i implemented ipfw2
> i thought that 'recv any' or 'xmit any' were effectively NOPs
> so the parser erroneously removes them, together with any 'not' prefix
> (which is processed before).
That explains it.
I wa
On Tue, Aug 02, 2005 at 09:51:45PM -0300, AT Matik wrote:
...
> even if I agree to your logic aspect in general I thought
>
> out and xmit is probably exactly the same still especially as you set
> src-ip and dst-ip so the interface where this packages are xmit is
> defined by the routes
>
> l
AT Matik <[EMAIL PROTECTED]> wrote:
> On Tuesday 02 August 2005 14:46, Oliver Fromme wrote:
> > > P.S. looks very strange "out not recv any xmit"
> >
> > It's perfectly valid syntax according to ipfw(8).
>
> (1+1-1)/1 also ... ;)
I should have added: "perfectly valid syntax _and_ it
make
Nicolas Rachinsky <[EMAIL PROTECTED]> wrote:
> ipfw add deny ip from me to any in
> ipfw add pass ip from me to $N out xmit xl0
Yes, I also have a work-around with two rules, but I would
prefer an independend check within the "out" rule.
> But I would like the 'not recv any' feature, too. At
On Wednesday 03 August 2005 06:19, Oliver Fromme wrote:
>
> > out and xmit is probably exactly the same
>
> No, it's not. "out" just says that this rule matches only
> outgoing packets. It doesn't specify anything about inter-
> faces or addresses.
>
packages catched by xmit IF are catched wit
On Wednesday 03 August 2005 06:11, Luigi Rizzo wrote:
> there are internally generated packets which do not have
> a rcvif (which is what really 'recv' means);
> and any packet in the input path does not have an output-if
> (which is wht really 'xmit' means).
>
well, means that any rule using IF
the question is simple: i made a mistake in implementing
recv|xmit any, Oliver spotted it, i posted a fix.
Whether his example was a good one or not is rather irrelevant.
Hopefully the discussion has clarified that some checks
are redundant, but the compiler cannot possibly spot all useless
sequenc
On Wednesday 03 August 2005 08:37, Luigi Rizzo wrote:
> the question is simple: i made a mistake in implementing
> recv|xmit any, Oliver spotted it, i posted a fix.
> Whether his example was a good one or not is rather irrelevant.
> Hopefully the discussion has clarified that some checks
> are re
AT Matik <[EMAIL PROTECTED]> wrote:
> On Wednesday 03 August 2005 06:19, Oliver Fromme wrote:
> >
> > > out and xmit is probably exactly the same
> >
> > No, it's not. "out" just says that this rule matches only
> > outgoing packets. It doesn't specify anything about inter-
> > faces or
18 matches
Mail list logo
