NPE in ClientHandshaker.receivedHelloVerifyRequest

[kaikreuzer]

I just had this exception in my logs, using Californium 1.0.6:

Nov 10, 2017 2:52:52 PM org.eclipse.californium.scandium.DTLSConnector receiveNextDatagramFromNetwork
INFO: Unexpected error occurred while processing record from peer [/192.168.0.177:5684]
java.lang.NullPointerException
	at org.eclipse.californium.scandium.dtls.ClientHandshaker.receivedHelloVerifyRequest(ClientHandshaker.java:343)
	at org.eclipse.californium.scandium.dtls.ClientHandshaker.doProcessMessage(ClientHandshaker.java:218)
	at org.eclipse.californium.scandium.dtls.Handshaker.processMessage(Handshaker.java:410)
	at org.eclipse.californium.scandium.DTLSConnector.processOngoingHandshakeMessage(DTLSConnector.java:796)
	at org.eclipse.californium.scandium.DTLSConnector.processDecryptedHandshakeMessage(DTLSConnector.java:783)
	at org.eclipse.californium.scandium.DTLSConnector.processHandshakeRecordWithConnection(DTLSConnector.java:767)
	at org.eclipse.californium.scandium.DTLSConnector.processHandshakeRecord(DTLSConnector.java:703)
	at org.eclipse.californium.scandium.DTLSConnector.receiveNextDatagramFromNetwork(DTLSConnector.java:438)
	at org.eclipse.californium.scandium.DTLSConnector.access$200(DTLSConnector.java:105)
	at org.eclipse.californium.scandium.DTLSConnector$2.doWork(DTLSConnector.java:331)
	at org.eclipse.californium.scandium.DTLSConnector$Worker.run(DTLSConnector.java:1448)

I cannot really give you code on how to reproduce it, but it certainly looks like a bug as an NPE should happen in no situation here.
Checking the code base, it also seems that 2.x still looks the same, so although I am using 1.0.6 I would assume that the issue still exists.

[sophokles73]

Hmm, it's really hard to imagine what causes this problem. As you already pointed out, there is basically no way that any of the objects at the indicated line of code is null.

[kaikreuzer]

There must be SOME way... I have seen it twice already now.

[sophokles73]

what is the scenario in which you use Cf?

[boaks]

Race condition. I would guess, there are stop/start close to that exception.

1. CoAP REQUEST (without established session)
2. triggers new HANDSHAKER
3. send HELLO_REQUEST
4. stop/start
5. CoAP REQUEST (without established session)
6. triggers new HANDSHAKER
7. Receives HELLO_VERIFY_REQUEST (for 3.)
8. null pointer ...
9. HELLO_REQUEST

If you restart because of "COMMUNICATION_ERRORS", but this may cause more problems,

[kaikreuzer]

Scenario is IKEA Tradfri binding in Eclipse SmartHome (what else ;-)).

Please note that this issue is not at all important for me - I only meant to report it as I came across this exception, but it happens seldomly enough to not cause any issue for me.

[kaikreuzer]

@boaks A race condition indeed sounds likely as I have seen it right after re-establishing a connection.

[boaks]

I still miss the information, how long californium runs with the tradfri gateway, until restarts are required or executors are shutdown. I've implemented a small californium pure client, which was running over a night without any issue. So, is information about MTBF available?

[kaikreuzer]

I've just finished a major refactoring (and adaption to the new Tradfri firmware authentication requirements), see eclipse-archived/smarthome#4530 and eclipse-archived/smarthome#4486 and will push this out to the openHAB community tonight - we will then see whether there are still any "failures after hours without touching anything". The debug logging is in place then as well. No worries, you will hear from me, if there are any news :-)

[boaks]

@kaikreuzer
Thanks a lot! Without MTBF, it would be very hard for me to analyse, what makes trouble when communicating with tradfri.

[boaks]

@kaikreuzer
From my side, this NPE issue is fixed. Do you have any information about MTBF?
Would a 1.0.7 release help to make progress?
(As far as I remember, the "irritating log messages on stop/shutdown" are still open. I would got to fix this also and then ask the other commiters for objections against a 1.0.7.)

[boaks]

@kaikreuzer

If a 1.0.7 release help to make progress, just open a new issue.

[kaikreuzer]

Thanks @boaks!
I cannot tell you a MTBF for this exception and I am also not sure if something breaks when it occurs.
I am therefore in no rush regarding a 1.0.7 release. I'd hope that you anyhow schedule one for the next weeks and I'll happily upgrade to it, once it is there.