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.

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.  

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

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!

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?

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.

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!

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.

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 "?".

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 "?".

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.