From nobody@FreeBSD.org  Wed Aug 23 06:58:38 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id E234016A4E5
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 23 Aug 2006 06:58:38 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 6A26D43D45
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 23 Aug 2006 06:58:38 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k7N6wcSC017938
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 23 Aug 2006 06:58:38 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k7N6wcDb017937;
	Wed, 23 Aug 2006 06:58:38 GMT
	(envelope-from nobody)
Message-Id: <200608230658.k7N6wcDb017937@www.freebsd.org>
Date: Wed, 23 Aug 2006 06:58:38 GMT
From: Stephen Halpin <seh-10lzx4@mail.quadrizen.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ipfw & kernel problems where firewall rules aren't interpreted correctly
X-Send-Pr-Version: www-2.3

>Number:         102422
>Category:       bin
>Synopsis:       [patch] ipfw & kernel problems where firewall rules aren't interpreted correctly
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-ipfw
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Aug 23 07:00:28 GMT 2006
>Closed-Date:    Sat Sep 30 14:17:19 GMT 2006
>Last-Modified:  Sat Sep 30 14:17:19 GMT 2006
>Originator:     Stephen Halpin
>Release:        FreeBSD 6.1 RELEASE i386
>Organization:
None
>Environment:
FreeBSD kira 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May  7 04:42:56 UTC 2006     root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP  i386

>Description:
I'm including three ipfw problems.  The first appears to be new.  The second appears to have been addressed to some degree in 7.0 long before the 6.1 release, and never made it to 6.1.  The third is an odd side effect which results in incorrect rule matching in the kernel, and can be covered with a quick hack to ipfw, or fixed in the kernel proper.  My hope is the simple fix/workaround set might be small enough to make it into 6.2, with the hope that higher level fixes are provided over time.

The first can easily be seen with the following command:

    ipfw add allow ipv6-icmp from any to 2002::1 icmp6types 1,2,128,129

The rule is accepted with icmp6types 1,2,32,33,34,...94,95,128,129.  The problem is the data structure in /usr/src/sbin/ipfw/ipfw2.c:fill_icmp6types() is not properly initialized.  The last address must be a host address to see this behavior, where the address and netmask are written to the command buffer but the netmask isn't actually to be sent to the kernel.  The fix is to initialize the array cmd->d[] in fill_icmp6types(), which could be poorly written "for (type = 0; type < 7; type++) cmd->d[type]=0;" in place of "cmd->d[0]=0;".  Ideally one would want to leverage ICMP6_MAXTYPE, which /usr/include/netinet/ip_fw.h assumes is 203, but is actually defined as 201 in icmp6.h and 205 in ip_compat.h.  The actual array d[] in cmd is hardcoded as a length of 7 32-bit words, and should probably be scaled according to a singular definition of ICMP6_MAXTYPE, which should probably allow for all 256 possible type values.  The extra 32-bits on a 2,700 rule firewall with more icmp6types
  based rules than should be necessary due to the third bug below results in an additional 2,900 bytes of extra kernel memory usage.

The second can easily be seen with the following command:

    ipfw add deny tcp from any to 2000::/3

which fails with "ipfw: bad netmask ``:/3''".  This apparently was addressed with bug number 91245, which the query interface won't bring up for anything.  I was able to find it using the global Google.  I found a set of diffs at:

    http://lists.freebsd.org/pipermail/freebsd-bugs/2006-January/016359.html

It's still not going to do the right thing when an IPv6 hostname is used as a "from" or "to" argument.  It appears when the IPv4 and IPv6 syntax was merged, there was a desire to allow rules like 'tcp from any <port-list> to any <port-list>" could be shared across the two underlying network protocols.  I've never seen any significant rule set where this simple case occurred at all, and the result is the ability to end up with an ambiguous rule specification with IPv4 and IPv6 bits which won't match anything, and that fact may not be at all obvious to the author.  What's worse, the syntax is no longer completely compatible with either the preexisting ipfw or ipfw6 syntax, which means the user may have to have to recode their rules anyway.  I think using something like 'ipfw -4' and 'ipfw -6' or some other easily macroized form for use in rc.firewall{,6} to drive the original syntax of each would have allowed the existing rules (minus the renumbering/interleaving) to move forwa
 rd.  The syntax would no longer be ambiguous, oddness with dst-ip6 options and the like wouldn't be necessary, and the result should be safer firewalls.

