Christian M. Amsüss
2018-03-23 22:01:24 UTC
Hello,
there has been some testing of CoAP-over-TCP interoperability before and
during IETF101.
At a remote interop set up by Hannes, Szymon and I tested java-coap[1]
against aiocoap[2] respectively, and achieved interoperability for
regular requests (unfragmented up to around Max-Message-Size) and Block2
operations with BERT.
During IETF101, Jim and I tested requests from my client to his server.
We achieved interoperability for both Block1 and Block2 operations that
were fragmented to BERT messages.
No observation was tested.
In an additional test, I ran a very quick-and-dirty Rust WASM
CoAP-over-WS client over an equally ad-hoc coap+ws-to-coap+tcp "proxy"
(both at [3]) against Szymon's server. The client obtained a simple
small resource from the server, which is almost everything it can do so
far. (It can do observe, but no such resource was available to test
against).
Issues we encountered and largely fixed right during those tests:
* A client could not deal with initial CSMs not carrying any options.
* A server did not abort when receiving malformed (TKL > 8 or
unreasonable length) packages.
* A server expected all Block1 exchanges to happen using the same token.
* A server replied to the last Block1 request with a final successful
message but using the first blocks's token.
* A server did not consider the non-payload size of the message, and
tried to send 16k-payload plus header and options to a client that
announced a CSM of exactly 16k.
* Tests with TLS were impeded by one implementation only supporting PSK
and the other only supporting certificates in the current incomplete
state of implementation.
* The question came up of how a large request payload be best managed
if it is the first message a client sends (see thread at [4]). During
tests, BERT operation was in some of these cases made possible by the
client delaying its first request until CSM was received, or by
requesting another resource before initiating the large PUT.
I have recorded the traffic during one of the tests, in case anyone
needs samples for building a Wireshark dissector (nudge nudge).
Best regards
Christian
[1]: https://github.com/ARMmbed/java-coap
[2]: https://github.com/chrysn/aiocoap
[3]: https://gitlab.com/chrysn/coap-wasm-demo
[4]: https://mailarchive.ietf.org/arch/msg/core/2CutxE3xjuDrvQaisWgcXk03cIE
there has been some testing of CoAP-over-TCP interoperability before and
during IETF101.
At a remote interop set up by Hannes, Szymon and I tested java-coap[1]
against aiocoap[2] respectively, and achieved interoperability for
regular requests (unfragmented up to around Max-Message-Size) and Block2
operations with BERT.
During IETF101, Jim and I tested requests from my client to his server.
We achieved interoperability for both Block1 and Block2 operations that
were fragmented to BERT messages.
No observation was tested.
In an additional test, I ran a very quick-and-dirty Rust WASM
CoAP-over-WS client over an equally ad-hoc coap+ws-to-coap+tcp "proxy"
(both at [3]) against Szymon's server. The client obtained a simple
small resource from the server, which is almost everything it can do so
far. (It can do observe, but no such resource was available to test
against).
Issues we encountered and largely fixed right during those tests:
* A client could not deal with initial CSMs not carrying any options.
* A server did not abort when receiving malformed (TKL > 8 or
unreasonable length) packages.
* A server expected all Block1 exchanges to happen using the same token.
* A server replied to the last Block1 request with a final successful
message but using the first blocks's token.
* A server did not consider the non-payload size of the message, and
tried to send 16k-payload plus header and options to a client that
announced a CSM of exactly 16k.
* Tests with TLS were impeded by one implementation only supporting PSK
and the other only supporting certificates in the current incomplete
state of implementation.
* The question came up of how a large request payload be best managed
if it is the first message a client sends (see thread at [4]). During
tests, BERT operation was in some of these cases made possible by the
client delaying its first request until CSM was received, or by
requesting another resource before initiating the large PUT.
I have recorded the traffic during one of the tests, in case anyone
needs samples for building a Wireshark dissector (nudge nudge).
Best regards
Christian
[1]: https://github.com/ARMmbed/java-coap
[2]: https://github.com/chrysn/aiocoap
[3]: https://gitlab.com/chrysn/coap-wasm-demo
[4]: https://mailarchive.ietf.org/arch/msg/core/2CutxE3xjuDrvQaisWgcXk03cIE
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom