Re: Kernel Oops when using the Netfilter QUEUE target
In message <[EMAIL PROTECTED]> you write: > On Wed, Apr 25, 2001 at 04:24:46PM +1000, James Morris wrote: > > Please try the patch below. > > So i did and it seems to work just fine (= no more oops') under 2.4.3/2.4.2-a James, I only glanced at the patch, but IIRC it just did route_me_harder() on everything. This is, unfortunately, no longer "Best Practice": the prevailing trend is to reroute only when something has actually been changed, to avoid overriding the socket binding, etc. See mangle for an example (store old values, see if they changed). I think this would be more complex, but still possible in your case, no? Thanks, Rusty. -- Premature optmztion is rt of all evl. --DK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops when using the Netfilter QUEUE target
In message [EMAIL PROTECTED] you write: On Wed, Apr 25, 2001 at 04:24:46PM +1000, James Morris wrote: Please try the patch below. So i did and it seems to work just fine (= no more oops') under 2.4.3/2.4.2-a James, I only glanced at the patch, but IIRC it just did route_me_harder() on everything. This is, unfortunately, no longer Best Practice: the prevailing trend is to reroute only when something has actually been changed, to avoid overriding the socket binding, etc. See mangle for an example (store old values, see if they changed). I think this would be more complex, but still possible in your case, no? Thanks, Rusty. -- Premature optmztion is rt of all evl. --DK - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops when using the Netfilter QUEUE target
On Wed, Apr 25, 2001 at 04:24:46PM +1000, James Morris wrote: > > I have encountered a problem (perhaps a bug)! The attached code makes my kernel >oops > > in some cases when injecting new packets through Netfilter's QUEUE target. The >problem > > only appears when the original packet is a TCP packet; i have tried with ICMP and >UDP packets > > also but this does not trigger any oops. I have tried to code on several computers >and they > > all oops. The following description regards the case when submitting new packets >instead > > of TCP packets. > > Please try the patch below. So i did and it seems to work just fine (= no more oops') under 2.4.3/2.4.2-ac21! The packets being sent also seems to be correct; James you're the man :-) BTW could you describe the problem? And why it caused an oops? Best regards, Martin -- There's no place like ~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops when using the Netfilter QUEUE target
On Wed, Apr 25, 2001 at 04:24:46PM +1000, James Morris wrote: I have encountered a problem (perhaps a bug)! The attached code makes my kernel oops in some cases when injecting new packets through Netfilter's QUEUE target. The problem only appears when the original packet is a TCP packet; i have tried with ICMP and UDP packets also but this does not trigger any oops. I have tried to code on several computers and they all oops. The following description regards the case when submitting new packets instead of TCP packets. Please try the patch below. So i did and it seems to work just fine (= no more oops') under 2.4.3/2.4.2-ac21! The packets being sent also seems to be correct; James you're the man :-) BTW could you describe the problem? And why it caused an oops? Best regards, Martin -- There's no place like ~ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops when using the Netfilter QUEUE target
On Tue, 24 Apr 2001 19:25:47 +0200, Martin Clausen <[EMAIL PROTECTED]> wrote: >I have encountered a problem (perhaps a bug)! The attached code makes my kernel oops >in some cases when injecting new packets through Netfilter's QUEUE target. The >problem >Entering kdb (current=0xc68f6000, pid 884) Oops: Oops >due to oops @ 0xc01e7456 >eax = 0x05dc ebx = 0xc7acf224 ecx = 0x000e edx = 0xc72f8440 >esi = 0xc7cee740 edi = 0x esp = 0xc68f7c90 eip = 0xc01e7456 >ebp = 0xc68f7cb0 xss = 0x0018 xcs = 0x0010 eflags = 0x00010287 >xds = 0x0018 xes = 0x0018 origeax = 0x = 0xc68f7c5c >kdb> > >I will be glad to submit som more (debug) information?! At the very least, you need to run the kdb commands 'bt' (backtrace) and 'id %eip-0x10' (disassemble around failing instruction). Registers and eip on their own are almost meaningless. ps. Don't copy me on the reply, I only maintain kdb, not the failing netfilter code. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops when using the Netfilter QUEUE target
On Wed, 25 Apr 2001, Martin Clausen wrote:
> Hi there!
>
> I have encountered a problem (perhaps a bug)! The attached code makes my kernel oops
> in some cases when injecting new packets through Netfilter's QUEUE target. The
>problem
> only appears when the original packet is a TCP packet; i have tried with ICMP and
>UDP packets
> also but this does not trigger any oops. I have tried to code on several computers
>and they
> all oops. The following description regards the case when submitting new packets
>instead
> of TCP packets.
Please try the patch below.
- James
--
James Morris
<[EMAIL PROTECTED]>
diff -urN linux-2.4.3/net/ipv4/netfilter/ip_queue.c
linux-2.4.3-fix/net/ipv4/netfilter/ip_queue.c
--- linux-2.4.3/net/ipv4/netfilter/ip_queue.c Tue Dec 12 07:37:04 2000
+++ linux-2.4.3-fix/net/ipv4/netfilter/ip_queue.c Wed Apr 25 16:10:24 2001
@@ -24,8 +24,10 @@
#include
#include
#include
+#include
#include
+#include
#define IPQ_QMAX_DEFAULT 1024
#define IPQ_PROC_FS_NAME "ip_queue"
@@ -198,6 +200,32 @@
kfree(q);
}
+/* With a chainsaw... */
+static int route_me_harder(struct sk_buff *skb)
+{
+ struct iphdr *iph = skb->nh.iph;
+ struct rtable *rt;
+
+ struct rt_key key = {
+ dst:iph->daddr, src:iph->saddr,
+ oif:skb->sk ? skb->sk->bound_dev_if : 0,
+ tos:RT_TOS(iph->tos)|RTO_CONN,
+#ifdef CONFIG_IP_ROUTE_FWMARK
+ fwmark:skb->nfmark
+#endif
+ };
+
+ if (ip_route_output_key(, ) != 0) {
+ printk("route_me_harder: No more route.\n");
+ return -EINVAL;
+ }
+
+ /* Drop old route. */
+ dst_release(skb->dst);
+ skb->dst = >u.dst;
+ return 0;
+}
+
static int ipq_mangle_ipv4(ipq_verdict_msg_t *v, ipq_queue_element_t *e)
{
int diff;
@@ -223,6 +251,8 @@
"in mangle, dropping packet\n");
return -ENOMEM;
}
+ if (e->skb->sk)
+ skb_set_owner_w(newskb, e->skb->sk);
kfree_skb(e->skb);
e->skb = newskb;
}
@@ -230,7 +260,13 @@
}
memcpy(e->skb->data, v->payload, v->data_len);
e->skb->nfcache |= NFC_ALTERED;
- return 0;
+
+ /*
+* Extra routing needed on local out, as the QUEUE target never
+* returns control to the table.
+*/
+ return ((e->info->hook == NF_IP_LOCAL_OUT) ?
+ route_me_harder(e->skb) : 0);
}
static inline int id_cmp(ipq_queue_element_t *e, unsigned long id)
diff -urN linux-2.4.3/net/ipv4/netfilter/iptable_mangle.c
linux-2.4.3-fix/net/ipv4/netfilter/iptable_mangle.c
--- linux-2.4.3/net/ipv4/netfilter/iptable_mangle.c Tue Jan 30 03:07:30 2001
+++ linux-2.4.3-fix/net/ipv4/netfilter/iptable_mangle.c Wed Apr 25 16:09:02 2001
@@ -148,7 +148,7 @@
ret = ipt_do_table(pskb, hook, in, out, _mangler, NULL);
/* Reroute for ANY change. */
- if (ret != NF_DROP && ret != NF_STOLEN
+ if (ret != NF_DROP && ret != NF_STOLEN && ret != NF_QUEUE
&& ((*pskb)->nh.iph->saddr != saddr
|| (*pskb)->nh.iph->daddr != daddr
|| (*pskb)->nfmark != nfmark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops when using the Netfilter QUEUE target
On Tue, 24 Apr 2001 19:25:47 +0200, Martin Clausen [EMAIL PROTECTED] wrote: I have encountered a problem (perhaps a bug)! The attached code makes my kernel oops in some cases when injecting new packets through Netfilter's QUEUE target. The problem Entering kdb (current=0xc68f6000, pid 884) Oops: Oops due to oops @ 0xc01e7456 eax = 0x05dc ebx = 0xc7acf224 ecx = 0x000e edx = 0xc72f8440 esi = 0xc7cee740 edi = 0x esp = 0xc68f7c90 eip = 0xc01e7456 ebp = 0xc68f7cb0 xss = 0x0018 xcs = 0x0010 eflags = 0x00010287 xds = 0x0018 xes = 0x0018 origeax = 0x regs = 0xc68f7c5c kdb I will be glad to submit som more (debug) information?! At the very least, you need to run the kdb commands 'bt' (backtrace) and 'id %eip-0x10' (disassemble around failing instruction). Registers and eip on their own are almost meaningless. ps. Don't copy me on the reply, I only maintain kdb, not the failing netfilter code. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel Oops when using the Netfilter QUEUE target
Hi there!
I have encountered a problem (perhaps a bug)! The attached code makes my kernel oops
in some cases when injecting new packets through Netfilter's QUEUE target. The problem
only appears when the original packet is a TCP packet; i have tried with ICMP and UDP
packets
also but this does not trigger any oops. I have tried to code on several computers and
they
all oops. The following description regards the case when submitting new packets
instead
of TCP packets.
It seems that new packets can not have a length greater than 92 bytes under 2.4.2-ac21
and 76 under 2.4.3; these sizes may vary but the oops can be triggered by choosing
a larger packet size.
Netfilter is configured the following way:
[root@lwb7 ipsecd]# modprobe iptable_filter
[root@lwb7 ipsecd]# modprobe ip_queue
[root@lwb7 ipsecd]# iptables -t mangle -A OUTPUT -d lwb5 -j LOG
[root@lwb7 ipsecd]# iptables -t mangle -A OUTPUT -d lwb5 -j QUEUE
[root@lwb7 ipsecd]# lsmod
Module Size Used by
ipt_LOG 4063 1 (autoclean)
iptable_mangle 2542 0 (autoclean) (unused)
ip_queue5946 0 (unused)
iptable_filter 2533 0 (unused)
ip_tables 14936 3 [ipt_LOG iptable_mangle iptable_filter]
NVdriver 688003 12 (autoclean)
8139too16845 1 (autoclean)
[root@lwb7 ipsecd]# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
LOGall -- anywhere lwb5.it.dtu.dk LOG level warning
QUEUE all -- anywhere lwb5.it.dtu.dk
I have added some printk's in net/code/netfilter.c in nf_reinject() and i seems that
the kernel oops' in info->okfn(skb) (i added printk before and after):
IN= OUT=eth0 SRC=130.225.76.37 DST=130.225.76.35 LEN=60 TOS=0x00 PREC=0x00 TTL=64
ID=173 PROTO=TCP SPT=1025 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0
nf_hook: Verdict = QUEUE.
In nf_reinject() before info->okfn(skb) line 521
Unable to handle kernel NULL pointer dereference at virtual address 02b4
printing eip:
c01e7456
*pde =
Entering kdb (current=0xc68f6000, pid 884) Oops: Oops
due to oops @ 0xc01e7456
eax = 0x05dc ebx = 0xc7acf224 ecx = 0x000e edx = 0xc72f8440
esi = 0xc7cee740 edi = 0x esp = 0xc68f7c90 eip = 0xc01e7456
ebp = 0xc68f7cb0 xss = 0x0018 xcs = 0x0010 eflags = 0x00010287
xds = 0x0018 xes = 0x0018 origeax = 0x = 0xc68f7c5c
kdb>
I will be glad to submit som more (debug) information?!
I really hope someone can help me :)
Best regards,
Martin Clausen
--
There's no place like ~
/* Compile: gcc -o nfcrash nfcrash.c -lipq
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* For CRASH_ME <= 32 everything seems to work (2.4.2-ac21).
* For CRASH_ME > 32 the kernel oops'es in case of TCP traffic (2.4.2-ac21)?!
*
* For CRASH_ME <= 16 everything seems to work (2.4.3).
* For CRASH_ME > 16 the kernel oops'es in case of TCP traffic (2.4.3)?!
*
*/
const int CRASH_ME = 17;
const int ESP_OFF = 0;
unsigned short in_cksum(unsigned short *addr, int len)
{
int nleft = len;
int sum = 0;
unsigned short *w = addr;
unsigned short answer = 0;
while (nleft > 1) {
sum += *w++;
nleft -= 2;
}
if (nleft == 1) {
*(unsigned char *)() = *(unsigned char *) w;
sum += answer;
}
sum = (sum >> 16) + (sum & 0x);
sum += (sum >> 16);
answer = ~sum;
return answer;
}
int main(int argc, char **argv)
{
struct ipq_handle *qh;
struct ipq_packet_msg *qpkt;
struct iphdr *iph;
unsigned char buff[8192];
unsigned char *esppkt;
int esppkt_len;
int type;
int len;
/* Init first (flags are not implemented; yet) */
if ( (qh = ipq_create_handle(0)) == NULL) {
/* Run away... */
ipq_perror("create_handle()");
exit(1);
}
/* We would like to receive not only metadata... */
if (ipq_set_mode(qh, IPQ_COPY_PACKET, sizeof(buff)) < 0) {
ipq_perror("set_mode()");
goto cleanup;
}
/* Now real fun begins... Just stay in loop, read packets,
* accept them if they are IP. */
while (1) {
len = ipq_read(qh, buff, sizeof buff, 0);
if (len == 0) {
fprintf(stderr, "read(): Zero
