netfilter problem

netfilter problem

[senthilkumaar2021]

Hi

I am getting the following kernel panic error in kernel 2.6.30.5 while 
running the squid t proxy in bridge mode

I have used the following iptables 1.4.3 and ebtables rules

The panic occurs once in 10 -15 hrs

iptable and ebtables are

iptables -t mangle -N DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT

iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY 
--tproxy-mark 0x1/0x1 --on-port 3129

ebtables -t broute -A BROUTING -i $CLIENT_IFACE -p ipv4 --ip-proto tcp 
--ip-dport 80 -j redirect --redirect-target DROP

ebtables -t broute -A BROUTING -i $INET_IFACE -p ipv4 --ip-proto tcp 
--ip-sport 80 -j redirect --redirect-target DROP

[<ffffffffa03933c2>] ? nf_nat_fn+0x138/0x14e [iptable_nat]
[<ffffffffa0393585>] ? nf_nat_in+0x2f/0x6e [iptable_nat]
[<ffffffffa027edaa>] ? br_nf_pre_routing_finish+0x0/0x2c4 [bridge]
[<ffffffffa027edfa>] br_nf_pre_routing_finish+0x50/0x2c4 [bridge]
[<ffffffffa027edaa>] ? br_nf_pre_routing_finish+0x0/0x2c4 [bridge]
[<ffffffff81339a50>] ? nf_hook_slow+0x68/0xc8
[<ffffffffa027edaa>] ? br_nf_pre_routing_finish+0x0/0x2c4 [bridge]
[<ffffffffa027f616>] br_nf_pre_routing+0x5a8/0x5c7 [bridge]
[<ffffffff813399ab>] nf_iterate+0x48/0x85
[<ffffffffa027a931>] ? br_handle_frame_finish+0x0/0x154 [bridge]
[<ffffffff81339a50>] nf_hook_slow+0x68/0xc8
[<ffffffffa027a931>] ? br_handle_frame_finish+0x0/0x154 [bridge]
[<ffffffffa027ac36>] br_handle_frame+0x1b1/0x1db [bridge]
[<ffffffff8131d54b>] netif_receive_skb+0x316/0x434
[<ffffffff8131dbfb>] napi_gro_receive+0x6e/0x83
[<ffffffffa0125bfe>] e1000_receive_skb+0x5c/0x65 [e1000e]
[<ffffffffa0125de8>] e1000_clean_rx_irq+0x1e1/0x28f [e1000e]
[<ffffffffa012730e>] e1000_clean+0x99/0x24a [e1000e]
[<ffffffff813bcfc5>] ? _spin_unlock_irqrestore+0x2c/0x43
[<ffffffff8131ba62>] net_rx_action+0xb8/0x1b4
[<ffffffff8104ed43>] __do_softirq+0x99/0x152
[<ffffffff8101284c>] call_softirq+0x1c/0x30
[<ffffffff81013a02>] do_softirq+0x52/0xb9
[<ffffffff8104e969>] irq_exit+0x53/0x8d
[<ffffffff81013d1a>] do_IRQ+0x135/0x157
[<ffffffff81011f93>] ret_from_intr+0x0/0x2e
<EOI> [<ffffffff81017e20>] ? mwait_idle+0x9e/0xc7
[<ffffffff81017e17>] ? mwait_idle+0x95/0xc7
[<ffffffff813bfd20>] ? atomic_notifier_call_chain+0x13/0x15
[<ffffffff810102f4>] ? enter_idle+0x27/0x29


Please help me in fixing the issue

Regards
senthil

Re: netfilter problem

[Patrick McHardy]

senthilkumaar2021 wrote:
> Hi
> 
> I am getting the following kernel panic error in kernel 2.6.30.5 while
> running the squid t proxy in bridge mode
> 
> I have used the following iptables 1.4.3 and ebtables rules
> 
> The panic occurs once in 10 -15 hrs
> 
> iptable and ebtables are
> 
> iptables -t mangle -N DIVERT
> iptables -t mangle -A DIVERT -j MARK --set-mark 1
> iptables -t mangle -A DIVERT -j ACCEPT
> 
> iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
> iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY
> --tproxy-mark 0x1/0x1 --on-port 3129
> 
> ebtables -t broute -A BROUTING -i $CLIENT_IFACE -p ipv4 --ip-proto tcp
> --ip-dport 80 -j redirect --redirect-target DROP
> 
> ebtables -t broute -A BROUTING -i $INET_IFACE -p ipv4 --ip-proto tcp
> --ip-sport 80 -j redirect --redirect-target DROP
> 
> [<ffffffffa03933c2>] ? nf_nat_fn+0x138/0x14e [iptable_nat]
> [<ffffffffa0393585>] ? nf_nat_in+0x2f/0x6e [iptable_nat]
> [<ffffffffa027edaa>] ? br_nf_pre_routing_finish+0x0/0x2c4 [bridge]
> [<ffffffffa027edfa>] br_nf_pre_routing_finish+0x50/0x2c4 [bridge]
> [<ffffffffa027edaa>] ? br_nf_pre_routing_finish+0x0/0x2c4 [bridge]
> [<ffffffff81339a50>] ? nf_hook_slow+0x68/0xc8
> [<ffffffffa027edaa>] ? br_nf_pre_routing_finish+0x0/0x2c4 [bridge]
> [<ffffffffa027f616>] br_nf_pre_routing+0x5a8/0x5c7 [bridge]
> [<ffffffff813399ab>] nf_iterate+0x48/0x85
> [<ffffffffa027a931>] ? br_handle_frame_finish+0x0/0x154 [bridge]
> [<ffffffff81339a50>] nf_hook_slow+0x68/0xc8
> [<ffffffffa027a931>] ? br_handle_frame_finish+0x0/0x154 [bridge]
> [<ffffffffa027ac36>] br_handle_frame+0x1b1/0x1db [bridge]
> [<ffffffff8131d54b>] netif_receive_skb+0x316/0x434
> [<ffffffff8131dbfb>] napi_gro_receive+0x6e/0x83
> [<ffffffffa0125bfe>] e1000_receive_skb+0x5c/0x65 [e1000e]
> [<ffffffffa0125de8>] e1000_clean_rx_irq+0x1e1/0x28f [e1000e]
> [<ffffffffa012730e>] e1000_clean+0x99/0x24a [e1000e]
> [<ffffffff813bcfc5>] ? _spin_unlock_irqrestore+0x2c/0x43
> [<ffffffff8131ba62>] net_rx_action+0xb8/0x1b4
> [<ffffffff8104ed43>] __do_softirq+0x99/0x152
> [<ffffffff8101284c>] call_softirq+0x1c/0x30
> [<ffffffff81013a02>] do_softirq+0x52/0xb9
> [<ffffffff8104e969>] irq_exit+0x53/0x8d
> [<ffffffff81013d1a>] do_IRQ+0x135/0x157
> [<ffffffff81011f93>] ret_from_intr+0x0/0x2e
> <EOI> [<ffffffff81017e20>] ? mwait_idle+0x9e/0xc7
> [<ffffffff81017e17>] ? mwait_idle+0x95/0xc7
> [<ffffffff813bfd20>] ? atomic_notifier_call_chain+0x13/0x15
> [<ffffffff810102f4>] ? enter_idle+0x27/0x29
> 
> 
> Please help me in fixing the issue

Please send the full panic output.

netfilter problem

[saravanan chanemouganandam]

Hi,

I have a problem in compiling "netfilter" for Iptables support into the 
linux 2.6.12 kernel version. I have manually enabled the config option 
"CONFIG_NETFILTER=y" and all netfilter configuration CONFIG_IP_NF_* manually 
in to the "mainstone_defconfig" file for my target arm board.

Now, the problem is that, on "make vmlinux", the files under the 
"linux/2.6.12/net/ipv4/netfilter" directory doesn't gets compiled leaving 
built-in.o and this annoys me a lot.

Could any one please precise me, what are the options I need to check or 
enable in the config, Kconfig or in Makefile to get the "netfilter" compiled 
into my kernel?

Thanks.

Regards,
Sara

Re: netfilter problem

[Yasuyuki KOZAKAI]

Hi,

From: "saravanan chanemouganandam" <saravanan_sprt@hotmail.com>
Date: Mon, 18 Sep 2006 17:46:59 +0530

> Hi,
> 
> I have a problem in compiling "netfilter" for Iptables support into the 
> linux 2.6.12 kernel version. I have manually enabled the config option 
> "CONFIG_NETFILTER=y" and all netfilter configuration CONFIG_IP_NF_* manually 
> in to the "mainstone_defconfig" file for my target arm board.
> 
> Now, the problem is that, on "make vmlinux", the files under the 
> "linux/2.6.12/net/ipv4/netfilter" directory doesn't gets compiled leaving 
> built-in.o and this annoys me a lot.
> 
> Could any one please precise me, what are the options I need to check or 
> enable in the config, Kconfig or in Makefile to get the "netfilter" compiled 
> into my kernel?

If you run 'make menuconfig' on the other machine, you will see that some
CONFIG_IP_NF_* are moved to CONFIG_NETFILTER_XT_* and NETFILTER_XTABLES is
added.

-- Yasuyuki Kozakai

Netfilter problem..

[Admin on sosi.sk]

Hi all,

I have interfaces:
eth0 - WAN
eth1 - LAN
eth2 - free
ath0 - Atheros AP

Then I have made a bridge br0(192.168.1.1) from ath0(0.0.0.0), eth1(0.0.0.0) 
because I want wired and wireless metwork in one address range 192.168.1.0 - 
192.168.1.255
and I run dhcp server over bridge br0.

Over eth1(wired network) works all fine.

I can not obtain IP address from dhcp over wifi interface ath0 and I get 
this message in
tcpdump -vv -i br0
-------------------------------------------------------------------------------
br_netfilter: Argh!! br_nf_post_routing: bad mac.raw pointer.[eth1][br0] 
head:c35d23e0, raw:c35d23fe, data:c35d23fe
-------------------------------------------------------------------------------
/var/log/messages
-------------------------------------------------------------------------------
Apr  4 22:38:23 sosiba kernel: IN=eth0 OUT= 
MAC=ff:ff:ff:ff:ff:ff:00:e0:4c:67:66:d6:08:00 SRC=195.46.67.248 
DST=255.255.255.255 LEN=128 TOS=0x00 PREC=0x00 TTL=128 ID=40800 PROTO=UDP 
SPT=164 DPT=164 LEN=108
Apr  4 22:43:54 sosiba kernel: br_netfilter: Argh!! br_nf_post_routing: bad 
mac.raw pointer.[eth1][br0] head:c2af95e0, raw:c2af95fe, data:c2af95fe
Apr  4 22:44:05 sosiba kernel: IN=br0 OUT= PHYSIN=ath0 PHYSOUT=eth1 
MAC=ff:ff:ff:ff:ff:ff:00:07:0e:b4:50:a5:08:00 SRC=0.0.0.0 
DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=540 PROTO=UDP 
SPT=68 DPT=67 LEN=308
Apr  4 22:44:05 sosiba dhcpd: DHCPREQUEST for 192.168.1.33 from 
00:07:0e:b4:50:a5 via br0
Apr  4 22:44:05 sosiba dhcpd: DHCPACK on 192.168.1.33 to 00:07:0e:b4:50:a5 
via br0
Apr  4 22:44:10 sosiba kernel: IN=br0 OUT= PHYSIN=ath0 PHYSOUT=eth1 
MAC=ff:ff:ff:ff:ff:ff:00:07:0e:b4:50:a5:08:00 SRC=0.0.0.0 
DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=541 PROTO=UDP 
SPT=68 DPT=67 LEN=308
Apr  4 22:44:10 sosiba dhcpd: DHCPREQUEST for 192.168.1.33 from 
00:07:0e:b4:50:a5 via br0
Apr  4 22:44:10 sosiba dhcpd: DHCPACK on 192.168.1.33 to 00:07:0e:b4:50:a5 
via br0
Apr  4 22:44:19 sosiba kernel: IN=br0 OUT= PHYSIN=ath0 PHYSOUT=eth1 
MAC=ff:ff:ff:ff:ff:ff:00:07:0e:b4:50:a5:08:00 SRC=0.0.0.0 
DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=542 PROTO=UDP 
SPT=68 DPT=67 LEN=308
Apr  4 22:44:19 sosiba dhcpd: DHCPREQUEST for 192.168.1.33 from 
00:07:0e:b4:50:a5 via br0
Apr  4 22:44:19 sosiba dhcpd: DHCPACK on 192.168.1.33 to 00:07:0e:b4:50:a5 
via br0
-------------------------------------------------------------------------------

