[SOLVED] Slackware 14.0 - iptables-restore BUG with --log-prefix

linuxxer · 10-05-2012, 09:09 AM

Slackers,

Few days back, I upgraded to Slackware 14.0.
It is VERY GREAT.

I found ONE problem with iptables-restore

My iptables rule is:

Code:

$IPTABLES -A bad_packets -p tcp \! --syn -m state --state NEW -j LOG --log-level info --log-prefix "iptables_bad_packet:"

$IPTABLES -A deny_packets -j LOG --log-level info --log-prefix="iptables_deny:"

Output of command :

Code:

# iptables --line-number -nv -L

1        0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags:! 0x17/0x02 state NEW LOG flags 0 level 6 prefix "iptables_bad_packet:"
1        0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 6 prefix "iptables_deny:"

Followed by :

Code:

# iptables-save > ipt-save
# iptables-restore < ipt-save
# iptables-save > new-ipt-save

See the diff :

Code:

42c42
< -A bad_packets -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j LOG --log-prefix "iptables_bad_packet:" --log-level 6
---
> -A bad_packets -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j LOG --log-prefix --log-prefix --log-level 6
44c44
< -A deny_packets -j LOG --log-prefix "iptables_deny:" --log-level 6
---
> -A deny_packets -j LOG --log-prefix --log-prefix --log-level 6

Output of command :

Code:

# iptables --line-number -nv -L

1        0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags:! 0x17/0x02 state NEW LOG flags 0 level 6 prefix "--log-prefix"
1        1    40 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 6 prefix "--log-prefix"

My syslogd says :

Code:

Oct  5 17:52:38 slax kernel: [ 4647.126101] --log-prefixIN=ppp0 OUT= MAC= SRC=115.236.16.238 DST=<my_internet_ip_removed> LEN=40 TOS=0x00 PREC=0x00 TTL=95 ID=256 PROTO=TCP SPT=6000 DPT=1433 WINDOW=16384 RES=0x00 SYN URGP=0

When I was running Slackware 13.37. I found NO PROBLEM with SAME iptables rules.

XGizzmo · 10-06-2012, 04:40 AM

It is a known bug in iptables https://bugzilla.redhat.com/show_bug.cgi?id=825796

Seems like iptables needs to be compiled with -O0 or this patch applied http://pkgs.fedoraproject.org/cgit/i...f0e3b5fc17979b

Sorry about the redhat/fedora links but the netfilter bug tracker seems to be down ATM.

linuxxer · 10-06-2012, 07:01 AM

Thanks for your reply.

I will try to compile iptables packages.

Quote:

Originally Posted by XGizzmo

Sorry about the redhat/fedora links but the netfilter bug tracker seems to be down ATM.

Why are you saying Sorry.
Redhat and Fedora is also Open Source Linux Projects.

GazL · 10-06-2012, 07:09 AM

Interesting bug.

Like one of the commentators on that bug report, I was under the impression that declaring a variable within the block of a loop simply restricted it's scope. Any C experts here who can explain when it's ok to do this and when it's not?

linuxxer · 10-06-2012, 07:55 AM

@GazL
I am NOT C expert.
But I recompile package with "-O2" flag removed.
I tried and it works.

@XGizzmo
Thanks for your reply.
It works.

GazL · 10-06-2012, 08:35 AM

I guess what I was trying to determine is whether it is a gcc optimisation bug or just bad C code in iptables.

I'm an old-school K&R C kinda guy, and would never have dreamed of declaring a variable in a loop (In my day we were taught to declare all your variables at the start of a function). I believe subsequent C standard revisions introduced this ability to declare variables within loops to restrict their scope, but perhaps I'm misunderstanding and it's only valid for the loop expressions themselves.

linuxxer · 10-07-2012, 07:10 AM

Quote:

Originally Posted by GazL

I guess what I was trying to determine is whether it is a gcc optimisation bug or just bad C code in iptables.

It is very difficult for me also to accept that,
compile time optimisation option create bug in program.

I agree with you.

XGizzmo · 10-11-2012, 05:21 PM

Quote:

Peter Lekensteyn provided the following sample code similar to the one

in iptables-restore:

Code:

int i = 0;



for (;;) {

	char x[5];



	x[i] = '0' + i;

	if (++i == 4) {

		x[i] = '\0'; /* terminate string with null byte */

		printf("%s\n", x);

		break;

	}

}

Many may expect 0123 as output. But GCC 4.7 does not do that when compiling

with optimization enabled (-O1 and higher). It instead puts random data in the

first bytes of the character array, which becomes:

| 0 | 1 | 2 | 3 | 4 |

| RANDOM | '3' | '\0' |

Since the array is declared inside the scope of loop's body, you can think of

it as of a new array being allocated in the automatic storage area for each

loop iteration.

The correct code should be:

Code:

char x[5];



for (;;) {

	x[i] = '0' + i;

	if (++i == 4) {

		x[i] = '\0'; /* terminate string with null byte */

		printf("%s\n", x);

		break;

	}

}

This seems to make sense to me.

linuxxer · 10-12-2012, 02:53 AM

@XGizzmo
Thanks for your reply.

GazL · 10-12-2012, 06:06 AM

The "new automatic variable per loop-iteration" does explain things. Thanks XGizzmo.

Automatic variables aren't initialised (which explains the random data). My guess is that gcc without optimisation just happened to choose the same memory location each time and it was working by accident.

In this case, declaring the variable as static while leaving it inside the block sounds like it would have also done the job.