While testing IOT-733 with the latest changeset (which I'm sorry to say didn't fix the server-side crash) I noticed that CT_DEFAULT doesn't work for issuing an observe request anymore.
I had to modify client.c to use CT_ADAPTER_IP | CT_IP_USE_V6 for the observe request instead of CT_DEFAULT, which is what I was using so far. When I tried CT_DEFAULT, My observe OCClientResponse->result was 29 (OC_STACK_COMM_ERROR) and the payload was null. Why doesn't CT_DEFAULT work anymore? I thought one of the major attractions of this stack was that you didn't need to worry about what the communication mechanism was, allowing you to concentrate on the resources themselves. I've noticed that you can derive the right value for the OCConnectivityType from the information inside OCDevAddr by looking at ->adapter and ->flags, but it would be really nice if I didn't have to. Is it possible to provide an API for converting an OCDevAddr to a OCConnectivityType? Alternatively connType could become part of OCDevAddr (it already kind of is), since client applications now need to maintain a tuple (OCDevAddr, OCConnectivityType) for use in OCDoResource() calls anyway. Cheers! Gabriel