The third problem can be demonstrated (thought not easily seen) with the following command:

    ipfw add allow ip6 from any to 2000::/16,2002::/16

It turns out that ipfw appears to take a list of IPv6 addresses, but the kernel only processes one address when it applies the rule.  The end result is the firewall does not behave as expected.  The simple fix here is to deny lists of ipv6 addresses until the kernel can  be brought up to date, though I'm hoping in time the kernel can be fixed.  It looks like ipfw allocates a small buffer for the entire context going to the kernel, so there may be a buffer overflow issue with sets of 256-bit address/netmasks hiding here as well in the existing ipfw implementation.
>How-To-Repeat:
Problem 1:

    ipfw add allow ipv6-icmp from any to 2002::1 icmp6types 1,2,128,129

The rule includes icmp6types 32..95 in addition to those listed above.  This can be seen on the console output when ipfw is run, either when adding the rule or when list/showing the rule.

Problem 2:

        ipfw add deny tcp from any to 2000::/3

An error message is displayed at the console and the rule is not accepted.

Problem 3:

        ipfw add allow ip6 from any to 2000::/16,2002::/16

The rule is echoed back as being accepted with multiple IPv6 addresses, but the kernel only matches one.  This requires passing traffic to see, which could be a security risk.
>Fix:
Problem 1 just requires proper intialization as described above.  A "better" solution is creating a single definition of ICMP6_MAXTYPE and sizing the array and it's initialization based on it, though there may be dependency issues with the header files which would change.

Problem 2 can be partially addressed with the patch from the in the description, which should be sufficient for the short term (6.2).  In the long term, I would strongly advocate an unambiguous syntax, as this is a security tool, and therefore must be as predictable and easy to use as possible.

Problem 3 could be addressed by having ipfw only accept a single IPv6 address as a parameter.  This would prevent the user from having what appears to be a valid firewall rule which does not properly match packets in the kernel.  A cursory look at the kernel code makes it seem fairly straightforward to have the kernel actually match multiple IPv6 addresses, though the fixed command buffer size in ipfw may have some scaling or buffer overflow issues.
>Release-Note:
>Audit-Trail:

From: "Andrey V. Elsukov" <bu7cher@yandex.ru>
To: bug-followup@FreeBSD.org
Cc: seh-10lzx4@mail.quadrizen.com, Oleg Bulyzhin <oleg@FreeBSD.org>,
	Gleb Smirnoff <glebius@FreeBSD.org>,
	Luigi Rizzo <rizzo@icir.org>
Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't
 interpreted correctly
Date: Thu, 24 Aug 2006 14:09:05 +0400

 This is a multi-part message in MIME format.
 --------------030406010708030003080707
 Content-Type: text/plain; charset=KOI8-R; format=flowed
 Content-Transfer-Encoding: 7bit
 
 Stephen Halpin wrote:
  > The rule is accepted with icmp6types 1,2,32,33,34,...94,95,128,129.
  > The problem is the data structure in
  > /usr/src/sbin/ipfw/ipfw2.c:fill_icmp6types() is not properly
  > initialized.
 
 Yes, you are right. A data buffer is previously zeroed, but
 fill_ip6() function can modified some data while parsing ipv6
 destination addresses. Quick fix is simple:
 
 --- ipfw2.c     23 Aug 2006 14:29:18 -0000      1.96
 +++ ipfw2.c     24 Aug 2006 09:08:06 -0000
 @@ -1206,7 +1206,7 @@
   {
          uint8_t type;
 
 -       cmd->d[0] = 0;
 +       bzero(cmd, sizeof(*cmd));
          while (*av) {
              if (*av == ',')
                  av++;
 
 
 But i think that here can be another similar issues.
 
  > addressed with bug number 91245, which the query interface won't
  > bring up for anything.  I was able to find it using the global
  > Google.  I found a set of diffs at:
 
 PR 91245 was closed.
 http://www.freebsd.org/cgi/query-pr.cgi?pr=91245
 
  > Problem 3:
  >
  > ipfw add allow ip6 from any to 2000::/16,2002::/16
 
 Can you try the attached patch?
 
 -- 
 WBR, Andrey V. Elsukov
 
 --------------030406010708030003080707
 Content-Type: text/plain;
  name="ipfw_fix.txt"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="ipfw_fix.txt"
 
 Index: ip_fw2.c
 ===================================================================
 RCS file: /mnt/cvs/ncvs/src/sys/netinet/ip_fw2.c,v
 retrieving revision 1.144
 diff -u -r1.144 ip_fw2.c
 --- ip_fw2.c	18 Aug 2006 22:36:04 -0000	1.144
 +++ ip_fw2.c	24 Aug 2006 09:55:38 -0000
 @@ -2869,22 +2869,20 @@
  				    &((ipfw_insn_ip6 *)cmd)->addr6);
  				break;
  			case O_IP6_SRC_MASK:
 -				if (is_ipv6) {
 -					ipfw_insn_ip6 *te = (ipfw_insn_ip6 *)cmd;
 -					struct in6_addr p = args->f_id.src_ip6;
 -
 -					APPLY_MASK(&p, &te->mask6);
 -					match = IN6_ARE_ADDR_EQUAL(&te->addr6, &p);
 -				}
 -				break;
 -
  			case O_IP6_DST_MASK:
  				if (is_ipv6) {
 -					ipfw_insn_ip6 *te = (ipfw_insn_ip6 *)cmd;
 -					struct in6_addr p = args->f_id.dst_ip6;
 +					int i = cmdlen - 1;
 +					struct in6_addr p;
 +					struct in6_addr *d = &((ipfw_insn_ip6 *)cmd)->addr6;
  
 -					APPLY_MASK(&p, &te->mask6);
 -					match = IN6_ARE_ADDR_EQUAL(&te->addr6, &p);
 +					for (; !match && i > 0; d += 2,
 +						i -= F_INSN_SIZE(struct in6_addr) * 2)
 +					{
 +						p = (cmd->opcode == O_IP6_SRC_MASK) ?
 +							args->f_id.src_ip6: args->f_id.dst_ip6;
 +						APPLY_MASK(&p, &d[1]);
 +						match = IN6_ARE_ADDR_EQUAL(&d[0], &p);
 +					}
  				}
  				break;
  
 
 --------------030406010708030003080707--
Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Aug 24 17:22:29 UTC 2006 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=102422 

From: "Stephen E. Halpin" <seh-10lzx4@mail.quadrizen.com>
To: Andrey V. Elsukov <bu7cher@yandex.ru>
Cc: bug-followup@FreeBSD.org,
 Oleg Bulyzhin <oleg@FreeBSD.org>,
 Gleb Smirnoff <glebius@FreeBSD.org>,
 Luigi Rizzo <rizzo@icir.org>
Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly
Date: Sat, 26 Aug 2006 05:01:39 -0400

 Sorry for taking so long to get back to you.  The changes look good.   
 I've tested the changes for ip_fw2.c for both source and destination  
 processing, and it worked fine.  I still have a question about PR  
 91245, as when I went to the following page:
 
      http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/
 
 and it looks like the last version of ipfw2.c is 1.96 on the MAIN  
 branch, and the changes in PR 91245 are not there.  It would be  
 awesome if all three fixes could make it into the 6.2 release!
 
 -Steve
 
 
 On Aug 24, 2006, at 6:09 AM, Andrey V. Elsukov wrote:
 
 > Stephen Halpin wrote:
 > > The rule is accepted with icmp6types 1,2,32,33,34,...94,95,128,129.
 > > The problem is the data structure in
 > > /usr/src/sbin/ipfw/ipfw2.c:fill_icmp6types() is not properly
 > > initialized.
 >
 > Yes, you are right. A data buffer is previously zeroed, but
 > fill_ip6() function can modified some data while parsing ipv6
 > destination addresses. Quick fix is simple:
 >
 > --- ipfw2.c     23 Aug 2006 14:29:18 -0000      1.96
 > +++ ipfw2.c     24 Aug 2006 09:08:06 -0000
 > @@ -1206,7 +1206,7 @@
 >  {
 >         uint8_t type;
 >
 > -       cmd->d[0] = 0;
 > +       bzero(cmd, sizeof(*cmd));
 >         while (*av) {
 >             if (*av == ',')
 >                 av++;
 >
 >
 > But i think that here can be another similar issues.
 >
 > > addressed with bug number 91245, which the query interface won't
 > > bring up for anything.  I was able to find it using the global
 > > Google.  I found a set of diffs at:
 >
 > PR 91245 was closed.
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=91245
 >
 > > Problem 3:
 > >
 > > ipfw add allow ip6 from any to 2000::/16,2002::/16
 >
 > Can you try the attached patch?
 >
 > -- 
 > WBR, Andrey V. Elsukov
 > Index: ip_fw2.c
 > ===================================================================
 > RCS file: /mnt/cvs/ncvs/src/sys/netinet/ip_fw2.c,v
 > retrieving revision 1.144
 > diff -u -r1.144 ip_fw2.c
 > --- ip_fw2.c	18 Aug 2006 22:36:04 -0000	1.144
 > +++ ip_fw2.c	24 Aug 2006 09:55:38 -0000
 > @@ -2869,22 +2869,20 @@
 >  				    &((ipfw_insn_ip6 *)cmd)->addr6);
 >  				break;
 >  			case O_IP6_SRC_MASK:
 > -				if (is_ipv6) {
 > -					ipfw_insn_ip6 *te = (ipfw_insn_ip6 *)cmd;
 > -					struct in6_addr p = args->f_id.src_ip6;
 > -
 > -					APPLY_MASK(&p, &te->mask6);
 > -					match = IN6_ARE_ADDR_EQUAL(&te->addr6, &p);
 > -				}
 > -				break;
 > -
 >  			case O_IP6_DST_MASK:
 >  				if (is_ipv6) {
 > -					ipfw_insn_ip6 *te = (ipfw_insn_ip6 *)cmd;
 > -					struct in6_addr p = args->f_id.dst_ip6;
 > +					int i = cmdlen - 1;
 > +					struct in6_addr p;
 > +					struct in6_addr *d = &((ipfw_insn_ip6 *)cmd)->addr6;
 >
 > -					APPLY_MASK(&p, &te->mask6);
 > -					match = IN6_ARE_ADDR_EQUAL(&te->addr6, &p);
 > +					for (; !match && i > 0; d += 2,
 > +						i -= F_INSN_SIZE(struct in6_addr) * 2)
 > +					{
 > +						p = (cmd->opcode == O_IP6_SRC_MASK) ?
 > +							args->f_id.src_ip6: args->f_id.dst_ip6;
 > +						APPLY_MASK(&p, &d[1]);
 > +						match = IN6_ARE_ADDR_EQUAL(&d[0], &p);
 > +					}
 >  				}
 >  				break;
 >
 

From: "Andrey V. Elsukov" <bu7cher@yandex.ru>
To: "Stephen E. Halpin" <seh-10lzx4@mail.quadrizen.com>
Cc: bug-followup@FreeBSD.org, Oleg Bulyzhin <oleg@FreeBSD.org>,
	Gleb Smirnoff <glebius@FreeBSD.org>,
	Luigi Rizzo <rizzo@icir.org>
Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't
 interpreted correctly
Date: Mon, 28 Aug 2006 14:26:36 +0400

 Stephen E. Halpin wrote:
 > processing, and it worked fine.  I still have a question about PR 91245, 
 > as when I went to the following page:
 >     http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/
 > 
 > and it looks like the last version of ipfw2.c is 1.96 on the MAIN 
 > branch, and the changes in PR 91245 are not there.  It would be awesome 
 > if all three fixes could make it into the 6.2 release!
 
 This PR was closed by rev. 1.88 in CURRENT, and rev. 1.76.2.10 in 
 RELENG_6, and will be in 6.2-RELEASE. But i don't know about this PR. 
 Gleb, Oleg - any comments? :)
 
 -- 
 WBR, Andrey V. Elsukov

From: Gleb Smirnoff <glebius@FreeBSD.org>
To: "Andrey V. Elsukov" <bu7cher@yandex.ru>
Cc: "Stephen E. Halpin" <seh-10lzx4@mail.quadrizen.com>,
        bug-followup@FreeBSD.org, Oleg Bulyzhin <oleg@FreeBSD.org>,
        Luigi Rizzo <rizzo@icir.org>
Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly
Date: Mon, 28 Aug 2006 16:15:30 +0400

 On Mon, Aug 28, 2006 at 02:26:36PM +0400, Andrey V. Elsukov wrote:
 A> Stephen E. Halpin wrote:
 A> >processing, and it worked fine.  I still have a question about PR 91245, 
 A> >as when I went to the following page:
 A> >    http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/
 A> >
 A> >and it looks like the last version of ipfw2.c is 1.96 on the MAIN 
 A> >branch, and the changes in PR 91245 are not there.  It would be awesome 
 A> >if all three fixes could make it into the 6.2 release!
 A> 
 A> This PR was closed by rev. 1.88 in CURRENT, and rev. 1.76.2.10 in 
 A> RELENG_6, and will be in 6.2-RELEASE. But i don't know about this PR. 
 A> Gleb, Oleg - any comments? :)
 
 I wonder why Max Laier, who has handled the isn't in cc?
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE

