forked from nrfconnect/sdk-zephyr
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Hack to reopen sockets after 55s of silence. This is to force DTLS se…
…ssion resumption in NB-IoT networks
- Loading branch information
Showing
1 changed file
with
36 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
a35f03c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reopen_sockets should return an error, because if coverage is lost, the lwm2m_socket_start will fail and ctx will become a null pointer that will cause a crash.
a35f03c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, good point, thanks. So far I have not found any better solution for this problem, so I guess I just have to make this "official" at some point(before our product goes to production line)
I have also been pondering if I should make a new function or configuration option gor lwm2m engine, for setting the timeout value. I think it would be good to have it dynamically configurable parameter instead of some compilation time flag. Then you could detect from engine events if things take too long(retries when DTLS context had disappeared) and reduce the value until it starts working. Kind of like poor man's "operator firewall settings detection" algorithm. Thoughts @JPSELC ?
a35f03c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is as good as it gets right now. Ultimately, we're waiting on : https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/history/ but it looks like that might take a while.
We are using a variable for timeout which should be updateable over the air. I don't think networks change that parameter very often. But safest thing is to keep the value small.
Reducing it on the fly could get tricky, especially in situations where you have poor/borderline coverage and retransmits are necessary