my iptables settings
-------------------------------------------------------------------------------
# Generated by iptables-save v1.2.9 on Fri Mar 18 11:14:11 2005
*mangle
:PREROUTING ACCEPT [1043684:865001650]
:INPUT ACCEPT [1041756:864643520]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [892707:425469139]
:POSTROUTING ACCEPT [892775:425458561]
COMMIT
# Completed on Fri Mar 18 11:14:11 2005
# Generated by iptables-save v1.2.9 on Fri Mar 18 11:14:11 2005
*nat
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE
-A PREROUTING -s 192.168.0.0/16 -i eth0 -j DROP
-A PREROUTING -s 172.16.0.0/12 -i eth0 -j DROP
-A PREROUTING -s 10.0.0.0/8 -i eth0 -j DROP
COMMIT
# Completed on Fri Mar 18 11:14:11 2005
# Generated by iptables-save v1.2.9 on Fri Mar 18 11:14:11 2005
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:syn_flood - [0:0]
-A INPUT -p udp -m udp -m multiport -j LOG --dports 67,68
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# ICMP pakety
-A INPUT -p icmp -m icmp -i eth0 --icmp-type echo-reply -j ACCEPT
-A INPUT -p icmp -m icmp -i eth0 --icmp-type destination-unreachable -j 
ACCEPT
-A INPUT -p icmp -m icmp -m limit -i eth0 --icmp-type echo-request --limit 
1/s --limit-burst 5 -j ACCEPT
-A INPUT -p icmp -m icmp -i eth0 --icmp-type time-exceeded -j ACCEPT
-A INPUT -p tcp -m tcp -i eth0 --dport 113 -j REJECT
-A INPUT -p tcp -m tcp -m multiport -i eth0 -j ACCEPT --dports 
4662,4663,4711
-A INPUT -p udp -m udp -i eth0 --dport 4672 -j ACCEPT
# sshd
-A INPUT -p tcp -m tcp -s 217.75.72.98 -i eth0 --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp -s 62.152.224.131 -i eth0 --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp -s 195.46.69.224/29 -i eth0 --dport 22 -j ACCEPT
# Prepustim toto na eth0
-A INPUT -p tcp -m tcp -m multiport -i eth0 -j ACCEPT --dports 
20,21,80,443,901,10000
# Prepustim toto na eth1, eth2
-A INPUT -i br0 -j ACCEPT
-A INPUT -i eth2 -j ACCEPT
-A OUTPUT -p udp -m udp -m multiport -j LOG --dports 67,68
-A OUTPUT -p udp -m udp -m multiport -j LOG --sports 67,68
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -s 127.0.0.1 -j ACCEPT
-A OUTPUT -s 192.168.1.1 -j ACCEPT
-A OUTPUT -s 192.168.2.1 -j ACCEPT
-A OUTPUT -s 195.46.69.228 -j ACCEPT
-A OUTPUT -m limit --limit 3/hour --limit-burst 5 -j LOG
-A FORWARD -m state -i br0 --state NEW,ESTABLISHED,RELATED -j ACCEPT
-A syn_flood -m limit --limit 1/s --limit-burst 5 -j RETURN
-A syn_flood -j DROP
# Prepustim toto na eth1
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -m udp -m multiport -j LOG --dports 67,68
-A INPUT -p tcp -i eth0 -j syn_flood  --syn
# log DoS
-A INPUT -m limit --limit 3/hour --limit-burst 5 -j LOG
# Vsetko ostatne zabi!
-A INPUT -j DROP
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -p udp -m udp -m multiport -j LOG --dports 67,68
-A FORWARD -p udp -m udp -m multiport -j LOG --sports 67,68
COMMIT
# Completed on Fri Mar 18 11:14:11 2005
-------------------------------------------------------------------------------

