Re: bin/131567: Update for regression/sockets/unix_cmsg
The following reply was made to PR bin/131567; it has been noted by GNATS. From: Andrey Simonenko To: bug-follo...@freebsd.org Cc: Subject: Re: bin/131567: Update for regression/sockets/unix_cmsg Date: Mon, 11 Feb 2013 11:38:02 +0200 Correctness of unix_cmsg verified on 7.1-STABLE, 9.1-STABLE and 10-CURRENT. ^^^\ \ Corrected typo in previous message. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
kern/92880: [libc] [patch] almost rewritten inet_network(3) function
The following reply was made to PR kern/92880; it has been noted by GNATS.
From: Andrey Simonenko
To: bug-follo...@freebsd.org
Cc:
Subject: kern/92880: [libc] [patch] almost rewritten inet_network(3) function
Date: Tue, 23 Oct 2012 11:36:04 +0300
I optimized inet_network() again.
Difference between implementation of inet_network(3) from 9.1-PRERELEASE
and my implementation.
STRING INET_NETWORKINET_NETWORK_NEW
"0x12" 0x0012 0x0012
"127.1"0x7f01 0x7f01
"127.1.2.3"0x7f010203 0x7f010203
"0x123456" INADDR_NONE INADDR_NONE
"0x12.0x34"0x1234 0x1234
"0x12.0x345" INADDR_NONE INADDR_NONE
"1.2.3.4.5"INADDR_NONE INADDR_NONE
"1..3.4" INADDR_NONE INADDR_NONE
"."INADDR_NONE INADDR_NONE
"1." INADDR_NONE INADDR_NONE
".1" INADDR_NONE INADDR_NONE
"0x" 0x INADDR_NONE <---
"0"0x 0x
"01.02.07.077" 0x0102073f 0x0102073f
"0x1.23.045.0" 0x01172500 0x01172500
"" INADDR_NONE INADDR_NONE
" "INADDR_NONE INADDR_NONE
" f" INADDR_NONE INADDR_NONE
"bar" INADDR_NONE INADDR_NONE
"1.2bar" INADDR_NONE INADDR_NONE
"1." INADDR_NONE INADDR_NONE
"=CA=C3=D5=CB=C5=CE" INADDR_NONE INADDR_NONE
"255.255.255.255" INADDR_NONE INADDR_NONE
"x"INADDR_NONE INADDR_NONE
"0X12" 0x0012 0x0012
"078" INADDR_NONE INADDR_NONE
"1 bar"0x0001 INADDR_NONE <---
"127.0xabcd" INADDR_NONE INADDR_NONE
"128" 0x0080 0x0080
"0.1.2"0x0102 0x0102
"0xff.010.23.0xa0" 0xff0817a0 0xff0817a0
"x10" 0x0010 INADDR_NONE <---
"X20" 0x0020 INADDR_NONE <---
"x10.x20" 0x1020 INADDR_NONE <---
"4294967297" 0x0001 INADDR_NONE <---
"0x1000f" 0x000f INADDR_NONE <---
"0403" 0x0003 INADDR_NONE <---
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static in_addr_t
inet_network_new(const char *s)
{
u_int d, base, dots;
in_addr_t addr, byte;
u_char c;
bool flag;
addr =3D 0;
dots =3D 0;
for (;; ++s) {
byte =3D 0;
flag =3D false;
if (*s =3D=3D '0') {
++s;
if (*s =3D=3D 'x' || *s =3D=3D 'X') {
++s;
base =3D 16;
} else {
base =3D 8;
flag =3D true;
}
} else
base =3D 10;
for (; (c =3D *s) !=3D '\0'; ++s) {
d =3D digittoint(c);
if (c !=3D '0' && (d =3D=3D 0 || d >=3D base))
break;
byte =3D byte * base + d;
if (byte > UINT8_MAX)
return (INADDR_NONE);
flag =3D true;
}
if (!flag)
return (INADDR_NONE);
addr =3D (addr << 8) | byte;
if (c !=3D '.')
break;
if (++dots =3D=3D 4)
return (INADDR_NONE);
}
return (c =3D=3D '\0' ? addr : INADDR_NONE);
}
int
main(void)
{
const char *const addr_str_tbl[] =3D {
"0x12", "127.1", "127.1.2.3", "0x123456", "0x12.0x34",
"0x12.0x345", "1.2.3.4.5", "1..3.4", ".", "1.", ".1", "0x",
"0", "01.02.07.077", "0x1.23.045.0", "", " ", " f", "bar",
"
Re: kern/92880: [libc] [patch] almost rewritten inet_network(3) function
On Tue, Oct 23, 2012 at 10:37:56AM -0700, Adrian Chadd wrote:
> ... don't suppose you want to throw this into a test case somewhere in the
> tree?
>
This was the bug-followup to my PR [1], that was created because I needed
own version of inet_network() for another my PR [2] and found out that
the current version of inet_network() has mistakes and is not optimal.
This bug-followup has inet_network_new() that is a rewritten implementation
of inet_network(). This message was sent to the net@ mailing list, since
this PR was assigned to freebsd-net.
> The new ATF import would be ideal for this. :)
I have not checked how ATF works yet, but I wrote socket/unix_cmsg that
verifies correctness of AF_LOCAL control messages implementation. It
cannot be used on recent versions, because changes from PR [3] were not
committed yet.
What do you think about lines pointed by "<---" where inet_network()
and my implementation gives different results?
[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92880
[2] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/136865
[3] http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/131567
>
>
>
> Adrian
>
> On 23 October 2012 01:40, Andrey Simonenko
> wrote:
> > The following reply was made to PR kern/92880; it has been noted by GNATS.
> >
> > From: Andrey Simonenko
> > To: bug-follo...@freebsd.org
> > Cc:
> > Subject: kern/92880: [libc] [patch] almost rewritten inet_network(3)
> > function
> > Date: Tue, 23 Oct 2012 11:36:04 +0300
> >
> > I optimized inet_network() again.
> >
> > Difference between implementation of inet_network(3) from 9.1-PRERELEASE
> > and my implementation.
> >
> > STRING INET_NETWORKINET_NETWORK_NEW
> > "0x12" 0x0012 0x0012
> > "127.1"0x7f01 0x7f01
> > "127.1.2.3"0x7f010203 0x7f010203
> > "0x123456" INADDR_NONE INADDR_NONE
> > "0x12.0x34"0x1234 0x1234
> > "0x12.0x345" INADDR_NONE INADDR_NONE
> > "1.2.3.4.5"INADDR_NONE INADDR_NONE
> > "1..3.4" INADDR_NONE INADDR_NONE
> > "."INADDR_NONE INADDR_NONE
> > "1." INADDR_NONE INADDR_NONE
> > ".1" INADDR_NONE INADDR_NONE
> > "0x" 0x INADDR_NONE <---
> > "0"0x 0x
> > "01.02.07.077" 0x0102073f 0x0102073f
> > "0x1.23.045.0" 0x01172500 0x01172500
> > "" INADDR_NONE INADDR_NONE
> > " "INADDR_NONE INADDR_NONE
> > " f" INADDR_NONE INADDR_NONE
> > "bar" INADDR_NONE INADDR_NONE
> > "1.2bar" INADDR_NONE INADDR_NONE
> > "1." INADDR_NONE INADDR_NONE
> > "=CA=C3=D5=CB=C5=CE" INADDR_NONE INADDR_NONE
> > "255.255.255.255" INADDR_NONE INADDR_NONE
> > "x"INADDR_NONE INADDR_NONE
> > "0X12" 0x0012 0x0012
> > "078" INADDR_NONE INADDR_NONE
> > "1 bar"0x0001 INADDR_NONE <---
> > "127.0xabcd" INADDR_NONE INADDR_NONE
> > "128" 0x0080 0x0080
> > "0.1.2"0x0102 0x0102
> > "0xff.010.23.0xa0" 0xff0817a0 0xff0817a0
> > "x10" 0x0010 INADDR_NONE <---
> > "X20" 0x0020 INADDR_NONE <---
> > "x10.x20" 0x1020 INADDR_NONE <---
> > "4294967297" 0x0001 INADDR_NONE <---
> > "0x1000f" 0x000f INADDR_NONE <---
> > "0403" 0x0003 INADDR_NONE <---
> >
> > #include
> > #include
> >
> > #include
> > #include
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> > static in_addr_t
> > inet_network_new(const char *s)
> > {
> > u_int d, base, dot
getnetent(3) return values for incorrect IPv4 network addresses
There is one feature of getnetent(3) that is not documented and is not
checked by applications that use getnetent(3) or similar functions.
If an IPv4 network address is specified incorrectly in the networks(5)
database, then the n_net field from the struct netent{} is set to INADDR_NONE.
This is done by the inet_network(3) function that is used for network address
translation.
Should this property of getnetent(3) be documented in its manual page
to make such behaviour of getnetent(3) official?
Example:
% grep abc /etc/networks
abc 1.
% getent networks abc
abc 255.255.255.255
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/92880: [libc] [patch] almost rewritten inet_network(3) function
The following reply was made to PR kern/92880; it has been noted by GNATS.
From: Andrey Simonenko
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/92880: [libc] [patch] almost rewritten inet_network(3)
function
Date: Fri, 21 Jan 2011 16:12:49 +0200
My previous modification had one typo and did not work correctly
for IPv4 addresses given in `.' donation in hexadecimal form.
Here another one update:
1. Test program that shows difference between implementation of
inet_network(3) from 9-CURRENT and my implementation.
2. Diff for the src/lib/libc/inet/inet_network.c file.
Look on output from the test program ("<---" shows different values):
STRING INET_NETWORKINET_NETWORK_NEW
"0x12" 0x0012 0x0012
"127.1"0x7f01 0x7f01
"127.1.2.3"0x7f010203 0x7f010203
"0x123456" INADDR_NONE INADDR_NONE
"0x12.0x34"0x1234 0x1234
"0x12.0x345" INADDR_NONE INADDR_NONE
"1.2.3.4.5"INADDR_NONE INADDR_NONE
"1..3.4" INADDR_NONE INADDR_NONE
"."INADDR_NONE INADDR_NONE
"1." INADDR_NONE INADDR_NONE
".1" INADDR_NONE INADDR_NONE
"0x" 0x INADDR_NONE <---
"0"0x 0x
"01.02.07.077" 0x0102073f 0x0102073f
"0x1.23.045.0" 0x01172500 0x01172500
"" INADDR_NONE INADDR_NONE
" "INADDR_NONE INADDR_NONE
" f" INADDR_NONE INADDR_NONE
"bar" INADDR_NONE INADDR_NONE
"1.2bar" INADDR_NONE INADDR_NONE
"1." INADDR_NONE INADDR_NONE
"=CA=C3=D5=CB=C5=CE" INADDR_NONE INADDR_NONE
"255.255.255.255" INADDR_NONE INADDR_NONE
"x"INADDR_NONE INADDR_NONE
"0X12" 0x0012 0x0012
"078" INADDR_NONE INADDR_NONE
"1 bar"0x0001 INADDR_NONE <---
"127.0xabcd" INADDR_NONE INADDR_NONE
"128" 0x0080 0x0080
"0.1.2"0x0102 0x0102
"0xff.010.23.0xa0" 0xff0817a0 0xff0817a0
"x10" 0x0010 INADDR_NONE <---
"X20" 0x0020 INADDR_NONE <---
"x10.x20" 0x1020 INADDR_NONE <---
"4294967297" 0x0001 INADDR_NONE <---
"0x1000f" 0x000f INADDR_NONE <---
"0403" 0x0003 INADDR_NONE <---
Test program:
diff -ruNp inet_network_test.orig/Makefile inet_network_test/Makefile
--- inet_network_test.orig/Makefile1970-01-01 03:00:00.0 +0300
+++ inet_network_test/Makefile 2011-01-21 12:48:48.0 +0200
@@ -0,0 +1,9 @@
+PROG=3Dinet_network
+
+NO_MAN=3Dtrue
+
+WARNS=3D6
+
+DEBUG_FLAGS=3D-g
+
+.include
diff -ruNp inet_network_test.orig/inet_network.c inet_network_test/inet_n=
etwork.c
--- inet_network_test.orig/inet_network.c 1970-01-01 03:00:00.0 +=
0300
+++ inet_network_test/inet_network.c 2011-01-21 15:29:47.0 +0200
@@ -0,0 +1,105 @@
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+static in_addr_t
+inet_network_new(const char *s)
+{
+ u_int base, dots;
+ in_addr_t res, val;
+ u_char c;
+ char got_data;
+
+ res =3D 0;
+ dots =3D 0;
+ for (;;) {
+ val =3D 0;
+ got_data =3D 0;
+ if (*s =3D=3D '0') {
+ s++;
+ if (*s =3D=3D 'x' || *s =3D=3D 'X') {
+ s++;
+ base =3D 16;
+ } else {
+ base =3D 8;
+ got_data =3D 1;
+ }
+ } else
+ base =3D 10;
+ while ((c =3D *s) !=3D '\0') {
+ if (isdigit(c)) {
+ if (base =3D=3D 8 && c > '7')
+ return (INADDR_NONE);
+ val =3D val * base + c - '0';
+ } else if (base =3D=3D 16 && isx
Re: kern/92880: [libc] [patch] almost rewritten inet_network(3) function
The following reply was made to PR kern/92880; it has been noted by GNATS.
From: Andrey Simonenko
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/92880: [libc] [patch] almost rewritten inet_network(3)
function
Date: Mon, 24 Jan 2011 14:56:25 +0200
Since all '=' were changed to '=3D' in previous email, here is the copy
of diff for the inet_network.c file.
--- inet_network.c.orig2008-01-15 00:55:20.0 +0200
+++ inet_network.c 2011-01-21 15:58:17.0 +0200
@@ -48,57 +48,56 @@ __FBSDID("$FreeBSD: src/lib/libc/inet/in
* network numbers.
*/
in_addr_t
-inet_network(cp)
- const char *cp;
+inet_network(const char *s)
{
- in_addr_t val, base, n;
- char c;
- in_addr_t parts[4], *pp = parts;
- int i, digit;
+ u_int base, dots;
+ in_addr_t res, val;
+ u_char c;
+ char got_data;
-again:
- val = 0; base = 10; digit = 0;
- if (*cp == '0')
- digit = 1, base = 8, cp++;
- if (*cp == 'x' || *cp == 'X')
- base = 16, cp++;
- while ((c = *cp) != 0) {
- if (isdigit((unsigned char)c)) {
- if (base == 8U && (c == '8' || c == '9'))
+ res = 0;
+ dots = 0;
+ for (;;) {
+ val = 0;
+ got_data = 0;
+ if (*s == '0') {
+ s++;
+ if (*s == 'x' || *s == 'X') {
+ s++;
+ base = 16;
+ } else {
+ base = 8;
+ got_data = 1;
+ }
+ } else
+ base = 10;
+ while ((c = *s) != '\0') {
+ if (isdigit(c)) {
+ if (base == 8 && c > '7')
+ return (INADDR_NONE);
+ val = val * base + c - '0';
+ } else if (base == 16 && isxdigit(c))
+ val = (val << 4) + c + 10 -
+ (islower(c) ? 'a' : 'A');
+ else
+ break;
+ if (val > 0xff)
return (INADDR_NONE);
- val = (val * base) + (c - '0');
- cp++;
- digit = 1;
- continue;
+ s++;
+ got_data = 1;
}
- if (base == 16U && isxdigit((unsigned char)c)) {
- val = (val << 4) +
-(c + 10 - (islower((unsigned char)c) ? 'a' :
'A'));
- cp++;
- digit = 1;
- continue;
- }
- break;
- }
- if (!digit)
- return (INADDR_NONE);
- if (pp >= parts + 4 || val > 0xffU)
- return (INADDR_NONE);
- if (*cp == '.') {
- *pp++ = val, cp++;
- goto again;
- }
- if (*cp && !isspace(*cp&0xff))
- return (INADDR_NONE);
- *pp++ = val;
- n = pp - parts;
- if (n > 4U)
- return (INADDR_NONE);
- for (val = 0, i = 0; i < n; i++) {
- val <<= 8;
- val |= parts[i] & 0xff;
+ if (!got_data)
+ return (INADDR_NONE);
+ if (dots != 0)
+ res <<= 8;
+ res |= val;
+ if (c != '.')
+ break;
+ if (++dots == 4)
+ return (INADDR_NONE);
+ s++;
}
- return (val);
+ return (c == '\0' ? res : INADDR_NONE);
}
/*
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
sys/net/radix.c refuses addresses with all zeroes
Hello, The sys/net/radix.c refuses to add 0.0.0.0 address to the tree, but allows to add 0.0.0.0/32 address (when mask is specified). The question. Is it not allowed to give address with all zeroes to radix.c or is there some mistake in the radix.c code? How to check: Create file, say, zero-export: / 0.0.0.0 / -network 0.0.0.0/32 / :: / -network ::/128 and run "mountd -d zero-export". ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ip-accounting
Try to use IP Accountoing Daemon: http://www.simon.org.ua/ipa/ You also can install it from ports, but on its web site version 1.0.3 is availble. Clemens Hermann <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Hi, > > are there any recommandationions how to get IP-accounting to work on > FreeBSD? I have switched from ipf to ipfw so now I need a new way do > keep track of the IP-traffic passing my machine. > I have a machine with 30 IP-aliases. > The least thing I need is monthly summary of the full amount of > IP-Traffic that passed my (one) NIC. If possible it would be great to > have it split by the different IPs. Furthermore if some scripts existed > that could create HTML reports that would be great but not necessary. > The way ipf and ipacct do the job was pretty cool so if anything similar > was possible with ipfw or if there existed a tool to do the accounting > on its own with the desired results I would appreciate it a lot to know. > > thanks in advance > > /ch > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Q about sbin/ipfw2.c:list()
Hello, Why is it needed to check both r->rulenum and (void *)r < lim in sbin/ipfw2.c:list() ? /* * Count static rules. They have variable size so we * need to scan the list to count them. */ for (nstat = 1, r = data, lim = data + nbytes; r->rulenum < 65535 && (void *)r < lim; ++nstat, r = (void *)r + RULESIZE(r) ) ; /* nothing */ Can I simply check r->rulenum < 65535 as it is done in sbin/ipfw.c:list() ? TIA ps: please CC to my email. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Q about sbin/ipfw2.c:list()
On Wed, 2 Oct 2002, Barney Wolff wrote: > Hmmm. In ipfw1 there is always a rule 65535, unless I'm confused. > Is that not true of ipfw2? In either case, should it or should it > not be counted? Can it ever be deleted? Can one have multiple > rules with the same number, as one can with ipfw1? What happens > if there are multiple rules with number 65535? I know, UTSL. According to the ipfw manual page, there is always a rule 65535. I made some experiments and ipfw and ipfw2 don't allow to add or delete 65535 rule. But I'm interesting if there is such comparison in the ipfw2.c code, then should we expect that in some cases "ipfw l" command will not show some last rules, not only last rule 65535 but some rules before it? Another thing that is not clear for me is src/ip6fw/ip6fw.c:list() function, according to code of this function ip6fw command can read no more than 65536 rules. May be I should ask question about ip6fw.c:list() in another mail, but now I'm interesting about ipfw2.c:list() code. > > On Wed, Oct 02, 2002 at 06:25:46AM -0700, Luigi Rizzo wrote: > > On Wed, Oct 02, 2002 at 02:15:42PM +0300, Andrey Simonenko wrote: > > > Hello, > > > > > > Why is it needed to check both r->rulenum and (void *)r < lim in > > > sbin/ipfw2.c:list() ? > > > > because the buffer has a limited size (nbytes) and you don't want > > to read past it. However there is a bug in the code below, > > because you should swap the checks (void *)r < lim && r->rulenum < 65535 > > > > Whether ipfw1.c has the same bug or not i don't remember, but that > > is irrelevant anyways. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Q about sbin/ipfw2.c:list()
On Wed, 2 Oct 2002, Luigi Rizzo wrote:
> On Wed, Oct 02, 2002 at 02:15:42PM +0300, Andrey Simonenko wrote:
> > Hello,
> >
> > Why is it needed to check both r->rulenum and (void *)r < lim in
> > sbin/ipfw2.c:list() ?
>
> because the buffer has a limited size (nbytes) and you don't want
> to read past it. However there is a bug in the code below,
> because you should swap the checks (void *)r < lim && r->rulenum < 65535
>
> Whether ipfw1.c has the same bug or not i don't remember, but that
> is irrelevant anyways.
ipfw1.c:list() doesn't check address boundary, it checks only a rule
65535.
Why is it possible that getsockopt(IP_FW_GET) can return not all IPFW2
rules? According to ipfw(8) manual page there is always a rule 65535, so
this rule should be always present after getsockopt(IP_FW_GET) call (of
course there should be enought memory in a buffer, but it is checked in
the code of list() function):
/* get rules or pipes from kernel, resizing array as necessary */
nbytes = nalloc;
while (nbytes >= nalloc) {
nalloc = nalloc * 2 + 200;
nbytes = nalloc;
if ((data = realloc(data, nbytes)) == NULL)
err(EX_OSERR, "realloc");
if (getsockopt(s, IPPROTO_IP, ocmd, data, &nbytes) < 0)
err(EX_OSERR, "getsockopt(IP_%s_GET)",
do_pipe ? "DUMMYNET" : "FW");
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Q about sbin/ip6fw/ip6fw.c:list()
Hello,
Why is it not allowed to get more that 65536 ip6fw rules from the kernel
in the ip6fw.c:list() function?
Here is some lines from ip6fw.c:
maxbytes = 65536 * sizeof *rules;
while (bytes >= nalloc) {
nalloc = nalloc * 2 + 200;
bytes = nalloc;
if ((rules = realloc(rules, bytes)) == NULL)
err(EX_OSERR, "realloc");
i = getsockopt(s, IPPROTO_IPV6, IPV6_FW_GET, rules, &bytes);
if ((i < 0 && errno != EINVAL) || nalloc > maxbytes)
err(EX_OSERR, "getsockopt(IPV6_FW_GET)");
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: ipfw: count=pass?
On Wed, 12 Feb 2003 16:02:37 + (UTC) in lucky.freebsd.net, Andrea Venturoli wrote: > Hello! > I've tried to block users from surfing the web, once they have moved > a certain amount of traffic per week. I put a series of "count" rules > in ipfw and let cron call a script every 5 minutes to read the > associeted byte counter and possibly insert "deny" rules *after* the > count rules. There is ports/sysutils/ipa for such kind of work. > The problem is that the traffic still goes through: the counters of the > deny rules are all 0, as though they were never reached. > ipfw's manual page states that after a count the packet goes ahead in > the rule chain as if nothing has happened, but at this points I'm > beginning to wonder wether this is true or wether the count rules also > allow traffic through as if they were "pass". > This on FreeBSD 4.7-p3. > If the counter of some IPFW rule is always 0, then this means that this rule is not reached (you are right here). After "count" rule the search continues with the next rule (with the same number or with the next number, at least this is true for IPFW1, check it). You should find "allow" rule before "deny" rule which allows some traffic. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ipfw: count=pass?
On Thu, 13 Feb 2003 10:25:17 + (UTC) in lucky.freebsd.net, Andrea Venturoli wrote: > >> You should find "allow" rule before "deny" rule which allows some traffic. > > I'm really sure there wasn't any. I don't have the system here available now, but >I'm sure rules 1001-1255 were counting > traffic (and worked, as seen with ipfw -a l) and next was 2000 which should have >denied, but it's counters were 0. > Hard to say something without seeing the configuration file you use. And even if you post your ipfw configuration file, then it will be also hard to analyze it, because it has many rules. Nevertheless, double check your configuration and add logging for Firewall and check which rule allows traffic, logging should help to solve a problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
