From hsw@generalresources.com  Thu Jan 18 19:36:36 2001
Return-Path: <hsw@generalresources.com>
Received: from mail.tucheng.generalresources.com (a1.tucheng.generalresources.com [211.21.4.234])
	by hub.freebsd.org (Postfix) with ESMTP id B14B937B400
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 18 Jan 2001 19:36:34 -0800 (PST)
Received: from w40.tucheng.generalresources.com (w40.tucheng.generalresources.com [192.168.1.40])
	by mail.tucheng.generalresources.com (8.11.1/8.11.1) with ESMTP id f0J3aWh33472
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 19 Jan 2001 11:36:37 +0800 (CST)
	(envelope-from hsw@generalresources.com)
Received: (from hsw@localhost)
	by w40.tucheng.generalresources.com (8.11.1/8.11.1) id f0J3aVe43887;
	Fri, 19 Jan 2001 11:36:31 +0800 (CST)
	(envelope-from hsw)
Message-Id: <200101190336.f0J3aVe43887@w40.tucheng.generalresources.com>
Date: Fri, 19 Jan 2001 11:36:31 +0800 (CST)
From: Christopher Hall <hsw@acm.org>
Reply-To: Christopher Hall <hsw@acm.org>
To: FreeBSD-gnats-submit@freebsd.org
Subject: ipnat does not parse its file properly
X-Send-Pr-Version: 3.2

>Number:         24445
>Category:       gnu
>Synopsis:       ipnat does not parse its file properly
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    darrenr
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jan 18 19:40:01 PST 2001
>Closed-Date:    Wed Nov 14 13:55:29 MET 2001
>Last-Modified:  Wed Nov 14 13:57:29 MET 2001
>Originator:     Christopher Hall
>Release:        FreeBSD 4.2-STABLE i386
>Organization:
>Environment:

  4.2-STABLE FreeBSD 4.2-STABLE #0: Thu Jan 18 13:15:08 CST 2001

>Description:

 Using the following configuration file:

   map fxp1 192.168.1.250/16 -> 1.2.3.4/32 portmap  tcp/udp 40000:60000
   map fxp1 192.168.1.250/16 -> 1.2.3.4/32
   ##rdr fxp0 192.168.1.250/32 port 80      -> 4.5.6.7 port 80
   rdr fxp0 192.168.1.250/32 port http      -> 4.5.6.7 port http
   rdr fxp0 192.168.1.250/32 port https     -> 4.5.6.7 port https


Get errors like this

  4: unknown service "http".
  4: syntax error in "rdr"
  5: unknown service "https".
  5: syntax error in "rdr"

 can stop error by:
  a) remove the '##' in line 3
  b) comment out line 1
  c) move line 1 to end of file


The problem is caused by a global variable in the file common.c
its definition is:   char    *proto = NULL;

the file natparse.c uses the routine "portnum" to convert the
string "http" to a number

'proto' is now pointing at the position in the line buffer where
the string "tcp/udp" used to be from line 1 of config file.

Therefore the variable 'proto' points at the ".7" of the ip number when
parsing line 4.

Using numeric port number does not access the global 'proto' variable in
portnum and later in natparse sets 'proto' pointing to static string "tcp"
for parsing the remaining lines.

Any line that contains a protocol will set the 'proto' variable for
the next line.  If this line is longer the 'proto' variable will be
pointing at an invalid string.


>How-To-Repeat:

  ipnat -f ipnat.conf  (see above for for config file contents)

>Fix:

  Don't use global variables like this!

  Should eliminate the global proto variable and pass the protocol
  as a parameter to portnum.  It looks like proto variable
  is only shared by natparse.c parse.c and common.c.

  As far as I can tell only the 'rdr' command is affected, because
  the protocol specified on the end of the line so the 'proto' variable
  gets set too late.

  In natparse.c the is a section to decode the protocol, this would
  have to be move before the first portnum call.  However the method
  of parsing the command line by using "cpp++;" to bump the toke pointer.
  The easiest would be to change the syntax of the "rdr" command
  from:
       rdr le0 203.1.2.3/32 port 80 -> 203.1.2.3,203.1.2.4 port 80 tcp
  to:
       rdr tcp le0 203.1.2.3/32 port 80 -> 203.1.2.3,203.1.2.4 port 80


  Temporary Fix:

   Assume the protocol will be tcp or udp and that the same number
   applies to both.

   To do this, just add the following line to the start of the
   function natparse in natparse.c:

      proto = NULL;


  Any better ideas?

>Release-Note:
>Audit-Trail:

From: Christopher Hall <hsw@acm.org>
To: FreeBSD-gnats-submit@FreeBSD.ORG
Cc:  
Subject: Re: gnu/24445: ipnat does not parse its file properly
Date: Fri, 19 Jan 2001 11:54:00 +0800

 setting 'proto' to NULL did not work completely as there
 some protocols e.g pop3s  that have no corresponding udp number
 
 Since I am only redirecting tcp add: proto = "tcp";
 to start of natparse instead.
 
 In message <200101190336.f0J3aVe43887@w40.tucheng.generalresources.com>,
   Christopher Hall writes:
 >
 >>Number:         24445
 >>Category:       gnu
 >>Synopsis:       ipnat does not parse its file properly
 >>Confidential:   no
 >>Severity:       serious
 >>Priority:       high
 >>Responsible:    freebsd-bugs
 >>State:          open
 >>Quarter:
 >>Keywords:
 >>Date-Required:
 >>Class:          sw-bug
 >>Submitter-Id:   current-users
 >>Arrival-Date:   Thu Jan 18 19:40:01 PST 2001
 >>Closed-Date:
 >>Last-Modified:
 >>Originator:     Christopher Hall
 >>Release:        FreeBSD 4.2-STABLE i386
 >>Organization:
 >>Environment:
 >
 >  4.2-STABLE FreeBSD 4.2-STABLE #0: Thu Jan 18 13:15:08 CST 2001
 >
 >>Description:
 >
 > Using the following configuration file:
 >
 >   map fxp1 192.168.1.250/16 -> 1.2.3.4/32 portmap  tcp/udp 40000:60000
 >   map fxp1 192.168.1.250/16 -> 1.2.3.4/32
 >   ##rdr fxp0 192.168.1.250/32 port 80      -> 4.5.6.7 port 80
 >   rdr fxp0 192.168.1.250/32 port http      -> 4.5.6.7 port http
 >   rdr fxp0 192.168.1.250/32 port https     -> 4.5.6.7 port https
 >
 >
 >Get errors like this
 >
 >  4: unknown service "http".
 >  4: syntax error in "rdr"
 >  5: unknown service "https".
 >  5: syntax error in "rdr"
 >
 > can stop error by:
 >  a) remove the '##' in line 3
 >  b) comment out line 1
 >  c) move line 1 to end of file
 >
 >
 >The problem is caused by a global variable in the file common.c
 >its definition is:   char    *proto = NULL;
 >
 >the file natparse.c uses the routine "portnum" to convert the
 >string "http" to a number
 >
 >'proto' is now pointing at the position in the line buffer where
 >the string "tcp/udp" used to be from line 1 of config file.
 >
 >Therefore the variable 'proto' points at the ".7" of the ip number when
 >parsing line 4.
 >
 >Using numeric port number does not access the global 'proto' variable in
 >portnum and later in natparse sets 'proto' pointing to static string "tcp"
 >for parsing the remaining lines.
 >
 >Any line that contains a protocol will set the 'proto' variable for
 >the next line.  If this line is longer the 'proto' variable will be
 >pointing at an invalid string.
 >
 >
 >>How-To-Repeat:
 >
 >  ipnat -f ipnat.conf  (see above for for config file contents)
 >
 >>Fix:
 >
 >  Don't use global variables like this!
 >
 >  Should eliminate the global proto variable and pass the protocol
 >  as a parameter to portnum.  It looks like proto variable
 >  is only shared by natparse.c parse.c and common.c.
 >
 >  As far as I can tell only the 'rdr' command is affected, because
 >  the protocol specified on the end of the line so the 'proto' variable
 >  gets set too late.
 >
 >  In natparse.c the is a section to decode the protocol, this would
 >  have to be move before the first portnum call.  However the method
 >  of parsing the command line by using "cpp++;" to bump the toke pointer.
 >  The easiest would be to change the syntax of the "rdr" command
 >  from:
 >       rdr le0 203.1.2.3/32 port 80 -> 203.1.2.3,203.1.2.4 port 80 tcp
 >  to:
 >       rdr tcp le0 203.1.2.3/32 port 80 -> 203.1.2.3,203.1.2.4 port 80
 >
 >
 >  Temporary Fix:
 >
 >   Assume the protocol will be tcp or udp and that the same number
 >   applies to both.
 >
 >   To do this, just add the following line to the start of the
 >   function natparse in natparse.c:
 >
 >      proto = NULL;
 >
 >
 >  Any better ideas?
 >
 >>Release-Note:
 >>Audit-Trail:
 >>Unformatted:
 >
 >
 >To Unsubscribe: send mail to majordomo@FreeBSD.org
 >with "unsubscribe freebsd-bugs" in the body of the message
 >
 
 ---
 Christopher Hall <atheist@generalresources.com>
 
Responsible-Changed-From-To: freebsd-bugs->darrenr 
Responsible-Changed-By: darrenr 
Responsible-Changed-When: Wed Feb 21 13:29:17 PST 2001 
Responsible-Changed-Why:  
darrenr is responsible for ipnat 

http://www.freebsd.org/cgi/query-pr.cgi?pr=24445 
State-Changed-From-To: open->suspended 
State-Changed-By: darrenr 
State-Changed-When: Fri Oct 19 20:44:53 PDT 2001 
State-Changed-Why:  
next import of ipfilter will fix this problem 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24445 
State-Changed-From-To: suspended->closed 
State-Changed-By: guido 
State-Changed-When: Wed Nov 14 13:55:29 MET 2001 
State-Changed-Why:  
FreeBSD 4.4 and -current with ipf version 3.4.20 does not have this problem. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24445 
>Unformatted:
