Re: [core] [Anima] constrained resources at root for debugging connectivity

[Michael Richardson <[e-mail]>]

Esko Dijk <[e-mail]> wrote:
    > There is already a "CoAP ping" described in RFC 7252 that can be
    > used. It does not access any resource, just the CoAP server endpoint at
    > CoAP message layer. As a side effect of this ping your DTLS stack will
    > set up the connection which is handy.

I recalled that later in the day that CoAP "ping" is not connected to CoAP
"echo" :-)
I think that there is also potentially a need for a way to debug possible MTU
issues.
Is there a way to use Olaf's "coap-client" to do the ping?
I don't see an option, and it also doesn't seem to be commonly built with DTLS.
We also have the issue of CCM8 vs OpenSSL that I thought got solved, but it
appears that it has not been, so one needs a tool built with mbedtls or wolfSSL.

    > So I don't think we need a resource at / that produces 2.05 , this is
    > for the maintainer of the server to decide how to allocate that
    > resource space.

    > Besides we have already defined some well-known resources accessible
    > with GET ( in core/est/brski) that the client could make use of to test
    > connectivity.

    > Even a non-existing resource in the /.well-known/X space could be used
    > just to get a 4.04 which confirms the server is working properly. This
    > is even better that trying to GET a resource of who knows how large
    > size.

BTW, I've changed my /version.json so that it now looks for and returns the
client certificate that it saw:

curl
        --cert spec/files/product/00-D0-E5-02-00-2E/device.crt
        --key  spec/files/product/00-D0-E5-02-00-2E/key.pem
        https://masa.honeydukes.sandelman.ca/version.json

->

{"version":"1.1.0","revision":"582044cfc536fd295e8bdcd3b90f30453d7784d3","Hostname":"masa.honeydukes.sandelman.ca","client_certificate":"-----BEGIN CERTIFICATE-----\nMIICBjCCAYugAwIBAgIEXKnlyDAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQB\nGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3Ry\ndW5nIEhpZ2h3YXkgQ0EwIBcNMTkwNDI0MDIxNjU4WhgPMjk5OTEyMzEwMDAwMDBa\nMBwxGjAYBgNVBAUMETAwLWQwLWU1LTAyLTAwLTJlMFkwEwYHKoZIzj0CAQYIKoZI\nzj0DAQcDQgAEey+I0TtIhm8ivRJY36vF5ZRHs/IwhQWRc2Ql70rN+aYLZPOIXYc6\nZzlO62kDYBo3IPrcjkiPVnhoCosUBpTzbqOBhzCBhDAdBgNVHQ4EFgQU/g+KaX9o\nDEKY2K3NGe7Vr/9geDAwCQYDVR0TBAIwADArBgNVHREEJDAioCAGCSsGAQQBgu5S\nAaATDBEwMC1EMC1FNS0wMi0wMC0yRTArBgkrBgEEAYLuUgIEHgwcbWFzYS5ob25l\neWR1a2VzLnNhbmRlbG1hbi5jYTAKBggqhkjOPQQDAgNpADBmAjEAuEwTKPMzS/Xm\nAhR4tFtDo3YHoPoBsaw/6UUYDHot4EoKy2L8AlriFzti/iNmH67/AjEAnRjH2R0T\n98DZjBIhz7W8LM52AeymMdCtsJyuDRjtVuncGEfMO/OWuFFx5qwYR63I\n-----END CERTIFICATE-----\n"}

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide