* Re: [PATCH v2] ipv4 : igmp : optimize timer modify logic in igmp_mod_timer()
From: David Miller @ 2011-11-23 22:28 UTC (permalink / raw)
To: mypopydev; +Cc: eric.dumazet, netdev
In-Reply-To: <1322066322-4782-1-git-send-email-mypopydev@gmail.com>
From: Jun Zhao <mypopydev@gmail.com>
Date: Thu, 24 Nov 2011 00:38:42 +0800
> When timer is pending and expires less-than-or-equal-to new delay,
> we need not used del_timer()/add_timer().
>
> Signed-off-by: Jun Zhao <mypopydev@gmail.com>
You did not answer Eric's question, why are you optimizing this
less-used code path?
^ permalink raw reply
* Loan Offer............(3%.Interest Rate)
From: Cortese, Lorraine L @ 2011-11-23 22:28 UTC (permalink / raw)
Home Finance Loan Firm is offering out loans for a low interest rate of 3%. If interested, Kindly provide the following details such as Full name, Address,Gender,Loan Amount, Mobile Number and Country Name to our email address: homeloan11@hotmail.com
^ permalink raw reply
* Re: [PATCH v3 05/10] bql: Byte queue limits
From: Stephen Hemminger @ 2011-11-23 22:22 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1111222140410.15246@pokey.mtv.corp.google.com>
This introduces a leak of kobj if kobject_init_and_add() fails:
Incorrect code:
static int netdev_queue_add_kobject(struct net_device *net, int index)
{
struct netdev_queue *queue = net->_tx + index;
struct kobject *kobj = &queue->kobj;
int error = 0;
kobj->kset = net->queues_kset;
error = kobject_init_and_add(kobj, &netdev_queue_ktype, NULL,
"tx-%u", index);
if (error)
goto exit;
#ifdef CONFIG_BQL
error = sysfs_create_group(kobj, &dql_group);
if (error) {
kobject_put(kobj);
goto exit;
}
#endif
kobject_uevent(kobj, KOBJ_ADD);
dev_hold(queue->dev);
return 0;
exit:
return error;
}
Correct code:
static int netdev_queue_add_kobject(struct net_device *net, int index)
{
struct netdev_queue *queue = net->_tx + index;
struct kobject *kobj = &queue->kobj;
int error = 0;
kobj->kset = net->queues_kset;
error = kobject_init_and_add(kobj, &netdev_queue_ktype, NULL,
"tx-%u", index);
if (error)
goto exit;
#ifdef CONFIG_BQL
error = sysfs_create_group(kobj, &dql_group);
if (error)
goto exit;
#endif
kobject_uevent(kobj, KOBJ_ADD);
dev_hold(queue->dev);
return 0;
exit:
kobject_put(kobj);
return error;
}
^ permalink raw reply
* Re: RAW netfilter - "advanced netfilter setting" or not?
From: Linus Torvalds @ 2011-11-23 22:02 UTC (permalink / raw)
To: David Miller; +Cc: richard.weinberger, pablo, netdev, kaber, netfilter-devel
In-Reply-To: <20111123.160719.540568233963799514.davem@davemloft.net>
On Wed, Nov 23, 2011 at 1:07 PM, David Miller <davem@davemloft.net> wrote:
>
> I just tossed the following into my tree:
Thanks, looking good,
Linus
^ permalink raw reply
* Re: RAW netfilter - "advanced netfilter setting" or not?
From: Linus Torvalds @ 2011-11-23 22:02 UTC (permalink / raw)
To: Jan Engelhardt
Cc: David Miller, Pablo Neira Ayuso, Patrick McHardy, netfilter-devel,
netdev
In-Reply-To: <alpine.LNX.2.01.1111232217220.27025@frira.zrqbmnf.qr>
On Wed, Nov 23, 2011 at 1:27 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> In my opinion, NETFILTER_ADVANCED should be changed to only control
> the visibility of all suboptions, i.e. I suggest that "default m if
> NETFILTER_ADVANCED=n" be done for all non-deprecated modules.
> (Similar to how CONFIG_EXPERT works.)
No thank you. That makes the whole option pointless.
If you want all the modules, just hold down the 'm' key, and be done
with it. There's no skill needed, or need for NETFILTER_ADVANCED.
The whole point of NETFILTER_ADVANCED is for people like me who
actually want a fairly *minimal* kernel config, and probably one that
has no modules.
Modules are evil. They are a security issue, and they encourage a
"distro kernel" approach that takes forever to compile. Just say no.
Build a lean and mean kernel that actually has what you need, and
nothing more. And don't spend stupid time compiling modules you won't
need.
I wish we had a better way of doing a sane localized kernel. "make
localyesconfig" certainly isn't it, even if it tries. But options like
NETFILTER_ADVANCED are at least meant to lessen the pain, and not have
to wade through options that no sane person will know whether they
would ever need.
Linus
^ permalink raw reply
* Re: [PATCH 5/5] ipv4: Don't use the cached pmtu informations for input routes
From: David Miller @ 2011-11-23 21:49 UTC (permalink / raw)
To: herbert; +Cc: steffen.klassert, netdev
In-Reply-To: <20111123155245.GA11638@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.hengli.com.au>
Date: Wed, 23 Nov 2011 23:52:45 +0800
> Steffen Klassert <steffen.klassert@secunet.com> wrote:
>> The pmtu informations on the inetpeer are visible for output and
>> input routes. On packet forwarding, we might propagate a learned
>> pmtu to the sender. As we update the pmtu informations of the
>> inetpeer on demand, the original sender of the forwarded packets
>> might never notice when the pmtu to that inetpeer increases.
>> So use the mtu of the outgoing device on packet forwarding instead
>> of the pmtu to the final destination.
>
> I disagree. MTU increases are detected by the source retrying,
> so they most certainly should notice if our cached value expires.
Herbert, consider the issue one level higher :-)
The issue is that "we", the forwarding entity, end up with a cached on
the input route and report this cached PMTU to the sender.
This takes a while to time out.
So even if the sender "probes" he will be kept from seeing new MTU space
becomming available due to our cached value.
What Steffen is doing is simply re-instating the behavior we had
before the inetpeer conversion occurred. We never used learned PMTU
information on input routes, only output routes stored them.
But now that input and output routes share learned information from
the same set of inetpeer entries, we have to accomodate cases like this
one.
^ permalink raw reply
* Re: [ANNOUNCE] iproute2 v3.0.1
From: Stephen Hemminger @ 2011-11-23 21:45 UTC (permalink / raw)
To: Iain Paton; +Cc: netdev, linux-kernel
In-Reply-To: <4ECD60D7.2010903@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
On Wed, 23 Nov 2011 21:08:39 +0000
Iain Paton <selsinork@gmail.com> wrote:
> Stephen Hemminger wrote:
> > Source: no longer at linux-foundation
> > http://kernel.org/pub/linux/kernel/utils/networking/iproute2/iproute2-3.1.0.gz
>
> That's a 404.
>
> Maybe http://kernel.org/pub/linux/utils/networking/iproute2/iproute2-3.1.0.tar.gz ?
Yes. Thanks.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] b44.c Use dev_kfree_skb_irq() in b44_tx()
From: David Miller @ 2011-11-23 21:40 UTC (permalink / raw)
To: LKML; +Cc: peter.p.waskiewicz.jr, zambrano, linux-kernel, netdev
In-Reply-To: <1322056588-26171-1-git-send-email-LKML@hover.be>
From: Xander Hover <LKML@hover.be>
Date: Wed, 23 Nov 2011 14:56:28 +0100
> Reported issues when using dev_kfree_skb() on UP systems and
> systems with low numbers of cores. dev_kfree_skb_irq() will
> properly save IRQ state before freeing the skb.
>
> Tested on 3.1.1 and 3.2_rc2
...
> Signed-off-by: Xander Hover <LKML@hover.be>
Applied, thanks.
^ permalink raw reply
* Re: Finding a hidden bound TCP socket
From: Rick Jones @ 2011-11-23 21:38 UTC (permalink / raw)
To: David Miller; +Cc: gdfuego, richard.weinberger, linux-kernel, netdev
In-Reply-To: <20111123.160143.58902472755124590.davem@davemloft.net>
On 11/23/2011 01:01 PM, David Miller wrote:
> From: "G. D. Fuego"<gdfuego@gmail.com>
> Date: Wed, 23 Nov 2011 15:27:33 -0500
>
>> Any comments? The behavior seems broken. At the very least its very
>> inconsistent with other Unixes.
>
> Until the socket has a full final tuple it is bound to, there is no
> reason to list it.
>
> No UNIX lists a socket which is partially bound and hasn't either
> performed a listen() or a connect().
Well.... I took the .c file mentioned previously, and compiled it on a
Solaris 10 8/11 instance. The 25-odd sockets it created *were* listed
in the output of netstat -an -- local address as *.<portnum> remote
address as *.* and a state of "BOUND."
A FreeBSD (rev 8 IIRC) netstat -an seems to display them in a state of
"CLOSED." I didn't check HP-UX 11i v3 or AIX 6.
rick jones
^ permalink raw reply
* Re: RAW netfilter - "advanced netfilter setting" or not?
From: Jan Engelhardt @ 2011-11-23 21:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, Pablo Neira Ayuso, Patrick McHardy, netfilter-devel,
netdev
In-Reply-To: <CA+55aFxtSgLppJQ8EbQEovdXsCNxQ1gT31FyP2cpyuvoBLajZw@mail.gmail.com>
On Wednesday 2011-11-23 20:45, Linus Torvalds wrote:
>So I'm the one who long ago asked for some of the more esoteric
>netfilter configuration questions to be hidden behind some "advanced"
>question, and thus the reason why a lot of them are behind that
>NETFILTER_ADVANCED Kconfig setting.
>
>However, I'm now trying OpenSUSE on one of my laptops, and it looks
>like the RAW filter is used by the default OS iptables setup. The fact
>that it is hidden behind NETFILTER_ADVANCED now means that I either
>have to enable the advanced netfilter Kconfig questions, or we should
>just remove the "depends on NETFILTER_ADVANCED" for the RAW case (or,
>rather - caseS - since there's a separate raw filter for ipv4 and
>ipv6, which sounds odd in itself, but that's another issue entirely)
Welcome to the green. You will find the most complete Netfilter stack
here :)
>My gut feel is that if it's one of the filters that a major distro
>depends on by default, it should no longer be hidden. But honestly, I
>didn't look at *why* OpenSUSE uses that filter. Maybe it's just doing
>something really odd and crazy.
The "raw" table is populated by SUSE SFW2 with rules to exempt all
loopback packets from connection tracking since SFW2 at the same time
unconditionally allows all lo transfers in the "filter" table.
>Comments?
In my opinion, NETFILTER_ADVANCED should be changed to only control
the visibility of all suboptions, i.e. I suggest that "default m if
NETFILTER_ADVANCED=n" be done for all non-deprecated modules.
(Similar to how CONFIG_EXPERT works.)
Unless one wants to argue that "that's a detail left to the distro
makers" and "people not compiling kernels would never run into this
issue".
^ permalink raw reply
* [iproute2 PATCH 2/2] tc: Use correct variable type for get_distribution() result
From: Thomas Jarosch @ 2011-11-23 21:15 UTC (permalink / raw)
To: netdev, shemminger
get_distribution() returns an int.
cppcheck reported:
[tc/q_netem.c:243]: (style) Checking if unsigned variable 'dist_size' is less than zero.
The mismatch actually rendered the error checking
after get_distribution() ineffective.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
---
tc/q_netem.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tc/q_netem.c b/tc/q_netem.c
index 01639a8..6dc40bd 100644
--- a/tc/q_netem.c
+++ b/tc/q_netem.c
@@ -125,7 +125,7 @@ static int get_ticks(__u32 *ticks, const char *str)
static int netem_parse_opt(struct qdisc_util *qu, int argc, char **argv,
struct nlmsghdr *n)
{
- size_t dist_size = 0;
+ int dist_size = 0;
struct rtattr *tail;
struct tc_netem_qopt opt;
struct tc_netem_corr cor;
--
1.7.6.4
^ permalink raw reply related
* Re: [GIT PULL] Support for Cadence GEM in the MACB driver
From: Arnd Bergmann @ 2011-11-23 21:14 UTC (permalink / raw)
To: Jamie Iles
Cc: Jean-Christophe PLAGNIOL-VILLARD, Nicolas Ferre, netdev,
linux-arm-kernel, davem
In-Reply-To: <20111121100020.GB7314@totoro>
On Monday 21 November 2011, Jamie Iles wrote:
> Hi Arnd,
>
> Please consider pulling the patches to add support for Cadence GEM to
> the MACB driver. These have been ready to go for a little while but got
> held up with the rename of Ethernet drivers in the last merge window.
> It would be great if we can get some exposure in -next for a little
> while before the next merge window.
Hi Jamie,
I was actually meaning to pull these in time for 3.2, but for some reason
this got dropped on the floor when I was travelling just before
and during the merge window.
Anyway, I've pulled them into the next/driver branch of the arm-soc tree
now. Thanks for your patience!
Arnd
^ permalink raw reply
* [iproute2 PATCH 1/2] tc: Remove unused variable 'res'.
From: Thomas Jarosch @ 2011-11-23 21:13 UTC (permalink / raw)
To: netdev; +Cc: shemminger
Detected by cppcheck.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
---
tc/m_ipt.c | 2 --
tc/m_xt_old.c | 2 --
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/tc/m_ipt.c b/tc/m_ipt.c
index a73d400..b8655f8 100644
--- a/tc/m_ipt.c
+++ b/tc/m_ipt.c
@@ -396,11 +396,9 @@ static int parse_ipt(struct action_util *a,int *argc_p,
char **argv = *argv_p;
int argc = 0, iargc = 0;
char k[16];
- int res = -1;
int size = 0;
int iok = 0, ok = 0;
__u32 hook = 0, index = 0;
- res = 0;
lib_dir = getenv("IPTABLES_LIB_DIR");
if (!lib_dir)
diff --git a/tc/m_xt_old.c b/tc/m_xt_old.c
index 3804d7f..7ed7ecc 100644
--- a/tc/m_xt_old.c
+++ b/tc/m_xt_old.c
@@ -215,11 +215,9 @@ static int parse_ipt(struct action_util *a,int *argc_p,
char **argv = *argv_p;
int argc = 0, iargc = 0;
char k[16];
- int res = -1;
int size = 0;
int iok = 0, ok = 0;
__u32 hook = 0, index = 0;
- res = 0;
set_lib_dir();
--
1.7.6.4
^ permalink raw reply related
* Re: [PATCH net-next] netxen: write IP address to firmware when using bonding
From: David Miller @ 2011-11-23 21:09 UTC (permalink / raw)
To: andy; +Cc: netdev, sony.chacko, rajesh.borundia
In-Reply-To: <1322073791-15223-1-git-send-email-andy@greyhouse.net>
From: Andy Gospodarek <andy@greyhouse.net>
Date: Wed, 23 Nov 2011 13:43:11 -0500
> The following patch was added to enable NX3031 devices to properly
> aggregate frames for LRO:
>
> commit 6598b169b856793f8f9b80a3f3c5a48f5eaf40e3
> Author: Dhananjay Phadke <dhananjay@netxen.com>
> Date: Sun Jul 26 20:07:37 2009 +0000
>
> netxen: enable ip addr hashing
>
> This patch is a followup to that fix as it allows LRO aggregation on
> bonded devices that contain an NX3031 device. This was tested on an
> older distro and modified slightly to the latest upstream.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Let's put a helper function somewhere instead of expanding this sequence
in every driver that might want to determine if it is a bonding slave.
^ permalink raw reply
* Re: [ANNOUNCE] iproute2 v3.0.1
From: Iain Paton @ 2011-11-23 21:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-kernel
In-Reply-To: <20111123122951.6ad25f74@nehalam.linuxnetplumber.net>
Stephen Hemminger wrote:
> Source: no longer at linux-foundation
> http://kernel.org/pub/linux/kernel/utils/networking/iproute2/iproute2-3.1.0.gz
That's a 404.
Maybe http://kernel.org/pub/linux/utils/networking/iproute2/iproute2-3.1.0.tar.gz ?
^ permalink raw reply
* Loan Offer............(3%.Interest Rate)
From: Cortese, Lorraine L @ 2011-11-23 20:53 UTC (permalink / raw)
Home Finance Loan Firm is offering out loans for a low interest rate of 3%. If interested, Kindly provide the following details such as Full name, Address,Gender,Loan Amount, Mobile Number and Country Name to our email address: homeloan11@hotmail.com
^ permalink raw reply
* Re: RAW netfilter - "advanced netfilter setting" or not?
From: David Miller @ 2011-11-23 21:07 UTC (permalink / raw)
To: torvalds; +Cc: richard.weinberger, pablo, netdev, kaber, netfilter-devel
In-Reply-To: <CA+55aFzvZowH1_bA66VZ5Aw0wF3KzdGSqiNZLw46J3u4gpKnxA@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 23 Nov 2011 12:58:20 -0800
> On Nov 23, 2011 12:51 PM, "richard -rw- weinberger" <
> richard.weinberger@gmail.com> wrote:
>>
>> SuSEfirewall2 is using NOTRACK for the lo interface.
>>
>> iptables -t raw -A PREROUTING -j NOTRACK -i lo
>> iptables -t raw -A OUTPUT -j NOTRACK -o lo
>
> Yeah, and that (NOTRACK) was another thing that was disabled due to
> depending on advanced config... Which is probably why my raw table was
> empty even after I enabled that one by hand.
>
> So we'd need to unhide both raw and notrack, methinks.
I just tossed the following into my tree:
--------------------
[PATCH] netfilter: Remove NOTRACK/RAW dependency on NETFILTER_ADVANCED.
Distributions are using this in their default scripts, so don't hide
them behind the advanced setting.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/netfilter/Kconfig | 1 -
net/ipv6/netfilter/Kconfig | 1 -
net/netfilter/Kconfig | 1 -
3 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig
index 1dfc18a..f19f218 100644
--- a/net/ipv4/netfilter/Kconfig
+++ b/net/ipv4/netfilter/Kconfig
@@ -325,7 +325,6 @@ config IP_NF_TARGET_TTL
# raw + specific targets
config IP_NF_RAW
tristate 'raw table support (required for NOTRACK/TRACE)'
- depends on NETFILTER_ADVANCED
help
This option adds a `raw' table to iptables. This table is the very
first in the netfilter framework and hooks in at the PREROUTING
diff --git a/net/ipv6/netfilter/Kconfig b/net/ipv6/netfilter/Kconfig
index 4484648..f792b34 100644
--- a/net/ipv6/netfilter/Kconfig
+++ b/net/ipv6/netfilter/Kconfig
@@ -186,7 +186,6 @@ config IP6_NF_MANGLE
config IP6_NF_RAW
tristate 'raw table support (required for TRACE)'
- depends on NETFILTER_ADVANCED
help
This option adds a `raw' table to ip6tables. This table is the very
first in the netfilter framework and hooks in at the PREROUTING
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 8260b13..e8f3796 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -542,7 +542,6 @@ config NETFILTER_XT_TARGET_NOTRACK
tristate '"NOTRACK" target support'
depends on IP_NF_RAW || IP6_NF_RAW
depends on NF_CONNTRACK
- depends on NETFILTER_ADVANCED
help
The NOTRACK target allows a select rule to specify
which packets *not* to enter the conntrack/NAT
--
1.7.6.4
^ permalink raw reply related
* Re: Finding a hidden bound TCP socket
From: David Miller @ 2011-11-23 21:01 UTC (permalink / raw)
To: gdfuego; +Cc: richard.weinberger, linux-kernel, netdev
In-Reply-To: <CALmbKGVUuZs+wigpkr0WPfn2pYP=tQh5-MsYWeRxbug=HskVQQ@mail.gmail.com>
From: "G. D. Fuego" <gdfuego@gmail.com>
Date: Wed, 23 Nov 2011 15:27:33 -0500
> Any comments? The behavior seems broken. At the very least its very
> inconsistent with other Unixes.
Until the socket has a full final tuple it is bound to, there is no
reason to list it.
No UNIX lists a socket which is partially bound and hasn't either
performed a listen() or a connect().
Nobody has any comments because nobody thinks it's worth worrying about.
^ permalink raw reply
* Re: drivers/net: Kconfig & Makefile cleanup
From: Jeff Kirsher @ 2011-11-23 20:58 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1321944662.2839.222.camel@deadeye>
[-- Attachment #1: Type: text/plain, Size: 749 bytes --]
On Mon, 2011-11-21 at 22:51 -0800, Ben Hutchings wrote:
> ou wrote that (some time ago now):
> > As a side cleanup, found that the arcnet, token ring, and PHY
> > Kconfig options were a tri-state option and should have been
> > a bool option.
>
> How did you decide that? This seems to be correct for TR, but ARCNET
> and PHYLIB each select some support code that can be built as a module
> (and which has been, in Debian).
>
> Ben.
Off the top of my head, I was making the decision based on the other
protocols Kconfig entries.
So does that mean ARCNET could be a module and a driver using ARCNET
would have to be a module as well?
I will take a look at this to come up with a solution, if one has not
been sent out yet.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] netprio_cgroup: Fix build break
From: David Miller @ 2011-11-23 20:53 UTC (permalink / raw)
To: nhorman; +Cc: netdev, kirr, john.r.fastabend, robert.w.love, sfr, linux-next
In-Reply-To: <1322051553-28987-1-git-send-email-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Wed, 23 Nov 2011 07:32:33 -0500
> I broke the build with the addition of netprio_cgroups if CONFIG_CGROUPS=n.
> This patch corrects it by moving the offending struct into an ifdef
> CONFIG_CGROUPS block. Also clean up a few needless defines and inline functions
> that don't get called if CONFIG_CGROUPS isn't defined while Im at it.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks.
^ permalink raw reply
* Re: RAW netfilter - "advanced netfilter setting" or not?
From: richard -rw- weinberger @ 2011-11-23 20:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Patrick McHardy, David Miller, Pablo Neira Ayuso, netfilter-devel,
netdev
In-Reply-To: <CA+55aFxy5iojY8AZfK+fK_OURLPsD_8Y6z9FXnHt88jYFMrimg@mail.gmail.com>
On Wed, Nov 23, 2011 at 9:17 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Nov 23, 2011 at 11:58 AM, Patrick McHardy <kaber@trash.net> wrote:
>>
>> Most likely they're using NOTRACK to avoid connection tracking for
>> some traffic. Could you post the output of "iptables -t raw -vxnL"?
>
> Hmm. That's actually empty for me. I only went by some error messages
> during bootup. Or maybe I should boot the distro kernel to see that
> there isn't something else I'm missing that makes the user setup
> unhappy.
>
SuSEfirewall2 is using NOTRACK for the lo interface.
iptables -t raw -A PREROUTING -j NOTRACK -i lo
iptables -t raw -A OUTPUT -j NOTRACK -o lo
--
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH] ipv6: tcp: fix panic in SYN processing
From: David Miller @ 2011-11-23 20:49 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1322048036.17693.6.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 23 Nov 2011 12:33:56 +0100
> commit 72a3effaf633bc ([NET]: Size listen hash tables using backlog
> hint) added a bug allowing inet6_synq_hash() to return an out of bound
> array index, because of u16 overflow.
>
> Bug can happen if system admins set net.core.somaxconn &
> net.ipv4.tcp_max_syn_backlog sysctls to values greater than 65536
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Good catch, applied and queued up for -stable.
Thanks!
^ permalink raw reply
* Re: cache forver in 3.2.0-rc2-00400-g866d43c ?
From: Arkadiusz Miśkiewicz @ 2011-11-23 20:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1322077447.2775.6.camel@edumazet-laptop>
On Wednesday 23 of November 2011, Eric Dumazet wrote:
> Le mercredi 23 novembre 2011 à 19:37 +0100, Eric Dumazet a écrit :
> > Le mercredi 23 novembre 2011 à 19:31 +0100, Arkadiusz Miśkiewicz a
> >
> > écrit :
> > > Mine 00400-g866d43c was after 6fe4c6d466e95d31164f14b1ac4aefb51f0f4f82
> > > (which is merge of ipv4: fix redirect handling), so I have it.
> > >
> > > (I'm using pure linus git repo)
> >
> > OK thanks for this information, I am working on a patch.
>
> Please test the following patch, thanks !
Applied and running, results in a few days (since using net A only once per
day).
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* Udp packets received with improper length
From: paul bilke @ 2011-11-23 20:14 UTC (permalink / raw)
To: netdev
We recently updated an embedded powerpc platform from 2.6.32 to 2.6.37. When deployed in the field devices with the new kernel have started receiving truncated UDP packets from their mates across noisy links. To test we wrote a simple client and
server. The client sends 512 byte packets with a sequence number to the server listening on a UDP socket. On the client box we use netem to corrupt 100% of the packets sent(after transferring some data so arp cache is populated). The server then
dumps the length received and the serial number from any packets that are received. Netem sometimes corrupts bits in the source MAC address so these packets arrive with valid UDP checksums and are delivered to the user application. With the
server running on the 2.6.32 box we send a few million packets to it and only receive packets that are exactly 512 bytes long. When we do the same on the box running 2.6.37 we receive hundred of short packets, zero length and also 504 byte packets.
When I use TCPdump on the box running 2.6.37 the truncated packets have valid checksums (Source MAC was corrupted by NETEM) and are of proper length (554 byte ethernet frame, 540 Byte IP portion and 520 byte UDP length) but the userland receives 504
or 0 length in recvfrom. To see if this was just a powerpc related issue I repeated the test on x86 virtual machines. A vm running 2.6.18 (Centos 5) receives only 512 byte packets. On a vm running 2.6.40 (Fedora 15) I receive 512, 504 and 0 length
packets.
Below is a hex dump of a packet captured on the 2.6.37 box (its identical on the wire as captured by a probe) but is dispatched to the user application which receives it as a 504 byte packet.
This is problematic in our environment since the IP connectivity is typically a high error rate (Satellite or long haul microwave link).
I did not know if there is a known behavior change that was introduced after 2.6.32 (before .37) that would explain this behavior.
Any ideas what is going on here would be appreciated.
Paul Bilke
00e10c0000fe00115510132808004500
021c00004000401110360a0a0a450a0a
0a43b0971391020875b4323233333400
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000
^ permalink raw reply
* Re: Finding a hidden bound TCP socket
From: Eric Dumazet @ 2011-11-23 20:32 UTC (permalink / raw)
To: G. D. Fuego; +Cc: richard -rw- weinberger, linux-kernel, netdev
In-Reply-To: <CALmbKGVUuZs+wigpkr0WPfn2pYP=tQh5-MsYWeRxbug=HskVQQ@mail.gmail.com>
Le mercredi 23 novembre 2011 à 15:27 -0500, G. D. Fuego a écrit :
> Any comments? The behavior seems broken. At the very least its very
> inconsistent with other Unixes.
Feel free to send a patch ;)
A user/process can consume all ports anyway, the 65000 port range is so
small...
^ 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