sctplab / sctp_nke_yosemite Goto Github PK

The following packetdrill script shows the problem:

`sysctl -w net.inet.sctp.strict_data_order=1`
// Create a non-blocking 1-to-1 style socket
 0.0 socket(..., SOCK_STREAM, IPPROTO_SCTP) = 3
+0.0 fcntl(3, F_GETFL) = 0x02 (flags O_RDWR)
+0.0 fcntl(3, F_SETFL, O_RDWR | O_NONBLOCK) = 0
+0.0 setsockopt(3, IPPROTO_SCTP, SCTP_RTOINFO, {srto_initial=100, srto_max=800, srto_min=100}, 16) = 0
// Trigger the active associtation setup
+0.1 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)
+0.0 > sctp: INIT[flgs=0, tag=1, a_rwnd=..., os=..., is=..., tsn=1, ...]
+0.0 < sctp: INIT_ACK[flgs=0, tag=2, a_rwnd=1500, os=1, is=1, tsn=1, STATE_COOKIE[len=4, val=...]]
+0.0 > sctp: COOKIE_ECHO[flgs=0, len=4, val=...]
+0.0 < sctp: COOKIE_ACK[flgs=0]
// Check if the setup was sucessful
+0.0 getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
// Inject a DATA chunk followed by a control chunk
+0.0 < sctp: DATA[flgs=BE, len=1016, tsn=1, sid=0, ssn=0, ppid=0];
             HEARTBEAT[flgs=0, HEARTBEAT_INFORMATION[len=4, val=...]]
+0.0 > sctp: ABORT[flgs=0x00, PROTOCOL_VIOLATION[info="DATA chunk followed by chunk of type 04"]]

Why does the following script does not issue an ABORT in response to the SHUTDOWN?

// Create a blocking 1-to-1 style socket
+0.0 socket(..., SOCK_STREAM, IPPROTO_SCTP) = 3
+0.0 bind(3, ..., ...) = 0
+0.0 listen(3, 1) = 0
+0.0 < sctp: INIT[flgs=0, tag=1, a_rwnd=1500, os=1, is=1, tsn=1]
+0.0 > sctp: INIT_ACK[flgs=0, tag=2, a_rwnd=..., os=..., is=..., tsn=1, ...]
+0.1 < sctp: COOKIE_ECHO[flgs=0, len=..., val=...]
+0.0 > sctp: COOKIE_ACK[flgs=0]
+0.0 accept(3, ..., ...) = 4
+0.0 close(3) = 0

// Inject the first message and verify the immediate sending of a SACK
+0.0 < sctp: DATA[flgs=BE, len=116, tsn=1, sid=0, ssn=0, ppid=0]
+0.0 read(4, ..., 200) = 100
+0.0 > sctp: SACK[flgs=0, cum_tsn=1, a_rwnd=..., gaps=[], dups=[]]
// Inject the third message (the second is missing)
+0.0 < sctp: DATA[flgs=BE, len=116, tsn=3, sid=0, ssn=3, ppid=0]
// Check if a SACK with a gap report is sent immediately
+0.0 > sctp: SACK[flgs=0, cum_tsn=1, a_rwnd=..., gaps=[2:2], dups=[]]

// Tear down the association
+1.0 < sctp: SHUTDOWN[flgs=0, cum_tsn=0]
+0.0 > sctp: SHUTDOWN_ACK[flgs=0]
+0.0 < sctp: SHUTDOWN_COMPLETE[flgs=0]
+0.0 close(4) = 0

See https://github.com/nplab/misc-sctp-testscripts/blob/master/sctp-invalid-length-tests/sctp-invalid-shutdown-complete-invalid-too-long-length.pkt for details.

The problem can be triggered by the following packetdrill script:

// Create a non-blocking 1-to-1 style socket
 0.0 socket(..., SOCK_STREAM, IPPROTO_SCTP) = 3
+0.0 fcntl(3, F_GETFL) = 0x02 (flags O_RDWR)
+0.0 fcntl(3, F_SETFL, O_RDWR | O_NONBLOCK) = 0
+0.0 setsockopt(3, IPPROTO_SCTP, SCTP_RTOINFO, {srto_initial=100, srto_max=800, srto_min=100}, 16) = 0
// Trigger the active associtation setup
+0.1 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)
+0.0 > sctp: INIT[flgs=0, tag=1, a_rwnd=..., os=..., is=..., tsn=1, ...]
+0.0 < sctp: INIT_ACK[flgs=0, tag=2, a_rwnd=1500, os=1, is=1, tsn=1, STATE_COOKIE[len=4, val=...]]
+0.0 > sctp: COOKIE_ECHO[flgs=0, len=4, val=...]
+0.0 < sctp: COOKIE_ACK[flgs=0]
// Check if the setup was sucessful
+0.0 getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
// Inject a too short DATA chunk (len can be 4..15)
+0.0 < sctp: CHUNK[type=0x00, flgs=0x00, len=4, val=[]]
+0.0 > sctp: ABORT[flgs=0x00, PROTOCOL_VIOLATION[info="DATA chunk of length 4"]]

