From: Davide Caratti <dcaratti@redhat.com>
To: linux-sctp@vger.kernel.org
Subject: Re: Problem on SCTP
Date: Tue, 21 Feb 2017 18:51:56 +0000 [thread overview]
Message-ID: <1487703116.2621.69.camel@redhat.com> (raw)
In-Reply-To: <CAFXGft+weUFodkkiY=kgHMX+t4fECQhB+PKg2dBKxCBeU7w7MA@mail.gmail.com>
On Tue, 2017-02-21 at 12:26 +0800, Sun Paul wrote:
> Hi,
>
> sorry to get back late, the platform is running on KVM. and this
> problem is resolved by moving to VMware environment, however, a new
> problem is coming out, we noticed that the HB REQ is being ABORT from
> client.
hello Sun,
I'm working on some issues with SCTP checksums: sometimes the kernel does
not compute CRC32c on forwarded SCTP packets (see
http://www.spinics.net/lists/linux-sctp/msg05666.html); but apparently this
is a scenario where the opposite occurs (i.e. the kernel computes CRC32c
even if when it is not necessary _ see below):
> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
> <Michael.Tuexen@lurchi.franken.de> wrote:
> >
> > >
> > > On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> > >
> > > Your router does NOT change any field in the SCTP packet, but the
> > > SCTP checksum was modified from
> > > Checksum: 0xbaea49e5 (not verified)
> > > to
> > > Checksum: 0xa9a86d3f (not verified)
> > > At least one of these is wrong.
what Michael says is correct: in case SCTP NAT did not translate port
numbers, the packet CRC32c should not be recomputed, because SCTP checksum
has no pseudo-header. The (RFC) patch below modifies netfilter SCTP NAT to
avoid useless calls to sctp_compute_csum() when source / destination port
is not changed (*).
------ 8< ------------
--- a/net/netfilter/nf_nat_proto_sctp.c
+++ b/net/netfilter/nf_nat_proto_sctp.c
@@ -33,6 +33,7 @@
enum nf_nat_manip_type maniptype)
{
sctp_sctphdr_t *hdr;
+ __be16 port_xlate = 0;
if (!skb_make_writable(skb, hdroff + sizeof(*hdr)))
return false;
@@ -41,14 +42,17 @@
if (maniptype = NF_NAT_MANIP_SRC) {
/* Get rid of src port */
+ port_xlate |= hdr->source ^ tuple->src.u.sctp.port;
hdr->source = tuple->src.u.sctp.port;
} else {
/* Get rid of dst port */
+ port_xlate |= hdr->dest ^ tuple->dst.u.sctp.port;
hdr->dest = tuple->dst.u.sctp.port;
}
if (skb->ip_summed != CHECKSUM_PARTIAL) {
- hdr->checksum = sctp_compute_cksum(skb, hdroff);
+ if (port_xlate)
+ hdr->checksum = sctp_compute_cksum(skb, hdroff);
skb->ip_summed = CHECKSUM_NONE;
}
------ >8 ------------
Please let me know if it can be useful in your setup.
Thank you in advance,
regards,
--
davide
Notes:
(*) how I tested this: on a two-namespace test setup, a
ncat server is running on namespace nat_test_b and listening for SCTP onÂ
eth1 (192.168.111.18:2000). On namespace nat_test_a, ncat client binds to
dummy0 (10.0.0.13) and connects to server through eth0 (192.168.111.17),
where a SNAT rule is configured; eth0 and eth1 are connected through a
switch. The following command is done on the client:
# perf probe -m nf_nat --add sctp_csum_update
# perf probe -m nf_nat --add sctp_csum_combine
# ip netns exec nat_test_a \
perf record -e '{probe:sctp_csum_combine,probe:sctp_csum_update}' -R -- \
ncat --sctp -c uname -s 10.0.0.13 -w1 192.168.111.18 2000
9 packets are received by the server:
IP 192.168.111.17.33022 > 192.168.111.18.2000: sctp (1) [INIT]
IP 192.168.111.18.2000 > 192.168.111.17.33022: sctp (1) [INIT ACK]
IP 192.168.111.17.33022 > 192.168.111.18.2000: sctp (1) [COOKIE ECHO]
IP 192.168.111.18.2000 > 192.168.111.17.33022: sctp (1) [COOKIE ACK]
IP 192.168.111.17.33022 > 192.168.111.18.2000: sctp (1) [DATA]
IP 192.168.111.18.2000 > 192.168.111.17.33022: sctp (1) [SACK]
IP 192.168.111.17.33022 > 192.168.111.18.2000: sctp (1) [SHUTDOWN]
IP 192.168.111.18.2000 > 192.168.111.17.33022: sctp (1) [SHUTDOWN ACK]
IP 192.168.111.17.33022 > 192.168.111.18.2000: sctp (1) [SHUTDOWN COMPLETE]
Before applying the patch:
# perf script | wc -l
9
After applying the patch:
# perf script | wc -l
0
prev parent reply other threads:[~2017-02-21 18:51 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-06 9:34 Problem on SCTP Sun Paul
2017-01-06 9:34 ` Sun Paul
2017-01-06 11:43 ` Marcelo Ricardo Leitner
2017-01-06 11:43 ` Marcelo Ricardo Leitner
2017-01-09 2:06 ` Sun Paul
2017-01-09 2:06 ` Sun Paul
2017-01-06 12:37 ` Neil Horman
2017-01-06 12:37 ` Neil Horman
2017-01-09 2:08 ` Sun Paul
2017-01-09 2:08 ` Sun Paul
2017-01-09 2:30 ` Sun Paul
2017-01-09 2:30 ` Sun Paul
2017-01-09 9:51 ` David Laight
2017-01-09 9:51 ` David Laight
2017-01-09 10:00 ` Sun Paul
2017-01-09 10:00 ` Sun Paul
2017-01-09 12:25 ` Neil Horman
2017-01-09 12:25 ` Neil Horman
2017-01-09 16:31 ` Sun Paul
2017-01-09 16:31 ` Sun Paul
2017-01-09 19:18 ` Neil Horman
2017-01-09 19:18 ` Neil Horman
2017-01-10 1:30 ` Sun Paul
2017-01-10 1:30 ` Sun Paul
2017-01-10 1:31 ` Sun Paul
2017-01-10 1:31 ` Sun Paul
2017-01-10 14:33 ` Neil Horman
2017-01-10 14:33 ` Neil Horman
2017-01-11 8:39 ` Sun Paul
2017-01-11 8:39 ` Sun Paul
2017-01-11 12:57 ` Neil Horman
2017-01-11 12:57 ` Neil Horman
2017-01-12 9:30 ` Sun Paul
2017-01-12 9:30 ` Sun Paul
2017-01-12 9:51 ` David Laight
2017-01-12 9:51 ` David Laight
2017-01-12 10:53 ` Michael Tuexen
2017-01-12 10:53 ` Michael Tuexen
2017-01-13 3:27 ` Sun Paul
2017-01-13 3:27 ` Sun Paul
2017-01-13 3:27 ` Sun Paul
2017-01-13 3:27 ` Sun Paul
2017-01-13 3:29 ` Sun Paul
2017-01-13 3:29 ` Sun Paul
2017-01-13 9:43 ` Michael Tuexen
2017-01-13 9:43 ` Michael Tuexen
2017-01-13 13:19 ` Michael Tuexen
2017-01-13 13:19 ` Michael Tuexen
2017-02-21 4:26 ` Sun Paul
2017-02-21 4:26 ` Sun Paul
2017-02-21 15:53 ` Xin Long
2017-02-21 15:53 ` Xin Long
2017-02-22 1:12 ` Sun Paul
2017-02-22 1:12 ` Sun Paul
2017-02-22 2:00 ` Xin Long
2017-02-22 2:00 ` Xin Long
2017-02-22 2:29 ` Sun Paul
2017-02-22 2:29 ` Sun Paul
2017-02-22 3:03 ` Xin Long
2017-02-22 3:03 ` Xin Long
2017-02-23 5:30 ` Sun Paul
2017-02-23 5:30 ` Sun Paul
2017-02-23 6:07 ` Xin Long
2017-02-23 6:07 ` Xin Long
2017-02-27 9:01 ` Sun Paul
2017-02-27 9:01 ` Sun Paul
2017-02-27 15:06 ` Xin Long
2017-02-27 15:06 ` Xin Long
2017-03-01 4:15 ` Sun Paul
2017-03-01 4:15 ` Sun Paul
2017-03-01 6:43 ` Xin Long
2017-03-01 6:43 ` Xin Long
2017-01-16 18:47 ` Marcelo Ricardo Leitner
2017-01-16 18:47 ` Marcelo Ricardo Leitner
2017-02-21 18:51 ` Davide Caratti [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=1487703116.2621.69.camel@redhat.com \
--to=dcaratti@redhat.com \
--cc=linux-sctp@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.