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

Chip-tool shutdowns when some contexts are still active when trying to open the commissioning window #11644

Closed
mkardous-silabs opened this issue Nov 10, 2021 · 0 comments · Fixed by #11645

Comments

@mkardous-silabs
Copy link
Contributor

Problem

Chip-tool shutdowns when some contexts are still active when trying to open the commissioning window.

Command:
./connectedhomeip/out/chip-tool/chip-tool pairing open-commissioning-window <nodeid> 1 100 1000 3840

Controller logs:

[1636564588.111806][2310:2315] CHIP:IN: New secure session created for device 0x0000000000001384, key 5!!
[1636564588.112008][2310:2315] CHIP:CTL: OnNewConnection was called for unknown device, ignoring it.
[1636564588.112072][2310:2315] CHIP:CTL: OpenCommissioningWindow for device ID 4996
[1636564588.124334][2310:2315] CHIP:DMG: ICR moving to [AddingComm]
[1636564588.124407][2310:2315] CHIP:DMG: ICR moving to [AddedComma]
[1636564588.124576][2310:2315] CHIP:IN: Prepared encrypted message 0xaaaaf4fc2880 to 0x0000000000001384 of type 0x8 and protocolId (0, 1) on exchange 1053i with MessageCounter:1.
[1636564588.124662][2310:2315] CHIP:IN: Sending encrypted msg 0xaaaaf4fc2880 with MessageCounter:1 to 0x0000000000001384 at monotonic time: 539640 msec
[1636564588.124846][2310:2315] CHIP:DMG: ICR moving to [CommandSen]
[1636564588.124929][2310:2315] CHIP:CTL: Manual pairing code: [35684737755]
[1636564588.125025][2310:2315] CHIP:CTL: SetupQRCode: [MT:00000CQM00I1QY5PB10]
[1636564588.125088][2310:2315] CHIP:TOO: Device commissioning completed with success
[1636564588.125180][2310:2315] CHIP:EM: Sending Standalone Ack for MessageCounter:2612415074 on exchange 1052i
[1636564588.125249][2310:2315] CHIP:IN: Prepared plaintext message 0xffffa96c9980 to 0x0000000000000000 of type 0x10 and protocolId (0, 0) on exchange 1052i with MessageCounter:948202350.
[1636564588.125324][2310:2315] CHIP:IN: Sending plaintext msg 0xffffa96c9980 with MessageCounter:948202350 to 0x0000000000000000 at monotonic time: 539641 msec
[1636564588.125472][2310:2315] CHIP:EM: Flushed pending ack for MessageCounter:2612415074 on exchange 1052i
[1636564588.125686][2310:2310] CHIP:CTL: Shutting down the commissioner
[1636564588.125714][2310:2310] CHIP:CTL: Shutting down the controller
[1636564588.126004][2310:2310] CHIP:CTL: Shutting down the System State, this will teardown the CHIP Stack
[1636564588.126232][2310:2310] CHIP:DL: writing settings to file (/tmp/chip_counters.ini-KJgeQT)
[1636564588.126778][2310:2310] CHIP:DL: renamed tmp file to file (/tmp/chip_counters.ini)
[1636564588.126826][2310:2310] CHIP:DL: NVS set: chip-counters/total-operational-hours = 0 (0x0)
[1636564588.126850][2310:2310] CHIP:DL: Inet Layer shutdown
[1636564588.126935][2310:2310] CHIP:DL: BLE shutdown
[1636564588.126960][2310:2310] CHIP:DL: System Layer shutdown
chip-tool: ../../examples/chip-tool/third_party/connectedhomeip/src/messaging/ExchangeMgr.cpp:102: chip::Messaging::ExchangeManager::Shutdown()::<lambda(auto:4*)> [with auto:4 = chip::Messaging::ExchangeContext]: Assertion `false' failed.

Related code :
src/messaging/ExchangeMgr.cpp line 96

CHIP_ERROR ExchangeManager::Shutdown()
{
    mReliableMessageMgr.Shutdown();

    mContextPool.ForEachActiveObject([](auto * ec) {
        // There should be no active object in the pool
        assert(false);
        return true;
    });

    if (mSessionManager != nullptr)
    {
        mSessionManager->SetDelegate(nullptr);
        mSessionManager = nullptr;
    }

    mState = State::kState_NotInitialized;

    return CHIP_NO_ERROR;
}
bzbarsky-apple added a commit to bzbarsky-apple/connectedhomeip that referenced this issue Nov 10, 2021
PairingCommand::RunCommand called mController.RegisterPairingDelegate
even in the open-commissioning-window case.  Then when the device was
connected we'd land in DeviceCommissioner::OnDeviceConnectedFn. This
would call OnCommissioningComplete on the pairing delegate, which
would land us in PairingCommand::OnCommissioningComplete and thinks
the command is done.

So we would exit without waiting for an actual response from the
server and with exchanges still open.

In PairingMode::OpenCommissioningWindow we should not be registering
as a pairing delegate and whatnot; we are just sending normal cluster
commands.

Fixes project-chip#11644
bzbarsky-apple added a commit to bzbarsky-apple/connectedhomeip that referenced this issue Nov 10, 2021
PairingCommand::RunCommand called mController.RegisterPairingDelegate
even in the open-commissioning-window case.  Then when the device was
connected we'd land in DeviceCommissioner::OnDeviceConnectedFn. This
would call OnCommissioningComplete on the pairing delegate, which
would land us in PairingCommand::OnCommissioningComplete and thinks
the command is done.

So we would exit without waiting for an actual response from the
server and with exchanges still open.

In PairingMode::OpenCommissioningWindow we should not be registering
as a pairing delegate and whatnot; we are just sending normal cluster
commands.

Fixes project-chip#11644
woody-apple pushed a commit to bzbarsky-apple/connectedhomeip that referenced this issue Nov 10, 2021
PairingCommand::RunCommand called mController.RegisterPairingDelegate
even in the open-commissioning-window case.  Then when the device was
connected we'd land in DeviceCommissioner::OnDeviceConnectedFn. This
would call OnCommissioningComplete on the pairing delegate, which
would land us in PairingCommand::OnCommissioningComplete and thinks
the command is done.

So we would exit without waiting for an actual response from the
server and with exchanges still open.

In PairingMode::OpenCommissioningWindow we should not be registering
as a pairing delegate and whatnot; we are just sending normal cluster
commands.

Fixes project-chip#11644
woody-apple pushed a commit that referenced this issue Nov 11, 2021
PairingCommand::RunCommand called mController.RegisterPairingDelegate
even in the open-commissioning-window case.  Then when the device was
connected we'd land in DeviceCommissioner::OnDeviceConnectedFn. This
would call OnCommissioningComplete on the pairing delegate, which
would land us in PairingCommand::OnCommissioningComplete and thinks
the command is done.

So we would exit without waiting for an actual response from the
server and with exchanges still open.

In PairingMode::OpenCommissioningWindow we should not be registering
as a pairing delegate and whatnot; we are just sending normal cluster
commands.

Fixes #11644
PSONALl pushed a commit to PSONALl/connectedhomeip that referenced this issue Dec 3, 2021
…1645)

PairingCommand::RunCommand called mController.RegisterPairingDelegate
even in the open-commissioning-window case.  Then when the device was
connected we'd land in DeviceCommissioner::OnDeviceConnectedFn. This
would call OnCommissioningComplete on the pairing delegate, which
would land us in PairingCommand::OnCommissioningComplete and thinks
the command is done.

So we would exit without waiting for an actual response from the
server and with exchanges still open.

In PairingMode::OpenCommissioningWindow we should not be registering
as a pairing delegate and whatnot; we are just sending normal cluster
commands.

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

Successfully merging a pull request may close this issue.

1 participant