[cf-dev] Potential bug...

[Stéphane Rouges <stephane.rouges@xxxxxxxxxx>]

Hi,

I'm working on a CoAP stack written in C and use Californium for interoperability tests. I think I found a bug in Californium. This issue is hard to reproduce since it involves randomness, requires heavy load and other specific parameters.

It occurs when CF is invoking a server using separate responses: message IDs sent from the server are logically kept in the Deduplicactor. The problem occurs when the CF client uses a subsequent colliding MID (hence the randomness of the issue) since it then considers the received piggy-backed response to its own request as a duplicate (and trap it). Note that it occurs when the same token is used by the client for successive requests.

I think that the protocol requires message IDs to be managed by each peer and may then collide. This is why, in my opinion, CF should verify the "message exchange pattern" to assert a duplicate. Here is my bug fix attempt in Matcher.java, line 310:

Exchange prev = deduplicator.findPrevious(idByMID, exchange);
if (prev != null && response.getType() != Type.ACK) { // (and thus it holds: prev == exchange)

	LOGGER.fine("Duplicate response "+response);

	response.setDuplicate(true);

} else {

	LOGGER.fine("Exchange got reply: Cleaning up "+idByMID);

	exchangesByMID.remove(idByMID);

}

It consist in not considering a received ACK can be a duplicate. What's your opinion ? I'm not sure about the fix since I did not study the  Matcher/Deduplicator fully.

BR,

--

Stéphane ROUGES

Phone: Mobile: Fax: Address:

+33 9 72 32 80 99 +33 6 51 98 34 64 +33 9 72 32 79 17 6, avenue Lulli - 92310 SEVRES - FRANCE

Contact us  for any kind of support about XML/EXI, embedded Web Services and DPWSCore software.