similar to: Does SCTP help against TCP reset attacks?

On Fri, Apr 20, 2018 at 02:22:19PM -0300, Marcelo Ricardo Leitner wrote: > On Wed, Apr 18, 2018 at 05:06:46PM +0300, Michael S. Tsirkin wrote: > > On Tue, Apr 17, 2018 at 04:35:18PM -0400, Vlad Yasevich wrote: > > > On 04/02/2018 10:47 AM, Marcelo Ricardo Leitner wrote: > > > > On Mon, Apr 02, 2018 at 09:40:01AM -0400, Vladislav Yasevich wrote: > > > >>

On 04/20/2018 01:22 PM, Marcelo Ricardo Leitner wrote: > On Wed, Apr 18, 2018 at 05:06:46PM +0300, Michael S. Tsirkin wrote: >> On Tue, Apr 17, 2018 at 04:35:18PM -0400, Vlad Yasevich wrote: >>> On 04/02/2018 10:47 AM, Marcelo Ricardo Leitner wrote: >>>> On Mon, Apr 02, 2018 at 09:40:01AM -0400, Vladislav Yasevich wrote: >>>>> Now that we have SCTP

https://bugzilla.mindrot.org/show_bug.cgi?id=2016 Bug #: 2016 Summary: SCTP Support Classification: Unclassified Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Miscellaneous AssignedTo:

Hi, I have written a patch to add SCTP support for OpenSSH on systems with SCTP capabilities with the following features: - SCTP support can be configured with --with-sctp, but is disabled by default - use SCTP for SSH connections instead of TCP - SCTP's multi-homing is activated for all available addresses by default, if SCTP is used - the sshd can be configured to listen with TCP, SCTP, or

Greetings, Are there any plans to import SCTP support to OpenSSH? There have been SCTP patches for OSX and FreeBSD, and those seem to work pretty decently. I guess there might quite a number of potential users for SCTP were it part of the common source tree. A second benefit of having SCTP support as a standard feature in OpenSSH for all platforms supporting SCTP would be kind of social pressure

On Wed, Apr 18, 2018 at 9:33 AM, Marcelo Ricardo Leitner <marcelo.leitner at gmail.com> wrote: > On Tue, Apr 17, 2018 at 04:35:18PM -0400, Vlad Yasevich wrote: >> On 04/02/2018 10:47 AM, Marcelo Ricardo Leitner wrote: >> > On Mon, Apr 02, 2018 at 09:40:01AM -0400, Vladislav Yasevich wrote: >> >> Now that we have SCTP offload capabilities in the kernel, we can

Dear all, I'm running into a possible memory issue with the SCTP implementation in CentOS 6, using lksctp-tools. So far I've not seen the problem with other distributions yet. The problem is that whenever a SCTP client connection is initiated to a second host and port at which no SCTP server application is listening The scenario is simple: - call socket() to create a socket. - call

http://bugzilla.netfilter.org/show_bug.cgi?id=763 Summary: dnat and snat not changing port numbers on sctp packets Product: netfilter/iptables Version: linux-2.6.x Platform: x86_64 OS/Version: RedHat Linux Status: NEW Severity: normal Priority: P3 Component: NAT AssignedTo: netfilter-buglog at

To support SCTP checksum offloading, we need to add a new feature to virtio_net, so we can negotiate support between the hypervisor and the guest. The signalling to the guest that an alternate checksum needs to be used is done via a new flag in the virtio_net_hdr. If the flag is set, the host will know to perform an alternate checksum calculation, which right now is only CRC32c. Signed-off-by:

On 04/11/2018 06:49 PM, Michael S. Tsirkin wrote: > On Mon, Apr 02, 2018 at 09:40:02AM -0400, Vladislav Yasevich wrote: >> To support SCTP checksum offloading, we need to add a new feature >> to virtio_net, so we can negotiate support between the hypervisor >> and the guest. >> >> The signalling to the guest that an alternate checksum needs to >> be used is