I am runing kernel-2.6.12-17mdk.

Please what could be wrong?

Robert. 

Re: Finegrained a/c/mtime was Re: Directory notification problem

[Eric W. Biederman]

Ulrich Drepper <drepper@redhat.com> writes:

> Andi Kleen <ak@suse.de> writes:
> 
> > For stat is also requires a changed glibc ABI -- the glibc/2.4 stat64
> 
> Not only stat64, also plain stat.
> 
> > structure reserved an additional 4 bytes for every timestamp, but these
> > either need to be used to give more seconds for the year 2038 problem
> > or be used for the ms fractions. y2038 is somewhat important too.
> 
> The fields are meant for nanoseconds.  The y2038 will definitely be
> solved by time-shifting or making time_t unsigned.  In any way nothing
> of importance here and now.  Especially since there won't be many
> systems which are running today and which have a 32-bit time_t be used
> then.  For the rest I'm sure that in 37 years there will be the one or
> the other ABI change.

Right.  Given current uptimes and being optimistic the fix for y2038 
is probably needed by 2030 or just a little later.  But in any case
64 bit systems should be maxing out by then, and the conversion to 128
bit systems should have already happened on the server side.  32 bit
systems will likely be limited to embedded and legacy systems by then.

Eric

Netfilter problem

[Kirill Ratkin]

Hi.

I've a strange error when I try to check protocol type
in netfilter hook function. 

I see this message:
kping.c: In function `knet_hook':
kping.c:116: dereferencing pointer to incomplete type
make: *** [kping.o] Error 1

This is part of my code:
static
unsigned int knet_hook(unsigned int hooknum,
                      struct sk_buff** p_skb,
                      const struct net_device* p_in,
                      const struct net_device* p_out,
                      int (*okfn)(struct sk_buff* ))
{
  ...
  if((*p_skb)->nh.iph->protocol==
	(unsigned char)IPPROTO_ICMP)
  {
    printk("<1>ICMP Packet killed\n");
    return NF_DROP;
  }
  ...
}

It had compiled on 2.4.1 version.

I don't understand why ... .


__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

Re: Netfilter problem

[Luigi Genoni]

strange!
it compiled correctly fr mw with all 2.4 kernels, with gcc 2.95.3, and gcc
3.0.0/1

Luigi


On Wed, 3 Oct 2001, Kirill Ratkin wrote:

> Hi.
>
> I've a strange error when I try to check protocol type
> in netfilter hook function.
>
> I see this message:
> kping.c: In function `knet_hook':
> kping.c:116: dereferencing pointer to incomplete type
> make: *** [kping.o] Error 1
>
> This is part of my code:
> static
> unsigned int knet_hook(unsigned int hooknum,
>                       struct sk_buff** p_skb,
>                       const struct net_device* p_in,
>                       const struct net_device* p_out,
>                       int (*okfn)(struct sk_buff* ))
> {
>   ...
>   if((*p_skb)->nh.iph->protocol==
> 	(unsigned char)IPPROTO_ICMP)
>   {
>     printk("<1>ICMP Packet killed\n");
>     return NF_DROP;
>   }
>   ...
> }
>
> It had compiled on 2.4.1 version.
>
> I don't understand why ... .
>
>
> __________________________________________________
> Do You Yahoo!?
> Listen to your Yahoo! Mail messages from any phone.
> http://phone.yahoo.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>