See the following test cases for more details:
https://github.com/nplab/misc-sctp-testscripts/blob/master/sctp-invalid-length-tests/sctp-invalid-abort-cause-length-too-short.pkt
https://github.com/nplab/misc-sctp-testscripts/blob/master/sctp-invalid-length-tests/sctp-invalid-error-cause-length-too-long.pkt

When a packet containing a SHUTDOWN-ACK chunk is received with a wrong verification tag, it is still responded with a SHUTDOWN-COMPLETE chunk and the T-bit set. The actual association is not affected. See sctp-imh-i-3-9. The following shows FreeBSD's behaviour:

+0.0 socket(..., SOCK_STREAM, IPPROTO_SCTP) = 3
+0.0 bind(3, ..., ...) = 0
+0.0 setsockopt(3, IPPROTO_SCTP, SCTP_RTOINFO, {srto_initial=100, srto_max=800, srto_min=100}, 16) = 0
+0.0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
+0.0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
+0.0 listen(3, 1) = 0
+0.0 < sctp: INIT[flgs=0, tag=1, a_rwnd=1500, os=1, is=1, tsn=1]
+0.0 > sctp: INIT_ACK[flgs=0, tag=2, a_rwnd=..., os=..., is=..., tsn=1, ...]
+0.0 < sctp: COOKIE_ECHO[flgs=0, len=..., val=...]
+0.0 > sctp: COOKIE_ACK[flgs=0]
+0.0 accept(3, ..., ...) = 4
+0.0 close(3) = 0
+0.0 close(4) = 0
+0.0 > sctp: SHUTDOWN[flgs=0, cum_tsn=0]
+0.0 < sctp(tag=3): SHUTDOWN_ACK[flgs=0]
+0.0 > sctp: SHUTDOWN_COMPLETE[flgs=T]
+0.1 > sctp: SHUTDOWN[flgs=0, cum_tsn=0]
+0.0 < sctp: SHUTDOWN_ACK[flgs=0]
+0.0 > sctp: SHUTDOWN_COMPLETE[flgs=0]

See the following test in packetdrill for more details:
https://github.com/nplab/misc-sctp-testscripts/blob/master/sctp-invalid-length-tests/sctp-invalid-init-ack-missing-state-cookie.pkt

When a packet containing a COOKIE-ECHO chunk is received with a wrong verification tag, it is still accepted. See sctp-imh-i-3-3.

I am trying to get a kext loaded for a fusion-io (ioDrive II) card. The kext was originally from the Yosemite bundle that SanDisk (at the time maybe even still Fusion-io themselves?) released. Now I am trying to make it load on ElCapitan. The bundle installs fine and after compulsory restart I end up with a kext in my Extensions folder. The problem is it doesn't load! Here is what terminal tells me:

sh-3.2# kextutil -t /System/Library/Extensions/iomemory-vsl.kext
Notice: /System/Library/Extensions/iomemory-vsl.kext has debug properties set.
Diagnostics for /System/Library/Extensions/iomemory-vsl.kext:
Code Signing Failure: not code signed
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/System/Library/Extensions/iomemory-vsl.kext"
kext signature failure override allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/System/Library/Extensions/iomemory-vsl.kext"
(kernel) kxld[com.fusionio.driver.iomemory-vsl]: The following symbols are unresolved for this kext:
(kernel) kxld[com.fusionio.driver.iomemory-vsl]: __ZN8IOMapper11NewARTTableEyPPvPj
(kernel) kxld[com.fusionio.driver.iomemory-vsl]: __ZN8IOMapper12FreeARTTableEP6OSDatay
(kernel) Can't load kext com.fusionio.driver.iomemory-vsl - link failed.
(kernel) Failed to load executable for kext com.fusionio.driver.iomemory-vsl.
(kernel) Kext com.fusionio.driver.iomemory-vsl failed to load (0xdc008016).
(kernel) Failed to load kext com.fusionio.driver.iomemory-vsl (error 0xdc008016).
Failed to load /System/Library/Extensions/iomemory-vsl.kext - (libkern/kext) link error.
Check library declarations for your kext with kextlibs(8).
sh-3.2# kextlibs /System/Library/Extensions/iomemory-vsl.kext
For all architectures:
com.apple.iokit.IOStorageFamily = 2.1
com.apple.kpi.bsd = 15.6
com.apple.kpi.iokit = 15.6
com.apple.kpi.libkern = 15.6
com.apple.kpi.mach = 15.6

For x86_64:
11 symbols not found in any library kext.

It looks like it could be an easy fix? I am by no means an expert, but I am sure there must be a way? Any suggestions/help would be much appreciated.

See the following test in packetdrill for details:
https://github.com/nplab/misc-sctp-testscripts/blob/master/sctp-invalid-length-tests/sctp-invalid-data-length-too-long.pkt

See sctp-dm-o-4-2-1, sctp-dm-o-4-2-2, sctp-as-o-1-9-1, and sctp-as-o-1-9-2.

Should an ABORT chunk indicating a protocol violation be sent if

• a chunk with an inconsistent chunk length is received
• partial chunks are received
• a SHUTDOWN bundled with a DATA chunk is received
• a SHUTDOWN-ACK bundled with a DATA chunk is received
• control chunks follow DATA chunks in a packet
• an INIT-ACK chunk bundled with another chunk is received
• a SHUTDOWN-COMPLETE chunk bundled with another chunk is received

The following packetdrill script:

 0.0 socket(..., SOCK_STREAM, IPPROTO_SCTP) = 3
+0.0 fcntl(3, F_GETFL) = 0x02 (flags O_RDWR)
+0.0 fcntl(3, F_SETFL, O_RDWR | O_NONBLOCK) = 0
// Trigger the active associtation setup
+0.1 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)
+0.0 > sctp: INIT[flgs=0, tag=1, a_rwnd=..., os=..., is=..., tsn=1, ...]
// Inject an INIT-ACK with an unknown parameter using the upper bits 11.
+0.0 < sctp: INIT_ACK[flgs=0, tag=2, a_rwnd=1500, os=1, is=1, tsn=1,
                      PARAMETER[type=0xc00c, len=5, val=[0xff]],
                      STATE_COOKIE[len=4, val=...]]
// Verify that the SUT reports the unknown parameter
+0.0 > sctp: COOKIE_ECHO[flgs=0, len=4, val=...];
             ERROR[flgs=0, UNRECOGNIZED_PARAMETERS[params=[PARAMETER[type=0xc00c, len=5, val=[0xff]]]]]

triggers the sending of an unpadded ERROR chunk.
This is a special case of sctp-e-i-6-5.

See sctp-at-i-2-7-2 to reproduce the problem.

This problem can be reproduced by sctp-bdc-i-7-1. The correct behaviour is specified in
RFC4960.

Here is what I get when trying to load the module:

➜ ~ sudo kextutil /System/Library/Extensions/SCTP.kext
Diagnostics for /System/Library/Extensions/SCTP.kext:
Code Signing Failure: not code signed
kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/System/Library/Extensions/SCTP.kext"
(kernel) kxld[org.sctp.nke.SCTP]: In interface org.sctp.kpi.sctpsupport of kernel, couldn't find symbol _nd_ifinfo

(kernel) kxld[org.sctp.nke.SCTP]: In interface org.sctp.kpi.sctpsupport of kernel, couldn't find symbol _nd_ifinfo_indexlim

(kernel) kxld[org.sctp.nke.SCTP]: The following symbols are unresolved for this kext:
(kernel) kxld[org.sctp.nke.SCTP]: _nd_ifinfo
(kernel) kxld[org.sctp.nke.SCTP]: _nd_ifinfo_indexlim
(kernel) Can't load kext org.sctp.nke.SCTP - link failed.
(kernel) Failed to load executable for kext org.sctp.nke.SCTP.
(kernel) Kext org.sctp.nke.SCTP failed to load (0xdc008016).
(kernel) Failed to load kext org.sctp.nke.SCTP (error 0xdc008016).
Failed to load /System/Library/Extensions/SCTP.kext - (libkern/kext) link error.
Check library declarations for your kext with kextlibs(8).

The shutdown guard timer is only configurable via the sysctl API. However, RFC 4960 requires it to be 5 * RTO_MAX. For testing the issue, sctp-at-i-2-5 can be used.

See the following testcase for more info:
https://github.com/nplab/misc-sctp-testscripts/blob/master/sctp-invalid-length-tests/sctp-invalid-shutdown-ack-invalid-too-long-length.pkt