From: Dilip Daya <dilip.daya@hp.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jmorris@namei.org" <jmorris@namei.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"adobrian@gmail.com" <adobrian@gmail.com>
Subject: Re: ip_local_deliver_finish: proto 108 (IPComp) isn't netns-ready
Date: Wed, 16 Nov 2011 10:01:55 -0500 [thread overview]
Message-ID: <1321455715.2530.27.camel@pro6455b.example.com> (raw)
In-Reply-To: <m1d3d0oraf.fsf@fess.ebiederm.org>
[-- Attachment #1: Type: text/plain, Size: 3957 bytes --]
Hi Eric,
> If you have a clue what is going on with ip compression my
> recommendation would be to add .netns_ok = 1. Verify that the
> everything works and send the patch. You probably want to
> verify and test ipv6 as well. It really looks like the code
> is fine and it just needs to be enabled.
Thank you for the above feedback.
FYI..my results
Environment:
- v3.0.9-stable kernel with ".netns_ok = 1" applied to ipcomp.c
(see attached patch)
- Same setup as described earlier for two netns stacks on single system.
- ltp-network test results:
- /usr/lib/ltp/testcases/bin/tcp[4|6]-multi-diffip13
IPv4: no issues
IPv6: no issues
- /usr/lib/ltp/testcases/bin/udp4-multi-diffip06
IPv4 -> no issues
IPv6 -> script issue (work-in-progress)
- /usr/lib/ltp/testcases/bin/udp[4|6]-multi-diffnic06
IPv4: no issues
IPv6: no issues
- /usr/lib/ltp/testcases/bin/udp[4|6]-multi-diffport06
IPv4 -> multiple messages:
UDP: short packet: From 10.0.9.2:1025 1008/267 to 10.0.9.1:55575
UDP: short packet: From 10.0.0.1:54544 253/38 to 10.0.0.2:1050
UDP: short packet: From 10.0.0.1:21601 27128/1008 to 10.0.0.2:27137
IPv6 -> multiple messages:
UDPv6: short packet: From [fd00:1:1:1::2]:1028 242/122 to
[fd00:1:1:1::1]:38438
UDPv6: short packet: From [fd00:1:1:1::2]:37972 21588/29 to
[fd00:1:1:1::1]:21588
UDPv6: short packet: From [fd00:1:1:1::2]:1026 1008/898 to
[fd00:1:1:1::1]:55703
- /usr/lib/ltp/testcases/bin/icmp4-multi-diffip06
IPv4 -> no issues
IPv6 -> multiple messages:
ICMPv6 checksum failed [fd00:0001:0000:0003:0000:0000:0000:0001 >
fd00:0001:0000:0003:0000:0000:0000:0002]
...continuing with debug.
--DilipD.
On Wed, 2011-11-09 at 22:38 +0000, Eric W. Biederman wrote:
> Dilip Daya <dilip.daya@hp.com> writes:
>
> > Hi All,
> >
> > LTP-network tests produced:
> >
> > "ip_local_deliver_finish: proto 108 (IPComp) isn't netns-ready"
> >
> > Question:
> > Is the above a bug or feature (IPComp, mode: transport) not netns
> > enabled?
>
> I would call it a missing feature.
>
> > Environment:
> >
> > * v3.1-stable kernel.
> >
> > * Configured two network-namespaces via "ip netns add ...".
> > on a single system: netns0 (assigned as server) and
> > netns1 (assigned as client).
> > - assigned multiple physical NICs to netns0 and netns1.
> >
> > * Entered netns1 (ip netns exec netns1 bash) to execute
> > ltp-network suite of tests between netns1 and netns0.
> >
> > * The following LTP tests produced messages:
> >
> > "kernel: ip_local_deliver_finish: proto 108 isn't netns-ready"
> >
> > - /usr/lib/ltp/testcases/bin/icmp4-multi-diffip06
> > - /usr/lib/ltp/testcases/bin/tcp4-multi-diffip13
> > - /usr/lib/ltp/testcases/bin/udp4-multi-diffip06
> > - /usr/lib/ltp/testcases/bin/udp4-multi-diffnic06
> > - /usr/lib/ltp/testcases/bin/udp4-multi-diffport06
> >
> > * I also noticed missing ".netns_ok = 1" in:
> > - http://lxr.linux.no/linux+v3.1/net/ipv4/ipcomp.c#L150
>
> The .netns_ok flag indicates that someone has audited the code and made
> certain it all works with network namespaces.
>
> Skimming the code I don't see anything that jumps out as me as
> wrong. And it looks like Alexy did the work in Jan of 2010.
>
> commit a92df2545402c1a08e7a158f4477a52dea0eeeed
> Author: Alexey Dobriyan <adobriyan@gmail.com>
> Date: Mon Jan 25 10:38:34 2010 +0000
>
> netns xfrm: ipcomp support
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> However it is clear that no one has actually tested ipcomp with
> network namespaces.
>
> If you have a clue what is going on with ip compression my
> recommendation would be to add .netns_ok = 1. Verify that the
> everything works and send the patch. You probably want to
> verify and test ipv6 as well. It really looks like the code
> is fine and it just needs to be enabled.
>
> Eric
[-- Attachment #2: ipcomp_netns.patch --]
[-- Type: text/x-patch, Size: 310 bytes --]
--- a/ipv4/ipcomp.c 2011-11-11 13:12:24.000000000 -0500
+++ b/net/ipv4/ipcomp.c 2011-11-08 09:12:37.000000000 -0500
@@ -151,6 +151,7 @@ static const struct net_protocol ipcomp4
.handler = xfrm4_rcv,
.err_handler = ipcomp4_err,
.no_policy = 1,
+ .netns_ok = 1,
};
static int __init ipcomp4_init(void)
prev parent reply other threads:[~2011-11-16 15:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1320858706.2531.45.camel@pro6455b.example.com>
2011-11-09 22:38 ` ip_local_deliver_finish: proto 108 (IPComp) isn't netns-ready Eric W. Biederman
2011-11-16 15:01 ` Dilip Daya [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1321455715.2530.27.camel@pro6455b.example.com \
--to=dilip.daya@hp.com \
--cc=adobrian@gmail.com \
--cc=ebiederm@xmission.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).