From: "Stephen E. Halpin" <seh-10lzx4@mail.quadrizen.com>
To: Andrey V. Elsukov <bu7cher@yandex.ru>
Cc: bug-followup@FreeBSD.org,
 Oleg Bulyzhin <oleg@FreeBSD.org>,
 Gleb Smirnoff <glebius@FreeBSD.org>,
 Luigi Rizzo <rizzo@icir.org>
Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly
Date: Tue, 29 Aug 2006 05:33:34 -0400

 On Aug 28, 2006, at 6:26 AM, Andrey V. Elsukov wrote:
 
 > Stephen E. Halpin wrote:
 >> processing, and it worked fine.  I still have a question about PR  
 >> 91245, as when I went to the following page:
 >>     http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/
 >> and it looks like the last version of ipfw2.c is 1.96 on the MAIN  
 >> branch, and the changes in PR 91245 are not there.  It would be  
 >> awesome if all three fixes could make it into the 6.2 release!
 >
 > This PR was closed by rev. 1.88 in CURRENT, and rev. 1.76.2.10 in  
 > RELENG_6, and will be in 6.2-RELEASE. But i don't know about this  
 > PR. Gleb, Oleg - any comments? :)
 
 Sorry, this was a misunderstanding on my part.  The diffs in the PR  
 (which is what I was looking for) are different from what's in the  
 actual fix, which was checked in to the revisions you mention.  At  
 least I know where to look next time :-/
 
 -Steve
 
 > -- 
 > WBR, Andrey V. Elsukov
 

From: Stephen E. Halpin <seh-10lzx4@mail.quadrizen.com>
To: Stephen E. Halpin <seh-10lzx4@mail.quadrizen.com>
Cc: Andrey V. Elsukov <bu7cher@yandex.ru>,
 bug-followup@FreeBSD.org,
 Oleg Bulyzhin <oleg@FreeBSD.org>,
 Gleb Smirnoff <glebius@FreeBSD.org>,
 Luigi Rizzo <rizzo@icir.org>
Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly
Date: Wed, 30 Aug 2006 01:44:01 -0400

 Erf.  I've since patched in the actual diffs for PR 91245 into a  
 clean install of 6.1-RELEASE, and it now thinks "me6" is a hostname  
 which it fails to process and dies.  An example is:
 
      ipfw add 1 deny ip6 from any to me6
      ipfw: hostname ``me6'' unknown
 
 There was a precedence issue which was addressed in MAIN, where the  
 'if' should not be taken if 'ret' is not NULL.  1.76.2.10 off  
 RELENG_6 has:
 
 	if ((ret == NULL) && proto == IPPROTO_IP || strcmp(av, "me") == 0 ||
 	    !inet_pton(AF_INET6, host, &a))
 
 1.96 off MAIN has:
 
 	if (ret == NULL && (proto == IPPROTO_IP || strcmp(av, "me") == 0 ||
 	    !inet_pton(AF_INET6, host, &a)))
 
 Note that these should occur in add_src() and add_dst().  When this  
 is added to the patches in 1.76.2.10, things appear to work.  The page:
 
      http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ipfw2.c
 
 doesn't appear to have another RELENG_6 checkin since 1.76.2.10, so  
 if possible this should be fixed there with the other changes you've  
 developed.
 
 -Steve
 
 
 On Aug 29, 2006, at 5:33 AM, Stephen E. Halpin wrote:
 
 >
 > On Aug 28, 2006, at 6:26 AM, Andrey V. Elsukov wrote:
 >
 >> Stephen E. Halpin wrote:
 >>> processing, and it worked fine.  I still have a question about PR  
 >>> 91245, as when I went to the following page:
 >>>     http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/
 >>> and it looks like the last version of ipfw2.c is 1.96 on the MAIN  
 >>> branch, and the changes in PR 91245 are not there.  It would be  
 >>> awesome if all three fixes could make it into the 6.2 release!
 >>
 >> This PR was closed by rev. 1.88 in CURRENT, and rev. 1.76.2.10 in  
 >> RELENG_6, and will be in 6.2-RELEASE. But i don't know about this  
 >> PR. Gleb, Oleg - any comments? :)
 >
 > Sorry, this was a misunderstanding on my part.  The diffs in the PR  
 > (which is what I was looking for) are different from what's in the  
 > actual fix, which was checked in to the revisions you mention.  At  
 > least I know where to look next time :-/
 >
 > -Steve
 >
 >> -- 
 >> WBR, Andrey V. Elsukov
 >
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/102422: commit references a PR
Date: Sat, 16 Sep 2006 06:34:44 +0000 (UTC)

 jhay        2006-09-16 06:34:30 UTC
 
   FreeBSD src repository
 
   Modified files:
     sbin/ipfw            ipfw2.c 
   Log:
   Use bzero() to clear the whole ipfw_insn_icmp6 structure in fill_icmp6types(),
   otherwise this command
   
   ipfw add allow ipv6-icmp from any to 2002::1 icmp6types 1,2,128,129
   
   turns into icmp6types 1,2,32,33,34,...94,95,128,129
   
   PR:             102422 (part 1)
   Submitted by:   Andrey V. Elsukov <bu7cher at yandex.ru>
   MFC after:      5 days
   
   Revision  Changes    Path
   1.97      +1 -1      src/sbin/ipfw/ipfw2.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/102422: commit references a PR
