netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Please i need help with this error, hunting bugs
@ 2009-01-31 21:19 ilninno
  2009-01-31 21:29 ` crash in nfnetlink_queue Eric Leblond
  0 siblings, 1 reply; 3+ messages in thread
From: ilninno @ 2009-01-31 21:19 UTC (permalink / raw)
  To: netfilter-devel

Hello again.


I tested the issue in different examples:

1- When using NF_REPEAT with only 1 queue, there isnt any problem
   $IPTABLES -A OUTPUT -m state --state NEW -m mark ! --mark 1 -j NF_QUEUE 0
   $IPTABLES -A OUTPUT -j ACCEPT

2- When using NF_REPEAT with (program 1 in queue 0 and program 2 in queue 1)

                $IPTABLES -A OUTPUT -m state --state NEW -m mark !
--mark 1 -j NF_QUEUE 0
                $IPTABLES -A OUTPUT -m state --state NEW -m mark
--mark 1 -j NF_QUEUE 1

then i got kernel panic. I think the problem is that using
nfq_set_verdict_mark(myQueue, id, NF_REPEAT, htonl(1) ,0, NULL)  don't
modify packet length and kernel freezes, but im not sure, im newbie
please help me.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: crash in nfnetlink_queue
  2009-01-31 21:19 Please i need help with this error, hunting bugs ilninno
@ 2009-01-31 21:29 ` Eric Leblond
  2009-02-09 17:08   ` Patrick McHardy
  0 siblings, 1 reply; 3+ messages in thread
From: Eric Leblond @ 2009-01-31 21:29 UTC (permalink / raw)
  To: ilninno; +Cc: netfilter-devel

Hi,

Could you specify your kernel version ?

By the way please use a explicit subject when posting: lot of people
avoir to read 'I need help' messages.

BR,

ilninno a écrit :
> Hello again.
> 
> 
> I tested the issue in different examples:
> 
> 1- When using NF_REPEAT with only 1 queue, there isnt any problem
>    $IPTABLES -A OUTPUT -m state --state NEW -m mark ! --mark 1 -j NF_QUEUE 0
>    $IPTABLES -A OUTPUT -j ACCEPT
> 
> 2- When using NF_REPEAT with (program 1 in queue 0 and program 2 in queue 1)
> 
>                 $IPTABLES -A OUTPUT -m state --state NEW -m mark !
> --mark 1 -j NF_QUEUE 0
>                 $IPTABLES -A OUTPUT -m state --state NEW -m mark
> --mark 1 -j NF_QUEUE 1
> 
> then i got kernel panic. I think the problem is that using
> nfq_set_verdict_mark(myQueue, id, NF_REPEAT, htonl(1) ,0, NULL)  don't
> modify packet length and kernel freezes, but im not sure, im newbie
> please help me.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Eric Leblond <eric@inl.fr>
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: crash in nfnetlink_queue
  2009-01-31 21:29 ` crash in nfnetlink_queue Eric Leblond
@ 2009-02-09 17:08   ` Patrick McHardy
  0 siblings, 0 replies; 3+ messages in thread
From: Patrick McHardy @ 2009-02-09 17:08 UTC (permalink / raw)
  To: Eric Leblond; +Cc: ilninno, netfilter-devel

Eric Leblond wrote:
> Hi,
> 
> Could you specify your kernel version ?
> 
> By the way please use a explicit subject when posting: lot of people
> avoir to read 'I need help' messages.

Indeed. It was specified in the first email:

> BUG: unable to handle kernel NULL pointer dereference
> IP: [<f89848a9>] :nfnetlink_queue:nfqnl_enqueue_packet+0x18f/0x507
> *pde = 2264c067 *pte = 00000000
> Oops: 0000 [#1] SMP
> Modules linked in: nfnetlink_queue nfnetlink vfat fat fuse sco bridge
> stp bnep l2cap bluetooth sunrpc ts_bm xt_string xt_comment xt_NFQUEUE
> ipt_LOG xt_mark iptable_nat nf_nat ip6t_REJECT nf_conntrack_ipv6
> ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq
> dm_multipath uinput ata_generic pata_acpi snd_hda_intel ppdev
> snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device
> snd_pcm_oss snd_mixer_oss snd_pcm floppy snd_timer i2c_i801 pcspkr
> firewire_ohci firewire_core snd_page_alloc i2c_core snd_hwdep
> parport_pc parport usb_storage iTCO_wdt pata_jmicron snd
> iTCO_vendor_support crc_itu_t sky2 soundcore [last unloaded:
> microcode]
> 
> Pid: 3258, comm: listener Not tainted (2.6.27.9-159.fc10.i686 #1)
> EIP: 0060:[<f89848a9>] EFLAGS: 00010282 CPU: 1
> EIP is at nfqnl_enqueue_packet+0x18f/0x507 [nfnetlink_queue]
> EAX: 00000000 EBX: 000000b0 ECX: 00000009 EDX: 00000001
> ESI: f25a9b40 EDI: e25c1a00 EBP: e749ebfc ESP: e749ebb0
>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> Process listener (pid: 3258, ti=e749e000 task=e89a59b0 task.ti=e749e000)
> Stack: e75353c0 f5d73800 f8cfb0b4 e74c6cb8 e2872a00 0000003c e2872a00 e25c1a30
>        00040438 00000438 e2642c80 e749ebfc 00000286 00b10f03 00000300 00000040
>        e75353c0 00000002 f8984cdc e749ec24 c0648717 c06d7cec f5d73800 c080f50c
> Call Trace:
>  [<c0648717>] ? __nf_queue+0x108/0x18b
>  [<c06488ab>] ? nf_reinject+0x111/0x134
>  [<c0654a3c>] ? dst_output+0x0/0xb
>  [<f8984707>] ? nfqnl_recv_verdict+0x1db/0x1ee [nfnetlink_queue]
>  [<f8c0b1aa>] ? nfnetlink_rcv_msg+0x10e/0x125 [nfnetlink]
>  [<c04f5143>] ? security_netlink_recv+0xf/0x11
>  [<f8c0b0b5>] ? nfnetlink_rcv_msg+0x19/0x125 [nfnetlink]
>  [<f8c0b09c>] ? nfnetlink_rcv_msg+0x0/0x125 [nfnetlink]
>  [<c0646c7c>] ? netlink_rcv_skb+0x30/0x78
>  [<f8c0b01c>] ? nfnetlink_rcv+0x1c/0x29 [nfnetlink]
>  [<c064688d>] ? netlink_unicast+0xee/0x144
>  [<c0646b12>] ? netlink_sendmsg+0x22f/0x23c

This looks like the packet went into a loop back to the queue. Which
shouldn't actually be a problem.

>> I tested the issue in different examples:
>>
>> 1- When using NF_REPEAT with only 1 queue, there isnt any problem
>>    $IPTABLES -A OUTPUT -m state --state NEW -m mark ! --mark 1 -j NF_QUEUE 0
>>    $IPTABLES -A OUTPUT -j ACCEPT
>>
>> 2- When using NF_REPEAT with (program 1 in queue 0 and program 2 in queue 1)
>>
>>                 $IPTABLES -A OUTPUT -m state --state NEW -m mark !
>> --mark 1 -j NF_QUEUE 0
>>                 $IPTABLES -A OUTPUT -m state --state NEW -m mark
>> --mark 1 -j NF_QUEUE 1
>>
>> then i got kernel panic. I think the problem is that using
>> nfq_set_verdict_mark(myQueue, id, NF_REPEAT, htonl(1) ,0, NULL)  don't
>> modify packet length and kernel freezes, but im not sure, im newbie
>> please help me.

Did you perform any changes on the ruleset during your test,
or unload any netfilter modules?

Please also send me the nfnetlink_queue object file in private.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-02-09 17:08 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-31 21:19 Please i need help with this error, hunting bugs ilninno
2009-01-31 21:29 ` crash in nfnetlink_queue Eric Leblond
2009-02-09 17:08   ` Patrick McHardy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).