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 register
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 issues
Mikael Starvik wrote:
Ok, this is what happens:
iptable_filter sets up initial_table.
The part that says { IPT_ALIGN(sizeof(struct ipt_standard_target)), }
initializes a xt_entry_target struct. target_size gets the value
0x24 and name .
This is copied to loc_cpu_entry in
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 client
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 tracking h
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 tracking handles the next fragment.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit
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 client
(patched with UDPv6 transport) the router
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 actual rules
ntrack_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_conntrack_netbi
in the expectation registered by the netbios_ns
helper and it later copied to the expected connection, which causes invalid
memory dereferences when trying to call the helper.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit fe6df90eb909a84593b6902e6e4f802687bc4564
tree
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"
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
the
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
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 REJECT
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
-p udp -m
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:
> 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
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
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 exist. This patch adds it.
Why does your match
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()
> -
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
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
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()
-
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. Pas
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
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 about
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. Past this commit I get corruptions after 5 minutes at most
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 noticed the following code in
include/linux/netdevice.h
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
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
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
> ---
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/module.c
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 you're
pposed 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 <[EMAIL PROTECTED]>
---
commit 90fdf8bc78b52d40190766c5496
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 [EMAIL PROTECTED]
---
commit 90fdf8bc78b52d40190766c5496a3d8c24903be8
tree
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 you're
going
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 second switch
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
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
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 second switch
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
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
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 traceroute
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 libipq
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:
>
>
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:
Alessandro Suardi wrote:
Stack is hand-copied from the dead box's console.
[c0103714] die+0xe4/0x170
[c010381f] do_trap+0x7f/0xc0
[c0103b33] do_invalid_op+0xa3/0xb0
[c0102faf] error_code+0x4f/0x54
[c02eb05b] kfree_skbmem+0xb/0x20
[c02eb0cf] __kfree_skb+0x5f/0xf0
[c031304a]
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
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,
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, while it
may
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
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
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
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, br
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
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, bridging is clean
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
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_data(icmp_socke
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_socke
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-sk)-cork.rt, which prevents
the route (and net_device) from ever
that one of ip_push_pending_frames() and
ip_flush_pending_frames() is always called. Both will do proper cleanup.
I'm open to suggestions if you think there's a cleaner way to implement
this.
Checking the return value of ip_append_data seems cleaner to me.
Patch attached.
Signed-off-by: Patrick
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
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
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}
>
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:80241ca9{add_preempt_count+105}
80241682{rwlock_bug+114}
re printk wrappers?
[NET]: Make NETDEBUG pure printk wrappers
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit a2db7bcdba3678fe8f67cd7d631c01a888031753
tree 7201cec98ca35b5854daebc14e4650ff95eb8571
parent db29e85a7ece62de1899917c1ec0ffe55cf1d3a0
author Patrick McHardy <[EMAI
)))
goto error;
These macros always looked a bit ugly to me, with your cleanup there
isn't a single spot left where we require them to accept code as
argument, so how about we change them to pure printk wrappers?
[NET]: Make NETDEBUG pure printk wrappers
Signed-off-by: Patrick McHardy [EMAIL PROTECTED
rop
all references, so flushing is moved to the cleanup path.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit d20d18715b8425060334e879ebb4835202457b3e
tree 3279243f59162c14f8ac145473e1c3f4c586b2fa
parent df2e0392536ecdd6385f4319f746045fd6fae38f
author Patrick McHardy <[EMA
-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit d20d18715b8425060334e879ebb4835202457b3e
tree 3279243f59162c14f8ac145473e1c3f4c586b2fa
parent df2e0392536ecdd6385f4319f746045fd6fae38f
author Patrick McHardy [EMAIL PROTECTED] Wed, 03 Aug 2005 20:33:25 +0200
committer Patrick McHardy [EMAIL
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
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 you give it
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 you give it a spin?
Done, also this patch fixes
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 -- * *
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 d43366a793d2fa3058c15a752010ef0fd22894cc
p
.
[NETFILTER]: Fix refcnt underflow in ip_conntrack_event_cache_init
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 5d55b8c6bfba6e6e2ffe26c2a2e2561e278428b7
tree d43366a793d2fa3058c15a752010ef0fd22894cc
parent df2e0392536ecdd6385f4319f746045fd6fae38f
author Patrick McHardy [EMAIL PROTECTED] Mon
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-08-01
15:08:52.0 +0200
@@ -298,6 +298,7
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:
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
+++ include/linux/netfilter_ipv4/ip_conntrack.h 2005-08-01
15:08:52.0
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
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
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
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
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 don't
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
was 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
was 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 McHardy
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
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
401 - 500 of 545 matches
Mail list logo
