Skip to content

GitLab

I
iotivity-classic
Switch branch/tag
  1. 25 Jul, 2019 2 commits
  3. 18 Jul, 2019 1 commit
  5. 26 Feb, 2019 1 commit
  7. 16 Jan, 2019 1 commit
  9. 06 Nov, 2018 1 commit
  11. 31 Oct, 2018 1 commit
  13. 06 Sep, 2018 1 commit
  15. 24 Apr, 2018 2 commits
  17. 06 Apr, 2018 1 commit
  19. 24 Mar, 2018 1 commit
    • Mats Wichmann's avatar
      static analysis: unintitialized struct · 9497dde7
      Mats Wichmann authored 
      A couple of instances in this file do not initialize a struct,
while the majority do so using memset. Aligned so this source file
does things consistently. Two of these (lines 709 and 748 in the
original source) are causing Coverity static checker complaints
("uninitialized scalar variable") because the struct is assigned -
even though the member in question is never actually accessed.

Note according to my understanding, for c++ code, it is considered
better to use object initialization, although if the data is
only POD (Plain Old Data), the result does come out the same.
Thus, instead of:

    CAInfo_t responseData;
    memset(&responseData, 0, sizeof(CAInfo_t));

it is suggested to use:

    CAInfo_t responseData {};

we could adjust that in a separate change if people agree.

It should not actually be necessary to pre-fill the whole struct
with zeroes since the fields that matter get values in the tests
before use anyway. However the problem with CAInfo_t is that
someone thought it was a sensible idea to have a conditional
field in an important (public API) struct in cacommon.h:

typedef struct
{
    CAMessageType_t type;       /**< Qos for the request */
.#ifdef ROUTING_GATEWAY
    bool skipRetransmission;    /**< Will not attempt retransmission even if type is CONFIRM.
                                     Required for packet forwarding */
.#endif
    uint16_t messageId;
    ...
} CAInfo_t;

which means every valid use of CAInfo_t has to have the same #ifdef
ROUTING_GATEWAY bracketing to deal with this optional member. This
is absolutely horrid in a public API and should never happen -
it means the API is different if you use different compile flags.

Change-Id: If178c7d245142e166fa33447cd00946cff4a56fc
Signed-off-by: default avatarMats Wichmann <mats@linux.com>
      9497dde7
  21. 07 Mar, 2018 1 commit
  23. 02 Mar, 2018 1 commit
  25. 24 Jan, 2018 1 commit
  27. 14 Dec, 2017 1 commit
    • Mats Wichmann's avatar
      Remove arduino support 2/3 · 29144368
      Mats Wichmann authored 
      Arduino is now supported only in iotivity-constrained,
but all the support in the iotivity build remains.
Remove in three phases (just to make shorter commits
to review).  Part 2 removes arduino from all the other
build scripts which referenced it, and from auto_build.py
and the vagrant setup.

Change also removes the remaining arduino directories, as
follows:

    extlibs/arduino
    resource/c_common/ocatomic/src/arduino
    resource/c_common/ocrandom/test/arduino
    resource/csdk/connectivity/build/arduino
    resource/csdk/connectivity/lib/arduino
    resource/csdk/connectivity/src/bt_le_adapter/arduino
    resource/csdk/connectivity/src/ip_adapter/arduino
    resource/csdk/connectivity/src/tcp_adapter/arduino
    resource/csdk/logger/test/arduino
    resource/csdk/stack/samples/arduino
    resource/csdk/stack/test/arduino
    service/easy-setup/sampleapp/enrollee/arduino
    tools/arduino

which means some code files are removed as well.

Bug: https://jira.iotivity.org/browse/IOT-2927
Change-Id: Idd5001a810ff4f67022f60bcb9d3252f7de7ccc2
Signed-off-by: default avatarMats Wichmann <mats@linux.com>
      29144368
  29. 15 Nov, 2017 1 commit
  31. 14 Nov, 2017 1 commit
  33. 13 Oct, 2017 1 commit
  35. 05 Oct, 2017 1 commit
    • Mats Wichmann's avatar
      builds: stop defeating Variant dir Part 1/3 · bd555d18
      Mats Wichmann authored 
      In various places in the build scripts, steps are taken which defeat the
intent of using a variant dir: a distinct tree where building takes place.
Mostly this works as expected, but in places where the scripts call
Python facilities directly to figure paths out, scons does not have
the ability to "know" the paths and do the internal substitutions if
VariantDir is in effect.

There is a bug report (IOT-645) which claims this "build in the source
dir" behavior inhibits multiple builds of different targets at the same
time on one machine/instance, although that bug is focused on extlibs
which is its own story, builds there are only initiated by scons passing
control to some other builder (make, etc.) so harder to solve.

Part one of this patch series is fixing resource/csdk/connectivity.

