Using 'demo' with *only* a bootstrap server about anjay HOT 8 CLOSED

Unfortunately, I haven't been able to reproduce your problem locally - your configuration works fine when pasted into the demo client and ran normally on Linux. Even the logs look the same as what you pasted - but the client connects. There might be some problem with your integration code with the embedded platform, or with some modifications you might have done in seemingly unrelated parts of the code.

I'd advise you to try running the demo client with such configuration on a proper OS (e.g. Linux), and compare the execution between that and your embedded version using a debugger. If you find some place in our code to be the cause of the problems, we'll be happy to fix it.

Also you may want to note that embedded platforms sometimes fail to keep the necessary invariants. We had an experience working with a build of ThreadX that did not align thread stacks to 8-byte boundaries, which in turn caused some standard library functions to behave erratically. You may want to double-check that nothing of the sort is happening in your code.

from anjay.

Thanks for the feedback and suggestions. I have it built and running on Linux now, so I can hopefully start trying to trace the problem. It may be the way I have implemented my 'client thread'.

The area where the log from my platform begins to differ is when it reports:
"src/interface/bootstrap_core.c:828]: Bootstrap already started on the same connection" <- EDIT: I'm looking into this now

My cmake options have to be different; at the moment I am using
-DWITH_AVS_COMPAT_THREADING=ON
-DWITH_CUSTOM_AVS_THREADING=OFF
-DWITH_AVS_COMPAT_THREADING_ATOMIC_SPINLOCK=ON
-DWITH_AVS_COMPAT_THREADING_PTHREAD=OFF
-DWITH_STANDARD_ALLOCATOR=OFF
-DWITH_AVS_HTTP=OFF \

Do any of these jump out as a possible cause?

from anjay.

Ok, I think I see the problem.
I have implemented my own clock_gettime() function. For CLOCK_REALTIME, I fetch tv_sec from my RTC but set tv_nsec=0 because the RTC [I think] only has second resolution.
If I change this to the RTOS tick count with msec resolution - which is what I return for CLOCK_MONOTONIC - then the "Bootstrap already started on the same connection" does not occur and it appears that bootstrapping succeeds.
Any thoughts on how I can resolve this please? Is there anywhere that CLOCK_REALTIME needs to be a real time, or would it all be ok if instead it is just a 'time since reset'?
(Should Anjay use a clock_getres() to determine how it should make it's decisions.....?)

from anjay.

Thank you for your investigation! Frankly speaking, we did not check what happens when precision of either of the clocks is as low as a second. We will look into it and investigate how can it be improved.

Any thoughts on how I can resolve this please? Is there anywhere that CLOCK_REALTIME needs to be a real time, or would it all be ok if instead it is just a 'time since reset'?

CLOCK_REALTIME is used for handling registration lifetime, and it not being actual real time can lead to problems if the machine can go into some kind of sleep mode, i.e. if the clock would not account for the time spent in sleep. That would cause the registration lifetime logic to behave erratically.

Also you definitely want to make sure that such "hacked" not-really-realtime clock is not used by the DTLS library, because otherwise you won't be able to properly check certificate validity.

from anjay.

Thanks. Cert validity was certainly a possible problem area that I had thought of.
(Does Anjay use it's clock_gettime for this and then pass it to the DTLS lib. i.e. Or, as long as the lib has its own method to get Real Datetime, then Anjay will be ok?

from anjay.

Or, as long as the lib has its own method to get Real Datetime, then Anjay will be ok?

Anjay will be OK in this case. AFAIK absolute times are never passed from Anjay to the DTLS library.

from anjay.

I have found a problem with using 'time since reset' - avs_time_real_now is used to seed the PRNG. This means that if I run and then reset/re-run, the same Token and Message ID are used in the CoAP message and are ignored by the server for being a 'duplicate'.
Probably I will have to modify the library code to use my RNG. It might be nice if avs_commons had the option to hook in a user-supplied PRNG function?

from anjay.

Since Anjay 2.3, cryptographically-safe PRNG from the TLS library, with an option to specify user-provided entropy source, is used. I hope that this solves this issue, especialy now that it has not been updated for over a year. Please open another one if you still have questions.

from anjay.