Date: Sat, 16 Sep 2006 10:27:22 +0000 (UTC)

 jhay        2006-09-16 10:27:05 UTC
 
   FreeBSD src repository
 
   Modified files:
     sys/netinet          ip_fw2.c 
   Log:
   Handle a list of IPv6 src and dst addresses correctly, eg.
   ipfw add allow ip6 from any to 2000::/16,2002::/16
   
   PR:             102422 (part 3)
   Submitted by:   Andrey V. Elsukov <bu7cher at yandex dot ru>
   MFC after:      5 days
   
   Revision  Changes    Path
   1.147     +17 -14    src/sys/netinet/ip_fw2.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/102422: commit references a PR
Date: Wed, 20 Sep 2006 19:15:34 +0000 (UTC)

 jhay        2006-09-20 19:15:03 UTC
 
   FreeBSD src repository
 
   Modified files:        (Branch: RELENG_6)
     sys/netinet          ip_fw2.c 
   Log:
   MFC: 1.147
   Handle a list of IPv6 src and dst addresses correctly, eg.
   ipfw add allow ip6 from any to 2000::/16,2002::/16
   
   PR:             102422 (part 3)
   Submitted by:   Andrey V. Elsukov <bu7cher at yandex dot ru>
   Approved by:    re (hrs)
   
   Revision    Changes    Path
   1.106.2.20  +17 -14    src/sys/netinet/ip_fw2.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/102422: commit references a PR
Date: Wed, 20 Sep 2006 19:18:32 +0000 (UTC)

 jhay        2006-09-20 19:18:03 UTC
 
   FreeBSD src repository
 
   Modified files:        (Branch: RELENG_6)
     sbin/ipfw            ipfw2.c 
   Log:
   MFC: 1.97
   Use bzero() to clear the whole ipfw_insn_icmp6 structure in fill_icmp6types(),
   otherwise this command
   
   ipfw add allow ipv6-icmp from any to 2002::1 icmp6types 1,2,128,129
   
   turns into icmp6types 1,2,32,33,34,...94,95,128,129
   
   PR:             102422 (part 1)
   Submitted by:   Andrey V. Elsukov <bu7cher at yandex.ru>
   Approved by:    re (hrs)
   
   Revision   Changes    Path
   1.76.2.12  +1 -1      src/sbin/ipfw/ipfw2.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->closed 
State-Changed-By: jhay 
State-Changed-When: Sat Sep 30 14:15:01 UTC 2006 
State-Changed-Why:  
Committed the fixes by Andrey for parts 1 and 3. Part 2 was already fixed. 
Also merged it to RELENG_6. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=102422 
>Unformatted:
