https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278666
Michael Tuexen changed:
What|Removed |Added
Assignee|n...@freebsd.org |tue...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278666
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251052
--- Comment #11 from bc...@lafn.org ---
(In reply to Bryan Drewery from comment #9)
It appears that iperf3 does not use multiple streams regardless of the settings
for the arguments. With nstreams set to > 1, tcpdump shows that the S
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251052
--- Comment #10 from Bryan Drewery ---
(In reply to Michael Tuexen from comment #7)
As for netperf it is doing something very different. -T is parsed into
num_associations in src/nettest_sctp.c and then only used for test length and
for ho
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251052
--- Comment #9 from Bryan Drewery ---
(In reply to Michael Tuexen from comment #7)
iperf3 only does this. num_ostreams is only used here so I don't think it does
anything else beyond this.
if (test->settings->num_ostreams > 0) {
struc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251052
--- Comment #8 from Bryan Drewery ---
(In reply to bc979 from comment #6)
-P is for multiple streams. --nstreams is for SCTP multiple subflows.
--sctpuse SCTP rather than TCP
--nstreams # number of
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251052
--- Comment #7 from Michael Tuexen ---
(In reply to bc979 from comment #6)
But how is iperf distributing the load on the two streams?
--
You are receiving this mail because:
You are the assignee for the bug.
ument for multiple streams is
-P. Hear are the results using -P 1 when sending on a 100MB LAN between 2
13.1-RC3 systems:
test# iperf3 -c master --sctp -P 1
Connecting to host master, port 5201
[ 5] local 10.0.1.235 port 52689 connected to 10.0.1.250 port 5201
[ ID] Interval Tra
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263474
Michael Tuexen changed:
What|Removed |Added
Assignee|n...@freebsd.org |tue...@freebsd.org
--
You are r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263474
Michael Tuexen changed:
What|Removed |Added
CC||tue...@freebsd.org
--- Comment #2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251052
--- Comment #5 from Michael Tuexen ---
(In reply to Bryan Drewery from comment #4)
How are iperf and netperf using multiple streams? Just selecting the stream
when performing a sendmsg() call or are they using multiple threads/processes,
ea
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251052
--- Comment #4 from Bryan Drewery ---
I see something that I think is similar with iperf3 and netperf. Using 1 stream
is fine but using >1 stream completely kills bandwidth.
`iperf3 --sctp -c 127.0.0.1` is OK. `iperf3 --sctp --nstream
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263474
Bryan Drewery changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are recei
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251052
Bryan Drewery changed:
What|Removed |Added
CC||bdrew...@freebsd.org
--- Comment #
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251052
Michael Tuexen changed:
What|Removed |Added
Status|New |In Progress
--- Comment #2 from M
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251052
Michael Tuexen changed:
What|Removed |Added
Summary|SCTP traffic becomes|[sctp] Throughput becomes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251052
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Michael Tuexen changed:
What|Removed |Added
Summary|Kernel panic in SCTP/IpV6 |[sctp] Kernel panic in
> On 8. Sep 2020, at 02:18, Doug Hardie wrote:
>
>
>> On 7 September 2020, at 13:57, Michael Tuexen
>> wrote:
>>
>> For UDP and TCP you always get IPv6 addresses on AF_INET6 sockets. If you
>> are actually using IPv4, IPv4-mapped IPv6 addresses are
rom
>>> recv_fd and recvfrom handle IPv4 addresses differently when using an INET6
>>> socket. I don't know if this was intended, or a side effect. I started
>>> using SCTP because of the need for accessing multi-homed servers. Some
>>> would be on
> On 7 September 2020, at 13:57, Michael Tuexen
> wrote:
>
> For UDP and TCP you always get IPv6 addresses on AF_INET6 sockets. If you are
> actually using IPv4, IPv4-mapped IPv6 addresses are used. For SCTP you an
> choose if you want IPv4-mapped IPv6 addresses or I
n INET6
>> socket. I don't know if this was intended, or a side effect. I started
>> using SCTP because of the need for accessing multi-homed servers. Some
>> would be on IPv6 and others on IPv4. SCTP handles that nicely if you use an
>> INET6 socket. When a
> On 7. Sep 2020, at 22:48, Doug Hardie wrote:
>
> I was quite surprised to discover that the sockaddr structure returned from
> recv_fd and recvfrom handle IPv4 addresses differently when using an INET6
> socket. I don't know if this was intended, or a side effect. I s
I was quite surprised to discover that the sockaddr structure returned from
recv_fd and recvfrom handle IPv4 addresses differently when using an INET6
socket. I don't know if this was intended, or a side effect. I started using
SCTP because of the need for accessing multi-homed servers.
On Fri, Jul 17, 2020 at 07:50:55PM +0200, Bernd Walter wrote:
> On Fri, Jul 17, 2020 at 07:27:00PM +0200, Michael Tuexen wrote:
> >
> >
> > > On 17. Jul 2020, at 18:07, Bernd Walter wrote:
> > >
> > > I'm running an LED matrix with SCTP.
> &g
On Fri, Jul 17, 2020 at 07:27:00PM +0200, Michael Tuexen wrote:
>
>
> > On 17. Jul 2020, at 18:07, Bernd Walter wrote:
> >
> > I'm running an LED matrix with SCTP.
> > The matrix consists from 24 raspberry pi running NFS-root FreeBSD
> > 12.0-RELEASE (t
> On 17. Jul 2020, at 18:07, Bernd Walter wrote:
>
> I'm running an LED matrix with SCTP.
> The matrix consists from 24 raspberry pi running NFS-root FreeBSD
> 12.0-RELEASE (they have an SD card for u-boot and loader).
> A client system is running FreeBSD 12.1-RE
I'm running an LED matrix with SCTP.
The matrix consists from 24 raspberry pi running NFS-root FreeBSD
12.0-RELEASE (they have an SD card for u-boot and loader).
A client system is running FreeBSD 12.1-RELEASE.
The matrix modules have a one to many service socket.
The daemon regularily
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #28 from Michael Tuexen ---
(In reply to Mark Johnston from comment #27)
OK, great. I think reducing the stack space worth the effort. It is not that
hard, will improve also the handling of pathological parameter configurations.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Mark Johnston changed:
What|Removed |Added
Resolution|Overcome By Events |---
Status|Closed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #26 from Michael Tuexen ---
(In reply to Mark Johnston from comment #25)
Increasing the stack size is a workaround. The plan was to rewrite the handling
such that only one buffer is needed. That is why I left the bug open. Since
On Thu, Jul 09, 2020 at 11:13:00AM -0400, Mark Johnston wrote:
> Hi,
>
> I spent some time working on making it possible to load the SCTP stack
> as a kernel module, the same as we do today with IPSec. There is one
> patch remaining to be committed before that can be done in head
Resolution|--- |Overcome By Events
Status|In Progress |Closed
--- Comment #25 from Mark Johnston ---
Closing since the default stack size was increased on i386.
The two major offenders in SCTP, sctp_auth_get_cookie_params() and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
Resoluti
icate.
>> In the context of userland stack, this is one of the most important issues.
>> In case of SCTP, this is needed to open a raw socket to send/recv SCTP
>> packets.
>> This is one of the reasons why you use UDP encapsulation...
>
> I see RFC 6951 on UDP encapsu
issues.
> In case of SCTP, this is needed to open a raw socket to send/recv SCTP
> packets.
> This is one of the reasons why you use UDP encapsulation...
I see RFC 6951 on UDP encapsulation and understand there are situations where
that would be needed. However, my replication processes
> On 10. Jul 2020, at 02:06, Eugene Grosbein wrote:
>
> 10.07.2020 2:44, Doug Hardie wrote:
>
>>> On 9 July 2020, at 08:13, Mark Johnston wrote:
>>>
>>> Hi,
>>>
>>> I spent some time working on making it possible to load the SCTP s
> On 9 July 2020, at 16:24, Mark Johnston wrote:
>
> On Thu, Jul 09, 2020 at 02:15:40PM -0700, Doug Hardie wrote:
>>> On 9 July 2020, at 13:10, Mark Johnston wrote:
>>> Hopefully "protocol not supported" is a sufficiently descriptive error
>>> message.
>>
>> Actually, the users of these system
e systems are rhapsberry pi 3s which I
>> understand don't use the loader.conf file.
> OK. Do you control the kernel which is running on the machines? If that is
> the case,
> you could add a line to the kernel config, rebuild the kernel and use that
> custom
> kernel with
10.07.2020 2:44, Doug Hardie wrote:
>> On 9 July 2020, at 08:13, Mark Johnston wrote:
>>
>> Hi,
>>
>> I spent some time working on making it possible to load the SCTP stack
>> as a kernel module, the same as we do today with IPSec. There is one
>> patch
On Thu, Jul 09, 2020 at 02:15:40PM -0700, Doug Hardie wrote:
> > On 9 July 2020, at 13:10, Mark Johnston wrote:
> > Hopefully "protocol not supported" is a sufficiently descriptive error
> > message.
>
> Actually, the users of these systems would have no clue about that message.
> All they wou
,
>>>>
>>>> I spent some time working on making it possible to load the SCTP stack
>>>> as a kernel module, the same as we do today with IPSec. There is one
>>>> patch remaining to be committed before that can be done in head. One
>>>> ca
> On 9 July 2020, at 13:10, Mark Johnston wrote:
>
> On Thu, Jul 09, 2020 at 12:44:25PM -0700, Doug Hardie wrote:
>>> On 9 July 2020, at 08:13, Mark Johnston wrote:
>>>
>>> Hi,
>>>
>>> I spent some time working on making it possible to l
On Thu, Jul 09, 2020 at 12:44:25PM -0700, Doug Hardie wrote:
> > On 9 July 2020, at 08:13, Mark Johnston wrote:
> >
> > Hi,
> >
> > I spent some time working on making it possible to load the SCTP stack
> > as a kernel module, the same as we do today
> On 9. Jul 2020, at 21:44, Doug Hardie wrote:
>
>> On 9 July 2020, at 08:13, Mark Johnston wrote:
>>
>> Hi,
>>
>> I spent some time working on making it possible to load the SCTP stack
>> as a kernel module, the same as we do today with IPS
> On 9 July 2020, at 08:13, Mark Johnston wrote:
>
> Hi,
>
> I spent some time working on making it possible to load the SCTP stack
> as a kernel module, the same as we do today with IPSec. There is one
> patch remaining to be committed before that can be done in head.
> On 9. Jul 2020, at 21:01, Eugene Grosbein wrote:
>
> 09.07.2020 23:59, Michael Tuexen wrote:
>
>>> This may be relaxed with "sctp_enable" knob for /etc/rc.conf and new
>>> startup script
>>> /etc/rc.d/sctp that: a) REQUIRE: kld; b) checks if
09.07.2020 23:59, Michael Tuexen wrote:
>> This may be relaxed with "sctp_enable" knob for /etc/rc.conf and new startup
>> script
>> /etc/rc.d/sctp that: a) REQUIRE: kld; b) checks if sctp.ko already loaded
>> and load it as needed;
>> c) applies sctp
sal. Any feedback is appreciated.
>>
>> I'm for it.
>>
>>> maybe it is acceptable to document user visible changes. This could include
>>> * parameter tunings in /etc/sysctl.conf are only applied if the SCTP module
>>> is loaded from /etc/loader.
> maybe it is acceptable to document user visible changes. This could include
> > * parameter tunings in /etc/sysctl.conf are only applied if the SCTP module
> > is loaded from /etc/loader.conf.
>
> You mean /boot/loader.conf.
>
> This may be relaxed with "sctp_enable&
it is acceptable to document user visible changes. This could include
>> * parameter tunings in /etc/sysctl.conf are only applied if the SCTP module
>> is loaded from /etc/loader.conf.
>
> You mean /boot/loader.conf.
Yes, sorry for the mistake.
>
> This may be relaxed with
in /etc/sysctl.conf are only applied if the SCTP module
> is loaded from /etc/loader.conf.
You mean /boot/loader.conf.
This may be relaxed with "sctp_enable" knob for /etc/rc.conf and new startup
script
/etc/rc.d/sctp that: a) REQUIRE: kld; b) checks if sctp.ko already loaded and
> On 9. Jul 2020, at 17:13, Mark Johnston wrote:
>
> Hi,
>
> I spent some time working on making it possible to load the SCTP stack
> as a kernel module, the same as we do today with IPSec. There is one
> patch remaining to be committed before that can be done in head.
Hi,
I spent some time working on making it possible to load the SCTP stack
as a kernel module, the same as we do today with IPSec. There is one
patch remaining to be committed before that can be done in head. One
caveat is that the module can't be unloaded, as some work is needed to
make
issue in SCTP
Fix a locking issue in sctp_accept.
PR: 238520
Reported by: pho
Changes:
_U stable/11/
stable/11/sys/netinet/sctp_usrreq.c
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net
d argument of socket()), you could use
> the implicit or explicit connection setup and use
> select() to figure out, that the peer has rejected the association.
>> never comes. If I disconnect the primary network cable, then after about 5
>> seconds of starting the client, I get the
>
>> On 9. Mar 2020, at 11:01, Doug Hardie wrote:
>>
>>> I am trying to get sctp_sendmsgx to work and not having a lot of success.
>>> I have not been able to find any examples on the web of using it. I have a
>>> client using sctp_sendmsg working fine. I need to make use of the
>>> multih
> On 9. Mar 2020, at 11:01, Doug Hardie wrote:
>
>> I am trying to get sctp_sendmsgx to work and not having a lot of success. I
>> have not been able to find any examples on the web of using it. I have a
>> client using sctp_sendmsg working fine. I need to make use of the
>> multihoming fea
> I am trying to get sctp_sendmsgx to work and not having a lot of success. I
> have not been able to find any examples on the web of using it. I have a
> client using sctp_sendmsg working fine. I need to make use of the
> multihoming feature which requires sctp_sendmsgx.I changed the cal
I am trying to get sctp_sendmsgx to work and not having a lot of success. I
have not been able to find any examples on the web of using it. I have a
client using sctp_sendmsg working fine. I need to make use of the multihoming
feature which requires sctp_sendmsgx.I changed the call to sct
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
Kubilay Kocak changed:
What|Removed |Added
Status|Closed |In Progress
Resolution|FIX
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
Michael Tuexen changed:
What|Removed |Added
Flags|mfc-stable11- |mfc-stable11?
--- Comment #11 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
Kubilay Kocak changed:
What|Removed |Added
Flags|mfc-stable11?, |mfc-stable11-,
|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
--- Comment #9 from commit-h...@freebsd.org ---
A commit references this bug:
Author: tuexen
Date: Sat Sep 7 11:58:32 UTC 2019
New revision: 352001
URL: https://svnweb.freebsd.org/changeset/base/352001
Log:
MFC r350626:
Fix a locking
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
--- Comment #7 from Peter Holm ---
r350626 LGTM.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
Michael Tuexen changed:
What|Removed |Added
Status|In Progress |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
--- Comment #6 from Michael Tuexen ---
@pho: Could you retest with the fix from base r350626 included. I think it
should fix the issue and was not able to reproduce the issue anymore.
--
You are receiving this mail because:
You are on th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
--- Comment #8 from Michael Tuexen ---
(In reply to Peter Holm from comment #7)
Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
--- Comment #5 from commit-h...@freebsd.org ---
A commit references this bug:
Author: tuexen
Date: Tue Aug 6 10:29:20 UTC 2019
New revision: 350626
URL: https://svnweb.freebsd.org/changeset/base/350626
Log:
Fix a locking issue in sctp_a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
Michael Tuexen changed:
What|Removed |Added
Status|New |In Progress
--- Comment #4 from M
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
--- Comment #3 from Peter Holm ---
To reproduce the problem run the https://people.freebsd.org/~pho/setup.sh
script like this:
root@t2:~pho/stress2/tools # ./setup.sh
Enter non-root test user name: stress
Extracting stress2 to /tmp/work
Te
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
Michael Tuexen changed:
What|Removed |Added
CC||tue...@freebsd.org
Assi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
--- Comment #1 from Kubilay Kocak ---
Created attachment 205007
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=205007&action=edit
sctp panic debug
Attach backtrace to issue, external URL references tend to go stale/missi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238520
Bug ID: 238520
Summary: [sctp] Fatal trap 9: general protection fault while in
kernel mode
Product: Base System
Version: CURRENT
Hardware: Any
OS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230242
Michael Tuexen changed:
What|Removed |Added
Assignee|n...@freebsd.org |tue...@freebsd.org
--
You are r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230242
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Rodney W. Grimes changed:
What|Removed |Added
CC||freebsd-net@FreeBSD.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Michael Tuexen changed:
What|Removed |Added
Assignee|freebsd-net@FreeBSD.org |tue...@freebsd.org
St
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #24 from Michael Tuexen ---
OK, I'll reduce the stack usage...
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
http
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #23 from Michael Tuexen ---
(In reply to Shreesh Holla from comment #22)
I tried to install gnome3 and xorg according to the FreeBSD handbook, but gnome
doesn't start. It complains about not finding the default font "fixed". I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #22 from Shreesh Holla ---
(In reply to Michael Tuexen from comment #21)
Here is what I may have which just be causing it. I backed out my change from
loader.conf and it went into panic immediately when I made an sctp
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #21 from Michael Tuexen ---
I'm using VMWare Fusion. The VM uses a single processor core and 256MB of RAM.
I installed FreeBSD from FreeBSD-11.1-RELEASE-i386-dvd1.iso.
Let me know what you find...
--
You are receiving this mai
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #20 from Shreesh Holla ---
(In reply to Michael Tuexen from comment #19)
That's strange. That's exactly what I did for the panic. So maybe there is
something else on my systems. I am using vm's too of vmware desktop. I will try
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #19 from Michael Tuexen ---
OK, I setup a Release 11.1 i386 VM and a HEAD i386 VM and installed nmap. Using
ncat --sctp -l IPv6_address on these VMs I can NOT reproduce the issue. I used
::1 and a client on the same VM, used a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #18 from commit-h...@freebsd.org ---
A commit references this bug:
Author: cem
Date: Mon Dec 11 04:32:37 UTC 2017
New revision: 326758
URL: https://svnweb.freebsd.org/changeset/base/326758
Log:
i386: Bump KSTACK_PAGES default
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #17 from Shreesh Holla ---
(In reply to Conrad Meyer from comment #16)
I agree with @eugene. The generally accepted case should just work. And special
configurations are well special configurations and they can tune accordingly.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #16 from Conrad Meyer ---
(In reply to Eugene Grosbein from comment #13)
(In reply to Shreesh Holla from comment #14)
Yeah, just bumping i386 KSTACK_PAGES will at least give parity with amd64.
That's reasonable. It seems kind
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #15 from Michael Tuexen ---
OK, so it is a problem in i386. Haven't tested that for ages... One problem we
ran into in the past was that the stack grew due to inline compilation. Not
sure what is the case here. I can try to nail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #14 from Shreesh Holla ---
(In reply to Conrad Meyer from comment #12)
@conrad - I see what you mean since i386 => 32 bit. And yes definitely fixing
the SCTP stack to not use that much stack is the right one. From what I saw
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #13 from Eugene Grosbein ---
There are no reasons to keep kstack_pages<4 for i386 with exception of very
specific load pattern when you have enormous number of threads in the system.
--
You are receiving this mail because:
You
-only
devices tend to be older and have smaller amounts of memory available.
I think the long term solution is fixing the SCTP (and other) code to not use
so much stack memory. However, bumping KSTACK_PAGES to maybe 3 by default on
i386 could be reasonable. I don't remember the resolution o
least this scenario wrt SCTP may be unusable on such devices.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Eugene Grosbein changed:
What|Removed |Added
Status|New |Open
CC|
. It's possible there is a
large stack buffer somewhere in SCTP causing the crash. (Or maybe 2 pages just
isn't enough anymore for i386 -- words and pointers are half size compared to
amd64, but not buffers or fixed-width integers.)
You might try bringing up an i386 VM and reproing the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #8 from Michael Tuexen ---
(In reply to Shreesh Holla from comment #7)
Is it a global IPv6 address or a link local one? I have been testing with link
local addresses...
--
You are receiving this mail because:
You are the assig
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #7 from Shreesh Holla ---
(In reply to Michael Tuexen from comment #6)
Oh I mentioned in the bug report right in the beginning. Here it is again:
ncat --sctp -l
--
You are receiving this mail because:
You are the assignee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
--- Comment #6 from Michael Tuexen ---
(In reply to Shreesh Holla from comment #5)
Can you please state the arguments you use on the server side for starting
ncat?
--
You are receiving this mail because:
You are the assignee for the bug.
address. And likely its some
compatibility issue between Linux SCTP and BSD SCTP and so the issue shows up
when the other machine is a Linux machine likely. I have seen this happen now
about 10 times and it is immediate. It seems the connection occurs since the
Linux machine shows as connected and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224218
Michael Tuexen changed:
What|Removed |Added
CC||tue...@freebsd.org
--- Comment #4
1 - 100 of 395 matches
Mail list logo
