Skip to content
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

[core] Fix: In rendezvous when processing resulted in ACCEPT it was still sending rejection #2774

Merged

Conversation

ethouris
Copy link
Collaborator

@ethouris ethouris commented Aug 7, 2023

The problem: there was a fix that added sending rejection HS packet back to the peer in case when rendezvous processing ended up in rejection. The condition, however, excluded only CONN_CONTINUE value, while beside CONN_REJECT there was also a possible CONN_ACCEPT value returned from processRendezvous, which would be still handled as it should outside the loop, but this way it was also treated the same as reject.

@ethouris ethouris added Type: Bug Indicates an unexpected problem or unintended behavior [core] Area: Changes in SRT library core labels Aug 7, 2023
@maxsharabayko
Copy link
Collaborator

@ethouris Please provide steps to reproduce for @bpolic to reproduce.

@ethouris
Copy link
Collaborator Author

ethouris commented Aug 8, 2023

I have reproduced it the following way: two commands on the same host (I was using srt-test-live, but srt-live-transmit should work as well):

./srt-live-transmit udp://:5555 srt://localhost:5001?mode=rendezvous\&port=5002 -ll debug

./srt-live-transmit srt://localhost:5002?mode=rendezvous\&port=5001 output.ts -ll debug

This is done without any data transmission (so this udp://:5555 is only a kinda stub). The only appearance of the problem is in the debug logs if you can find the ERROR:ROGUE phrase, which is being ignored by the receiver as "possible attack". The true impact is unknown, but potentially it may make random inability to connect in rendezvous.

If the problem doesn't reproduce this way, then just invert the direction or the order of command execution (might be that it won't appear at certain arrangement of waveahand/conclusion order and initiator/responder assignment).

To confirm the fix, prepare complied both versions, then first confirm the appearance of the problem in a certain arrangement, then repeat the same on the fixed version immediately. Several times, to be sure, as when 1 minute passes, it might generate different cookies and this may result in a different initiator/responder assignment.

Aha, also please make sure that your 'localhost' here doesn't resolve to an IPv6 wildcard address, and if so, use a different name of the current host.

@maxsharabayko
Copy link
Collaborator

Changed in PR #2667 (SRT v1.5.2)?

@ethouris
Copy link
Collaborator Author

ethouris commented Aug 9, 2023

Changed in PR #2667 (SRT v1.5.2)?

Yes, exactly.

@maxsharabayko maxsharabayko added this to the v1.5.3 milestone Aug 10, 2023
@maxsharabayko maxsharabayko merged commit 50619bd into Haivision:master Aug 10, 2023
9 checks passed
@bpolic
Copy link
Collaborator

bpolic commented Aug 29, 2023

@maxsharabayko @ethouris with steps mentioned in ticket i can not reproduce issue. Maybe we can close this ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[core] Area: Changes in SRT library core Type: Bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants