Bug 32270

Summary: ipfw misreads 'skipto' rule number with leading zero
Product: Base System Reporter: Brian Candler <B.Candler>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description Brian Candler 2001-11-25 15:30:00 UTC
'ipfw list' displays rule numbers as 5 digits with leading zeros.
'ipfw add nnnnn' accepts rule numbers with leading zeros.

However, 'ipfw ... skipto nnnnn ...' fails when given a number with
a leading zero; it appears to treat it as octal, but silently ignores
non-octal digits (e.g. 02999 is accepted but treated as '2')

The man page does not say that 'skipto' treats rule numbers any
differently than elsewhere.

Trivial to workaround - by dropping the leading zero - but wasted time
trying to work out why my ruleset wasn't working!

How-To-Repeat: # ipfw add 00500 skipto 02999 ip from 1.2.3.4 to 5.6.7.8
00500 skipto 2 ip from 1.2.3.4 to 5.6.7.8
# ipfw add 00600 skipto 03777 ip from 1.2.3.4 to 5.6.7.8
00600 skipto 2047 ip from 1.2.3.4 to 5.6.7.8
# ipfw list
...
00500 skipto 2 ip from 1.2.3.4 to 5.6.7.8
00600 skipto 2047 ip from 1.2.3.4 to 5.6.7.8
Comment 1 Peter Pentchev 2001-11-25 15:42:21 UTC
On Sun, Nov 25, 2001 at 07:24:44AM -0800, Brian Candler wrote:
> 
> >Number:         32270
> >Category:       bin
> >Synopsis:       ipfw misreads 'skipto' rule number with leading zero
> >Originator:     Brian Candler
> >Release:        FreeBSD-4.4
> >Organization:
> >Environment:
> >Description:
> 'ipfw list' displays rule numbers as 5 digits with leading zeros.
> 'ipfw add nnnnn' accepts rule numbers with leading zeros.
> 
> However, 'ipfw ... skipto nnnnn ...' fails when given a number with
> a leading zero; it appears to treat it as octal, but silently ignores
> non-octal digits (e.g. 02999 is accepted but treated as '2')
[snip]
> 
> >How-To-Repeat:
> # ipfw add 00500 skipto 02999 ip from 1.2.3.4 to 5.6.7.8
> 00500 skipto 2 ip from 1.2.3.4 to 5.6.7.8
> # ipfw add 00600 skipto 03777 ip from 1.2.3.4 to 5.6.7.8
> 00600 skipto 2047 ip from 1.2.3.4 to 5.6.7.8
> # ipfw list
> ...
> 00500 skipto 2 ip from 1.2.3.4 to 5.6.7.8
> 00600 skipto 2047 ip from 1.2.3.4 to 5.6.7.8

I cannot reproduce this here:

[root@straylight:v3 ~]# ipfw list
65535 allow ip from any to any
[root@straylight:v3 ~]# ipfw add 00500 skipto 02999 ip from 1.2.3.4 to 5.6.7.8
00500 skipto 2999 ip from 1.2.3.4 to 5.6.7.8
[root@straylight:v3 ~]# ipfw add 00600 skipto 03777 ip from 1.2.3.4 to 5.6.7.8
00600 skipto 3777 ip from 1.2.3.4 to 5.6.7.8
[root@straylight:v3 ~]# ipfw list
00500 skipto 2999 ip from 1.2.3.4 to 5.6.7.8
00600 skipto 3777 ip from 1.2.3.4 to 5.6.7.8
65535 allow ip from any to any
[root@straylight:v3 ~]#

Are you running FreeBSD 4.4-RELEASE?  If so, could you update to -stable
and see if the problem is really fixed?  I cannot find anything related
to parsing rule numbers in the ipfw.c changes after 4.4-RELEASE, though..

G'luck,
Peter

-- 
No language can express every thought unambiguously, least of all this one.
Comment 2 Brian Candler 2001-11-25 15:56:10 UTC
On Sun, Nov 25, 2001 at 05:42:21PM +0200, Peter Pentchev wrote:
> I cannot reproduce this here:
...
> Are you running FreeBSD 4.4-RELEASE?

Yes: the laptop I reproduced it on was recently upgraded to 4.4 via the
'upgrade' process, but the machine where it actually caused the headache was
a freshly- installed 4.4-RELEASE.

$ ls -l /sbin/ipfw
-r-xr-xr-x  1 root  wheel  260412 Sep 18 18:27 /sbin/ipfw
$ md5 /sbin/ipfw
MD5 (/sbin/ipfw) = 165f54834431e4437e192ac0c31ef4c3

(on both machines)
Comment 3 Brian Candler 2001-11-25 16:07:04 UTC
I can't upgrade to 4.4-STABLE at the moment, but I do see the following in
ipfw.c from /src/ssbin.?? on the CD-ROM, line 1654:

        } else if (!strncmp(*av, "skipto", strlen(*av))) {
                rule.fw_flg |= IP_FW_F_SKIPTO; av++; ac--;
                if (!ac)
                        show_usage("missing skipto rule number");
                rule.fw_skipto_rule = strtoul(*av, NULL, 0); av++; ac--;

I think the third parameter to strtoul should be 10, not 0.

Regards,

Brian.
Comment 4 Peter Pentchev 2001-11-25 16:14:45 UTC
On Sun, Nov 25, 2001 at 03:56:10PM +0000, Brian Candler wrote:
> On Sun, Nov 25, 2001 at 05:42:21PM +0200, Peter Pentchev wrote:
> > I cannot reproduce this here:
> ...
> > Are you running FreeBSD 4.4-RELEASE?
> 
> Yes: the laptop I reproduced it on was recently upgraded to 4.4 via the
> 'upgrade' process, but the machine where it actually caused the headache was
> a freshly- installed 4.4-RELEASE.
> 
> $ ls -l /sbin/ipfw
> -r-xr-xr-x  1 root  wheel  260412 Sep 18 18:27 /sbin/ipfw
> $ md5 /sbin/ipfw
> MD5 (/sbin/ipfw) = 165f54834431e4437e192ac0c31ef4c3
> 
> (on both machines)

If the /sbin/ipfw files are exactly the same on both machines, then you
do not really have a recent -stable.  There have been several changes
to the ipfw userland code..  and actually, come to think of it, I just
found one that would seem to fix your problem:

ru          2001/09/24 02:58:47 PDT
  Modified files:        (Branch: RELENG_4)
    sbin/ipfw            ipfw.c
  Log:
  MFC: 1.109: Non-decimal ``skipto'' rule numbers are confusing.

This was committed on Sep 24, about two months ago; are you sure
that your stable laptop is running a really recent -stable?

G'luck,
Peter

-- 
If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false.
Comment 5 Brian Candler 2001-11-25 16:28:42 UTC
On Sun, Nov 25, 2001 at 06:14:45PM +0200, Peter Pentchev wrote:
> If the /sbin/ipfw files are exactly the same on both machines, then you
> do not really have a recent -stable.

That's right, I am running -RELEASE on both.

> ru          2001/09/24 02:58:47 PDT
>   Modified files:        (Branch: RELENG_4)
>     sbin/ipfw            ipfw.c
>   Log:
>   MFC: 1.109: Non-decimal ``skipto'' rule numbers are confusing.

That looks like the one. Thanks - problem closed.
Comment 6 Peter Pentchev freebsd_committer freebsd_triage 2001-11-25 16:29:32 UTC
State Changed
From-To: open->closed

The originator agrees that this was probably solved in rev. 1.109 
and 1.80.2.12 of src/sbin/ipfw/ipfw.c.