ZCL Tunneling - RequestTunnel not received

RE: ZCL Tunneling - RequestTunnel not received

Simonr — Tue, 18 May 2021 05:13:55 GMT

Another note: Each command is handled by the callback registered by ZB_ZCL_REGISTER_DEVICE_CB must set the command statucs (ZB_ZCL_DEVICE_CMD_PARAM_STATUS(bufid)) to RET_OK if it's a success, and RET_ERROR respectively. That's how the lower layer knows if the callback is handling the command or not.

Best regards,

Simon

RE: ZCL Tunneling - RequestTunnel not received

Simonr — Wed, 12 May 2021 06:24:14 GMT

Sorry about the delayed reply. Edvin is currently out of office and I've been tasked with looking after this case. I got an update from one of our Zigbee experts today with a few suggestions to get the client side up and running.

Register zb_tunnel_endpoint_handler with ZB_ZCL_REGISTER_DEVICE_CB instead of ZB_AF_SET_ENDPOINT_HANDLER
Change enum values in mentioned callback to the ones from zboss_api_zcl.h (beginning with ZB_ZCL_TUNNELING_)

If callback at the server side is registered in a respective way there will be no need to manually fill the tunnel request response.

Here are some examples of the client and server callbacks. It's not perfect but I believe it shows how to implement them.

// server side
static void zb_tunnel_endpoint_handler(zb_bufid_t bufid){    switch(ZB_ZCL_DEVICE_CMD_PARAM_CB_ID(bufid))
    {
        case ZB_ZCL_TUNNELING_REQUEST_TUNNEL_CB_ID:
        {
            zb_zcl_tunneling_request_tunnel_t tun;
            zb_zcl_parse_status_t status;
            zb_zcl_device_callback_param_t *param =
                    ZB_BUF_GET_PARAM(bufid, zb_zcl_device_callback_param_t);
            zb_zcl_tunnel_request_params_out_t *params =
                    (zb_zcl_tunnel_request_params_out_t*)param->cb_param.gnr.out;
 
            ZB_ZCL_TUNNELING_GET_REQUEST_TUNNEL(&tun, bufid, status);
            NRF_LOG_INFO("Tunneling request: %d/%d/%d %d",
                         tun.protocol_id, tun.manufacturer_code, status,
 tun.max_incoming_transfer_size);
            params->tunnel_status = ZB_ZCL_TUNNELING_STATUS_SUCCESS;
            params->max_incoming_to_srv_transfer_size = 100;//tun.max_incoming_transfer_size;
            ZB_ZCL_DEVICE_CMD_PARAM_STATUS(bufid) = RET_OK;
 
            if (status==ZB_ZCL_PARSE_STATUS_SUCCESS &&
                tun.protocol_id==TUNNELING_PROTOCOL_ID &&
                tun.manufacturer_code==TUNNELING_MANUF_CODE)
            {
                zb_bufid_t buf_resp = zb_buf_get_out();
                zb_ret_t zb_err_code=ZB_SCHEDULE_APP_ALARM(tunnel_send_transfer_data, buf_resp, 5*ZB_TIME_ONE_SECOND);
                ZB_ERROR_CHECK(zb_err_code);
            }
            break;
        }
        case ZB_ZCL_TUNNELING_CLOSE_TUNNEL_CB_ID:
        {
            zb_zcl_tunneling_close_tunnel_t tun;
            zb_zcl_parse_status_t status;
            ZB_ZCL_TUNNELING_GET_CLOSE_TUNNEL(&tun, bufid, status);
            NRF_LOG_INFO("Tunnel close: %d/%d", tun.tunnel_id, status);
            zb_buf_free(bufid);
            break;
        }
 
        default:
        {
            NRF_LOG_INFO("Unhandled cmd");
            break;
        }
    }
}

// client side 
static void zb_tunnel_endpoint_handler(zb_bufid_t bufid){
 switch(ZB_ZCL_DEVICE_CMD_PARAM_CB_ID(bufid))
 {
 case ZB_ZCL_TUNNELING_REQUEST_TUNNEL_RESPONSE_CB_ID:
 {
 zb_zcl_tunneling_request_tunnel_response_t tun;
 zb_zcl_parse_status_t status;
 ZB_ZCL_TUNNELING_GET_REQUEST_TUNNEL_RESPONSE(&tun, bufid, status);
 NRF_LOG_INFO("Tunneling request response: %d/%d/%d-max transfer:%d", tun.tunnel_id, tun.tunnel_status, status, tun.max_incoming_transfer_size);
 if (status==ZB_ZCL_PARSE_STATUS_SUCCESS &&
 tun.tunnel_status==ZB_ZCL_TUNNELING_STATUS_SUCCESS)
 {
 tunnel_id=tun.tunnel_id;
 zb_ret_t zb_err_code=ZB_SCHEDULE_APP_ALARM(tunnel_send_transfer_data, bufid, 2*ZB_TIME_ONE_SECOND);
 ZB_ERROR_CHECK(zb_err_code);
 NRF_LOG_INFO("Tunnel response parse OK");
 }
 else
 {
 zb_buf_free(bufid);
 }
 break;
 }
 case ZB_ZCL_TUNNELING_SRV_CMD_TUNNEL_CLOSURE_NOTIFICATION:
 {
 NRF_LOG_INFO("Tunnel closed/timeout");
 break;
 }
 
 case ZB_ZCL_TUNNELING_SRV_CMD_TRANSFER_DATA:
 {
 zb_zcl_tunneling_transfer_data_payload_t data;
 zb_zcl_parse_status_t status;
 ZB_ZCL_TUNNELING_GET_TRANSFER_DATA(&data, bufid, status);
 NRF_LOG_INFO("Transfer data: %d/%d", data.data_size, status);
 if (status==ZB_ZCL_PARSE_STATUS_SUCCESS)
 {
 NRF_LOG_INFO("%s", data.tun_data);
 }
 zb_buf_free(bufid);
 break;
 }
 
 default:
 NRF_LOG_INFO("Unhandled command");
 }
}

Best regards,

Simon

RE: ZCL Tunneling - RequestTunnel not received

jen — Thu, 08 Apr 2021 04:53:07 GMT

RET_ERROR results from the calls of ZB_ZCL_TUNNELING_CLIENT_SEND_TRANSFER_DATA and ZB_ZCL_TUNNELING_SERVER_SEND_TRANSFER_DATA, respectively (client and server functions tunnel_send_transfer_data after tunnel is established).

Client:

<info> app: tunnel_request: 4
<info> app: tunnel_request_cb: 4
<info> app: zb_tunnel_endpoint_handler: 0
<info> app: Tunneling request response: 72/0/0
<info> app: Transfer data: 72/11
<info> zboss: 07 00 00 00 DE AD 0A 02|........
<info> zboss: D8 06 24 00 BD F8 30 01|..$...0.
<info> zboss: DE AD 0E 02 B4 02 23 00|......#.
<info> zboss: 7A 6E 7D 01 04 00 00 00|zn}.....
<error> app: ERROR 1 [RET_ERROR] at ../../../main.c:393

Server:

<info> app: zb_tunnel_endpoint_handler: 0
<info> app: Tunneling request: 200/3910/0
<info> app: Tunneling request response
<info> app: Transfer data: 72/11
<info> zboss: 06 00 00 00 DE AD 0E 02|........
<info> zboss: 47 0A 24 00 BB F8 05 02|G.$.....
<error> app: ERROR 1 [RET_ERROR] at ../../../main.c:321

RE: ZCL Tunneling - RequestTunnel not received

Edvin — Tue, 06 Apr 2021 13:39:24 GMT

Hello,

I am sorry for the late reply.

Where is the RET_ERROR coming from? Do you see them in your log? What function or callback do they point you to?

RE: ZCL Tunneling - RequestTunnel not received

jen — Mon, 22 Mar 2021 09:19:06 GMT

Meanwhile I managed to create a Wireshark nRF Sniffer log. There can be seen
- t=50 s: Request Tunnel
- t=51 s: Request Tunnel Response
(- t=53 s: Client Transfer Data expected, RET_ERROR)
(- t=55 s: Server Transfer Data expected, RET_ERROR)
- t=57 s: Close Tunnel

devzone.nordicsemi.com/.../tunnel.pcapng

RE: ZCL Tunneling - RequestTunnel not received

jen — Wed, 17 Mar 2021 13:44:35 GMT

devzone.nordicsemi.com/.../main_2D00_server.c devzone.nordicsemi.com/.../main_2D00_client.c

I stripped down the example project to use the tunnel endpoint only.

Execution:
- On client press button BSP_BUTTON_0:
- Tunnel request (buttons_handler/tunnel_request)
- 2s after tunnel request response (zb_tunnel_endpoint_handler), transfer data (tunnel_send_transfer_data)
- On server:
- 5s after tunnel request (zb_tunnel_endpoint_handler), transfer data (tunnel_send_transfer_data)
- On client press button BSP_BUTTON_1:
- Tunnel close (buttons_handler/tunnel_close)

Actual problems are:
- Profile ID seems to have to be ZB_AF_HA_PROFILE_ID, with other values ZB server won't even get its tunnel endpoint handler called (zb_tunnel_endpoint_handler)
- ZB_ZCL_TUNNELING_CLIENT_SEND_TRANSFER_DATA and ZB_ZCL_TUNNELING_SERVER_SEND_TRANSFER_DATA both return RET_ERROR, though their connection seems established
- Tunnel timeout never seems to be raised (ZB_ZCL_TUNNELING_SRV_CMD_TUNNEL_CLOSURE_NOTIFICATION), though tunnel timeout is configured (close_tunnel_timeout=60s)

RE: ZCL Tunneling - RequestTunnel not received

Edvin — Tue, 16 Mar 2021 08:11:49 GMT

The ZB_AF_SE_PROFILE_ID / ZB_AF_HA_PROFILE_ID wasn't mentioned before now. Where are you using it? Perhaps you are trying to add this profile to the light_switch endpoint? If so, I believe they need to be on the same profile ID.

[quote user="jen"]At this point, transfer data fails in both directions with RET_ERROR as already described here. Is there any progress what may cause this error?[/quote]

Is this something I can reproduce on my side with 2x nRF52840 DKs?

If so, can you please zip the two projects that you are using to test this on? It is not easy to say what's wrong only from your snippets. From where do you get the bufid, how is the tunnel_send_transfer_data_cb set up, what is your tunnel_id?

RE: ZCL Tunneling - RequestTunnel not received

jen — Mon, 15 Mar 2021 08:57:33 GMT

In the meantime I found out that profile ID ought to be HA:

#define TUNNELING_PROFILE_ID ZB_AF_HA_PROFILE_ID

With this, RequestTunnel seems working, client side request tunnel callback gets invoked and server receives ZB_ZCL_TUNNELING_CLI_CMD_REQUEST_TUNNEL as expected.

Question is, why does profile ID have to be HA (even ZB_AF_SE_PROFILE_ID does not work)?

At this point, transfer data fails in both directions with RET_ERROR as already described here. Is there any progress what may cause this error?

zb_uint8_t *data=(zb_uint8_t*)"Testdata";
NRF_LOG_INFO("Transfer data: %d/%d", tunnel_id, strlen((char*)data));
zb_ret_t zb_err_code=ZB_ZCL_TUNNELING_CLIENT_SEND_TRANSFER_DATA(bufid, TUNNELING_ENDPOINT_ID, TUNNELING_PROFILE_ID,
		ZB_ZCL_DISABLE_DEFAULT_RESPONSE, tunnel_send_transfer_data_cb,
		tunnel_id, strlen((char*)data), data);
ZB_ERROR_CHECK(zb_err_code);

RE: ZCL Tunneling - RequestTunnel not received

jen — Tue, 09 Mar 2021 10:49:30 GMT

Dear Edvin,

first of all, the intent to use Tunneling is to run proprietary protocols over ZigBee for an existing application, which is its main use case. I haven't found any example doing so, yet. The ticket you refer to does Tunneling, though there can not be seen how server and client prepare their ZigBee clusters and endpoints, etc. There instead, request tunnel seems to run properly but problems arise later during data transfer.

In my example, tunnel_request is called from a button handler (showing no error):

static void buttons_handler(bsp_event_t evt)
{
    zb_ret_t zb_err_code;
    switch(evt)
    {
        case BSP_EVENT_KEY_0:
            button = LIGHT_SWITCH_BUTTON_ON;
            {
				zb_bufid_t bufid=zb_buf_get_out_func();
			    zb_err_code=ZB_SCHEDULE_APP_ALARM(tunnel_request, bufid, 3*ZB_TIME_ONE_SECOND);
                ZB_ERROR_CHECK(zb_err_code);
            }
            break;

On server log some output appears upon the tunnel request, i.e. something seems to be received, though the server tunnel endpoint handler does not get invoked:

<info> zboss: 01 00 00 00 DE AD 12 02|........
<info> zboss: F6 0E 38 00 29 08 EA 00|..8.)...
<info> zboss: 03 00 00 00 0B 00 00 00|........

RE: ZCL Tunneling - RequestTunnel not received

Edvin — Mon, 08 Mar 2021 21:01:15 GMT

Hello,

I have never used the RequestTunnel in zigbee. Is there a particular reason why you need to use it? (I don't think it is used in any of the examples).

I see that the only other ticket on Devzone discussing this is this one. Can you please check it out? It didn't come to a conclusion, but perhaps you can try to follow where that person left of.

First, where in your client do you call the tunnel_request()? I can't see that from your snippets. And second, do you get any return values by doing so? Do they all indicate that everything is OK, or do they indicate that something is wrong? (the return values, that is).

Best regards,

Edvin