From danielh@zorkmid.dakcs.com  Fri Aug  1 09:56:24 1997
Received: from zorkmid.dakcs.com (zorkmid.dakcs.com [206.29.223.201])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA29068
          for <FreeBSD-gnats-submit@freebsd.org>; Fri, 1 Aug 1997 09:56:19 -0700 (PDT)
Received: (from danielh@localhost)
	by zorkmid.dakcs.com (8.8.5/8.8.5) id QAA03913;
	Fri, 1 Aug 1997 16:56:08 GMT
Message-Id: <199708011656.QAA03913@zorkmid.dakcs.com>
Date: Fri, 1 Aug 1997 16:56:08 GMT
From: danielh@dakcs.com
Reply-To: danielh@dakcs.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: ipfw does not work with multiple digit interface numbers
X-Send-Pr-Version: 3.2

>Number:         4209
>Category:       bin
>Synopsis:       ipfw does not work with multiple digit interface numbers
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    alex
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Aug  1 10:00:00 PDT 1997
>Closed-Date:    Wed Aug 20 18:30:09 PDT 1997
>Last-Modified:  Wed Aug 20 18:33:06 PDT 1997
>Originator:     Daniel Holmes
>Release:        FreeBSD 2.2.2-RELEASE i386
>Organization:
DAKCS Software Systems
>Environment:

	FreeBSD-2.2.2-RELEASE, Emerging Technologies Frame Relay Card.

>Description:

	Emerging Technologies FR Card creates interfaces based on the DLCI
	of the Frame Relay PVC.  If the DLCI is several digits (i.e. 16),
	ipfw truncates the interface to a single digit. This causes actions
	to be performed on the wrong interface, or no action whatsoever

>How-To-Repeat:

	Try this at a command line: (as root, of course)

	ipfw add allow ip from any to any via etha16

	Result is:
	Warning: interface does not exist
	00000 allow ip from any to any via etha1

	At this point, an 'ipfw list' produces:
	65100 allow ip from any to any via etha1 

>Fix:
	
	No workarounds/fixes known by me.

>Release-Note:
>Audit-Trail:

From: Nate Williams <nate@mt.sri.com>
To: danielh@dakcs.com
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/4209: ipfw does not work with multiple digit interface numbers
Date: Fri, 1 Aug 1997 13:23:55 -0600 (MDT)

 > >Number:         4209
 > >Category:       bin
 > >Synopsis:       ipfw does not work with multiple digit interface numbers
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    freebsd-bugs
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   current-users
 > >Arrival-Date:   Fri Aug  1 10:00:00 PDT 1997
 > >Last-Modified:
 > >Originator:     Daniel Holmes
 > >Organization:
 > DAKCS Software Systems
 > >Release:        FreeBSD 2.2.2-RELEASE i386
 > >Environment:
 > 
 > 	FreeBSD-2.2.2-RELEASE, Emerging Technologies Frame Relay Card.
 > 
 > >Description:
 > 
 > 	Emerging Technologies FR Card creates interfaces based on the DLCI
 > 	of the Frame Relay PVC.  If the DLCI is several digits (i.e. 16),
 > 	ipfw truncates the interface to a single digit. This causes actions
 > 	to be performed on the wrong interface, or no action whatsoever
 > 
 > >How-To-Repeat:
 > 
 > 	Try this at a command line: (as root, of course)
 > 
 > 	ipfw add allow ip from any to any via etha16
 > 
 > 	Result is:
 > 	Warning: interface does not exist
 > 	00000 allow ip from any to any via etha1
 > 
 > 	At this point, an 'ipfw list' produces:
 > 	65100 allow ip from any to any via etha1 
 
 Hmm, this works in 2.1-stable:
 
 # /sbin/ipfw add 65000 deny log all from any to any via etha16
 
 What's the output of:
 # ifconfig etha16
 
 
 Nate

From: Daniel Holmes <danielh@dakcs.com>
To: nate@mt.sri.com
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/4209: ipfw does not work with multiple digit interface numbers
Date: Mon, 4 Aug 1997 15:58:51 GMT

    Hmm, this works in 2.1-stable:
 
    # /sbin/ipfw add 65000 deny log all from any to any via etha16
 
 Just tried it on 2.2-RELEASE, no go.  I'll check some sources and see
 what has changed. 
 
    What's the output of:
    # ifconfig etha16
 
 # ifconfig -a
 ed0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         inet 207.108.157.97 netmask 0xfffffff0 broadcast 207.108.157.111
         ether 00:c0:26:38:ab:4a
 lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
 eth0: flags=41<UP,RUNNING> mtu 1500
         inet 192.168.1.3 netmask 0xffffffff
 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
         inet 127.0.0.1 netmask 0xff000000
 etha16: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
         inet 206.80.195.22 --> 206.80.195.21 netmask 0xfffffffc
 
 I did check the source to ipfw.c over the weekend, and it looks like
 when it sets up the unit name and number, it sets the last
 character from the string to a null but it looks like it gets
 everything after the first digit on the unit number.  At line 742 in ipfw.c:
 
 	rule.fw_via_name[sizeof(rule.fw_via_name) - 1] = '\0';
 
 changing that to
 
 	rule.fw_via_name[sizeof(rule.fw_via_name)] = '\0';      
 
 at least makes the rule show up correctly in the 'ipfw list' command,
 but I don't know if it actually does any good, or not.  I did notice
 that it doesn't accept 3 digit unit numbers, but that is a secondary
 concern at the moment.
 
 uname gives:
 FreeBSD ns1.recoverycoll.com 2.2.2-RELEASE FreeBSD 2.2.2-RELEASE #0: Wed Jul 2
 14:38:29 GMT 1997 danielh@hwroom.dakcs.com:/usr/src/sys/compile/FIREWALL i386
 
 Any ideas?  
 
 Thanks,
 Dan
 
 -- 
 Daniel D Holmes, N7NKR               "Mr. Worf, fire at will!"  <ZAP!>
 I'net:  DANIELH@DAKCS.COM            "Hey--where'd Riker go?"
 Standard disclaimers apply wherever you can find a sticky spot.

From: Nate Williams <nate@mt.sri.com>
To: Daniel Holmes <danielh@dakcs.com>
Cc: nate@mt.sri.com, FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/4209: ipfw does not work with multiple digit interface numbers
Date: Mon, 4 Aug 1997 14:07:35 -0600 (MDT)

 > Any ideas?  
 
 None.  Ask alex@FreeBSD.org.
 
 
 Nate

