This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Thu Apr 25 19:35:27 2024 >From mailfetcher Thu Jan 12 12:13:00 2017 Envelope-to: lkml@grols.ch Delivery-date: Thu, 12 Jan 2017 12:12:59 +0100 Received: from srv.grols.ch [5.172.41.101] by 7a0960bb2a7f with IMAP (fetchmail-6.3.26) for (single-drop); Thu, 12 Jan 2017 12:13:00 +0100 (CET) Received: from vger.kernel.org ([209.132.180.67]) by home.grols.ch with esmtp (Exim 4.88) (envelope-from ) id 1cRdJT-0007V5-92 for lkml@grols.ch; Thu, 12 Jan 2017 12:12:59 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750980AbdALLM4 convert rfc822-to-8bit (ORCPT ); Thu, 12 Jan 2017 06:12:56 -0500 Received: from mail-n.franken.de ([193.175.24.27]:46149 "EHLO drew.franken.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750807AbdALLM4 (ORCPT ); Thu, 12 Jan 2017 06:12:56 -0500 X-Greylist: delayed 602 seconds by postgrey-1.27 at vger.kernel.org; Thu, 12 Jan 2017 06:12:55 EST Received: from [10.0.1.108] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 9DFEE721E281E; Thu, 12 Jan 2017 11:53:18 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Problem on SCTP From: Michael Tuexen In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB025F9FD@AcuExch.aculab.com> Date: Thu, 12 Jan 2017 11:53:17 +0100 Cc: Sun Paul , Neil Horman , "linux-sctp@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Transfer-Encoding: 8BIT Message-Id: <4163FC71-3A20-4484-8CDC-FA22D4FA72CF@lurchi.franken.de> References: <20170106123711.GA15139@hmsreliant.think-freely.org> <063D6719AE5E284EB5DD2968C1650D6DB025A97E@AcuExch.aculab.com> < To: David Laight X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-Id: X-Mailing-List: linux-kernel@vger.kernel.org Received-SPF: none client-ip=209.132.180.67; envelope-from=linux-kernel-owner@vger.kernel.org; helo=vger.kernel.org X-Spam-Score: 4.2 X-Spam-Score-Bar: ++++ X-Spam-Action: greylist X-Spam-Report: Action: greylist Symbol: FROM_NEQ_ENVFROM(0.00) Symbol: TO_DN_EQ_ADDR_SOME(0.00) Symbol: R_SPF_NA(0.00) Symbol: PRECEDENCE_BULK(0.00) Symbol: R_DKIM_NA(0.00) Symbol: FORGED_SENDER(0.30) Symbol: RCPT_COUNT_5(0.00) Symbol: MIME_GOOD(-0.10) Symbol: FORGED_R > On 12 Jan 2017, at 10:51, David Laight wrote: > > From: Sun Paul [mailto:paulrbk@gmail.com] >> Sent: 12 January 2017 09:31 >> Let me clear the understanding. below is the flow. >> >> 1. Client sends to Linux Router: 192.168.206.83 -> 192.168.206.56, >> 2. Linux router sends to SERVER where the source IP is unchanged: >> 192.168.206.83 -> 192.168.206.66 >> >> My question here is why SERVER cannot response this INIT chunk? > > Probably because the IP addresses embedded in the SCTP packet > don't match the ones in the IP header. I don't know if it matters on the linux implementation, but it shouldn't. An SCTP endpoint should consider the source address of the packet containing the INIT chunk and all the addresses listed in the INIT chunk as valid peer addresses. Could we get a .pcap file of the packet containing the INIT chunk captured at the server? I would expect an INIT-ACK or and ABORT. If that is not sent, the checksum was wrong or some kind of packet filtering is active on the server... Best regards Michael > > David > > N‹§ēæėrļ›yúčšØbēXŽķĮ§vØ^–)Þš{.nĮ+‰·ĨŠ{ąąËiŠ{ayšʇڙë,j­ĒfĢĒ·hš‹āzđŪwĨĒļ Ē·Ķj:+v‰ĻŠwčjØmķŸĸūŦ‘ęįzZ+ƒųšŽŠÝĒj"ú!