* Re: [PATCH 0/4] netfilter fixes
From: David Miller @ 2010-03-25 18:49 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1269539686-3885-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Thu, 25 Mar 2010 18:54:42 +0100
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Pulled, thanks a lot Patrick.
^ permalink raw reply
* QoS weirdness : HTB accuracy
From: Julien Vehent @ 2010-03-25 18:06 UTC (permalink / raw)
To: Netdev, netfilter
[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]
Hello folks,
I observe unused bandwidth on my QoS policy that I cannot explain.
Conditions are: I have a HTB tree with 8 classes and a total rate of
768kbits. I use the ATM option so I assume the real rate to be something
close to 675kbits (about 88% of the ethernet rate).
The sum of my 8 rates is exactly 768kbits. Some have ceil values up to
768kbits.
When class 20 "tcp_acks" starts borrowing, TC reduces the total bandwidth
down to 595kbits/S (minus 79kbits/s). And I can't explain why....
The attached graph "tc_htb_weirdness.png" shows the result: there are
'holes' in the sending rate.
I tried to play with burst sizes, r2q value and hysteresis mode, but the
results are the same.
System is debian squeeze, kernel version is 2.6.26, iproute2 version is
2.6.26 - 07/25/2008.
I have attached two files:
- "tcrules.txt" : the traffic control rules
- "tc_htb_weirdness.png" : the rrdtool graph, resolution is 1 second.
And here: http://jve.linuxwall.info/ressources/code/tc_hole_analysis.html
a sheet with some of the measures values. I used it to calculate the size
of one of the hole. The last table (with green and red cells) shows that,
when class 20 "tcp_acks" starts sending at unixtime 1265496813, there is a
lot of bandwidth left over (last column is all green). During the 95
seconds while class 20 is sending, 3880776 bits could be sent but are not.
That's about 40kbits/s on average.
Does anybody observess the same behavior? Any logical explanation to this
or is it a bug ?
Julien
[-- Attachment #2: tcrules.txt --]
[-- Type: text/plain, Size: 2619 bytes --]
#root
tc qdisc add dev eth0 root handle 1: htb default 99 r2q 100
#main branch
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 768kbit ceil 768kbit linklayer atm overhead 5
# class 10 "interactive"
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 128kbit ceil 200kbit burst 5k prio 1 linklayer atm overhead 5
tc qdisc add dev eth0 parent 1:10 handle 110: pfifo limit 1000
tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 10 fw flowid 1:10
# class 20 "tcp_acks"
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 64kbit ceil 768kbit burst 3k prio 2 linklayer atm overhead 5
tc qdisc add dev eth0 parent 1:20 handle 120: pfifo limit 1000
tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 20 fw flowid 1:20
# class 30 "ssh"
tc class add dev eth0 parent 1:1 classid 1:30 htb rate 64kbit ceil 300kbit burst 2k prio 3 linklayer atm overhead 5
tc qdisc add dev eth0 parent 1:30 handle 130: sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 3 handle 30 fw flowid 1:30
# class 40 "main web"
tc class add dev eth0 parent 1:1 classid 1:40 htb rate 256kbit ceil 768kbit burst 20k prio 4 linklayer atm overhead 5
# class 41 "sub web 1"
tc class add dev eth0 parent 1:40 classid 1:41 htb rate 100kbit ceil 768kbit burst 20k prio 4 linklayer atm overhead 5
tc qdisc add dev eth0 parent 1:41 handle 141: sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 4 handle 41 fw flowid 1:41
# class 42 "sub web 2"
tc class add dev eth0 parent 1:40 classid 1:42 htb rate 100kbit ceil 768kbit burst 20k prio 4 linklayer atm overhead 5
tc qdisc add dev eth0 parent 1:42 handle 142: sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 5 handle 42 fw flowid 1:42
# class 49 "sub web gen"
tc class add dev eth0 parent 1:40 classid 1:49 htb rate 56kbit ceil 768kbit burst 20k prio 4 linklayer atm overhead 5
tc qdisc add dev eth0 parent 1:49 handle 149: sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 6 handle 49 fw flowid 1:49
# class 50 "torrent"
tc class add dev eth0 parent 1:1 classid 1:50 htb rate 128kbit ceil 768kbit burst 2k prio 5 linklayer atm overhead 5
tc qdisc add dev eth0 parent 1:50 handle 150: sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 7 handle 50 fw flowid 1:50
# class 99 "default"
tc class add dev eth0 parent 1:1 classid 1:99 htb rate 128kbit ceil 768kbit burst 2k prio 5 linklayer atm overhead 5 mtu 1500
tc qdisc add dev eth0 parent 1:99 handle 199: sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 99 handle 99 fw flowid 1:99
[-- Attachment #3: tc_htb_weirdness.png --]
[-- Type: image/png, Size: 29681 bytes --]
^ permalink raw reply
* [PATCH 4/4] netfilter: xt_hashlimit: IPV6 bugfix
From: kaber @ 2010-03-25 17:54 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1269539686-3885-4-git-send-email-kaber@trash.net>
From: Eric Dumazet <eric.dumazet@gmail.com>
A missing break statement in hashlimit_ipv6_mask(), and masks
between /64 and /95 are not working at all...
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
net/netfilter/xt_hashlimit.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
index 70d561a..215a648 100644
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -493,6 +493,7 @@ static void hashlimit_ipv6_mask(__be32 *i, unsigned int p)
case 64 ... 95:
i[2] = maskl(i[2], p - 64);
i[3] = 0;
+ break;
case 96 ... 127:
i[3] = maskl(i[3], p - 96);
break;
--
1.6.5.7
^ permalink raw reply related
* [PATCH 3/4] netfilter: ip6table_raw: fix table priority
From: kaber @ 2010-03-25 17:54 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1269539686-3885-3-git-send-email-kaber@trash.net>
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
The order of the IPv6 raw table is currently reversed, that makes impossible
to use the NOTRACK target in IPv6: for example if someone enters
ip6tables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK
and if we receive fragmented packets then the first fragment will be
untracked and thus skip nf_ct_frag6_gather (and conntrack), while all
subsequent fragments enter nf_ct_frag6_gather and reassembly will never
successfully be finished.
Singed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
include/linux/netfilter_ipv6.h | 1 +
net/ipv6/netfilter/ip6table_raw.c | 2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/linux/netfilter_ipv6.h b/include/linux/netfilter_ipv6.h
index d654873..1f7e300 100644
--- a/include/linux/netfilter_ipv6.h
+++ b/include/linux/netfilter_ipv6.h
@@ -59,6 +59,7 @@
enum nf_ip6_hook_priorities {
NF_IP6_PRI_FIRST = INT_MIN,
NF_IP6_PRI_CONNTRACK_DEFRAG = -400,
+ NF_IP6_PRI_RAW = -300,
NF_IP6_PRI_SELINUX_FIRST = -225,
NF_IP6_PRI_CONNTRACK = -200,
NF_IP6_PRI_MANGLE = -150,
diff --git a/net/ipv6/netfilter/ip6table_raw.c b/net/ipv6/netfilter/ip6table_raw.c
index aef31a2..b9cf7cd 100644
--- a/net/ipv6/netfilter/ip6table_raw.c
+++ b/net/ipv6/netfilter/ip6table_raw.c
@@ -13,7 +13,7 @@ static const struct xt_table packet_raw = {
.valid_hooks = RAW_VALID_HOOKS,
.me = THIS_MODULE,
.af = NFPROTO_IPV6,
- .priority = NF_IP6_PRI_FIRST,
+ .priority = NF_IP6_PRI_RAW,
};
/* The work comes in here from netfilter.c. */
--
1.6.5.7
^ permalink raw reply related
* [PATCH 2/4] netfilter: xt_hashlimit: dl_seq_stop() fix
From: kaber @ 2010-03-25 17:54 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1269539686-3885-2-git-send-email-kaber@trash.net>
From: Eric Dumazet <eric.dumazet@gmail.com>
If dl_seq_start() memory allocation fails, we crash later in
dl_seq_stop(), trying to kfree(ERR_PTR(-ENOMEM))
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
net/netfilter/xt_hashlimit.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
index 9e9c489..70d561a 100644
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -879,7 +879,8 @@ static void dl_seq_stop(struct seq_file *s, void *v)
struct xt_hashlimit_htable *htable = s->private;
unsigned int *bucket = (unsigned int *)v;
- kfree(bucket);
+ if (!IS_ERR(bucket))
+ kfree(bucket);
spin_unlock_bh(&htable->lock);
}
--
1.6.5.7
^ permalink raw reply related
* [PATCH 0/4] netfilter fixes
From: kaber @ 2010-03-25 17:54 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
Hi Dave,
following are four netfilter fixes for 2.6.34, fixing:
- a regression in the recent match, introduced during 2.6.33
- a crash after a failed memory allocation in xt_hashlimit seq_file handling
- an incorrect hook priority of the IPv6 raw table
- a missing 'break' in the IPv6 xt_hashlimit netmask calculation
include/linux/netfilter_ipv6.h | 1 +
net/ipv6/netfilter/ip6table_raw.c | 2 +-
net/netfilter/xt_hashlimit.c | 4 +++-
net/netfilter/xt_recent.c | 2 +-
4 files changed, 6 insertions(+), 3 deletions(-)
Please apply or pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Thanks!
PS: this is my first "live" attempt at using git-send-email, so appologies
in advance in case I made any mistakes.
^ permalink raw reply
* [PATCH 1/4] netfilter: xt_recent: fix regression in rules using a zero hit_count
From: kaber @ 2010-03-25 17:54 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev
In-Reply-To: <1269539686-3885-1-git-send-email-kaber@trash.net>
From: Patrick McHardy <kaber@trash.net>
Commit 8ccb92ad (netfilter: xt_recent: fix false match) fixed supposedly
false matches in rules using a zero hit_count. As it turns out there is
nothing false about these matches and people are actually using entries
with a hit_count of zero to make rules dependant on addresses inserted
manually through /proc.
Since this slipped past the eyes of three reviewers, instead of
reverting the commit in question, this patch explicitly checks
for a hit_count of zero to make the intentions more clear.
Reported-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Tested-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Cc: stable@kernel.org
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
net/netfilter/xt_recent.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/xt_recent.c b/net/netfilter/xt_recent.c
index 7073dbb..971d172 100644
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -267,7 +267,7 @@ recent_mt(const struct sk_buff *skb, const struct xt_match_param *par)
for (i = 0; i < e->nstamps; i++) {
if (info->seconds && time_after(time, e->stamps[i]))
continue;
- if (info->hit_count && ++hits >= info->hit_count) {
+ if (!info->hit_count || ++hits >= info->hit_count) {
ret = !ret;
break;
}
--
1.6.5.7
^ permalink raw reply related
* Re: [PATCH] e1000e: export some settings using ethtool private flags
From: Laurent Chavey @ 2010-03-25 17:52 UTC (permalink / raw)
To: Tantilov, Emil S; +Cc: Jeff Garzik, netdev@vger.kernel.org
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FE4B3E600@rrsmsx501.amr.corp.intel.com>
http://lists.openwall.net/netdev/2007/08/10/114
On Thu, Mar 25, 2010 at 10:33 AM, Tantilov, Emil S
<emil.s.tantilov@intel.com> wrote:
> Jeff Garzik wrote:
>> On 03/25/2010 01:16 PM, Tantilov, Emil S wrote:
>>> Jeff Garzik wrote:
>>>> The ethtool private flags interface exists to get/set
>>>> driver-specific settings at runtime, in a flexible manner.
>>>>
>>>> Use this facility to export a couple e1000e features, that were
>>>> previously only set at module initialization time.
>>>>
>>>> Signed-off-by: Jeff Garzik<jgarzik@redhat.com>
>>>> ---
>>>> drivers/net/e1000e/ethtool.c | 27 +++++++++++++++++++++++++++
>>>> 1 file changed, 27 insertions(+)
>>>
>>> Jeff,
>>>
>>> What is the use case for the ethtool private flags?
>>
>> It is stated in the changelog above :) It enables feature setting at
>> setting, on an easy, per-network-interface basis, that were previously
>> only settable at module initialization (ie. load) time.
>>
>>
>>> At least I don't see an option in ethtool that would make use of
>>> them.
>>
>> This is added in a separate patch, since the above patch is the first
>> to make use of the private-flags ethtool mechanism.
>
> Can you point me to it? It would really help me with testing.
>
> Thanks,
> Emil
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* Re: Problem with talking to the kernel and iproute2/ifconfig
From: Paweł Staszewski @ 2010-03-25 17:52 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Linux Network Development list
In-Reply-To: <4BAB9E02.2040605@trash.net>
Yes
This patch resolve this problem and all is working now correctly.
cat gateways.conf | grep 'addr add' | wc -l
6267
ip -batch gateways.conf
ip a sh | grep ' 10.' | grep inet | wc -l
6267
W dniu 2010-03-25 18:31, Patrick McHardy pisze:
> Paweł Staszewski wrote:
>
>> Hello
>>
>> I have strange problem with kernel 2.6.33.1
>>
>> I have script with 6267 ip's
>>
>> cat gateways.conf | grep 'addr add' | wc -l
>> 6267
>>
>> and when i want to commit this interfaces by command:
>> ip -batch gateways.conf
>>
>> I have only 680 ip interfaces
>> ip a | grep inet | grep ' 10.' | wc -l
>> 680
>>
>>
>> I test this on kernels 2.6.29.1 and 2.6.30.1 and all was OK.
>> on kernel 2.6.29.1
>>
>> ip -batch gateways.conf
>> ip a | grep inet | grep ' 10.' | wc -l
>> 6267
>>
>> on kernel 2.6.30.1
>> ip -batch gateways.conf
>> ip a | grep inet | grep ' 10.' | wc -l
>> 6267
>>
> Does this patch help? When "idx" points to the last device
> of a chain, it will never get incremented past s_idx and we
> fail to reset s_ip_idx.
>
>
^ permalink raw reply
* Re: Oops from tcp_collapse() when using splice()
From: Steven J. Magnani @ 2010-03-25 17:38 UTC (permalink / raw)
To: netdev
In-Reply-To: <1269538271.3012.92.camel@iscandar.digidescorp.com>
On Wed, 2009-11-11 at 11:22 GMT, Karl Hiramoto wrote:
>
> Hi, the following oops occurs with both 2.6.28.9 and 2.6.30.9
>
> userspace program is using splice() on two tcp sockets.
>
> Internal error: Oops: 817 [#1]
> Modules linked in: pppoe pppox br2684 crc_ccitt nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp
> nf_conntrack_proto_gre af_key ixp4xx_crypto ipt_MASQUERADE
> CPU: 0 Not tainted (2.6.30.9 #1)
> PC is at tcp_collapse+0x268/0x338
> LR is at 0xc2c49640
> pc : [<c020be4c>] lr : [<c2c49640>] psr: 80000013
> sp : c0323c80 ip : c3a09920 fp : c0323cb8
> r10: 20ec0490 r9 : 00000e2c r8 : c2d117a0
> r7 : c2c49620 r6 : c2d11780 r5 : c2c49600 r4 : 00000074
> r3 : 00000000 r2 : 20ec4594 r1 : 00004104 r0 : c2c49600
> Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 000039ff Table: 02efc000 DAC: 00000017
> Process swapper (pid: 0, stack limit = 0xc0322260)
> Stack: (0xc0323c80 to 0xc0324000)
> 3c80: c3a09920 c3a09920 c3a098c0 ffffc476 c3a098c0 c3a098c0 0000059a c2cded80
> 3ca0: c2eef054 c3a09c20 c2eef054 c0323cfc c0323cbc c020c114 c020bbf0 20ec0490
> 3cc0: 20ed15b0 18295345 00000000 c3a09c20 00000000 000008ec c3a098c0 0000059a
> 3ce0: c2cded80 c2eef054 c2cdeda0 c2eef054 c0323d30 c0323d00 c020c394 c020bf28
> 3d00: c2e5ec00 ffffffff c3a098c0 c2cded80 0000059a c2eef054 00000020 c2cdeda0
> 3d20: c2eef054 c0323d5c c0323d34 c02102f8 c020c1b4 00000000 c2cded80 c3a098c0
> 3d40: c2eef054 c03576fc c2eef040 0000cd2b c0323d8c c0323d60 c0215770 c020fddc
> 3d60: bf11dcfc 00000000 c0323d8c c0323d78 00000000 c2cded80 c3a098c0 c2eef054
> 3d80: c0323dc8 c0323d90 c021750c c021574c 0a430f2d 0000cd2b 00000005 c0357e58
> 3da0: c033dd04 c2cded80 00000000 c03576fc c0358518 c033b870 00000000 c0323dec
> 3dc0: c0323dcc c01fb6ac c0216e6c c2cded80 c2cded80 c2eef040 c2e5ec00 c0357a40
> 3de0: c0323e0c c0323df0 c01fbb68 c01fb55c 00000000 c01fb550 80000000 c0357a20
> 3e00: c0323e38 c0323e10 c01fb52c c01fbaf8 c2e5ec00 c2cded80 c0357a20 c2cded80
> 3e20: c03576fc c2e5ec00 c0357a40 c0323e64 c0323e3c c01fbab8 c01fb22c 00000000
> 3e40: c01fb220 80000000 c0357a20 c2cded80 c2e5ec00 00000800 c0323e94 c0323e68
> 3e60: c01ddf24 c01fb86c c2e5c600 c0323ecc 00000002 c033b888 ffffbe5e 00000040
> 3e80: 00000000 c033b86c c0323ec0 c0323e98 c01ddff4 c01ddb9c c033b888 00000040
> 3ea0: 00000100 0000012c c033b86c c033b87c ffffbe60 c0323eec c0323ec4 c01e095c
> 3ec0: c01ddf74 c0322000 0000000c 00000100 00000001 00000009 c034b72c 00000000
> 3ee0: c0323f20 c0323ef0 c00359dc c01e0900 c0323efc c0029608 00000003 00000000
> 3f00: 00000008 c03426a8 0001c608 690541f1 0001c49c c0323f30 c0323f24 c0035c98
> 3f20: c003597c c0323f48 c0323f34 c0020058 c0035c60 ffffffff 0000001f c0323fa0
> 3f40: c0323f4c c00209c4 c002000c c03273c8 c383e300 c0322000 00000000 c0021de8
> 3f60: c0322000 c0021de8 c03426a8 0001c608 690541f1 0001c49c c0323fa0 c0323fa4
> 3f80: c0323f94 c0021cb0 c0021dfc 60000013 ffffffff c0323fc0 c0323fa4 c0021cb0
> 3fa0: c0021df4 c034dfc4 c0342450 c001dd60 c0326344 c0323fd0 c0323fc4 c0263be4
> 3fc0: c0021c80 c0323ff4 c0323fd4 c00089c0 c0263b98 c00083ac c001dd60 000039fd
> 3fe0: c03426d8 c001e164 00000000 c0323ff8 00008034 c00087bc 00000000 00000000
> Backtrace:
> [<c020bbe4>] (tcp_collapse+0x0/0x338) from [<c020c114>] (tcp_prune_queue+0x1f8/0x28c)
> [<c020bf1c>] (tcp_prune_queue+0x0/0x28c) from [<c020c394>] (tcp_data_queue+0x1ec/0xc3c)
> [<c020c1a8>] (tcp_data_queue+0x0/0xc3c) from [<c02102f8>] (tcp_rcv_established+0x528/0x5e0)
> [<c020fdd0>] (tcp_rcv_established+0x0/0x5e0) from [<c0215770>] (tcp_v4_do_rcv+0x30/0x1c4)
> [<c0215740>] (tcp_v4_do_rcv+0x0/0x1c4) from [<c021750c>] (tcp_v4_rcv+0x6ac/0x754)
> r7:c2eef054 r6:c3a098c0 r5:c2cded80 r4:00000000
> [<c0216e60>] (tcp_v4_rcv+0x0/0x754) from [<c01fb6ac>] (ip_local_deliver_finish+0x15c/0x21c)
> [<c01fb550>] (ip_local_deliver_finish+0x0/0x21c) from [<c01fbb68>]
> (ip_local_deliver+0x7c/0x88)
> r8:c0357a40 r7:c2e5ec00 r6:c2eef040 r5:c2cded80 r4:c2cded80
> [<c01fbaec>] (ip_local_deliver+0x0/0x88) from [<c01fb52c>] (ip_rcv_finish+0x30c/0x330)
> r4:c0357a20
> [<c01fb220>] (ip_rcv_finish+0x0/0x330) from [<c01fbab8>] (ip_rcv+0x258/0x28c)
> r8:c0357a40 r7:c2e5ec00 r6:c03576fc r5:c2cded80 r4:c0357a20
> [<c01fb860>] (ip_rcv+0x0/0x28c) from [<c01ddf24>] (netif_receive_skb+0x394/0x3d8)
> r7:00000800 r6:c2e5ec00 r5:c2cded80 r4:c0357a20
> [<c01ddb90>] (netif_receive_skb+0x0/0x3d8) from [<c01ddff4>] (process_backlog+0x8c/0xd8)
> [<c01ddf68>] (process_backlog+0x0/0xd8) from [<c01e095c>] (net_rx_action+0x68/0x188)
> [<c01e08f4>] (net_rx_action+0x0/0x188) from [<c00359dc>] (__do_softirq+0x6c/0xf8)
> [<c0035970>] (__do_softirq+0x0/0xf8) from [<c0035c98>] (irq_exit+0x44/0x4c)
> [<c0035c54>] (irq_exit+0x0/0x4c) from [<c0020058>] (asm_do_IRQ+0x58/0x6c)
> [<c0020000>] (asm_do_IRQ+0x0/0x6c) from [<c00209c4>] (__irq_svc+0x24/0x80)
> Exception stack(0xc0323f4c to 0xc0323f94)
> 3f40: c03273c8 c383e300 c0322000 00000000 c0021de8
> 3f60: c0322000 c0021de8 c03426a8 0001c608 690541f1 0001c49c c0323fa0 c0323fa4
> 3f80: c0323f94 c0021cb0 c0021dfc 60000013 ffffffff
> r5:0000001f r4:ffffffff
> [<c0021de8>] (default_idle+0x0/0x4c) from [<c0021cb0>] (cpu_idle+0x3c/0x58)
> [<c0021c74>] (cpu_idle+0x0/0x58) from [<c0263be4>] (rest_init+0x58/0x6c)
> r7:c0326344 r6:c001dd60 r5:c0342450 r4:c034dfc4
> [<c0263b8c>] (rest_init+0x0/0x6c) from [<c00089c0>] (start_kernel+0x210/0x264)
> [<c00087b0>] (start_kernel+0x0/0x264) from [<00008034>] (0x8034)
> r6:c001e164 r5:c03426d8 r4:000039fd
> Code: e50b302c e06a1002 5a000002 e3a03000 (e5833000)
If there was any followup to this, I can't find it. I see similar
problems with 2.6.33.1:
BUG: failure at net/ipv4/tcp_input.c:4665/tcp_collapse()!
Kernel panic - not syncing: BUG!
Call Trace:
[<20002a20>] microblaze_unwind+0x30/0x50
[<20002724>] show_stack+0x130/0x16c
[<20002768>] dump_stack+0x8/0x20
[<2000b5a0>] panic+0x78/0x1f4
[<20177e50>] tcp_collapse+0x358/0x42c
[<20178110>] tcp_prune_queue+0x1ec/0x2c8
[<201783d8>] tcp_data_queue+0x1ec/0xd30
[<2017cb78>] tcp_rcv_established+0x724/0x800
[<20182eb8>] tcp_v4_do_rcv+0x34/0x1d8
[<20185014>] tcp_v4_rcv+0x504/0x814
[<2016585c>] ip_local_deliver+0x118/0x1ec
[<20165e50>] ip_rcv+0x520/0x5ac
[<201468e4>] netif_receive_skb+0x2ec/0x338
[<201469b8>] process_backlog+0x88/0xec
[<2014ad20>] net_rx_action+0x84/0x1b8
[<20011244>] __do_softirq+0x94/0x148
[<20011328>] do_softirq+0x30/0x54
[<2001161c>] irq_exit+0x30/0x48
[<2000114c>] do_IRQ+0xcc/0xf8
IRQ
[<200d6b40>] strncpy+0x1c/0x30
[<200da618>] strncpy_from_user+0x40/0x88
[<2005a374>] getname+0x84/0xf4
[<2004dff8>] do_sys_open+0x28/0xe4
[<2004e0e4>] sys_open+0x14/0x2c
SYSCALL
[<2d19d33c>] PID 88 [syslogd]
Any suggestions on how to pin this down?
------------------------------------------------------------------------
Steven J. Magnani "I claim this network for MARS!
www.digidescorp.com Earthling, return my space modulator!"
#include <standard.disclaimer>
^ permalink raw reply
* Re: [PATCH] e1000e: export some settings using ethtool private flags
From: Jeff Garzik @ 2010-03-25 17:30 UTC (permalink / raw)
To: Tantilov, Emil S; +Cc: netdev@vger.kernel.org
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FE4B3E5A7@rrsmsx501.amr.corp.intel.com>
On 03/25/2010 01:16 PM, Tantilov, Emil S wrote:
> Jeff Garzik wrote:
>> The ethtool private flags interface exists to get/set driver-specific
>> settings at runtime, in a flexible manner.
>>
>> Use this facility to export a couple e1000e features, that were
>> previously only set at module initialization time.
>>
>> Signed-off-by: Jeff Garzik<jgarzik@redhat.com>
>> ---
>> drivers/net/e1000e/ethtool.c | 27 +++++++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>
> Jeff,
>
> What is the use case for the ethtool private flags?
It is stated in the changelog above :) It enables feature setting at
setting, on an easy, per-network-interface basis, that were previously
only settable at module initialization (ie. load) time.
> At least I don't see an option in ethtool that would make use of them.
This is added in a separate patch, since the above patch is the first to
make use of the private-flags ethtool mechanism.
Jeff
^ permalink raw reply
* RE: [PATCH] e1000e: export some settings using ethtool private flags
From: Tantilov, Emil S @ 2010-03-25 17:33 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev@vger.kernel.org
In-Reply-To: <4BAB9DB0.7020203@garzik.org>
Jeff Garzik wrote:
> On 03/25/2010 01:16 PM, Tantilov, Emil S wrote:
>> Jeff Garzik wrote:
>>> The ethtool private flags interface exists to get/set
>>> driver-specific settings at runtime, in a flexible manner.
>>>
>>> Use this facility to export a couple e1000e features, that were
>>> previously only set at module initialization time.
>>>
>>> Signed-off-by: Jeff Garzik<jgarzik@redhat.com>
>>> ---
>>> drivers/net/e1000e/ethtool.c | 27 +++++++++++++++++++++++++++
>>> 1 file changed, 27 insertions(+)
>>
>> Jeff,
>>
>> What is the use case for the ethtool private flags?
>
> It is stated in the changelog above :) It enables feature setting at
> setting, on an easy, per-network-interface basis, that were previously
> only settable at module initialization (ie. load) time.
>
>
>> At least I don't see an option in ethtool that would make use of
>> them.
>
> This is added in a separate patch, since the above patch is the first
> to make use of the private-flags ethtool mechanism.
Can you point me to it? It would really help me with testing.
Thanks,
Emil
^ permalink raw reply
* Re: Problem with talking to the kernel and iproute2/ifconfig
From: Patrick McHardy @ 2010-03-25 17:31 UTC (permalink / raw)
To: Paweł Staszewski; +Cc: Linux Network Development list
In-Reply-To: <4BAB88A3.9070702@itcare.pl>
[-- Attachment #1: Type: text/plain, Size: 749 bytes --]
Paweł Staszewski wrote:
> Hello
>
> I have strange problem with kernel 2.6.33.1
>
> I have script with 6267 ip's
>
> cat gateways.conf | grep 'addr add' | wc -l
> 6267
>
> and when i want to commit this interfaces by command:
> ip -batch gateways.conf
>
> I have only 680 ip interfaces
> ip a | grep inet | grep ' 10.' | wc -l
> 680
>
>
> I test this on kernels 2.6.29.1 and 2.6.30.1 and all was OK.
> on kernel 2.6.29.1
>
> ip -batch gateways.conf
> ip a | grep inet | grep ' 10.' | wc -l
> 6267
>
> on kernel 2.6.30.1
> ip -batch gateways.conf
> ip a | grep inet | grep ' 10.' | wc -l
> 6267
Does this patch help? When "idx" points to the last device
of a chain, it will never get incremented past s_idx and we
fail to reset s_ip_idx.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 455 bytes --]
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 51ca946..3feb2b3 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1194,7 +1194,7 @@ static int inet_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb)
hlist_for_each_entry_rcu(dev, node, head, index_hlist) {
if (idx < s_idx)
goto cont;
- if (idx > s_idx)
+ if (h > s_h || idx > s_idx)
s_ip_idx = 0;
in_dev = __in_dev_get_rcu(dev);
if (!in_dev)
^ permalink raw reply related
* Re: [BUG] i.MX25: Broken include in mach-mx25pdk.c
From: Matthias Kaehlcke @ 2010-03-25 17:28 UTC (permalink / raw)
To: Baruch Siach; +Cc: Sascha Hauer, linux-arm-kernel, David S. Miller, netdev
In-Reply-To: <20100325164147.GA27698@jasper.tkos.co.il>
hi,
El Thu, Mar 25, 2010 at 06:41:47PM +0200 Baruch Siach ha dit:
> On Thu, Mar 25, 2010 at 05:16:35PM +0100, Matthias Kaehlcke wrote:
> > compiling arch/arm/mach-mx25/mach-mx25pdk.c fails due to the missing
> > include "linux/fec.h" and incomplete types that are supposed to
> > defined in this header
> >
> > i'd send a fix, but greping through the kernel tree i haven't been
> > able to identify the file defining the missing elements, i suppose it's still
> > sitting bored in some development tree waiting to be merged
>
> Apply the patch at http://patchwork.ozlabs.org/patch/41235/.
>
> For some reason this patch never made it to the mainline even after my
> repeated nagging :(.
thanks for the pointer, baruch!
david: is there any inconvenience to merge the patch to netdev? if so,
what can be done to make it mergeable?
regards
--
Matthias Kaehlcke
Embedded Linux Developer
Barcelona
The assumption that what currently exists must necessarily
exist is the acid that corrodes all visionary thinking
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
^ permalink raw reply
* Re: Question about e06e7c615877026544ad7f8b309d1a3706410383 -- [IPV4]: The scheduled removal of multipath cached routing support.
From: Nick Bowler @ 2010-03-25 17:21 UTC (permalink / raw)
To: Richard Hartmann; +Cc: linux-kernel, netdev, davem
In-Reply-To: <2d460de71003251011y2d8d1931u683b396f40df4ed1@mail.gmail.com>
On 18:11 Thu 25 Mar , Richard Hartmann wrote:
> I was wondering what the rationale for commit
> e06e7c615877026544ad7f8b309d1a3706410383 is. We upgraded our custom
> image to 2.6.33 recently and found those options to be missing.
>From the diff of that commit:
-What: Multipath cached routing support in ipv4
-When: in 2.6.23
-Why: Code was merged, then submitter immediately disappeared leaving
- us with no maintainer and lots of bugs. The code should not have
- been merged in the first place, and many aspects of it's
- implementation are blocking more critical core networking
- development. It's marked EXPERIMENTAL and no distribution
- enables it because it cause obscure crashes due to unfixable bugs
- (interfaces don't return errors so memory allocation can't be
- handled, calling contexts of these interfaces make handling
- errors impossible too because they get called after we've
- totally commited to creating a route object, for example).
- This problem has existed for years and no forward progress
- has ever been made, and nobody steps up to try and salvage
- this code, so we're going to finally just get rid of it.
-Who: David S. Miller <davem@davemloft.net>
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* RE: [PATCH] e1000e: export some settings using ethtool private flags
From: Tantilov, Emil S @ 2010-03-25 17:16 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev@vger.kernel.org
In-Reply-To: <20100227082305.GA18194@havoc.gtf.org>
Jeff Garzik wrote:
> The ethtool private flags interface exists to get/set driver-specific
> settings at runtime, in a flexible manner.
>
> Use this facility to export a couple e1000e features, that were
> previously only set at module initialization time.
>
> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
> ---
> drivers/net/e1000e/ethtool.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
Jeff,
What is the use case for the ethtool private flags? At least I don't see an option in ethtool that would make use of them.
Thanks,
Emil
^ permalink raw reply
* Question about e06e7c615877026544ad7f8b309d1a3706410383 -- [IPV4]: The scheduled removal of multipath cached routing support.
From: Richard Hartmann @ 2010-03-25 17:11 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: davem
Hi all,
I was wondering what the rationale for commit
e06e7c615877026544ad7f8b309d1a3706410383 is. We upgraded our custom
image to 2.6.33 recently and found those options to be missing.
Thanks,
Richard Hartmann
^ permalink raw reply
* Re: mmotm 2010-03-23 - IPv6 warnings...
From: Valdis.Kletnieks @ 2010-03-25 16:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, linux-kernel
In-Reply-To: <20100324184226.3bf42d8f.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
On Wed, 24 Mar 2010 18:42:26 EDT, Andrew Morton said:
> On Wed, 24 Mar 2010 21:36:41 -0400 Valdis.Kletnieks@vt.edu wrote:
>
> > On Tue, 23 Mar 2010 15:34:59 PDT, akpm@linux-foundation.org said:
> > > The mm-of-the-moment snapshot 2010-03-23-15-34 has been uploaded to
> > >
> > > http://userweb.kernel.org/~akpm/mmotm/
> >
> > Seen in my dmesg. It may be relevant that I'm at home, and my IPv6
> > prefix arrives via a PPP VPN connection. This happened about 20-25 seconds
> > after I launched pppd.
>
> Yes, thanks, I get the same - it doesn't seem to break anything. It
> also happens some time after boot has completed.
Just doing an 'ifup eth0' on a network with IPv6 on it is sufficient.
And it does break stuff:
% ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:24:E8:C6:AD:17
inet addr:128.173.14.107 Bcast:128.173.15.255 Mask:255.255.252.0
inet6 addr: fe80::224:e8ff:fec6:ad17/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
With 2.6.34-rc1-mmotm0309, I see:
% ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:24:E8:C6:AD:17
inet addr:128.173.14.107 Bcast:128.173.15.255 Mask:255.255.252.0
inet6 addr: 2001:468:c80:2103:224:e8ff:fec6:ad17/64 Scope:Global
inet6 addr: fe80::224:e8ff:fec6:ad17/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Something ate my IPv6 address. We run a lot of IPv6 in production, so stuff
is acting wonky.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH] xt_hashlimit: IPV6 bugfix
From: Patrick McHardy @ 2010-03-25 16:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Netfilter Development Mailinglist, David Miller
In-Reply-To: <1269533869.3626.41.camel@edumazet-laptop>
Eric Dumazet wrote:
> A missing break statement in hashlimit_ipv6_mask(), and masks
> between /64 and /95 are not working at all...
Applied, thanks Eric.
^ permalink raw reply
* [PATCH] xt_hashlimit: IPV6 bugfix
From: Eric Dumazet @ 2010-03-25 16:17 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, Netfilter Development Mailinglist, David Miller
A missing break statement in hashlimit_ipv6_mask(), and masks
between /64 and /95 are not working at all...
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
index 8f3e0c0..7ac6ea7 100644
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -487,6 +487,7 @@ static void hashlimit_ipv6_mask(__be32 *i, unsigned int p)
case 64 ... 95:
i[2] = maskl(i[2], p - 64);
i[3] = 0;
+ break;
case 96 ... 127:
i[3] = maskl(i[3], p - 96);
break;
^ permalink raw reply related
* Problem with talking to the kernel and iproute2/ifconfig
From: Paweł Staszewski @ 2010-03-25 16:00 UTC (permalink / raw)
To: Linux Network Development list
Hello
I have strange problem with kernel 2.6.33.1
I have script with 6267 ip's
cat gateways.conf | grep 'addr add' | wc -l
6267
and when i want to commit this interfaces by command:
ip -batch gateways.conf
I have only 680 ip interfaces
ip a | grep inet | grep ' 10.' | wc -l
680
I test this on kernels 2.6.29.1 and 2.6.30.1 and all was OK.
on kernel 2.6.29.1
ip -batch gateways.conf
ip a | grep inet | grep ' 10.' | wc -l
6267
on kernel 2.6.30.1
ip -batch gateways.conf
ip a | grep inet | grep ' 10.' | wc -l
6267
And also weird thing is that on kernel 2.6.33.1
ip addr ls dev vlan0100
158: vlan0100@eth2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noqueue
state DOWN qlen 100
link/ether 00:30:48:67:fd:2e brd ff:ff:ff:ff:ff:ff
the same machine - the same interface but ifconfig use to list ip's
ifconfig vlan0100
vlan0100 Link encap:Ethernet HWaddr 00:30:48:67:fd:2e
inet addr:10.0.0.1 Bcast:0.0.0.0 Mask:255.255.255.248
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
The same machine - with the same script that loads gateways but on
kernel 2.6.29.1
ip a ls dev vlan0100
8: vlan0100@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb
state UP qlen 100
link/ether 00:30:48:d3:33:d6 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/29 brd 10.0.0.7 scope global vlan0100:1
inet 10.0.0.25/29 brd 10.0.0.31 scope global vlan0100:2
inet 10.0.0.49/29 brd 10.0.0.55 scope global vlan0100:3
inet 10.0.0.121/29 brd 10.0.0.127 scope global vlan0100:4
inet 10.0.0.129/29 brd 10.0.0.135 scope global vlan0100:5
inet 10.0.0.153/29 brd 10.0.0.159 scope global vlan0100:6
Bests Regards
Paweł
^ permalink raw reply
* [PATCH 1/1] [TIPC] Removed inactive maintainer
From: Jon Paul Maloy @ 2010-03-25 15:35 UTC (permalink / raw)
To: David Miller; +Cc: Maloy, netdev, tipc-discussion, Jon
In-Reply-To: </home/lmcjoma/tipc/git-tipc/outgoing_patches/>
From: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
MAINTAINERS | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 449d444..5c99bd6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5423,7 +5423,6 @@ S: Maintained
F: sound/soc/codecs/twl4030*
TIPC NETWORK LAYER
-M: Per Liden <per.liden@ericsson.com>
M: Jon Maloy <jon.maloy@ericsson.com>
M: Allan Stephens <allan.stephens@windriver.com>
L: tipc-discussion@lists.sourceforge.net
--
1.5.4.3
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
^ permalink raw reply related
* Re: [Bugme-new] [Bug 15571] New: TCP madness - some packets are shunned.
From: Arnd Hannemann @ 2010-03-25 15:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugzilla-daemon, bugme-daemon, jasen
In-Reply-To: <20100322143711.b78c7a93.akpm@linux-foundation.org>
Am 22.03.2010 22:37, schrieb Andrew Morton:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Thu, 18 Mar 2010 02:46:29 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=15571
>>
>> URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=53646
>> 2
>> Summary: TCP madness - some packets are shunned.
>> Product: Networking
>> Version: 2.5
>> Kernel Version: 2.6.30
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: Other
>> AssignedTo: acme@ghostprotocols.net
>> ReportedBy: jasen@treshna.com
>> Regression: No
>>
>>
>> The host http://www.cv-it.com is virtually unreachable with kernel 2.6.26
>> (and later) slow with kernel 2.6.18 and just fine with windows XP.
>>
>> I used telnet to port 80 for testing.
>>
>> it seems to be a TCP issue, as the having the XP machine behind a linux based
>> iptables firewall pc causes no problems, but telnet from the firewall pc itself
>> to port 80 on www.cv-it.com does not work
For me it seems to be the host is messing up with the window scale option.
Although it claims to support window scaling:
16:23:17.466592 IP x.x.x.x.51151 > 121.199.32.220.80: Flags [S], seq 2159265664, win 5840, options [mss 1460,sackOK,TS val 8382141 ecr 0,nop,wscale 7], length 0
16:23:17.761697 IP 121.199.32.220.80 > x.x.x.x.51151: Flags [S.], seq 3910885479, ack 2159265665, win 65535, options [mss 1448,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,wscale 8], length 0
My host (linux 2.6.32) is offering a window of 5888 (46<<7):
16:23:17.761740 IP x.x.x.x.51151 > 121.199.32.220.80: Flags [.], ack 1, win 46, length 0
And cv-it.com seems to think there is only a window of 46 ignoring the previously negotiated window scaling:
16:23:23.066318 IP 121.199.32.220.80 > x.x.x.x.51151: Flags [.], seq 1:47, ack 112, win 65160, length 46
You can disable window scaling with:
sysctl -w "net.ipv4.tcp_window_scaling=0"
Best regards,
Arnd
^ permalink raw reply
* Re: 2.6.34-rc1: bluetooth oops
From: Pavel Machek @ 2010-03-25 14:26 UTC (permalink / raw)
To: Marcel Holtmann, netdev, Rafael J. Wysocki
Cc: kernel list, linux-bluetooth, Rafael J. Wysocki
In-Reply-To: <20100314204434.GB5208@elf.ucw.cz>
On Sun 2010-03-14 21:44:34, Pavel Machek wrote:
> Hi!
>
> > > I got this after trying to use bnep for few minutes... Machine locked
> > > after that, not sure if it is related.
> >
> > I can't explain it since we haven't changed the BNEP code. So that might
> > be a problem in the networking layer. So posting it to netdev might be a
> > good idea.
>
> Ok, I'll try using bnep some more. I had bad problems with cellphone
> connection at that point, so maybe it is not easy to repeat, and it
> the fact I have not seen it before may not mean much...
So it seems to repeat about twice a week, definitely a regression :-(.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: YOSHIFUJI Hideaki @ 2010-03-25 14:14 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Patrick McHardy, Shan Wei, YOSHIFUJI Hideaki, David Miller,
Alexey Dobriyan, Yasuyuki KOZAKAI, netdev@vger.kernel.org,
netfilter-devel, YOSHIFUJI Hideaki
In-Reply-To: <alpine.DEB.2.00.1003251004200.21825@blackhole.kfki.hu>
(2010/03/25 18:23), Jozsef Kadlecsik wrote:
>> First of all. in "sane" setup, people should configure according
>> to their own requirements. They may or may not want send back
>> icmp packet. And, even if the core is to send icmp back, the
>> state would be correctly assigned.
>
> I meant the state of the fragmented packets. If we let the uncompleted
> fragments to enter conntrack, as far as I see their state will be INVALID.
> Or should we add an exception and set their state to UNTRACKED in
> conntrack?
Got it. INVALID seems fine to me so far
while further consideration might be needed.
>> For my conclusion, first option is just to drop
>> uncompleted fragments as we do today. Second option
>> would be to forward them to the next process so that
>> core code could send ICMPv6 etc. or, we could have
>> new code to send ICMPV6_TIME_EXCEED in REJECT target.
>> In longer term, I think it is better to introduce
>> per-exthdr hooks.
>
> I agree with your conclusion too, except a few question.
>
> It is unclear for me how can you forward the packets to the next process:
> above you pointed out that in defrag/reassembly before conntrack we do not
> know yet whether the packets are destined to the host or not. So again,
> how would you let through the fragments on conntrack then?
>
> I don't know how could the REJECT target help in any way.
Argh, more explanation.
If you unconditionally send ICMPv6, behavior would be
broken.
If you do really want to send ICMP in netfilter,
you could pretend additional rules in filter table.
For example, ICMP to be sent back only if other exthdrs
do not exist, and other packets to be silently dropped.
This cannot be our clean/final/full answer, so I said it'd
be better to introduce per-exthdr hooks in longer term.
Regards,
--yoshfuji
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox