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

Restyle Ensure that we send MRP acks to incoming messages as needed. #19407

Closed
wants to merge 2 commits into from

Conversation

restyled-io[bot]
Copy link
Contributor

@restyled-io restyled-io bot commented Jun 9, 2022

A duplicate of #19398 with additional commits that automatically address
incorrect style, created by Restyled.

⚠️ Even though this PR is not a Fork, it contains outside contributions.
Please review accordingly.

Since the original Pull Request was opened as a fork in a contributor's
repository, we are unable to create a Pull Request branching from it with only
the style fixes.

The following Restylers made fixes:

To incorporate these changes, you can either:

  1. Merge this Pull Request instead of the original, or

  2. Ask your contributor to locally incorporate these commits and push them to
    the original Pull Request

    Expand for example instructions
    ```console
    git remote add upstream https://github.com/project-chip/connectedhomeip.git
    git fetch upstream pull/<this PR number>/head
    git merge --ff-only FETCH_HEAD
    git push
    ```
    

NOTE: As work continues on the original Pull Request, this process will
re-run and update (force-push) this Pull Request with updated style fixes as
necessary. If the style is fixed manually at any point (i.e. this process finds
no fixes to make), this Pull Request will be closed automatically.

Sorry if this was unexpected. To disable it, see our documentation.

bzbarsky-apple and others added 2 commits June 9, 2022 15:57
There were two ways we could fail to send an ack to an incoming reliable message:

1) If we found no matching handler, and hence created an ephemeral exchange to
handle the message, but the message was unencrypted.  In this case our ephemeral
exchange would return true for IsEncryptionRequired(), because it would default
to an ApplicationExchangeDispatch, and we would never call into
ExchangeContext::HandleMessage.

2) If ExchangeMessageDispatch::MessagePermitted returned false for the message.
In particular, for an ApplicationExchangeDispatch, this would happen for all the
handshake messages except StatusReport.

The fix for issue 1 is to ensure we always call into HandleMEssage if we manage
to allocate an exchange.  If there is an encryption mismatch, which only matters
when the exchange is non-ephemeral, we close the exchange first to prevent event
delivery to the delegate.

The fix for issue 2 is to move the MRP processing out of ExchangeMessageDispatch
and into ExchangeContext, and to move the MessagePermitted check so the only
thing it prevents is delivery of the message to the delegate, not any other
processing by the exchange.

Fixes #10515
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants