-
Notifications
You must be signed in to change notification settings - Fork 270
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
Data Race in SecureChannel #184
Comments
its this block s.cfg.SequenceNumber++
s.reqhdr.AuthenticationToken = authToken
s.reqhdr.RequestHandle++
s.reqhdr.Timestamp = time.Now() |
I'll have a look. |
@dwhutchison do you know whether it is crucial that the sequence number and request id don't have gaps or is it sufficient that they just increase? |
This is a first attempt to fix the data race in SendAsync. Fixes #184
@wsnotify I've pushed a simple fix for this. Could you test whether this fixes the race? I need to think about this a bit more. |
Sequence number needs to increase by one on each request and reset to <1024 when it reaches the limit of a uint32-1024. It's a security check to make sure there's nobody masquerading as the real sender. The spec mentions having a reasonable allowance for gaps to account for dropped packets and temporary comms loss, but I would expect servers to disconnect clients if the series jumped more than 3-5 at once. If I can find a test case or other documentation to give a more firm number, I'll update this comment. I don't believe request ID has the same restriction and simply needs to be unique for each request so the server can keep track of chunks. |
@magiconair with this fix does not see races in my tests. |
Issue #184: fix data race in SendAsync
I've merged the fix so that your tests don't break and added #189 to follow-up on the sequence number description from @dwhutchison. |
Doing subscribe, then publish, then BrowseRequest.
Debug logs
The text was updated successfully, but these errors were encountered: