Encapsulation

[trivialkettle]

Hi,
Do I see it correct, that encapsulation is not supported?

In the spec:
https://www.oasis-open.org/committees/download.php/66091/MQTT-SN_spec_v1.2.pdf

5.5 Forwarder Encapsulation

I have an forwarder and a connect from the client is responded with a "normal" CONNAK package

03 05 00

[arobenko]

Yes, you are correct. The forwarding encapsulation functionality is not implemented. For two reasons:

• I personally didn't need this functionality at the time of implementation and I haven't seen any practical application to it.
• I find the spec about the functionality confusing (length of the "Wireless Node ID" is not properly defined, and the reason why forwarder encapsulates message sent to a gateway is not clear).

Please properly describe your use case so I can advice on the solution. Do you use a gateway implementation from this project? If this is the case you'll probably have to implement the "facade" by yourself identifying the encapsulated packet and stripping the encapsulation framing before forwarding the data to the gateway, and for response packets wrap them in the appropriate encapsulation frame and send the data to the forwarder.

Note that this project provides a gateway functionality as the library exposing all the exchanged data to the driving application. It allows you to add any extra framing (such as forwarding encapsulation) and/or encryption if needed.

Maybe in the future I will add extra "forwarder" that will help handle appropriate use cases once I properly understand it.

[trivialkettle]

My usecase is:
I have some PCB with a BLE chip that I want to connect to MQTT, I use your MQTT-SN client and the gateway.
The BLE chip connects to a BLE dongle on the host system, that is by itself a MQTTSN client but also forwards the traffic by the BLE chip to the MQTT broker.

Currently I use https://github.com/eclipse/paho.mqtt-sn.embedded-c on commit ca4675 as MQTTSN gateway for the forwarder only. The reason I use this specific commit is, that newer commits are sometimes broken, though this commit is also broken and the connected clients are sometimes disconnected (it seems like it just forgets that the clients exist) or the gateway segfaults. So I tried to move to your gateway, so far everything works better than the paho gateway except for the forwarder.

[arobenko]

I see. After some consideration I came to conclusion that the job of the forwarder is to be a mini gateway for multiple clients before the actual gateway, such as managing multiple wireless clients and forwarding their traffic to the gateway in the single communication channel. To properly support your use case you need to use the gateway as a library, not as binary. You need to implement the data parsing yourself and strip the forwarder framing. The latter contains id of the client, use it to identify the Session object. If it's new connection create a new Session object and retain it for the future messages. Forward the stripped MQTT-SN message to the relevant Session object. When the Session object reports data to be sent out, wrap it in the appropriate forwarder framing. All the said above should not be difficult to implement. Use the current gateway application as reference, which uses the origin ip as the session identifier. Use your favourite event handling framework not necessarily Qt. Unfortunately I'm too busy with other things and won't come around to supporting forwarding functionality in the next several months. Hope it helps

…

On Fri, 16 Feb 2024, 22:36 trivialkettle, ***@***.***> wrote: My usecase is: I have some PCB with a BLE chip that I want to connect to MQTT, I use your MQTT-SN client and the gateway. The BLE chip connects to a BLE dongle on the host system, that is by itself a MQTTSN client but also forwards the traffic by the BLE chip to the MQTT broker. Currently I use https://github.com/eclipse/paho.mqtt-sn.embedded-c on commit ca4675 as MQTTSN gateway for the forwarder only. The reason I use this specific commit is, that newer commits are sometimes broken, though this commit is also broken and the connected clients are sometimes disconnected (it seems like it just forgets that the clients exist) or the gateway segfaults. So I tried to move to your gateway, so far everything works better than the paho gateway except for the forwarder. — Reply to this email directly, view it on GitHub <#15 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASJKGWDRACJ36JXPXG3FUDYT5HDTAVCNFSM6AAAAABDKODKDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBYGMYTGMZZGA> . You are receiving this because you commented.Message ID: <commschamp/cc. ***@***.***>

[arobenko]

On the second thought, for your specific use case, why don't you run the gateway instead of the forwarder on the host with the BT dongle? Note that the gateway doesn't necessarily need to run on the same machine with the MQTT broker. The gateway uses TCP to talk to the broker and can be remote.

…

On Sat, 17 Feb 2024, 02:58 Alex Robenko, ***@***.***> wrote: I see. After some consideration I came to conclusion that the job of the forwarder is to be a mini gateway for multiple clients before the actual gateway, such as managing multiple wireless clients and forwarding their traffic to the gateway in the single communication channel. To properly support your use case you need to use the gateway as a library, not as binary. You need to implement the data parsing yourself and strip the forwarder framing. The latter contains id of the client, use it to identify the Session object. If it's new connection create a new Session object and retain it for the future messages. Forward the stripped MQTT-SN message to the relevant Session object. When the Session object reports data to be sent out, wrap it in the appropriate forwarder framing. All the said above should not be difficult to implement. Use the current gateway application as reference, which uses the origin ip as the session identifier. Use your favourite event handling framework not necessarily Qt. Unfortunately I'm too busy with other things and won't come around to supporting forwarding functionality in the next several months. Hope it helps On Fri, 16 Feb 2024, 22:36 trivialkettle, ***@***.***> wrote: > My usecase is: > I have some PCB with a BLE chip that I want to connect to MQTT, I use > your MQTT-SN client and the gateway. > The BLE chip connects to a BLE dongle on the host system, that is by > itself a MQTTSN client but also forwards the traffic by the BLE chip to the > MQTT broker. > > Currently I use https://github.com/eclipse/paho.mqtt-sn.embedded-c on > commit ca4675 as MQTTSN gateway for the forwarder only. The reason I use > this specific commit is, that newer commits are sometimes broken, though > this commit is also broken and the connected clients are sometimes > disconnected (it seems like it just forgets that the clients exist) or the > gateway segfaults. So I tried to move to your gateway, so far everything > works better than the paho gateway except for the forwarder. > > — > Reply to this email directly, view it on GitHub > <#15 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AASJKGWDRACJ36JXPXG3FUDYT5HDTAVCNFSM6AAAAABDKODKDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBYGMYTGMZZGA> > . > You are receiving this because you commented.Message ID: <commschamp/cc. > ***@***.***> >

[trivialkettle]

Hi,
thanks for you explanation.

The BT dongle is not just a BT dongle, but another PCB with a BLE chip and is by itself an MQTT client and also forwards the traffic from the BLE chip.
In fact the whole "pipeline" is like this: BLE PCB -> BLE-Dongle -> USB-to-UDP -> MQTTSN-Gateway.

For now I found a commit of the paho gateway that works with forwarding and seems to be stable.

Is it ok for you, if I integrate the forwarder into your example gateway and make a pull request? Maybe I find some time in the next weeks. Since I hope I can avoid the 'client:client:port:forwarder` configuration that paho mqttsn gateway needs for forwarders. So that I can use the gateway inside a docker container.