Throws `KNXTimeoutException` due to missing confirmation although the confirmation was received

[dallmair]

Throws `KNXTimeoutException` due to missing confirmation although the confirmation was received

[dallmair]

The only thing that looks a bit suspicious to me is the implementation of ClientConnection::doExtraBlockingModes: waitForStateChange already returns whether the state change happened or not, but doExtraBlockingModes ignores that result and compares the internalState field again. That seems odd to me, but I have no idea whether this is actually in the relevant code path for the issue reported here.

[bmalinowsky]

Thank you for the log file. I'll try to find out what's wrong.

• There are several duplicate confirmations in the log, e.g., 00:17:18.807 and 00:17:18.840.
• The logic in KNXnet/IP tunneling for determining a successful .con is currently after the notification to the link layer. Hence, a .con is always reported (logged). This has its benefits (there is a TODO to move that, because I know that can be confusing), but is not helpful in your case: a L2 log entry does not mean that tunneling moved on from CEMI_CON_PENDING. I think that's the culprit.
  In essence, the relevant part whether a .con is accepted or not starts here:

  calimero-core/src/io/calimero/knxnetip/KNXnetIPTunnel.java

  Line 408 in 104731d

  if (ldata != null && internalState == CEMI_CON_PENDING) {

• For instance, at

  calimero-core/src/io/calimero/knxnetip/KNXnetIPTunnel.java

  Line 421 in 104731d

  final int sendCount = ldata.getHopCount() - 1;

  
  there is a workaround for eibd, but there is currently no other log output for other conditions (i.e., if the array comparison of recv and sent fails completely).

I don't know how easy it is for you to run with changed source code, but setting the log output to TRACE, and adding some log output, e.g., array mismatch, would help. I think the .con is currently not accepted.