From: Alex Nash <nash@mcs.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:  Subject: Re: bin/4209: ipfw does not work with multiple digit interface numbers
Date: Tue, 05 Aug 1997 07:44:58 -0500

 Daniel Holmes wrote:
 >  I did check the source to ipfw.c over the weekend, and it looks like
 >  when it sets up the unit name and number, it sets the last
 >  character from the string to a null but it looks like it gets
 >  everything after the first digit on the unit number.  At line 742 in ipfw.c:
 > 
 >         rule.fw_via_name[sizeof(rule.fw_via_name) - 1] = '\0';
 > 
 >  changing that to
 > 
 >         rule.fw_via_name[sizeof(rule.fw_via_name)] = '\0';
 
 You don't want that, it'll overwrite the unit field.
 
 The real problem is that the name field is fixed at 6 characters,
 even though net/if.h defines IFNAMSIZ to be 16.  The following
 (briefly tested) patch discards some flexibility in ICMP type
 handling in return for a longer name size.  Previously, any ICMP
 type from 0-255 could be used even though a only handful were
 useful (typically 0-18).  Since the ip_fw structure couldn't be
 expanded beyond its current 108 byte size (due to setsockopt),
 I threw out some of the not-so-often used ICMP types -- those
 above 31.
 
 I've purposely resized the structure to 104 bytes to make it
 incompatible with previous versions of ipfw.
 
 Since the fine folks at Whistle Communications have kept the
 2.2 and -current trees in sync, this patch should apply cleanly
 to both trees.
 
 Alex
 
 Index: src/sbin/ipfw/ipfw.c
 ===================================================================
 RCS file: /cvs/src/sbin/ipfw/ipfw.c,v
 retrieving revision 1.34.2.5
 diff -c -r1.34.2.5 ipfw.c
 *** ipfw.c	1997/06/23 22:34:24	1.34.2.5
 --- ipfw.c	1997/08/04 23:41:07
 ***************
 *** 384,390 ****
   
   		printf(" icmptype");
   
 ! 		for (type_index = 0; type_index < 256; ++type_index)
   			if (chain->fw_icmptypes[type_index / (sizeof(unsigned) * 8)] & 
   				(1U << (type_index % (sizeof(unsigned) * 8)))) {
   				printf("%c%d", first == 1 ? ' ' : ',', type_index);
 --- 384,390 ----
   
   		printf(" icmptype");
   
 ! 		for (type_index = 0; type_index < IP_FW_ICMPTYPES_DIM * sizeof(unsigned) * 8; ++type_index)
   			if (chain->fw_icmptypes[type_index / (sizeof(unsigned) * 8)] & 
   				(1U << (type_index % (sizeof(unsigned) * 8)))) {
   				printf("%c%d", first == 1 ? ' ' : ',', type_index);
 ***************
 *** 697,704 ****
   		if ( *c != ',' && *c != '\0' )
   			show_usage("invalid ICMP type");
   
 ! 		if (icmptype > 255)
 ! 			show_usage("ICMP types are between 0 and 255 inclusive");
   
   		types[icmptype / (sizeof(unsigned) * 8)] |= 
   			1 << (icmptype % (sizeof(unsigned) * 8));
 --- 697,704 ----
   		if ( *c != ',' && *c != '\0' )
   			show_usage("invalid ICMP type");
   
 ! 		if (icmptype >= IP_FW_ICMPTYPES_DIM * sizeof(unsigned) * 8)
 ! 			show_usage("ICMP type out of range");
   
   		types[icmptype / (sizeof(unsigned) * 8)] |= 
   			1 << (icmptype % (sizeof(unsigned) * 8));
 Index: src/sys/netinet/ip_fw.h
 ===================================================================
 RCS file: /cvs/src/sys/netinet/ip_fw.h,v
 retrieving revision 1.23.2.2
 diff -c -r1.23.2.2 ip_fw.h
 *** ip_fw.h	1997/06/20 23:05:34	1.23.2.2
 --- ip_fw.h	1997/08/04 22:58:41
 ***************
 *** 17,22 ****
 --- 17,24 ----
   #ifndef _IP_FW_H
   #define _IP_FW_H
   
 + #include <net/if.h>
 + 
   /*
    * This union structure identifies an interface, either explicitly
    * by name or implicitly by IP address. The flags IP_FW_F_IIFNAME
 ***************
 *** 33,39 ****
   union ip_fw_if {
       struct in_addr fu_via_ip;	/* Specified by IP address */
       struct {			/* Specified by interface name */
 ! #define FW_IFNLEN	6	/* To keep structure on 2^x boundary */
   	    char  name[FW_IFNLEN];
   	    short unit;		/* -1 means match any unit */
       } fu_via_if;
 --- 35,41 ----
   union ip_fw_if {
       struct in_addr fu_via_ip;	/* Specified by IP address */
       struct {			/* Specified by interface name */
 ! #define FW_IFNLEN     IFNAMSIZ
   	    char  name[FW_IFNLEN];
   	    short unit;		/* -1 means match any unit */
       } fu_via_if;
 ***************
 *** 58,64 ****
       u_short fw_pts[IP_FW_MAX_PORTS];	/* Array of port numbers to match */
       u_char fw_ipopt,fw_ipnopt;		/* IP options set/unset */
       u_char fw_tcpf,fw_tcpnf;		/* TCP flags set/unset */
 ! #define IP_FW_ICMPTYPES_DIM (256 / (sizeof(unsigned) * 8))
       unsigned fw_icmptypes[IP_FW_ICMPTYPES_DIM]; /* ICMP types bitmap */
       long timestamp;			/* timestamp (tv_sec) of last match */
       union ip_fw_if fw_in_if, fw_out_if;	/* Incoming and outgoing interfaces */
 --- 60,66 ----
       u_short fw_pts[IP_FW_MAX_PORTS];	/* Array of port numbers to match */
       u_char fw_ipopt,fw_ipnopt;		/* IP options set/unset */
       u_char fw_tcpf,fw_tcpnf;		/* TCP flags set/unset */
 ! #define IP_FW_ICMPTYPES_DIM (32 / (sizeof(unsigned) * 8))
       unsigned fw_icmptypes[IP_FW_ICMPTYPES_DIM]; /* ICMP types bitmap */
       long timestamp;			/* timestamp (tv_sec) of last match */
       union ip_fw_if fw_in_if, fw_out_if;	/* Incoming and outgoing interfaces */
State-Changed-From-To: open->analyzed 
State-Changed-By: alex 
State-Changed-When: Tue Aug 5 05:55:24 PDT 1997 
State-Changed-Why:  
I have a preliminary patch ready to fix this. 


Responsible-Changed-From-To: freebsd-bugs->alex 
Responsible-Changed-By: alex 
Responsible-Changed-When: Tue Aug 5 05:55:24 PDT 1997 
Responsible-Changed-Why:  
I'll commit the patch after some more thought. 
State-Changed-From-To: analyzed->closed 
State-Changed-By: alex 
State-Changed-When: Wed Aug 20 18:30:09 PDT 1997 
State-Changed-Why:  
Fix applied to 2.2-STABLE: 
ipfw.c    rev 1.34.2.6 
ip_fw.h   rev 1.23.2.2 
>Unformatted:
