Please enable DEBUG_IP_FIREWALL_USER in net/netfilter/x_tables.c as well
and retry. Results of the raw or mangle table would also be interesting
because they contain a different number of built-in chains.
Sorry it took so long, I was away. Adding this define does not seem to
do much (table->pri
Meelis Roos wrote:
>> Very strange, this means that the initial table data must somehow
>> be wrong, but for some reason it still seems to get past the
>> size and offset checks for the filter table. I can't see how
>> loading the filter table could fail after the "Finished chain .."
>> messages wi
Very strange, this means that the initial table data must somehow
be wrong, but for some reason it still seems to get past the
size and offset checks for the filter table. I can't see how
loading the filter table could fail after the "Finished chain .."
messages without another message. Which kern
Meelis Roos wrote:
>> Then lets try something different. Please enable the
>> DEBUG_IP_FIREWALL_USER define in net/ipv4/netfilter/ip_tables.c and
>> post the results, if any.
>
>
> On bootup I get this in dmesg (one Bad offset has been added):
>
> ip_tables: (C) 2000-2006 Netfilter Core Team
> N
Then lets try something different. Please enable the
DEBUG_IP_FIREWALL_USER define in net/ipv4/netfilter/ip_tables.c and
post the results, if any.
On bootup I get this in dmesg (one Bad offset has been added):
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip
Meelis Roos wrote:
>> Meelis, it would really help if you could try 2.6.16 and in case
>> that doesn't work 2.6.15 to give an idea about whether this is a
>> recent regression or an old problem. We had a number of changes
>> in this area in the last two kernel versions that could be related.
>
>
modprobe iptable_filter (errors out with Invalid Argument)
iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -j SNAT --to 192.168.1.1 (usually
errors out with Invalid Argument, sometimes succeeds, when succeeds then the
rule works fine)
Meelis, it would really help if you could try 2.6.16 and in case
Meelis Roos wrote:
Unfortunatlety, 2.6.15 does not boot on this machine so I'm locked out
remotely at the moment.
Here it my paranoid boot setup:
Thanks, but it's not much use here, since the machine is a PReP powerpc
machine that can boot one kernel from disk (directly loaded from boot
par
Hi Andi,
Andi Kleen wrote:
> > 4. Put "sysctl -w kernel.panic_on_oops=1" as early as possible
> > in your boot scripts[1].
>
> You can as well boot with oops=panic
Only on x86_64 as of Linux 2.6.16.
But maybe this could be put into kernel/panic.c instead :-)
Regards
Ingo Oeser
-
To unsubs
> 4. Put "sysctl -w kernel.panic_on_oops=1" as early as possible
> in your boot scripts[1].
You can as well boot with oops=panic
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel
Ingo Oeser wrote:
> Hi Meelis,
>
>> Unfortunatlety, 2.6.15 does not boot on this machine so I'm locked out
>> remotely at the moment.
>
> Here it my paranoid boot setup:
>
> 1. Use "lilo -R new-kernel", to boot a kernel only
> once and reboot the default kernel next time.
>
> 2. Force rebo
Hi Meelis,
> Unfortunatlety, 2.6.15 does not boot on this machine so I'm locked out
> remotely at the moment.
Here it my paranoid boot setup:
1. Use "lilo -R new-kernel", to boot a kernel only
once and reboot the default kernel next time.
2. Force reboot on any panic after 10 seconds:
Unfortunatlety, 2.6.15 does not boot on this machine so I'm locked out
remotely at the moment.
Here it my paranoid boot setup:
Thanks, but it's not much use here, since the machine is a PReP powerpc
machine that can boot one kernel from disk (directly loaded from boot
partition, no fancy boo
Meelis, it would really help if you could try 2.6.16 and in case
that doesn't work 2.6.15 to give an idea about whether this is a
recent regression or an old problem. We had a number of changes
in this area in the last two kernel versions that could be related.
Unfortunatlety, 2.6.15 does not bo
http://bugzilla.kernel.org/show_bug.cgi?id=6613
Meelis, it would really help if you could try 2.6.16 and in case
that doesn't work 2.6.15 to give an idea about whether this is a
recent regression or an old problem. We had a number of changes
in this area in the last two kernel versions that coul
Meelis, it would really help if you could try 2.6.16 and in case
that doesn't work 2.6.15 to give an idea about whether this is a
recent regression or an old problem. We had a number of changes
in this area in the last two kernel versions that could be related.
Yes, I'm still compiling 2.6.16, s
Andrew Morton wrote:
> [EMAIL PROTECTED] wrote:
>
>>http://bugzilla.kernel.org/show_bug.cgi?id=6613
>>
>> Summary: iptables broken on 32-bit PReP (ARCH=ppc)
>>Kernel Version: 2.6.17-rc4
>>Status: NEW
>> Severity: normal
>> Owner: [EMAIL PROTECTED]
>>
[EMAIL PROTECTED] wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6613
>
>Summary: iptables broken on 32-bit PReP (ARCH=ppc)
> Kernel Version: 2.6.17-rc4
> Status: NEW
> Severity: normal
> Owner: [EMAIL PROTECTED]
> Submitter: [EMAI
18 matches
Mail list logo
