Bug 207675 - iptables problems in fresh rawhide install
Summary: iptables problems in fresh rawhide install
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2006-09-22 14:15 UTC by David Woodhouse
Modified: 2008-05-07 00:52 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-07 00:52:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description David Woodhouse 2006-09-22 14:15:40 UTC
[root@pegasos ~]# iptables -F
iptables v1.3.5: can't initialize iptables table `filter': Table does not exist
(do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
[root@pegasos ~]# modprobe iptable_filter
FATAL: Error inserting iptable_filter
Invalid argument
[root@pegasos ~]# rmmod ip_tables
[root@pegasos ~]# modprobe iptable_filter
[root@pegasos ~]# iptables -F
iptables: Unknown error 4294967295
[root@pegasos ~]# strace iptables -F 2>&1| tail -5
setsockopt(3, SOL_IP, 0x40 /* IP_??? */,
"filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 728) = 0
setsockopt(3, SOL_IP, 0x41 /* IP_??? */,
"filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 104) = 0
close(3)                                = 0
exit_group(0)                           = ?
Process 2499 detached

Comment 1 David Woodhouse 2006-09-25 09:26:46 UTC
Sorry, wrong strace. Sometimes, bizarrely, it does seem to work. This is a
failing one:

getsockopt(3, SOL_IP, 0x41 /* IP_??? */,
"filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., [672]) = 0
setsockopt(3, SOL_IP, 0x40 /* IP_??? */,
"filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 728) = -1 EINVAL
(Invalid argument)
write(2, "iptables: Unknown error 42949672"..., 35iptables: Unknown error 4294967295
) = 35
exit_group(1)                           = ?

Comment 2 David Woodhouse 2006-09-25 10:03:25 UTC
It seems that in ipt_register_table() the call to xt_alloc_table_info() is
returning a result which is not suitably aligned. This causes
check_entry_size_and_hooks() to fail.

For example, I see (in ipt_register_table()) 
   newinfo == d77e9614 
   loc_cpu_entry == newinfo->entries[0]==d6473a44

...and subsequent 'Bad offset d6473a44' from check_entry_size_and_hooks.

Caused by the fact that we have CONFIG_DEBUG_SLAB set, presumably.

Comment 3 David Woodhouse 2006-09-25 10:18:06 UTC
I mean the original failure to load is caused by CONFIG_DEBUG_SLAB. Not sure
about the 'Unknown error 4294967295', which I can't reproduce any more since
today the iptable_filter.ko module doesn't load at all.

Comment 4 Robert Scheck 2006-09-25 10:30:11 UTC
At least the discovered issue seems to be ppc/ppc64 specific, is it possible?

Comment 5 David Woodhouse 2006-09-25 10:38:04 UTC
This is ppc32, not ppc64 -- and I don't see why that should be the case. Does
the slab debugging redzone stuff behave differently on ppc32, or do we have
larger alignment requirements for the struct ipt_entry? 

struct ipt_entry contains a 'struct xt_counters', which in turn contains 64-bit
integers. I would expect that this is aligned to 8 bytes on most architectures.

Comment 6 Matthew Hall 2007-05-10 12:25:56 UTC
I'm seeing this too with F7test4, looks to be ppc32 specific as it's fine on my
i386; more debug info to come.

Comment 7 Bug Zapper 2008-04-03 18:17:58 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 8 Bug Zapper 2008-05-07 00:52:10 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:

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