The main type of thing which causes the issue is:

    src_dir = os.path.abspath(os.curdir)

This absolute path (which scons has no ability to adjust to use the
variant dir) is typically joined with source file names in subdirectories
when the builder will not be invoked in that directory. Replacing that
model, source files are now added as File objects (instead of simple
path strings), which leaves scons in full knowlege of the file and how
to find it. It's possible a plain filename string would be good enough;
scons is aware of the location it's in when running a given script.

A challenge was in the resource/csdk/connectivity/src/*adapter build
scripts: these invoke a target-specific subsidiary script to add source
files particular to the target (tizen, android, etc.) - but not all
possible build tergets have a script for each adapter.  So the scripts
checked for the script using os.path.exists() using an absolute path as
noted above, as it must since the Python module does not know scons path
tools, but then when calling it using the same path, the context is wrong
and the added sources and thus their derived object dependencies were
relative to the source tree, not the the variant dir. Again using a File
object, it is possible to extract both a regular (variant-adjustable)
path and a srcdir-relative path, the latter used for the check by
os.path.exists.

With this change, of the original 81 non-extlibs and non-libcoap builds
not happening in variant dir, there are only four remaining (though note
counts are build-dependent and this only refers to Linux x86_64 with the
options I used). Those four will be the subject of part 2/3.  (Part 3/3
is already merged to master and fixed the ones coming from bridging/):

Preparing target resource/c_common/oic_malloc/src/oic_malloc.o...
Preparing target resource/csdk/logger/src/logger.o...
Preparing target resource/c_common/oic_string/src/oic_string.o...
Preparing target resource/src/OCRepresentation.o...

While working on this, a few missed list-assignment reformattings were
snuck in, these should clearly be seen to be zero-impact.

Additionally, in a few places when a comparison is done against a list
which will be used as if it were immutable, like:

    if foo in ['linux', 'tizen']:

it was actually changed to be immutable, i.e. [] changed to tuple ().

Some old debugging prints announcing when a script is being scanned were
also dropped.

This change is independent of the others in the series.

Bug: https://jira.iotivity.org/browse/IOT-645
Change-Id: I54ba8c6613bcfefb6dba64687e9f1a0e72327a41
Signed-off-by: default avatarMats Wichmann <mats@linux.com>
      bd555d18
  37. 19 Sep, 2017 1 commit
  39. 14 Sep, 2017 1 commit
    • saurabh.s9's avatar
      Security error notification engine · ad1f7db6
      saurabh.s9 authored 
      Purpose:
Errors happens during OCDoResource calls should be returned to app layer

Previously, session errors (handshake failed) didn't returned properly to app layer
and this cause side effects (CA retransmission works in cases when it should not)

Current state:
1. Source code builds ok
2. Secure stack samples (UDP/TCP) works well (both positive/negative cases)
3. Provisioning (OTM, 20th menu item) works well for following:
   a. justworks    positive UDP/TCP, negative UDP case
   b. mfg          positive UDP/TCP, negative UDP case
   c. mv_justworks positive UDP/TCP, negative UDP case
   d. randompin    positive UDP/TCP, negative UDP case
4. OTM in provisioning via TCP - negative case - should work properly after fix IOT-2454

How to test:
1. Positive case - just test samples (f.e secure stack samples) & provisioning with all servers
2. Negative case - add following code which artificially breaks handshake (to ca_adapter_net_ssl.c)
   if (peer->ssl.state == MBEDTLS_SSL_CERTIFICATE_REQUEST)
   {
       ret = MBEDTLS_SSL_ALERT_MSG_INTERNAL_ERROR;
   }
   And again test all samples and provisioning with all servers.
   As result - you should see an error returned to app immidiately (without timeouts, etc)
   and there should be no CA retransmission attempts (UDP case)

Change-Id: Ia1fe1c7c58f9e40040a0be5e7e83abbc66f80bfe
Signed-off-by: default avatarAndrii Shtompel <a.shtompel@samsung.com>
Signed-off-by: default avatarsaurabh.s9 <saurabh.s9@samsung.com>
      ad1f7db6
  41. 29 Aug, 2017 1 commit
  43. 14 Aug, 2017 1 commit
  45. 12 Aug, 2017 1 commit
  47. 27 Jun, 2017 1 commit
  49. 20 Jun, 2017 1 commit
  51. 18 Jun, 2017 1 commit
  53. 17 Jun, 2017 1 commit
  55. 16 Jun, 2017 1 commit
  57. 15 Jun, 2017 1 commit
  59. 14 Jun, 2017 1 commit
  61. 12 Jun, 2017 1 commit
  63. 08 Jun, 2017 1 commit
  65. 24 May, 2017 1 commit
  67. 23 May, 2017 1 commit
  69. 22 May, 2017 1 commit
  71. 19 May, 2017 1 commit
  73. 15 May, 2017 2 commits