This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 232889 - Somewhat erroneous parsing of truncated "address/bits" IP range specification
Somewhat erroneous parsing of truncated "address/bits" IP range specification
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: iptables (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-19 06:24 EDT by David Tonhofer
Modified: 2012-06-20 09:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 09:22:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch to extend shorthand ipaddress notations (1.35 KB, patch)
2007-08-13 16:23 EDT, Neil Horman
no flags Details | Diff

  None (edit)
Description David Tonhofer 2007-03-19 06:24:03 EDT
Description of problem:

An address range written as "90.33/16" in an iptables command yields
"90.0.0.0/16" (surprising), whereas "90.33.0/16" yields "90.33.0.0/16"
(expected). This seems to indicate some slight error in parsing the
specified address. For example:

Surprising
==========

/sbin/iptables -A input_tcp -p tcp --destination 80.90.63.49 --dport 110
--source 80.187.0/17 -j ACCEPT;
/sbin/iptables -A input_tcp -p tcp --destination 80.90.63.49 --dport 110
--source 90.33/16 -j ACCEPT;

ACCEPT     tcp  --  80.187.0.0/17        80.90.63.49         tcp dpt:110
ACCEPT     tcp  --  90.0.0.0/16          80.90.63.49         tcp dpt:110
                    ^^^^^^^^^^^

Expected
========

/sbin/iptables -A input_tcp -p tcp --destination 80.90.63.49 --dport 110
--source 80.187.0/17 -j ACCEPT;
/sbin/iptables -A input_tcp -p tcp --destination 80.90.63.49 --dport 110
--source 90.33.0/16 -j ACCEPT;


ACCEPT     tcp  --  80.187.0.0/17        80.90.63.49         tcp dpt:110
ACCEPT     tcp  --  90.33.0.0/16         80.90.63.49         tcp dpt:110
                    ^^^^^^^^^^^^

Version-Release number of selected component (if applicable):

iptables-1.2.11-3.1.RHEL4

How reproducible:

Always
Comment 1 Thomas Woerner 2007-07-25 09:31:43 EDT
This problem does not occur with:
kernel-2.6.23-0.30.rc0.git6.fc8
iptables-1.3.8-1

But with iptables-1.3.8-1 and kernel-2.6.9-55.0.2.ELsmp this problem is present.
Therefore this is no userland iptables problem.

Assigning to kernel.
Comment 2 Neil Horman 2007-08-09 10:58:11 EDT
Not really sure what, if anything we need to do about this.  iptables
communicates  with the kernel via messaging over a netfilter socket.  That means
that the messaging protocol needs to be kept in line between the iptables
utility and the kernel.  All the failed tests above appear to occur between a
newer iptables version (1.3.8-1, for fc7/8) and an older kernel (2.6.9-55.0.2.ELsmp.

When I run the latest RHEL4 version of iptables (1.2.11-3.1.RHEL4) I get the
following:

[root@pe2850 ~]# /sbin/iptables -A input_tcp -p tcp --destination 80.90.63.49
--dport 110 -source 90.33/16 -j ACCEPT
Bad argument `90.33/16'
Try `iptables -h' or 'iptables --help' for more information.

Which makes sense, since the parsing code in that version expects a complete
4-dot delimited address to be provided.  

If we update RHEL4 to iptables-1.3.8-1 or later in RHEL4 then the corresponding
code to understand the netfilter protocol changes in the kernel will have to be
ported at the same time, and vice versa.  But given that the current latest
iptables in RHEL4 works quite well with the latest kernel in RHEL4, and
dist-4e-qu-candidates shows no pending later versions of iptables, I'm inclined
to close this as NOTABUG, unless you have an argument to the contrary.  
Comment 3 David Tonhofer 2007-08-13 03:21:03 EDT
Neil,

At least on my RH ES4, iptables *does not warn*, but above you used "-source"
instead of "--source", which indeed gives a warning:

"2.6.9-55.0.2.ELsmp" and "iptables-1.2.11-3.1.RHEL4"

$ iptables -A input_tcp -p tcp --destination 80.90.63.49 --dport 110 --source
99.67/16 -j ACCEPT
$ iptables -L -n | grep 99

ACCEPT     tcp  --  99.0.0.0/16          80.90.63.49         tcp dpt:110


$ iptables -A input_tcp -p tcp --destination 80.90.63.49 --dport 110 --source
98.67.0/16 -j ACCEPT
$ iptables -L -n | grep 98
ACCEPT     tcp  --  98.67.0.0/16         80.90.63.49         tcp dpt:110





Comment 4 Neil Horman 2007-08-13 16:23:00 EDT
Created attachment 161221 [details]
patch to extend shorthand ipaddress notations

Ok, not sure why this would be working with a newer kernel, but its definately
clear that the dotted_to_addr function in iptables is failing when it should be
succeding in its parsing of 99.67 as an address.  It expects a fully qualified
dotted address, and is failing because it doesn't get one.  This patch fixes
that by extending the dot notation to a A.B.C.D in parse_hostnetwork, and fixes
the problem for me (which I managed to recreate after you pointed out my
previous error).  Please give this patch a try and confirm that it fixes the
problem for you.  Thanks!
Comment 5 David Tonhofer 2007-08-14 05:37:24 EDT
Uh, I currently don't have a machine with a compilable kernel at hand, all my
machines are stock RHES4 and currently in production. Also, I'm in my "Java
development" phase currently, so It will probably be some time until I can test
this. Maybe somebody else?
Comment 6 Neil Horman 2007-08-14 07:22:56 EDT
I'm not going to check something in unless the reporter can confirm the problem
is resolved.  I've built a test iptables package for you, available here:
http://people.redhat.com/nhorman/rpms/iptables-1.2.11-3.1.RHEL4.232889.i386.rpm
Please test when you are able, and report results.
Comment 7 David Tonhofer 2007-08-15 11:54:17 EDT
Okido, testing:

On "2.6.9-55.0.2.ELsmp", "iptables-1.2.11-3.1.RHEL4"

1) Confirm problem exists

$ iptables -A input_tcp -p tcp --destination 80.90.63.35 --dport 110 --source
99.67/16 -j ACCEPT
$ iptables -A input_tcp -p tcp --destination 80.90.63.35 --dport 110 --source
98.67.0/16 -j ACCEPT
$ iptables -L -n | egrep '(99|98).*dpt:110'

ACCEPT     tcp  --  99.0.0.0/16          80.90.63.35         tcp dpt:110  <--
unexpected
ACCEPT     tcp  --  98.67.0.0/16         80.90.63.35         tcp dpt:110  <--
expected

2) Install provided bumped package

