iperf3 (SCTP): error - unable to start stream listener: Bad file descriptor

[esa4321]

I installed iperf3-3.3

iperf 3.3 (cJSON 1.5.2)

I tried to test sctp flow but getting the error in both server and client:

Server side:

-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
iperf3: error - unable to start stream listener: Bad file descriptor
-----------------------------------------------------------
Server listening on 5201

Client side:

Connecting to host 192.168.250.82, port 5201
iperf3: error - unable to start stream listener: Bad file descriptor

I think it is related to sctp stack, don't know if something is missing or a bug

Best regards,

[esa4321]

when removing bind option in the server, sctp association started but then terminated with the following errors:
Client Side:

iperf 3.3
Linux lteemu2 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64
Control connection MSS 1448
Time: Wed, 20 Dec 2017 18:01:24 GMT
Connecting to host 192.168.250.82, port 5201
      Cookie: 24ihg4ppcozki57tqebac2fdvhr4fukpvr7d
[  5] local 192.168.250.66 port 43379 connected to 192.168.250.82 port 5201
Starting Test: protocol: SCTP, 1 streams, 65536 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   192 KBytes  1.57 Mbits/sec                  
[  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec                  
13:01:28.295362 IP lteemu2.43379 > lteemu2.5201: sctp (1) [HB REQ] 
13:01:28.295401 IP lteemu2.5201 > lteemu2.43379: sctp (1) [ABORT] 
iperf3: error - unable to write to stream socket: Connection reset by peer

Server Side:

iperf 3.3
Linux lteemu3 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Time: Wed, 20 Dec 2017 18:06:12 GMT
Accepted connection from 192.168.250.66, port 39392
      Cookie: tmu6pdqhi7egu2nb3fkb2rjgjueyy6mjhcae
[  5] local 192.168.250.82 port 5201 connected to 192.168.250.66 port 48924
Starting Test: protocol: SCTP, 1 streams, 65536 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  0.00 Bytes  0.00 bits/sec                  
[  5]   1.00-2.00   sec  64.0 KBytes   524 Kbits/sec                  
iperf3: the client has unexpectedly closed the connection
iperf 3.3
Linux 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64

[esa4321]

running the client/server in the same machine seem to work:

# iperf3 -c 127.0.0.1 --sctp -V
iperf 3.3
Linux lteemu3 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64
Control connection MSS 21845
Time: Wed, 20 Dec 2017 18:08:46 GMT
Connecting to host 127.0.0.1, port 5201
      Cookie: tczjzegqhgdkzaorch5iieooye2zh5wy3no4
[  5] local 127.0.0.1 port 46407 connected to 127.0.0.1 port 5201
Starting Test: protocol: SCTP, 1 streams, 65536 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   512 KBytes  4.19 Mbits/sec                  
[  5]   1.00-2.00   sec   576 KBytes  4.72 Mbits/sec                  
[  5]   2.00-3.00   sec   384 KBytes  3.15 Mbits/sec                  
[  5]   3.00-4.00   sec   576 KBytes  4.72 Mbits/sec                  
[  5]   4.00-5.00   sec   384 KBytes  3.15 Mbits/sec                  
[  5]   5.00-6.00   sec   576 KBytes  4.72 Mbits/sec                  
[  5]   6.00-7.00   sec   384 KBytes  3.15 Mbits/sec                  
[  5]   7.00-8.00   sec   576 KBytes  4.72 Mbits/sec                  
[  5]   8.00-9.00   sec   384 KBytes  3.15 Mbits/sec                  
[  5]   9.00-10.00  sec   576 KBytes  4.72 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  4.81 MBytes  4.04 Mbits/sec                  sender
[  5]   0.00-10.04  sec  4.62 MBytes  3.87 Mbits/sec                  receiver
CPU Utilization: local/sender 0.4% (0.0%u/0.4%s), remote/receiver 0.1% (0.0%u/0.0%s)

[bmah888]

Issue acknowledged, but we probably won't have time to look into it before the holidays. Reformatting some of the comments to make them easier to follow.

[bmah888]

Is there any sort of middlebox between the client and server? Also are either the client or server multi-homed (more than one network interface)?

[esa4321]

Hello Bruce, yeah we have boxes between, routers & ipsec-gws I am using single homed. I did captures on client side, compared with TCP test, MSS for the case of SCTP is big, too many fragments happening. Regrds,

…

On Thu, Dec 21, 2017 at 4:02 PM, Bruce A. Mah ***@***.***> wrote: Is there any sort of middlebox between the client and server? Also are either the client or server multi-homed (more than one network interface)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#678 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AhHFcrY1vclJURTolapgEnWwLWLnps71ks5tCoErgaJpZM4RItdO> .

-- ElHassane SRAIDI IP/MPLS Service Provider Expert Deployment Team Alcatel-lucent Morocco elhassane.sraidi@alcatel-lucent.com +212 661 724996

[bmah888]

Hmmm...the reason why I asked about middleboxes (e.g. firewalls, NAT gateways, etc.) was because if the test works on a single machine but not between two hosts, usually (but not always!) that means there's something weird happening on the path. Middleboxes that do any kind of Layer 4 filtering can't always deal with SCTP, so I wonder if that could be a factor?

Any chance you would be able to run a test between two hosts on the same subnet, either directly connected or with only an Ethernet switch between? I'm just trying to figure out if my hypothesis about something on the path messing things up is correct or not.

You could also try a small -l parameter to try to make SCTP use a smaller MSS and see if eliminating fragmentation helps (I think that option works for SCTP).

[esa4321]

thanks for your support tried in the same LAN, so no L3/FW boxes between, as per scenario= client->layer2Switch->Server, I've got the same result Server-side: Server listening on 5201 ----------------------------------------------------------- Accepted connection from 10.55.179.45, port 50326 [ 10] local 10.55.179.46 port 5201 connected to 10.55.179.45 port 42572 [ ID] Interval Transfer Bitrate [ 10] 0.00-1.00 sec 100 Bytes 800 bits/sec [ 10] 1.00-2.00 sec 125 Bytes 1.00 Kbits/sec iperf3: error - unable to read from stream socket: Bad file descriptor ----------------------------------------------------------- Server listening on 5201 Client-Side: ---------- [root@lteemu2 ~]# iperf3 -c 10.55.179.46 --sctp -l 1 -b 1k Connecting to host 10.55.179.46, port 5201 [ 5] local 10.55.179.45 port 42572 connected to 10.55.179.46 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 125 Bytes 1000 bits/sec [ 5] 1.00-2.00 sec 125 Bytes 1000 bits/sec iperf3: error - control socket has closed unexpectedly ===

…

On Thu, Dec 21, 2017 at 4:24 PM, Bruce A. Mah ***@***.***> wrote: Hmmm...the reason why I asked about middleboxes (e.g. firewalls, NAT gateways, etc.) was because if the test works on a single machine but not between two hosts, usually (but not always!) that means there's something weird happening on the path. Middleboxes that do any kind of Layer 4 filtering can't always deal with SCTP, so I wonder if that could be a factor? Any chance you would be able to run a test between two hosts on the same subnet, either directly connected or with only an Ethernet switch between? I'm just trying to figure out if my hypothesis about something on the path messing things up is correct or not. You could also try a small -l parameter to try to make SCTP use a smaller MSS and see if eliminating fragmentation helps (I think that option works for SCTP). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#678 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AhHFcuboAOPyf6T8JUIYIHSl7qP_BCmeks5tCoZPgaJpZM4RItdO> .

-- ElHassane SRAIDI IP/MPLS Service Provider Expert Deployment Team Alcatel-lucent Morocco elhassane.sraidi@alcatel-lucent.com +212 661 724996

[bmah888]

Fixed by #715.