Mikael Starvik wrote:
>>Which iptables/kernel versions are you using?
>
>
> 2.6.19. After further testing it seams to be a compiler/CPU issue. The exact
>
> same kernelconfig works on ARM. So I have to dig some...
On which architecture did the error occur? It could be related
to 32 bit compat i
Mikael Starvik wrote:
> I have a kernel with
>
> CONFIG_IP_NF_TABLES=y
> CONFIG_IP_NF_FILTER=y
> CONFIG_IP_NF_TARGET_LOG=y
>
> all other NF options are off.
Which iptables/kernel versions are you using?
> During kernel startup I get
> iptables: loop hook 1 pos 0022
>
> when filter tries to
Linus Torvalds wrote:
>
> On Tue, 9 Jan 2007, Tomasz Kvarsin wrote:
>
>>During boot into 2.6.20-rc4 iptables says
>>iptables-restore: line 15 failed.
>>And works fine with my default kernel: 2.6.18.x
>
>
> I bet you enabled the new transport-agnostic netfilter, and didn't enable
> some of the
Bernhard Schmidt wrote:
> Patrick McHardy wrote:
>
>>> I've hit another kernel oops with 2.6.20-rc3 on i386 platform. It is
>>> reproducible, as soon as I load nf_conntrack_ipv6 and try to send
>>> something large (scp or so) inside an OpenVPN tunnel on my cl
g splits up a defragmented packet into
its original fragments, the packets are taken from a list and are
passed to the network stack with skb->next still set. This causes
dev_hard_start_xmit to treat them as GSO fragments, resulting in
a use after free when connection track
n struct
nf_conntrack_expect, which is then copied from the expectation to
the conntrack entry.
Peter, do you have locally generated netbios ns queries on the machine
running nf_conntrack? If so, please try this patch. Otherwise, are
there any other conntrack helpers that are actually used?
[NETFILTER]: nf_
Martin Josefsson wrote:
> Check the return value of nfct_nat() in device_cmp(), we might very well
> have non NAT conntrack entries as well.
>
> Signed-off-by: Martin Josefsson <[EMAIL PROTECTED]>
Applied, thanks Martin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Santiago Garcia Mantinan wrote:
> Hi!
>
> When trying to upgrade a machine from 2.6.18 to 2.6.19.1 I found that it
> crashed when loading the ebtables rules on startup.
>
> This is an example of the crash I get:
>
> BUG: unable to handle kernel paging request at virtual address e081e004
>
Jan Engelhardt wrote:
>>Make sure the user specifies the match on the command line before
>>your match. Look at the TCPMSS or REJECT targets for examples for
>>this.
>
>
> That would mean I'd have to
>
> -p tcp -m multiport --dport 1,2,3,4 -m time --time sundays -m
> lotsofothers -j TARGET
>
Jan Engelhardt wrote:
> [...]
>
> Ok, but let's say I wanted to use a bigger match module (layer7, anyone?)
> Then it's just not if(protocol == IPPROTO_TCP). What's the preferred solution
> then?
Make sure the user specifies the match on the command line before
your match. Look at the TCPMSS or RE
Jan Engelhardt wrote:
> On Dec 19 2006 12:51, Patrick McHardy wrote:
>
>>>Reusing code is a good idea, and I would like to do so from my
>>>match modules. netfilter already provides a xt_request_find_target() but
>>>an xt_request_find_match() does not yet ex
Jan Engelhardt wrote:
> Reusing code is a good idea, and I would like to do so from my
> match modules. netfilter already provides a xt_request_find_target() but
> an xt_request_find_match() does not yet exist. This patch adds it.
Why does your match module needs to lookup other matches?
-
To u
Adrian Bunk wrote:
> This patch contains the following possible cleanups:
> - make the following needlessly global functions static:
> - net/netfilter/nf_conntrack_core.c: nf_conntrack_register_cache()
> - net/netfilter/nf_conntrack_core.c: nf_conntrack_unregister_cache()
> - net/netfilter/nf
Adrian Bunk wrote:
> This patch removes ip{,6}_queue that were scheduled for removal
> in mid-2005.
Thanks for the reminder, I forgot to remove the feature-removal-schedule
entry last time you asked.
We really can't remove ip_queue. Many users use this, there is no binary
compatible interface and
Krzysztof Halasa wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>
>>It might be the case that your network device has a
>>hard_header_len > LL_MAX_HEADER, which could trigger
>>a corruption.
>
>
> Hmm... GRE tunnels add 24 bytes... I just
Krzysztof Halasa wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>>How sure are you about this? I can see nothing wrong with that
>>commit and can't reproduce the slab corruption. Please post
>>the rule that triggers this.
>
>
> 99% sure
Krzysztof Halasa wrote:
> Hi,
>
> The following commit breaks ipt_REJECT on my machine. Tested with latest
> 2.6.19rc*, found with git-bisect. i386, gcc-4.1.1, the usual stuff.
> All details available on request, of course.
>
> commit 9d02002d2dc2c7423e5891b97727fde4d667adf1
How sure are you abo
Faidon Liambotis wrote:
> H.323 connection tracking code calls ip_ct_refresh_acct() when
> processing RCFs and URQs but passes NULL as the skb.
> When CONFIG_IP_NF_CT_ACCT is enabled, the connection tracking core tries
> to derefence the skb, which results in an obvious panic.
> A similar fix was a
Jan Beulich wrote:
> Debugging and maintenance support code occasionally needs to know not
> only of module insertions, but also modulke removals. This adds a
> notifier
> chain for this purpose.
>
>
> diff -Npru 2.6.13/kernel/module.c
> 2.6.13-rmmod-notifier/kernel/module.c
> --- 2.6.13/kernel/mo
David S. Miller wrote:
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 07 Sep 2005 01:02:01 +0200
You're right, good catch. This patch fixes it by moving the lock
down to the list-operation which it is supposed to protect.
I think we need to unlink from the list first if y
st-operation which it is supposed to protect.
[NET]: proto_unregister: fix sleeping while atomic
proto_unregister holds a lock while calling kmem_cache_destroy, which can
sleep.
Noticed by Daniele Orlandi <[EMAIL PROTECTED]>.
Signed-off-by: Patrick McHardy &
Patrick McHardy wrote:
Herbert Xu wrote:
We aren't handling the reading of specific fields like the IP protocol
field correctly. This patch should make it work again.
I can't spot the problem, could you give me a hint?
Never mind, I got it, we never fall through to the sec
Herbert Xu wrote:
We aren't handling the reading of specific fields like the IP protocol
field correctly. This patch should make it work again.
I can't spot the problem, could you give me a hint?
I tried to move this logic into the new load_pointer function but it
all came out messy so I sim
Michael Rash wrote:
> Attached is a patch against
> linux-2.6.11.12/net/ipv4/netfilter/ip_queue.c to put Ethernet MAC
> addresses directly into the indev_name and outdev_name portions of the
> ipq_packet_msg struct. This is a total kludge and I doubt anyone else
> will find this useful, but for li
John McGowan wrote:
> Kernel 2.6.13: TCP (libnet?)
>
> Broken libnet?
>
> KERNEL: linux-kernel@vger.kernel.org
> LIBNET 1.1 (c) 1998 - 2004 Mike D. Schiffman <[EMAIL PROTECTED]>
>
> I don't like spam. I track spamvertized sites. Many only respond to TCP
> packets sent to port 80. I need a TCP tr
Alessandro Suardi wrote:
> Stack is hand-copied from the dead box's console.
>
> [] die+0xe4/0x170
> [] do_trap+0x7f/0xc0
> [] do_invalid_op+0xa3/0xb0
> [] error_code+0x4f/0x54
> [] kfree_skbmem+0xb/0x20
> [] __kfree_skb+0x5f/0xf0
> [] tcp_clean_rtx_queue+0x16a/0x470
> [] tcp_ack+0xf6/0x360
> []
Lukasz Spaleniak wrote:
> Hello,
>
> I have simple linux router with three fastethernet cards (intel , e100
> driver). About two months ago it started hanging. It's completly
> freezing machine (no ooops. First of all when it's booting few
> messages like this appears on screen:
>
> NF_IP_ASSERT:
Danial Thom wrote:
> None of this is helpful, but since no one has
> been able to tell me how to tune it to provide
> absolute priority to the network stack I'll
> assume it can't be done.
The network stack already has priority over user processes,
except when executed in process context, so preem
Danial Thom wrote:
> I think part of the problem is the continued
> misuse of the word "latency". Latency, in
> language terms, means "unexplained delay". Its
> wrong here because for one, its explainable. But
> it also depends on your perspective. The
> "latency" is increased for kernel tasks, whi
Gopalakrishnan Raman wrote:
Hi
I'm using 2.6.11.7 and debugging why my ESP tunnel mode does
not work between two 2.6 machines one of which is behind a NAT.
I'm using tcpdump to capture NAT-T packets on one of the hosts
and using espdecrypt (http://www.cs.rpi.edu/~flemej/freebsd/espdecrypt/)
to se
Danial Thom wrote:
--- Patrick McHardy <[EMAIL PROTECTED]> wrote:
Do you have netfilter enabled? Briging
netfilter was
added in 2.6, enabling it will influence
performance
negatively. Otherwise, is this performance drop
visible in other setups besides bridging as
well?
Yes, bridg
Danial Thom wrote:
I just started fiddling with 2.6.12, and there
seems to be a big drop-off in performance from
2.4.x in terms of networking on a uniprocessor
system. Just bridging packets through the
machine, 2.6.12 starts dropping packets at
~100Kpps, whereas 2.4.x doesn't start dropping
until
aner to me.
Patch attached.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -349,12 +349,12 @@ static void icmp_push_reply(struct icmp_
{
struct sk_buff *skb;
- ip_append_
Ollie Wild wrote:
> Patrick McHardy wrote:
>
>> Ollie Wild wrote:
>>
>>> If the ip_append_data() call in icmp_push_reply() fails,
>>> ip_flush_pending_frames() needs to be called. Otherwise, ip_rt_put()
>>> is never called on inet_sk(icmp_socket->
Ollie Wild wrote:
If the ip_append_data() call in icmp_push_reply() fails,
ip_flush_pending_frames() needs to be called. Otherwise, ip_rt_put() is
never called on inet_sk(icmp_socket->sk)->cork.rt, which prevents the
route (and net_device) from ever being freed.
I've attached a patch which f
Rafael J. Wysocki wrote:
> I've got the following BUG on Asus L5D (x86-64) with the 2.6.13-rc5-mm1
> kernel:
>
> BUG: rwlock recursion on CPU#0, nscd/3668, 8817d4a0
>
> Call Trace:{add_preempt_count+105}
> {rwlock_bug+114}
>{_raw_write_lock+62}
> {_write_lock_bh+40}
>{:
them to pure printk wrappers?
[NET]: Make NETDEBUG pure printk wrappers
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit a2db7bcdba3678fe8f67cd7d631c01a888031753
tree 7201cec98ca35b5854daebc14e4650ff95eb8571
parent db29e85a7ece62de1899917c1ec0ffe55cf1d3a0
author Patrick McHardy
esn't need to drop
all references, so flushing is moved to the cleanup path.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit d20d18715b8425060334e879ebb4835202457b3e
tree 3279243f59162c14f8ac145473e1c3f4c586b2fa
parent df2e0392536ecdd6385f4319f746045fd6fae38f
author Patr
David S. Miller wrote:
From: James Bottomley <[EMAIL PROTECTED]>
Date: Sat, 30 Jul 2005 15:23:20 -0500
Actually, I saw this and increased MAX_LINKS as well.
That does absolutely nothing, you cannot create sockets
with protocol numbers larger than NPROTOS which like MAX_LINKS
has the value 32.
Mattia Dongili wrote:
> On Tue, Aug 02, 2005 at 02:47:55AM +0200, Patrick McHardy wrote:
>
>>This should be a fist step towards fixing it. It's probably incomplete
>>(I'm too tired to check it now), but it should fix the problem you're
>>seeing. Could y
Denis Vlasenko wrote:
Linux 2.6.12
Was running for months with this simple iptables rule:
iptables -t nat -A PREROUTING -s 172.17.6.44 -d 172.16.42.201 -p tcp --dport
9100 -j REDIRECT --to 9123
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
00 REDIRECT tcp -- * *
Patrick McHardy wrote:
> Mattia Dongili wrote:
>
>>On Mon, Aug 01, 2005 at 04:27:53PM +0200, Patrick McHardy wrote:
>>
>>
>>>>--- include/linux/netfilter_ipv4/ip_conntrack.h.clean 2005-08-01
>>>>15:09:49.0 +0200
>>>>++
Nishanth Aravamudan wrote:
> On 01.08.2005 [15:11:48 -0600], Josip Loncaric wrote:
>
>>Line 589 of linux-2.6.11.10/net/sunrpc/svcsock.c is obviously wrong:
>>
>>skb->stamp.tv_usec = xtime.tv_nsec * 1000;
>>
>>To convert nsec to usec, one should divide instead of multiplying:
>>
>>
Mattia Dongili wrote:
> On Mon, Aug 01, 2005 at 04:27:53PM +0200, Patrick McHardy wrote:
>
>>>--- include/linux/netfilter_ipv4/ip_conntrack.h.clean2005-08-01
>>>15:09:49.0 +0200
>>>+++ include/linux/netfilter_ipv4/ip_conntrack.h 2005-0
ch is probably why it makes the
underflow go away :) Please try this patch instead.
[NETFILTER]: Fix refcnt underflow in ip_conntrack_event_cache_init
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 5d55b8c6bfba6e6e2ffe26c2a2e2561e278428b7
tree d43366a793d2fa3058c15a752010ef0fd2289
Thomas Graf wrote:
* Patrick McHardy <[EMAIL PROTECTED]> 2005-07-26 01:46
You still have to take care of mixed 64/32 bit environments, u64 fields
for example are differently alligned.
My solution to this (in the same patchset) is that we never
derference u64s but instead copy them.
I
Evgeniy Polyakov wrote:
On Mon, Jul 25, 2005 at 04:32:32PM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
If I understand correctly it tries to workaround some netlink
limitations (limited number of netlink families and multicast groups)
by sending everything to userspace and
Evgeniy Polyakov wrote:
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris ([EMAIL PROTECTED])
wrote:
On Sun, 24 Jul 2005, David S. Miller wrote:
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Sat, 23 Jul 2005 13:14:55 +0400
Andrew has no objection against connector and it lives in
Patrick McHardy wrote:
Andrew McDonald wrote:
Take account of whether a socket is bound to a particular device when
selecting an IPv6 raw socket to receive a packet. Also perform this
check when receiving IPv6 packets with router alert options.
I guess this one makes sense on top.
[IPV4/6
actually delivered to a raw socket to decide
whether to send an ICMP unreachable
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 0fc074eed6ad201d76392dcabbc156784570ea64
tree 913c87ad866f4abb23e9788c0170b81b564cfe7a
parent 36245c9aaddbed7e50d9600c8d1889ebee48a90f
author Patrick M
k8 s wrote:
I AM SORRY FOR THE PREVIOUS MAIL.
I am correcting my previous mail.
Infact I see only One race(not three as was wrongly pointed out).
I commented out the section once again where the race might be.
/
Race Here . The Check(x-
Francois Romieu wrote:
Daniel Higgins <[EMAIL PROTECTED]> :
[napi for natsemi]
Can you please fill a bugzilla entry for it at bugzilla.kernel.org ?
It is bugzilla, not featurewishzilla. If some external patches
cause problem I suggest to contact their authors.
-
To unsubscribe from this list:
onnection-tracking.patch
Daniel's patch is fine, thanks.
ACKed-by: Patrick McHardy <[EMAIL PROTECTED]>
Regards
Patrick
-
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://vg
[NETFILTER]: Revert nf_reset change
Revert the nf_reset change that caused so much trouble, drop conntrack
references manually before packets are queued to packet sockets.
Signed-off-by: Phil Oester <[EMAIL PROTECTED]>
Signed-off-by: Patrick McHardy <[EMAIL PROT
Denis Vlasenko wrote:
text with 8-char tabs:
struct s {
int n; /* comment */
unsigned int u; /* comment */
};
Same text viewed with tabs set to 4-char width:
struct s {
int n; /* comment */
unsigned int u; /* comment */
};
Comments are not aligned anymore
Daniel Drake wrote:
When retrying the telnet test, this appears in the logs:
Jul 8 14:53:04 dsd inv IN=lo OUT=
MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1
LEN=40 TOS=0x10 PREC=0x00 TTL=64 ID=15 DF PROTO=TCP SPT=80 DPT=58950 WINDOW=0
RES=0x00 ACK RST URGP=0
Does th
Karsten Keil wrote:
Hi,
We do not longer use DLT_LINUX_SLL for activ/pass filters but
DLT_PPP_WITHDIRECTION
witch need 1 as outbound flag.
Please apply.
Won't this break compatibility with old ipppd binaries?
Regards
Patrick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Herbert Xu wrote:
On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
qdisc_destroy can still be invoked without qdisc_tree_lock via the
deletion of a class when it calls qdisc_destroy to destroy its
leaf qdisc.
Indeed. Fortuantely HTB seems to be safe as it calls sch_tree_lock
which is a
s bug, one for 2.6.10, one for 2.6.11.
Regards
Patrick
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/10 18:20:44-08:00 [EMAIL PROTECTED]
# [IPV4]: Fix crash while reading /proc/net/route caused by stale pointers
#
# Signed-off-by: Patrick McHardy <[EMAIL P
Alex Tribble wrote:
[EMAIL PROTECTED], 2005-03-15 13:46:12-06:00, [EMAIL PROTECTED]
Export dev_get_flags to fix missing symbols in ipv6.ko
The same patch is already in Linus' tree:
ChangeSet 1.2186, 2005/03/15 10:16:32-08:00, [EMAIL PROTECTED]
[NET]: Need to export dev_get_flags() to modu
Kimmo Sundqvist wrote:
Mar 12 10:39:45 shadowgate Badness in local_bh_enable at kernel/softirq.c:140
Mar 12 10:39:45 shadowgate [] local_bh_enable+0x64/0x70
Mar 12 10:39:45 shadowgate [] isdn_ppp_xmit+0xf7/0x7e0 [isdn]
Mar 12 10:39:45 shadowgate [] isdn_net_xmit+0x186/0x1d0 [isdn]
Mar 12 10:39:45 s
Herbert Xu wrote:
Patrick McHardy <[EMAIL PROTECTED]> wrote:
You're right, good catch. IPT_RETURN is interpreted internally by
ip_tables, but since the value changed it isn't recognized by ip_tables
anymore and returned to nf_iterate() as NF_REPEAT. This patch restores
the old va
eper generated diff -Nru style patch.
#
# ChangeSet
# 2005/03/11 21:41:01+01:00 [EMAIL PROTECTED]
# [NETFILTER]: Fix iptables userspace compatibility breakage
#
# Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
#
# include/linux/netfilter_ipv6/ip6_tables.h
# 2005/03/11 21
Dmitry Torokhov wrote:
My box gets stuck while booting (actually starting ntpd) whith tonight
pull from Linus. It looks like it is spinning in ipt_do_table when I do
SysRq-P. No call trace though.
Please post your ruleset and .config. A backtrace would also be
useful.
Anyone else seeing it? Any ide
Michal Vanco wrote:
On Wednesday 09 March 2005 20:45, Patrick McHardy wrote:
This patch should fix it. The crash is caused by stale pointers,
the pointers in fib_iter_state are not reloaded after seq->stop()
followed by seq->start(pos > 0).
Well. Trap vanished after applying this p
ute caused by stale pointers
#
# Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
#
# net/ipv4/fib_hash.c
# 2005/03/09 20:41:37+01:00 [EMAIL PROTECTED] +11 -1
# [IPV4]: Fix crash while reading /proc/net/route caused by stale pointers
#
# Signed-off-by: Patrick McHardy <[EMAI
govind raj wrote:
/lib/modules/2.4.29/kernel/net/ipv4/netfilter/ip_nat_ftp.o: init_module:
Device or resource busy
You probably already have in already statically linked in. Check your
.config.
Regards
Patrick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
mukesh agrawal wrote:
The cause of the crash is that udp_manip_pkt reads *pskb into iph before
calling skb_ip_make_writable, and fails to update iph after the call.
Since skb_ip_make_writable may delete the original skb when it makes a
copy, a page fault may occur when udp_manip_pkt later derefe
Tompa Septimius Paul wrote:
Hi,
I try to recompile iptables iptables-1.2.11 with kernel 2.6.11-rc2
(and mm2) running and I don't succeed. It complains about
/usr/src/linux/include/linux/netfilter_ipv4/ip_conntrack_tuple.h
after this small changes iptables is compiling again.
I just added a simil
YOSHIFUJI Hideaki / [EMAIL PROTECTED] wrote:
In article <[EMAIL PROTECTED]> (at Mon, 31 Jan 2005 15:11:32 +1100), Herbert Xu
<[EMAIL PROTECTED]> says:
Patrick McHardy <[EMAIL PROTECTED]> wrote:
Ok, final decision: you are right :) conntrack also defragments locally
generated p
Patrick McHardy wrote:
Russell King wrote:
I don't know if the code is using fragment lists in ip_fragment(), but
on reading the code a question comes to mind: if we have a list of
fragments, does each fragment skb have a valid (and refcounted) dst
pointer before ip_fragment() does it'
Patrick McHardy wrote:
Russell King wrote:
I don't know if the code is using fragment lists in ip_fragment(), but
on reading the code a question comes to mind: if we have a list of
fragments, does each fragment skb have a valid (and refcounted) dst
pointer before ip_fragment() does it'
Russell King wrote:
I don't know if the code is using fragment lists in ip_fragment(), but
on reading the code a question comes to mind: if we have a list of
fragments, does each fragment skb have a valid (and refcounted) dst
pointer before ip_fragment() does it's job? If yes, then isn't the
first
David S. Miller wrote:
I've forwarded this to netfilter-devel for inspection.
Thanks for collecting all the data points so well.
Here is the fix for everyone. Please report back if it doesn't
solve the problem. Thanks.
= net/ipv4/netfilter/ip_nat_proto_tcp.c 1.10 vs edited =
--- 1.10/net/i
Jasper Spaans wrote:
I'm seeing a similar problem on my machine - one that does not know what ppp
is. Main suspect is the network bridging code in combination with iptables;
the first lines of the message:
The patch which caused this has already been reverted.
# This is a BitKeeper generated diff
201 - 275 of 275 matches
Mail list logo
