LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Slackware 14.0 - iptables-restore BUG with --log-prefix (http://www.linuxquestions.org/questions/slackware-14/slackware-14-0-iptables-restore-bug-with-log-prefix-4175430678/)

linuxxer 10-05-2012 10:09 AM

Slackware 14.0 - iptables-restore BUG with --log-prefix
 
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 05: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 08:01 AM

Thanks for your reply.

I will try to compile iptables packages.


Quote:

Originally Posted by XGizzmo (Post 4798669)
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 08: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 08: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 09: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 08:10 AM

Quote:

Originally Posted by GazL (Post 4798768)
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 06: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 03:53 AM

@XGizzmo
Thanks for your reply.

GazL 10-12-2012 07: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.


All times are GMT -5. The time now is 06:07 AM.