This patch allows the OpenSSH client to make connections over SCTP, and allows the OpenSSH server to listen for connections over SCTP. SCTP is a robust transport-layer protocol which supports, amongst other things, the changing of endpoint IPs without breaking the connection. To connect via SCTP, pass -H or set "ConnectViaSCTP yes". To listen via SCTP as well as TCP, set

To support SCTP checksum offloading, we need to add a new feature to virtio_net, so we can negotiate support between the hypervisor and the guest. The HOST feature bit signifies offloading support for transmit and enables device offload features. The GUEST feature bit signifies offloading support of recieve and is currently only used by the driver in case of xdp. That patch also adds an

https://bugzilla.netfilter.org/show_bug.cgi?id=1742 Bug ID: 1742 Summary: using nfqueue breaks SCTP connection (tracking) Product: libnetfilter_queue Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: libnetfilter_queue Assignee:

On 04/02/2018 10:47 AM, Marcelo Ricardo Leitner wrote: > On Mon, Apr 02, 2018 at 09:40:01AM -0400, Vladislav Yasevich wrote: >> Now that we have SCTP offload capabilities in the kernel, we can add >> them to virtio as well. First step is SCTP checksum. > > Thanks. > >> As for GSO, the way sctp GSO is currently implemented buys us nothing >> in added support

On Wed, May 02, 2018 at 11:14:13AM -0300, Marcelo Ricardo Leitner wrote: > On Wed, May 02, 2018 at 06:16:45AM +0300, Michael S. Tsirkin wrote: > > On Tue, May 01, 2018 at 10:07:34PM -0400, Vladislav Yasevich wrote: > > > To support SCTP checksum offloading, we need to add a new feature > > > to virtio_net, so we can negotiate support between the hypervisor > > >

On 04/02/2018 10:47 AM, Marcelo Ricardo Leitner wrote: > On Mon, Apr 02, 2018 at 09:40:01AM -0400, Vladislav Yasevich wrote: >> Now that we have SCTP offload capabilities in the kernel, we can add >> them to virtio as well. First step is SCTP checksum. > > Thanks. > >> As for GSO, the way sctp GSO is currently implemented buys us nothing >> in added support

On Mon, Apr 16, 2018 at 09:45:48AM -0400, Vlad Yasevich wrote: > On 04/11/2018 06:49 PM, Michael S. Tsirkin wrote: > > On Mon, Apr 02, 2018 at 09:40:02AM -0400, Vladislav Yasevich wrote: > >> To support SCTP checksum offloading, we need to add a new feature > >> to virtio_net, so we can negotiate support between the hypervisor > >> and the guest. > >>

Author: jarrett Repository: /hg/zfs-crypto/gate Revision: 2b3ac8eaab2d527612935ece4c1ab97f288287ff Log message: 6405777 SCTP cannot find a correct source address 6405400 sctp_send_abort() tips over referencing uninitialized variable Files: update: usr/src/uts/common/inet/sctp/sctp_common.c update: usr/src/uts/common/inet/sctp/sctp_error.c

Aki Tuomi wrote in <1907575568.4364.1597984769802 at appsuite-dev-gw1.open-xchange.com>: |> On 21/08/2020 02:17 Steffen Nurpmeso <steffen at sdaoden.eu> wrote: ... |> Wietse Venema wrote in |> <4BXSTk189nzJrP3 at spike.porcupine.org>: |> ... |>|Steffen Nurpmeso: |> ... |>|> until SASL says it is done?!. How could EXTERNAL ever work

Hi there I've just done some brief reading up on SCTP, and I get the impression it will allow multiple "threads" of streamed data as part of one connection? I was wondering what impact that would have on high bandwidth, high latency links? Currently our bottleneck in using rsync is due to that. We have fat pipes and yet a single rsync session cannot saturate it due to the latency.