How to Enable TCP Transport for CASE in All-Clusters-App on FRDM-RW612 - Matter

[farazahmed8]

Hi everyone,

I’m currently using the all-clusters-app on FRDM-RW612 as the Matter device, and my commissioner setup is i.MX93 + iW612 running the chip-tool.

I noticed that the CASE (Certificate-Authenticated Session Establishment) is currently being performed over UDP, but I want to switch to TCP. My goal is to extend the message size in CASE, as UDP has an MTU limit of 1280 bytes, which is restrictive for my use case.

I have already checked the CASESession.cpp file, and it seems that TCP is supported. However, I am not sure what configuration or steps are required on both the FRDM-RW612 device and the chip-tool side to force CASE over TCP.

Could anyone guide me on how to enable TCP for CASE for Wi-Fi commissioning in this setup?

[farazahmed8]

In Matter specs 1.4 [Section 4.13.2.2] Session Establishment over IP
The initiator supports TCP Clients as defined in the Supported Transport Mode Values table in the T record
The responder supports TCP Server as defined in the Supported Transport Mode Values table in the T record
Otherwise, the initiator SHALL use MRP to establish the session

This value is inside the Session Params Struct as SUPPORTED_TRANSPORT in the CASE Sigma1 message.

[farazahmed8]

I tried chip-tool onoff on 8888 1 --allow-large-payload true, it tries to establish TCP connection, but the stack called a fatal error handler which stops execution because continuing could corrupt state.
Commissioner Log

[1723844507.478] [615:617][DIS] Checking node lookup status for 85B54CECAA338E8B-00000000000022B8 after 5 ms 
[1723844507.478] [615:617] [DIS] Keeping DNSSD lookup active [1723844507.556] [615:617] [DIS] UDP:[fe80::c295:daff:fe01:52ef%mlan0]:5540: new best score: 7 (for 85B54CECAA338E8B-00000000000022B8) 
[1723844507.556] [615:617] [DIS] Lookup clearing interface for non LL address [1723844507.556] [615:617] [DIS] UDP:192.168.0.101%mlan0:5540: new best score: 2 (for 85B54CECAA338E8B-00000000000022B8) 
[1723844507.556] [615:617] [DIS] Checking node lookup status for 85B54CECAA338E8B-00000000000022B8 after 83 ms [1723844507.556] [615:617] [DIS] Keeping DNSSD lookup active 
[1723844507.673] [615:617] [DIS] Checking node lookup status for 85B54CECAA338E8B-00000000000022B8 after 200 ms 
[1723844507.673] [615:617] [DIS] OperationalSessionSetup[1:00000000000022B8]: Updating device address to UDP:[fe80::c295:daff:fe01:52ef%mlan0]:5540 while in state 2 
[1723844507.673] [615:617] [DIS] OperationalSessionSetup[1:00000000000022B8]: State change 2 --> 3 
[1723844507.673] [615:617] [IN] SecureSession[0xffff9c00ba10]: Allocated Type:2 LSID:16675 
[1723844507.673] [615:617] [SC] Initiating session on local FabricIndex 1 from 0x000000000001B669 -> 0x00000000000022B8 
[1723844507.673] [615:617] [IN] Connecting over TCP with peer at TCP:[fe80::c295:daff:fe01:52ef%mlan0]:5540. 
[1723844507.674] [615:617] [IN] Connecting to peer TCP:[fe80::c295:daff:fe01:52ef%mlan0]:5540. [1723844507.676] [615:617] [DIS] OperationalSessionSetup[1:00000000000022B8]: State change 3 --> 4 [1723844507.678] [615:617] [IN] Connection established successfully with TCP:[fe80::c295:daff:fe01:52ef%mlan0]:5540. 
[1723844507.678] [615:617] [SC] TCP Connection established with TCP:[fe80::c295:daff:fe01:52ef%mlan0]:5540 before session establishment [1723844507.680] [615:617] [EM] <<< [E:16429i S:0 M:143072787] (U) Msg TX from C6EDEE73A3CE4107 to 0:0000000000000000 [0000] [TCP:[fe80::c295:daff:fe01:52ef%mlan0]:5540] --- Type 0000:30 (SecureChannel:CASE_Sigma1) (B:196) 
[1723844507.680] [615:617] [SC] Sent Sigma1 msg to <00000000000022B8, 1> [II:500ms AI:300ms AT:4000ms]

 Commissionee Log 

[52693] [ERR] [DL] Chip stack locking error at 'src/inet/InetLayer.h:82'. Code is unsafe/racy 
[52702] [ERR] [-] chipDie chipDie chipDie

It appears that the Chip stack locking error occurs because NewEndPoint() is called without proper thread-safe locking (assertChipStackLockedByCurrentThread() fails),

Is there a way to force a TCP connection directly from the chip-tool pairing command, similar to how chip-tool onoff … --allow-large-payload true establishes TCP for cluster commands?

[Christine_Li]

Hi， @farazahmed8 

Would you please let me know your detailed setup steps?

And also your SDK version of FRDM-RW612, IDE version of your MCUXpresso.

I prefer to setup same test environment with you and to see whether can reproduce your issue locally.

Best regards,

Christine.

[farazahmed8]

Ubuntu 22.04.
I am using MCUXpresso IDE, instead building with GN + Ninja in VS code

I followed the Matter setup steps

~ git clone https://github.com/NXP/matter.git
~ cd matter
~ scripts/checkout_submodules.py --shallow --platform nxp --recursive
~ source ./scripts/activate.sh
~ ./third_party/nxp/nxp_matter_support/scripts/update_nxp_sdk.py --platform common
~ git submodule update --init --recursive
~ source ./scripts/activate.sh
~ cd examples/all-clusters-app/nxp/rt/rw61x
~ gn gen --args="chip_enable_wifi=true chip_inet_config_enable_tcp_endpoint=true board_version=\"frdm\"" out/debug
~ ninja -C out/debug

inside out/debug/ there is a .hex file, which I first renamed to .srec for flashing
For SDK version, I checked

matter/third_party/nxp/nxp_matter_support/github_sdk/common_sdk/repo/examples/frdmrw612/frdmrw612_example_manifest_v3_14.xml

the SDK version is 2.16.100

[farazahmed8]

The branch for Matter is default one (release/v1.4.0)

[Christine_Li]

Hi, @farazahmed8 

Thanks for creating case to us.

I will check your query and reply to ASAP.

Best regards,

Christine.

[Christine_Li]

Hi， @farazahmed8 

Sorry for replying you late because of blocking by other priority customer cases.

As I know and discussed with our AE colleague, your issue has been resolved by csa matter repo + your method.

So would you please help to close this ticket?

Best regards,

Christine.

[farazahmed8 · Accepted solution]

I’ve found that TCP over LwIP on Matter applications has not yet been thoroughly tested on the NXP MCU platforms, and the application crashes sometimes with LwIP when transmitting larger payloads. I was able to confirm this by replicating the setup using the all-clusters-app on Ubuntu 22.04 laptop and the chip-tool on the i.MX93. With this configuration, everything worked smoothly without crashes or initial connection failures.