$ rpm --force --install ~/iptables-1.2.11-3.1.RHEL4.232889.i386.rpm

warning: /etc/rc.d/init.d/iptables saved as /etc/rc.d/init.d/iptables.rpmsave
warning: /etc/sysconfig/iptables-config created as
/etc/sysconfig/iptables-config.rpmnew

(Take care of the warnings and some local, homegrown special features...)

3) Restart iptables, clearing existing setp

$ /etc/rc.d/init.d/iptables restart
$ iptables -L -n | egrep '(99|98).*dpt:110'

empty result, as expected

4) Retest

$ iptables -A input_tcp -p tcp --destination 80.90.63.35 --dport 110 --source
99.67/16 -j ACCEPT
$ iptables -A input_tcp -p tcp --destination 80.90.63.35 --dport 110 --source
98.67.0/16 -j ACCEPT
$ iptables -A input_tcp -p tcp --destination 80.90.63.35 --dport 110 --source
97.67.14/16 -j ACCEPT
$ iptables -A input_tcp -p tcp --destination 80.90.63.35 --dport 110 --source
96.67.14.18/16 -j ACCEPT

$ iptables -L -n | egrep '(99|98|97|96).*dpt:110'

ACCEPT     tcp  --  99.67.0.0/16         80.90.63.35         tcp dpt:110
ACCEPT     tcp  --  98.67.0.0/16         80.90.63.35         tcp dpt:110
ACCEPT     tcp  --  97.67.0.0/16         80.90.63.35         tcp dpt:110
ACCEPT     tcp  --  96.67.0.0/16         80.90.63.35         tcp dpt:110

Conclusion: works!


Comment 8 Neil Horman 2007-08-15 12:44:24 EDT
copy that.  Thank you.  Reassigning to the iptables maintainer for review and
acceptance.

Thomas, the above patch in comment number 4 is confirmed to solve the issue. 
This probably needs to go into RHEL5 (and perhaps upstream) as well.
Comment 10 RHEL Product and Program Management 2008-02-01 14:09:31 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 12 RHEL Product and Program Management 2008-10-31 12:39:24 EDT
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 13 Jiri Pallich 2012-06-20 09:22:34 EDT
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.

Note You need to log in before you can comment on or make changes to this bug.