From nobody@FreeBSD.org  Thu May  8 13:53:21 2014
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1])
	(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hub.freebsd.org (Postfix) with ESMTPS id 14E7D25F
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  8 May 2014 13:53:21 +0000 (UTC)
Received: from cgiserv.freebsd.org (cgiserv.freebsd.org [IPv6:2001:1900:2254:206a::50:4])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 02EF3220
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  8 May 2014 13:53:21 +0000 (UTC)
Received: from cgiserv.freebsd.org ([127.0.1.6])
	by cgiserv.freebsd.org (8.14.8/8.14.8) with ESMTP id s48DrK4D094144
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 8 May 2014 13:53:20 GMT
	(envelope-from nobody@cgiserv.freebsd.org)
Received: (from nobody@localhost)
	by cgiserv.freebsd.org (8.14.8/8.14.8/Submit) id s48DrKpL094143;
	Thu, 8 May 2014 13:53:20 GMT
	(envelope-from nobody)
Message-Id: <201405081353.s48DrKpL094143@cgiserv.freebsd.org>
Date: Thu, 8 May 2014 13:53:20 GMT
From: Dennis Yusupoff <dyr@smartspb.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ipfw table regression
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         189471
>Category:       bin
>Synopsis:       [ipfw] ipfw table regression
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    melifaro
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu May 08 14:00:00 UTC 2014
>Closed-Date:    
>Last-Modified:  Sun May 18 04:50:00 UTC 2014
>Originator:     Dennis Yusupoff
>Release:        10.0-STABLE, 9.2-RELEASE
>Organization:
Smart Telecom
>Environment:
FreeBSD nata1 10.0-STABLE FreeBSD 10.0-STABLE #1 r261884M: Mon Mar 31 16:01:36 MSK 2014     root@nata1:/usr/obj/usr/src/sys/ROUTER_HN  amd64

FreeBSD utm.leskolovo.ru 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013     root@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
There is regression in ipfw table adding, in compare with, for example,
9.0-RELEASE.

Adding some hostname in a ipfw table leading in appearance of record
'::/0 0' instead of correct IPv4 address. See below ("how to repeat the
problem").  After this record appeared in ipfw table it passing ALL
traffic, even all IPv4 addresses.

>How-To-Repeat:
# uname -a
FreeBSD nata1 10.0-STABLE FreeBSD 10.0-STABLE #1 r261884M: Mon Mar 31 16:01:36 MSK 2014     root@nata1:/usr/obj/usr/src/sys/ROUTER_HN  amd64
# ipfw table 100 flush
# host 3ds.ubrr.ru
3ds.ubrr.ru has address 91.208.121.209
# ipfw table 100 add 3ds.ubrr.ru
# ipfw table 100 list
::/0 0

---
# uname -a
FreeBSD utm.leskolovo.ru 9.2-RELEASE FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013     root@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
# ipfw table 92 flush
# host 3ds.ubrr.ru
3ds.ubrr.ru has address 91.208.121.209
# ipfw table 92 add 3ds.ubrr.ru
# ipfw table 92 list
::/0 0

----
# uname -a
FreeBSD stek 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Fri Mar 16 05:08:15 MSK 2012     root@bsd9:/usr/obj/usr/src/sys/ROUTER_HOME_NETS  amd64
# ipfw table 90 flush
# host 3ds.ubrr.ru
3ds.ubrr.ru has address 91.208.121.209
# ipfw table 90 add 3ds.ubrr.ru
# ipfw table 90 list
91.208.121.209/32 0


>Fix:
Don't know

>Release-Note:
>Audit-Trail:

From: bycn82 <bycn82@gmail.com>
To: bug-followup@FreeBSD.org, dyr@smartspb.net
Cc:  
Subject: Re: bin/189471: ipfw table regression
Date: Tue, 13 May 2014 14:45:11 +0800

 This is a multi-part message in MIME format.
 --------------040309010906080603070008
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 developers are still working on it, so
 
 1.    you can get the latest source which already fixed this issue.
 
 2.    or just comment out the whole else trunk as below
          } else {
              /* Port or any other key */
              key = strtol(arg, &p, 10);
              /* Skip non-base 10 entries like 'fa1' */
              if (p != arg) {
                  pkey = (uint32_t *)paddr;
                  *pkey = htonl(key);
                  type = IPFW_TABLE_CIDR;
                  addrlen = sizeof(uint32_t);
              }
          }
 
 3.    or only comment out this  line in the else trunk
      type = IPFW_TABLE_CIDR;
 
 
 Can the developer help to explain what kind of data you want to support 
 in the table?
 
 --------------040309010906080603070008--

From: Dennis Yusupoff <dyr@smartspb.net>
To: bycn82 <bycn82@gmail.com>, bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/189471: ipfw table regression
Date: Tue, 13 May 2014 13:58:11 +0400

 This is a multi-part message in MIME format.
 --------------060309080704020200020902
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 OK, I will try.
 
 I think it's a time to add "helper" argument to *ipfw table add* command
 so that you could set data type explicity, is it IPv6 or IPv4. Something
 like that:
 
 ipfw table XX add beef.de ipv6
 ipfw table XX add beef.de ipv4
 
 AFAIK, it greatly reduce complexity of programming attempt to guess what
 kind of input data user meant.
 
 -- 
 Best regards,
 Dennis Yusupoff,
 network engineer of
 Smart-Telecom ISP
 Russia, Saint-Petersburg 
 
 --------------060309080704020200020902--
Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Tue May 13 10:56:39 UTC 2014 
Responsible-Changed-Why:  
Over to maintainer(s). 

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

From: Marcelo Gondim <gondim@intnet.com.br>
To: bug-followup@FreeBSD.org, dyr@smartspb.net
Cc:  
Subject: Re: bin/189471: [ipfw] ipfw table regression
Date: Tue, 13 May 2014 11:13:29 -0300

 This is a multi-part message in MIME format.
 --------------020508070802030905040507
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 The problem continues. Try:
 
 # ipfw table 99 add 0.0.0.0/8
 # ipfw table 99 list
 ::/8 0
 
 # uname -a
 FreeBSD mail.xxxxxx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #14 r265947: 
 Tue May 13 08:18:03 BRT 2014 
 root@mail.xxxxxx.com.br:/usr/obj/usr/src/sys/GONDIM  amd64
 
 Cheers,
 
 --------------020508070802030905040507
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 <html>
   <head>
 
     <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
   </head>
   <body text="#000000" bgcolor="#FFFFFF">
     <meta http-equiv="content-type" content="text/html;
       charset=ISO-8859-1">
     <span id="result_box" class="short_text" lang="en"><span class="hps">The
         problem</span> <span class="hps">continues</span><span class="">.</span>
       <span class="hps">Try</span><span class="">:<br>
         <br>
         # ipfw table 99 add 0.0.0.0/8<br>
         # ipfw table 99 list<br>
         ::/8 0<br>
         <br>
         # uname -a<br>
         FreeBSD mail.xxxxxx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #14
         r265947: Tue May 13 08:18:03 BRT 2014&nbsp;&nbsp;&nbsp;&nbsp;
         <a class="moz-txt-link-abbreviated" href="mailto:root@mail.xxxxxx.com.br:/usr/obj/usr/src/sys/GONDIM">root@mail.xxxxxx.com.br:/usr/obj/usr/src/sys/GONDIM</a>&nbsp; amd64<br>
         <br>
         Cheers,<br>
       </span></span>
   </body>
 </html>
 
 --------------020508070802030905040507--
Responsible-Changed-From-To: freebsd-ipfw->melifaro 
Responsible-Changed-By: melifaro 
Responsible-Changed-When: Sat May 17 12:07:29 UTC 2014 
Responsible-Changed-Why:  
Take. 

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

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/189471: commit references a PR
Date: Sat, 17 May 2014 13:45:08 +0000 (UTC)

 Author: melifaro
 Date: Sat May 17 13:45:03 2014
 New Revision: 266310
 URL: http://svnweb.freebsd.org/changeset/base/266310
 
 Log:
   Fix wrong formatting of 0.0.0.0/X table records in ipfw(8).
   
   Add `flags` u16 field to the hole in ipfw_table_xentry structure.
   Kernel has been guessing address family for supplied record based
   on xent length size.
   Userland, however, has been getting fixed-size ipfw_table_xentry structures
   guessing address family by checking address by IN6_IS_ADDR_V4COMPAT().
   
   Fix this behavior by providing specific IPFW_TCF_INET flag for IPv4 records.
   
   PR:		bin/189471
   Submitted by:	Dennis Yusupoff <dyr@smartspb.net>
   MFC after:	2 weeks
 
 Modified:
   head/sbin/ipfw/ipfw2.c
   head/sys/netinet/ip_fw.h
   head/sys/netpfil/ipfw/ip_fw_table.c
 
 Modified: head/sbin/ipfw/ipfw2.c
 ==============================================================================
 --- head/sbin/ipfw/ipfw2.c	Sat May 17 12:47:11 2014	(r266309)
 +++ head/sbin/ipfw/ipfw2.c	Sat May 17 13:45:03 2014	(r266310)
 @@ -4389,7 +4389,7 @@ table_list(uint16_t num, int need_header
  			addr6 = &xent->k.addr6;
  
  
 -			if (IN6_IS_ADDR_V4COMPAT(addr6)) {
 +			if ((xent->flags & IPFW_TCF_INET) != 0) {
  				/* IPv4 address */
  				inet_ntop(AF_INET, &addr6->s6_addr32[3], tbuf, sizeof(tbuf));
  			} else {
 
 Modified: head/sys/netinet/ip_fw.h
 ==============================================================================
 --- head/sys/netinet/ip_fw.h	Sat May 17 12:47:11 2014	(r266309)
 +++ head/sys/netinet/ip_fw.h	Sat May 17 13:45:03 2014	(r266310)
 @@ -614,6 +614,7 @@ typedef struct	_ipfw_table_xentry {
  	uint8_t		type;		/* entry type			*/
  	uint8_t		masklen;	/* mask length			*/
  	uint16_t	tbl;		/* table number			*/
 +	uint16_t	flags;		/* record flags			*/
  	uint32_t	value;		/* value			*/
  	union {
  		/* Longest field needs to be aligned by 4-byte boundary	*/
 @@ -621,6 +622,7 @@ typedef struct	_ipfw_table_xentry {
  		char	iface[IF_NAMESIZE];	/* interface name	*/
  	} k;
  } ipfw_table_xentry;
 +#define	IPFW_TCF_INET	0x01		/* CIDR flags: IPv4 record	*/
  
  typedef struct	_ipfw_table {
  	u_int32_t	size;		/* size of entries in bytes	*/
 
 Modified: head/sys/netpfil/ipfw/ip_fw_table.c
 ==============================================================================
 --- head/sys/netpfil/ipfw/ip_fw_table.c	Sat May 17 12:47:11 2014	(r266309)
 +++ head/sys/netpfil/ipfw/ip_fw_table.c	Sat May 17 13:45:03 2014	(r266310)
 @@ -697,6 +697,7 @@ dump_table_xentry_base(struct radix_node
  		xent->masklen = 33 - ffs(ntohl(n->mask.sin_addr.s_addr));
  	/* Save IPv4 address as deprecated IPv6 compatible */
  	xent->k.addr6.s6_addr32[3] = n->addr.sin_addr.s_addr;
 +	xent->flags = IPFW_TCF_INET;
  	xent->value = n->value;
  	tbl->cnt++;
  	return (0);
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: bycn82 <bycn82@gmail.com>
To: Dennis Yusupoff <dyr@smartspb.net>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/189471: ipfw table regression
Date: Sun, 18 May 2014 12:48:29 +0800

 This is a multi-part message in MIME format.
 --------------040401090807030506010600
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 On 5/13/14 17:58, Dennis Yusupoff wrote:
 > OK, I will try.
 >
 > I think it's a time to add "helper" argument to *ipfw table add* 
 > command so that you could set data type explicity, is it IPv6 or IPv4. 
 > Something like that:
 >
 > ipfw table XX add beef.de ipv6
 > ipfw table XX add beef.de ipv4
 >
 > AFAIK, it greatly reduce complexity of programming attempt to guess 
 > what kind of input data user meant.
 >
 > 13.05.2014 10:45, bycn82 ?????:
 >> developers are still working on it, so
 >>
 >> 1.    you can get the latest source which already fixed this issue.
 >>
 >> 2.    or just comment out the whole else trunk as below
 >>         } else {
 >>             /* Port or any other key */
 >>             key = strtol(arg, &p, 10);
 >>             /* Skip non-base 10 entries like 'fa1' */
 >>             if (p != arg) {
 >>                 pkey = (uint32_t *)paddr;
 >>                 *pkey = htonl(key);
 >>                 type = IPFW_TABLE_CIDR;
 >>                 addrlen = sizeof(uint32_t);
 >>             }
 >>         }
 >>
 >> 3.    or only comment out this  line in the else trunk
 >>     type = IPFW_TABLE_CIDR;
 >>
 >>
 >> Can the developer help to explain what kind of data you want to 
 >> support in the table?
 >
 > -- 
 > Best regards,
 > Dennis Yusupoff,
 > network engineer of
 > Smart-Telecom ISP
 > Russia, Saint-Petersburg
 1.Totally agree with you,And maybe the better design will be "define the 
 type of the table in the beginning."
 2.Currently it supports only ipv4 &ipv6, actually it can support more types.
 3.Currently it supports hostname/domain in the command line,But the the 
 mapping between IP and domain is not always accurate because it is 
 depends on the dns service.
 
 
 
 
 
 
 --------------040401090807030506010600
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 <html>
   <head>
     <meta content="text/html; charset=ISO-8859-1"
       http-equiv="Content-Type">
   </head>
   <body bgcolor="#FFFFFF" text="#000000">
     On 5/13/14 17:58, Dennis Yusupoff wrote:
     <blockquote cite="mid:5371ECB3.2020603@smartspb.net" type="cite">
       <meta content="text/html; charset=ISO-8859-1"
         http-equiv="Content-Type">
       OK, I will try.<br>
       <br>
       I think it's a time to add "helper" argument to *ipfw table add*
       command so that you could set data type explicity, is it IPv6 or
       IPv4. Something like that:<br>
       <br>
       ipfw table XX add beef.de ipv6<br>
       ipfw table XX add beef.de ipv4<br>
       <br>
       AFAIK, it greatly reduce complexity of programming attempt to
       guess what kind of input data user meant.<br>
       <br>
       <div class="moz-cite-prefix">13.05.2014 10:45, bycn82 &#1087;&#1080;&#1096;&#1077;&#1090;:<br>
       </div>
       <blockquote cite="mid:5371BF77.5060400@gmail.com" type="cite">
         <meta http-equiv="content-type" content="text/html;
           charset=ISO-8859-1">
         <font face="Calibri">developers are still working on it, so <br>
           <br>
           1.&nbsp;&nbsp;&nbsp; you can get the latest source which already fixed this
           issue.<br>
           <br>
           2.&nbsp;&nbsp;&nbsp; or just comment out the whole else trunk as below<br>
           &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; } else {<br>
           &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; /* Port or any other key */<br>
           &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; key = strtol(arg, &amp;p, 10);<br>
           &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; /* Skip non-base 10 entries like 'fa1' */<br>
           &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if (p != arg) {<br>
           &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; pkey = (uint32_t *)paddr;<br>
           &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; *pkey = htonl(key);<br>
           &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; type = IPFW_TABLE_CIDR;<br>
           &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; addrlen = sizeof(uint32_t);<br>
           &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
           &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }<br>
           <br>
           3.&nbsp;&nbsp;&nbsp; or only comment out this&nbsp; line in the else trunk <br>
         </font><font face="Calibri"> &nbsp;&nbsp;&nbsp; type = IPFW_TABLE_CIDR;</font><br>
         <br>
         &nbsp; <br>
         <font face="Calibri">Can the developer help to explain what kind
           of data you want to support in the table?<br>
         </font> </blockquote>
       <br>
       <pre class="moz-signature" cols="72">-- 
 Best regards,
 Dennis Yusupoff,
 network engineer of
 Smart-Telecom ISP
 Russia, Saint-Petersburg </pre>
     </blockquote>
     <font face="Calibri">1.Totally agree with you,And maybe the better
       design will be "define the type of the table in the beginning."<br>
       2.Currently it supports only ipv4 &amp;ipv6, actually it can
       support more types.<br>
       3.Currently it supports hostname/domain in the command line,But
       the the mapping between IP and domain is not always accurate
       because it is depends on the dns service.<br>
       <br>
       <br>
       <br>
       <br>
       <br>
     </font>
   </body>
 </html>
 
 --------------040401090807030506010600--
>Unformatted:
