-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add sctp.Association.Abort(reason string) method #183
Conversation
Codecov Report
@@ Coverage Diff @@
## master #183 +/- ##
==========================================
- Coverage 80.64% 78.09% -2.55%
==========================================
Files 47 47
Lines 3901 2648 -1253
==========================================
- Hits 3146 2068 -1078
+ Misses 617 441 -176
- Partials 138 139 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
ddb16a6
to
c3b10d2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one minor request from me. There's merge conflict to resolve. Other changes look good to me.
import ( | ||
"fmt" | ||
) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you able to add the following text just to be consistent with other error_cause_xxx.go files?
/*
This error cause MAY be included in ABORT chunks that are sent
because of an upper-layer request. The upper layer can specify an
Upper Layer Abort Reason that is transported by SCTP transparently
and MAY be delivered to the upper-layer protocol at the peer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=12 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Upper Layer Abort Reason /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'll try to address it over the next couple of days
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jeremija !
Some auto tests are failing with TestAssociation_HandlePacketBeforeInit/Abort.
From what I can see, a.handleAbort() calls a.close() which sets the state to closed
. Then the test case calls a.Close() which complains "use of closed network connection".
I think calling a.close() on the receipt of Abort chunk is right. I believe we could safely skip a.Close() in the test when the test case is "Abort"
in TestAssociation_HandlePacketBeforeInit.
Otherwise, it all looks good to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is something from before but I think this test case name should be changed to something like: "TestAssociation_HandlePacketInCookieWaitState" IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I didn't realize there was a failing test. It should be fixed now. I also renamed the test case.
c3b10d2
to
9299e2c
Compare
@jeremija I am pretty sure this is a test issue. If you'd prefer, I can sort this out for you. Please let me know. |
cf3a11a
to
23f7b42
Compare
23f7b42
to
50c75e6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @jeremija . LGTM!
According to RFC 4960 Section 9.1. Also see my comment at #176, more precisely: #176 (comment)
Closes #182.
I don't think we currently do any tag verification for any packets, but we can implement that later.
I think that
Close
method should be modified to callAbort("close")
or similar; I was unable to find any part of the spec that allows just closing the underlying connection.