openweave / openweave-core Goto Github PK

The addition of WoBLE unit tests break against LwIP with commit 04e3638. It is likely this test either needs to be re-strategized for LwIP or disabled for LwIP.

The link on the ./BUILDING-ESP32.md page entitled 'OpenWeave ESP32 demo project' points to the wrong project.

With the introduction of C++11 support in Weave when available on the target compiler, when using clang/LLVM, there are a lot of warnings about -Woverloaded-virtual and -Winconsistent-missing-override.

The -Woverloaded-virtual is arguably unhelpful noise since the code is correct and clear. However, in our class hierarchy, we have a smattering of __OVERRIDE annotations on some overrides but not others, making the -Winconsistent-missing-override an accurate warning. The code should either consistently apply __OVERRIDE or consistently remove and not use __OVERRIDE.

Add full IPv4 and IPv6 multicast join / leave and multicast loopback control support to the Inet layer.

Dear,
I am able to build Standalone Application on Ubuntu Platform.
Even I am about to run./configure command successfully.
But I get an Error when running 'make all' command.
Will you please help me to solve this error.
Giving link to error screenshot below.
https://goo.gl/8uBAUQ

Thanks for releasing this source code!

Just a note to say that the README says "Explore the OpenWeave Wiki on GitHub" but the wiki link is broken.

Is the Weave protocol documented anywhere?

Please create new versions of the Build guide as discussed. One should be for Standalone, one for anything else. These new guides will replace the outdated guide currently at openweave.io/guides/build.

The guides should be placed in /doc/guides once that directory is available.

from nest.com link to openweave.io ends in google.com

We have an existing changelog, but it's had only minimal updates:
https://github.com/openweave/openweave-core/blob/master/CHANGELOG

Since we don't have a formal release process with versioning and notes, we should reformat the changelog to be a bit more comprehensive, and use it for all substantial feature and dependency changes that should be highlighted for end users.

Taking inspiration from:
https://keepachangelog.com/en/1.0.0/
https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md

I can get it started with some of the recent updates made to the project.

There appears to be a segment fault in both the sender and receiver in the TCP portion of the Inet layer when running the Inet layer functional test built against LwIP when the sender attempts to, and fails, to connect to the receiver.

code coverage data drop from 73% to 53% for master code

Later Ubuntu releases do not come with a 'python' executable (i.e. python 2.7) installed by default. Building OpenWeave on such a system results in a failure while attempting to run the gen-oid-table.py script. Conveniently, the generated error message properly identifies that the python command was not found.

However, as a result of this failure, the ASN1OID.h file that is checked in as part of the openweave-core source tree is replaced with an empty file. Subsequently, any attempt to build OpenWeave, even after python 2.7 is installed, fails with the following error:

../../src/include/Weave/Support/ASN1.h:123:28: error: 'OID' has not been declared
ASN1_ERROR GetObjectId(OID& oid);

This must be corrected by reverting the ASN1OID.h file.

While testing some changes that caused EC point operations in TestECMath to fail I discovered that running "make -f Makefile-Standalone check" did not report a failure. This appears to be because the main() function in TestECMath.cpp does not report the failure back to the caller.

(This issue corresponds to WEAV-1881).

I'm getting the following compiler errors in IPEndPointBasis.cpp when I build for nRF5.

These seem to stem from the way LwIP is configured in this context:

• Multicast support is not enabled in LwIP. (I may enabled this later, but I expect it should build without it.)
• RawEndPoints are not enabled. (Not needed.)
• IPv4 is not enabled. (Not needed.)

./src/inet/IPEndPointBasis.cpp:199:17: note: #pragma message: 
Please enable LWIP_IPV6_MLD && LWIP_IPV6_ND && LWIP_IPV6 for IPv6 JoinMulticastGroup and LeaveMulticastGroup support.
 #pragma message "\n \
                 ^~~~~
 Please enable LWIP_IPV6_MLD && LWIP_IPV6_ND && LWIP_IPV6 for IPv6 JoinMulticastGroup and LeaveMulticastGroup support."
In file included from ./src/inet/IPEndPointBasis.cpp:45:0:
./src/inet/IPEndPointBasis.cpp: In member function 'INET_ERROR nl::Inet::IPEndPointBasis::SetMulticastLoopback(nl::Inet::IPVersion, bool)':
./src/inet/IPEndPointBasis.cpp:318:27: error: 'mRaw' was not declared in this scope
             raw_set_flags(mRaw, RAW_FLAGS_MULTICAST_LOOP);
                           ^
./third_party/lwip/repo/lwip/src/include/lwip/raw.h:121:58: note: in definition of macro 'raw_set_flags'
 #define          raw_set_flags(pcb, set_flags)     do { (pcb)->flags = (u8_t)((pcb)->flags |  (set_flags)); } while(0)
                                                          ^~~
./src/inet/IPEndPointBasis.cpp:325:29: error: 'mRaw' was not declared in this scope
             raw_clear_flags(mRaw, RAW_FLAGS_MULTICAST_LOOP);
                             ^
./third_party/lwip/repo/lwip/src/include/lwip/raw.h:122:58: note: in definition of macro 'raw_clear_flags'
 #define          raw_clear_flags(pcb, clr_flags)   do { (pcb)->flags = (u8_t)((pcb)->flags & ~(clr_flags)); } while(0)
                                                          ^~~
./src/inet/IPEndPointBasis.cpp: In member function 'INET_ERROR nl::Inet::IPEndPointBasis::JoinMulticastGroup(nl::Inet::InterfaceId, const nl::Inet::IPAddress&)':
./src/inet/IPEndPointBasis.cpp:375:79: error: 'mld6_joingroup_netif' was not declared in this scope
             lRetval = LwIPIPv6JoinLeaveMulticastGroup(aInterfaceId, aAddress, mld6_joingroup_netif);
                                                                               ^~~~~~~~~~~~~~~~~~~~
./src/inet/IPEndPointBasis.cpp:375:79: note: suggested alternative: 'udp_bind_netif'
             lRetval = LwIPIPv6JoinLeaveMulticastGroup(aInterfaceId, aAddress, mld6_joingroup_netif);
                                                                               ^~~~~~~~~~~~~~~~~~~~
                                                                               udp_bind_netif
./src/inet/IPEndPointBasis.cpp: In member function 'INET_ERROR nl::Inet::IPEndPointBasis::LeaveMulticastGroup(nl::Inet::InterfaceId, const nl::Inet::IPAddress&)':
./src/inet/IPEndPointBasis.cpp:408:10: error: 'kIPAddressType_IPv4' was not declared in this scope
     case kIPAddressType_IPv4:
          ^~~~~~~~~~~~~~~~~~~
./src/inet/IPEndPointBasis.cpp:408:10: note: suggested alternative: 'kIPAddressType_IPv6'
     case kIPAddressType_IPv4:
          ^~~~~~~~~~~~~~~~~~~
          kIPAddressType_IPv6
./src/inet/IPEndPointBasis.cpp:411:79: error: 'igmp_leavegroup_netif' was not declared in this scope
             lRetval = LwIPIPv4JoinLeaveMulticastGroup(aInterfaceId, aAddress, igmp_leavegroup_netif);
                                                                               ^~~~~~~~~~~~~~~~~~~~~
./src/inet/IPEndPointBasis.cpp:411:23: error: 'LwIPIPv4JoinLeaveMulticastGroup' was not declared in this scope
             lRetval = LwIPIPv4JoinLeaveMulticastGroup(aInterfaceId, aAddress, igmp_leavegroup_netif);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/inet/IPEndPointBasis.cpp:411:23: note: suggested alternative: 'LwIPIPv6JoinLeaveMulticastGroup'
             lRetval = LwIPIPv4JoinLeaveMulticastGroup(aInterfaceId, aAddress, igmp_leavegroup_netif);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                       LwIPIPv6JoinLeaveMulticastGroup
./src/inet/IPEndPointBasis.cpp:425:79: error: 'mld6_leavegroup_netif' was not declared in this scope
             lRetval = LwIPIPv6JoinLeaveMulticastGroup(aInterfaceId, aAddress, mld6_leavegroup_netif);
                                                                               ^~~~~~~~~~~~~~~~~~~~~
./src/inet/IPEndPointBasis.cpp: At global scope:
./src/inet/IPEndPointBasis.cpp:169:19: warning: 'INET_ERROR nl::Inet::LwIPIPv6JoinLeaveMulticastGroup(nl::Inet::InterfaceId, const nl::Inet::IPAddress&, err_t (*)(netif*, const ip6_addr_t*))' defined but not used [-Wunused-function]
 static INET_ERROR LwIPIPv6JoinLeaveMulticastGroup(InterfaceId aInterfaceId, const IPAddress &aAddress, err_t (*aMethod)(struct netif *, const LWIP_IPV6_ADDR_T *))
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There is an implicit, undocumented requirement of the Python module 'pyobjc' to run the Weave Device Manager on Mac OS X. Failure to meet this requirement results in this run time error:

% src/device-manager/python/weave-device-mgr
...
Traceback (most recent call last):
  File "src/device-manager/python/weave-device-mgr", line 96, in <module>
    from WeaveCoreBluetoothMgr import CoreBluetoothManager as BleManager
  File "/Users/gerickson/Source/github.com/openweave/openweave-core/src/device-manager/python/WeaveCoreBluetoothMgr.py", line 36, in <module>
    from Foundation import *
ImportError: No module named Foundation

This requirement should be, at minimum, be noted in documentation. Ideally, it would be codified in a requirements check in configure.

Going forward, let's put all guides and tutorials in the /doc folder. It will be structured similar to what we have on openweave.io for ease of translation to that site. Add a README with a brief explanation if necessary.

Background

A number of failures have been observed wherein the recipient of a Weave WRM message discards the message as a duplicate, despite the message having never been received. This situation arises when the sender of the message is having multiple simultaneous exchanges with the target node (or in the case of group keys, with a set of other nodes) and the initial transmission of the message is somehow lost.

In this situation, the rapid pace of the other communications causes the sender's message counter to advance to the point that the message id for the original message is now prior to the recipient's out-of-order message window. At this point, retransmissions of the original message are implicitly treated as duplicates and dropped by the recipient at the Weave layer. Once this situation occurs, the original message will never be successfully delivered, and recovery can only happen at the application layer.

Currently the Weave out-of-order message window is set to 16 messages. Testing has shown that this value is probably too small in at least two situations. First, when Secure reboots it attempts to reestablish communication with all Detects in parallel. As these are group key encrypted conversations, all message ids are vended from a common counter, causing the message ids to advance rapidly. Should one of these messages get lost, there is high probability that Detect will see a retransmission of the lost message as a duplicate.

Similarly, in cases where Secure is performing a rapid-fire BDX log upload to the service, it has been observed that a lost WDM message from the service to Secure will end up in the same situation. (See WEAV-2368).

Proposed Resolution

The propose resolution is to increase the message out-of-order window size to 64 messages. This will give the system greater head-room for handling lost messages in situations of rapid communication.

This change will have a RAM cost of at least 12 bytes per peer node and per session key, i.e. 12 * (WEAVE_CONFIG_MAX_PEER_NODES + WEAVE_CONFIG_MAX_SESSION_KEYS). There will also be some small increase in code side.

This cost will apply to all device types.

(This issue corresponds to WEAV-2369).

I am building on Ubuntu 18.0.4.
I ran into the same issues building on the Windows Subsystem for Linux, which btw, I generally ignored. I know you all do not really support it. Anyway, the error is basically that I'm missing OpenSSL which is not the case. I have installed libssl-dev. I also made sure to install Text::Template from cpan.

In file included from ../../src/include/Weave/Support/crypto/WeaveCrypto.h:88:0,
                 from ../../src/include/Weave/Support/crypto/HashAlgos.h:46,
                 from ../../src/include/Weave/Profiles/security/WeavePASE.h:42,
                 from ../../src/include/Weave/Core/WeaveSecurityMgr.h:36,
                 from ../../src/include/Weave/Core/WeaveCore.h:61,
                 from ../../src/include/Warm/Warm.h:80,
                 from /home/pacs/weave/openweave-core/src/warm/../../src/warm/WarmCore.cpp:26:
../../src/include/Weave/Support/crypto/WeaveRNG.h:33:2: error: #error "INVALID WEAVE CONFIG: OpenSSL RNG implementation enabled but OpenSSL not available (WEAVE_CONFIG_RNG_IMPLEMENTATION_OPENSSL == 1 && WEAVE_WITH_OPENSSL == 0)."
 #error "INVALID WEAVE CONFIG: OpenSSL RNG implementation enabled but OpenSSL not available (WEAVE_CONFIG_RNG_IMPLEMENTATION_OPENSSL == 1 && WEAVE_WITH_OPENSSL == 0)."
  ^~~~~
In file included from ../../src/include/Weave/Support/crypto/WeaveCrypto.h:89:0,
                 from ../../src/include/Weave/Support/crypto/HashAlgos.h:46,
                 from ../../src/include/Weave/Profiles/security/WeavePASE.h:42,
                 from ../../src/include/Weave/Core/WeaveSecurityMgr.h:36,
                 from ../../src/include/Weave/Core/WeaveCore.h:61,
                 from ../../src/include/Warm/Warm.h:80,
                 from /home/pacs/weave/openweave-core/src/warm/../../src/warm/WarmCore.cpp:26:
../../src/include/Weave/Support/crypto/AESBlockCipher.h:35:2: error: #error "INVALID WEAVE CONFIG: OpenSSL AES implementation enabled but OpenSSL not available (WEAVE_CONFIG_AES_IMPLEMENTATION_OPENSSL == 1 && WEAVE_WITH_OPENSSL == 0)."
 #error "INVALID WEAVE CONFIG: OpenSSL AES implementation enabled but OpenSSL not available (WEAVE_CONFIG_AES_IMPLEMENTATION_OPENSSL == 1 && WEAVE_WITH_OPENSSL == 0)."
  ^~~~~
In file included from ../../src/include/Weave/Profiles/security/WeavePASE.h:42:0,
                 from ../../src/include/Weave/Core/WeaveSecurityMgr.h:36,
                 from ../../src/include/Weave/Core/WeaveCore.h:61,
                 from ../../src/include/Warm/Warm.h:80,
                 from /home/pacs/weave/openweave-core/src/warm/../../src/warm/WarmCore.cpp:26:
../../src/include/Weave/Support/crypto/HashAlgos.h:49:2: error: #error "INVALID WEAVE CONFIG: OpenSSL hash implementation enabled but OpenSSL not available (WEAVE_CONFIG_HASH_IMPLEMENTATION_OPENSSL == 1 && WEAVE_WITH_OPENSSL == 0)."
 #error "INVALID WEAVE CONFIG: OpenSSL hash implementation enabled but OpenSSL not available (WEAVE_CONFIG_HASH_IMPLEMENTATION_OPENSSL == 1 && WEAVE_WITH_OPENSSL == 0)."
  ^~~~~
In file included from ../../src/include/Weave/Core/WeaveSecurityMgr.h:36:0,
                 from ../../src/include/Weave/Core/WeaveCore.h:61,
                 from ../../src/include/Warm/Warm.h:80,
                 from /home/pacs/weave/openweave-core/src/warm/../../src/warm/WarmCore.cpp:26:
../../src/include/Weave/Profiles/security/WeavePASE.h:47:2: error: #error "INVALID WEAVE CONFIG: PASE Config1 enabled but OpenSSL not available (WEAVE_CONFIG_SUPPORT_PASE_CONFIG1 == 1 && WEAVE_WITH_OPENSSL == 0)."
 #error "INVALID WEAVE CONFIG: PASE Config1 enabled but OpenSSL not available (WEAVE_CONFIG_SUPPORT_PASE_CONFIG1 == 1 && WEAVE_WITH_OPENSSL == 0)."
  ^~~~~
In file included from ../../src/include/Weave/Profiles/security/WeavePASE.h:51:0,
                 from ../../src/include/Weave/Core/WeaveSecurityMgr.h:36,
                 from ../../src/include/Weave/Core/WeaveCore.h:61,
                 from ../../src/include/Warm/Warm.h:80,
                 from /home/pacs/weave/openweave-core/src/warm/../../src/warm/WarmCore.cpp:26:
../../src/include/Weave/Support/crypto/EllipticCurve.h:36:2: error: #error "INVALID WEAVE CONFIG: OpenSSL ECC implementation enabled but OpenSSL not available (WEAVE_CONFIG_USE_OPENSSL_ECC == 1 && WEAVE_WITH_OPENSSL == 0)."
 #error "INVALID WEAVE CONFIG: OpenSSL ECC implementation enabled but OpenSSL not available (WEAVE_CONFIG_USE_OPENSSL_ECC == 1 && WEAVE_WITH_OPENSSL == 0)."

Also attaching the config.log which I read in another issue might be helpful as well.

config.log: https://pastebin.com/GwvZtAMX

In nrf5-app.mk, STD_DEFINES should not include SoC and board-specific defines, such as NRF52840_XXAA or BOARD_PCA10056. Rather, these should be set by the project Makefile in its DEFINES variable.

Dear,
Getting error when I am running make all command.
Also bin/ and lib/ folders are not generated.
lib/ contains Architecture-independent libraries. Does this means I can use these libraries for Embedded Arm Platform?

Previously, the OpenWeave Device Description profile was extended to support a Rendezvous WiFi ESSID Suffix field in a Weave Device Descriptor (see issue #142, commit 6fb3782). This issue is to add support for using the new field from Objective C++, via the existing NLWeaveDeviceDescriptor object.

The NLWeaveDeviceDescriptor object should be extended in a similar manner as was done for the Java object. In particular, a new BOOL method should be added which returns the value of the IsRendezvousWiFiESSIDSuffix flag. The application can then use this to determine whether the existing RendezvousWiFiESSIDSuffix contains the full SSID or just the SSID suffix.

In certain circumstances, the release of a WeaveConnection object by an application can result in an attempt to decrement the reference count of that object below zero, triggering an assert.

The scenarios arises as follows: a response message is received for an outstanding exchange over a Weave connection. As part of handling the response, the application releases its reference to the associated WeaveConnection object. The thread of control then returns to the WeaveExchangeManager DispatchMessage() method which releases the last reference to the ExchangeContext. This causes the ExchangeContext to release its reference to the WeaveConnection, which being the last such reference, results in the connecting being closed. During the course of closing the connection, a callback is made back to the same ExchangeContext to alert it of the connection’s closing. Code in this handler erroneously attempts to release the WeaveConnection object a second time, triggering the assert.

The fix is to re-order the clearing of the ShouldAutoReleaseConnection flag in the ExchangeContext code such that only one code path attempts release of the connection associated with the ExchangeContext.

All links on the Specifications page (https://openweave.io/reference/specifications) are broken. All lead to a "404, page not found" error.

Add support for the new Rendezvous WiFi ESSID Suffix field in a Weave Device Descriptor.

For products that support a WiFi soft access point, the Rendezvous WiFi ESSID Suffix field contains a string that will appear at the end the access point ESSID presented by device. This field is intended to be used by devices where the base portion of ESSID varies at runtime (e.g. where the base portion contains a user assigned device name).

The new Rendezvous WiFi ESSID Suffix field is mutually elusive with the existing Rendezvous WiFi ESSID field.

The work items necessary to implement this feature are:

• Extended the WeaveDeviceDescriptor class to accommodate the new field.
• Modify the encode / decode methods for device descriptors to handle the new field. This includes changing the Weave TLV encoder/decoder and the text-based encoder/decoder used for QR code strings.
• Update the WeaveDeviceDescriptor Java helper class.
• Update the NLWeaveDeviceDescriptor objective-C helper class.
• Add support for the new field to the weave-device-description command line tool.
• Extend existing unit tests to cover the above features.

Replace the WeaveEncodePrivateKey() function in KeyUtils.cpp with a call to EncodePrivateKey().

This JIRA captures the intent of a TODO in KeyUtils.cpp.

(This issue corresponds to WEAV-2149).

The TestDNSResolution unit test fails with a segmentation fault in udp_sendto() when built for LwIP.

#0  0x000000000047abee in udp_sendto (pcb=0x900, p=0x6dcac8 <ram_heap+8>, dst_ip=0x6dc260 <dns_servers>, dst_port=53)
    at /home/jay/projects/openweave-core/src/lwip/../../third_party/lwip/repo/lwip/src/core/udp.c:532
#1  0x000000000045f89d in dns_send (idx=1 '\001') at /home/jay/projects/openweave-core/src/lwip/../../third_party/lwip/repo/lwip/src/core/dns.c:886
#2  0x000000000046034e in dns_check_entry (i=1 '\001') at /home/jay/projects/openweave-core/src/lwip/../../third_party/lwip/repo/lwip/src/core/dns.c:1150
#3  0x0000000000460434 in dns_check_entries () at /home/jay/projects/openweave-core/src/lwip/../../third_party/lwip/repo/lwip/src/core/dns.c:1184
#4  0x000000000045eb4b in dns_tmr () at /home/jay/projects/openweave-core/src/lwip/../../third_party/lwip/repo/lwip/src/core/dns.c:424
#5  0x0000000000482b67 in cyclic_timer (arg=0x6c5da0 <lwip_cyclic_timers+96>)
    at /home/jay/projects/openweave-core/src/lwip/../../third_party/lwip/repo/lwip/src/core/timeouts.c:177
#6  0x0000000000482f9b in sys_check_timeouts () at /home/jay/projects/openweave-core/src/lwip/../../third_party/lwip/repo/lwip/src/core/timeouts.c:364
#7  0x000000000048307f in sys_timeouts_mbox_fetch (mbox=0x6dbbd0 <mbox>, msg=0x7ffff69dcec0)
    at /home/jay/projects/openweave-core/src/lwip/../../third_party/lwip/repo/lwip/src/core/timeouts.c:437
#8  0x000000000045df95 in tcpip_thread (arg=0x0) at /home/jay/projects/openweave-core/src/lwip/../../third_party/lwip/repo/lwip/src/api/tcpip.c:107
#9  0x00007ffff7bc4184 in start_thread (arg=0x7ffff69dd700) at pthread_create.c:312
#10 0x00007ffff71fe03d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

The root cause of the problem is unclear, but seems to be stem from a logic bug in dns_recv() which fails to reset the state of a dns_table_entry when no answer is received after trying all available DNS servers.

I tried running
make -f Makefile-Standalone
and it ran for a while and then ended with this error

Making all in warm
  CXX      ../../src/warm/libWarm_a-WarmCore.o
In file included from ../../src/include/InetLayer/TunEndPoint.h:59:0,
                 from ../../src/include/InetLayer/InetLayer.h:85,
                 from ../../src/include/BleLayer/BleLayer.h:67,
                 from ../../src/include/Weave/Core/WeaveCore.h:34,
                 from ../../src/include/Warm/Warm.h:80,
                 from /home/lmacvean/workarea/openweave-core/src/warm/../../src/warm/WarmCore.cpp:26:
/usr/include/linux/route.h:31:8: error: redefinition of ‘struct rtentry’
 struct rtentry {
        ^~~~~~~
In file included from ../../src/include/InetLayer/TunEndPoint.h:52:0,
                 from ../../src/include/InetLayer/InetLayer.h:85,
                 from ../../src/include/BleLayer/BleLayer.h:67,
                 from ../../src/include/Weave/Core/WeaveCore.h:34,
                 from ../../src/include/Warm/Warm.h:80,
                 from /home/lmacvean/workarea/openweave-core/src/warm/../../src/warm/WarmCore.cpp:26:
/usr/include/net/route.h:31:8: note: previous definition of ‘struct rtentry’
 struct rtentry
        ^~~~~~~
In file included from ../../src/include/InetLayer/TunEndPoint.h:63:0,
                 from ../../src/include/InetLayer/InetLayer.h:85,
                 from ../../src/include/BleLayer/BleLayer.h:67,
                 from ../../src/include/Weave/Core/WeaveCore.h:34,
                 from ../../src/include/Warm/Warm.h:80,
                 from /home/lmacvean/workarea/openweave-core/src/warm/../../src/warm/WarmCore.cpp:26:
/usr/include/linux/ipv6_route.h:43:8: error: redefinition of ‘struct in6_rtmsg’
 struct in6_rtmsg {
        ^~~~~~~~~
In file included from ../../src/include/InetLayer/TunEndPoint.h:52:0,
                 from ../../src/include/InetLayer/InetLayer.h:85,
                 from ../../src/include/BleLayer/BleLayer.h:67,
                 from ../../src/include/Weave/Core/WeaveCore.h:34,
                 from ../../src/include/Warm/Warm.h:80,
                 from /home/lmacvean/workarea/openweave-core/src/warm/../../src/warm/WarmCore.cpp:26:
/usr/include/net/route.h:57:8: note: previous definition of ‘struct in6_rtmsg’
 struct in6_rtmsg
        ^~~~~~~~~
make[4]: *** [Makefile:622: ../../src/warm/libWarm_a-WarmCore.o] Error 1
make[3]: *** [Makefile:578: all-recursive] Error 1
make[2]: *** [Makefile:655: all-recursive] Error 1
make[1]: *** [Makefile:580: all] Error 2
make: *** [Makefile-Standalone:380: do-build-x86_64-unknown-linux-gnu] Error 2

Dear,
I am referring to instructions given on BUILDING.md page.

I get error when I try to build Standalone application.

Error Description:
../../src/include/Weave/Support/crypto/WeaveRNG.h:33:2: error: #error "INVALID WEAVE CONFIG: OpenSSL RNG implementation enabled but OpenSSL not available (WEAVE_CONFIG_RNG_IMPLEMENTATION_OPENSSL == 1 && WEAVE_WITH_OPENSSL == 0)."
#error "INVALID WEAVE CONFIG: OpenSSL RNG implementation enabled but OpenSSL not available (WEAVE_CONFIG_RNG_IMPLEMENTATION_OPENSSL == 1 && WEAVE_WITH_OPENSSL == 0)."
^~~~~

I am using Ubuntu 18.

Screenshot of error: Please open the link: https://goo.gl/iPzw4e

One more suggestion: OpenWeave TAG on StackOverFlow is not active. No users are actively commenting on it. Please make it active.

Currently, LwIP-based network and service tests are not included in the continuous integration matrix, leaving a substantial amount of exposure in continuous integration.

In the context of the python adaptation of Weave, enable Weave logging to be bridged back into python code to support logging via standard python methods.

NOTE: Because the python adaptation employs a separate I/O thread, careful consideration will need to be taken when bridging log messages generated by the I/O thread back into the python runtime.

(This issue corresponds to WEAV-1135).

cat << EOF >~/.happy_conf.json
{
"weave_path": "$TRAVIS_BUILD_DIR/build/x86_64-unknown-linux-gnu/src/test-apps/"
"happy_log_path": "/tmp/happy_test_log/"
}

Standalone tunnel establishment should disable the platform-level border gateway configuration directly instead of relying on the restricted routing flag sent as part of the StatusReport in response to a TunnelOpen.

Dear,

How to integrate OpenWeave and OpenThread? Could you give me some advice or documentations?

Best Regard,
Kevin Zhu

It appears that commit 5316dfd somehow broke invocation of the Python weave-device-mgr, both in-situ and from an installation:

% src/device-manager/python/weave-device-mgr
/usr/local/lib/python2.7/site-packages/_WeaveDeviceMgr.so not exist
Could not find the WeaveDeviceMgr module!

The TestDNSResolution unit test fails with an assert in dns_exec_found_callback() (dns.c:976) complaining about an "invalid table index". This is due to a logic bug in the test expression.

This bug was introduced as part of the Nest-authored patch adding support for multiple response records (change 767e3f6 in old weave repo). A fix for this was submitted to nest-internal/tps/lwip (52c9c15c29) but not to openweave-core.

What platforms are supported? Would it be possible to run this together with OpenThread on a KW41Z node with a raspberry pi as borderrouter?

Dear, How to compile Openweave Project for Embedded Platform?

Any tutorial available on this?

I want to use this library on 32 bit Arm Processor.

How to create library file (.a extension) and use it in Embedded Projects?

Previously, all DNS testing was disabled when building for LwIP; however, this had the downside of precluding validating changes to DNS functionality.

Because of the way LwIP works, DNS testing for LwIP cannot work without a format test framework like "Happy" or some other manual networking configuration due to its need to talk to a TUN device and to bridge the hosts network interface.

For TestDNSResolution, we should probably:

• Build: Always
• Test:
  -- LwIP, w/o Happy: No
  -- LwIP, w/ Happy: Yes (Need Driver)
  -- Sockets, w/o Happy: Yes
  -- Sockets, w/ Happy: Yes

As with many Weave Happy functional tests, the functional test for the Inet layer is disabled when building Weave against LwIP, leaving a large continuous integration (CI) exposure gap.

Remove magic numbers, and explain the PREFERRED_ADDRESS assignment for LwIP-based tests

On Travis CI, in particular, there seems to be flakiness observed in the WDM mutual subscription tests, primarily on LwIP.

test_inet_01.py.log

When using 'Makefile-Standalone' or directly using 'configure', when build jobs is greater than one (1), the weave unit and functional tests seem to get both built and run multiple times (2x).

Add support for remotely rebooting a device via a Weave interaction.

A new message (DeviceReset) should be added to the DeviceControl profile to initiate a remote reboot of a device. A DeviceReset request message should have no payload, and its response should always be a StatusReport.

The existing DeviceControlServer class should be enhanced to decode and process the DeviceReset message. The processing of the message should be subject to standard device access controls using the existing server access control framework (WeaveServerDelegateBase::EnforceAccessControl()). Additionally, upon receiving a DeviceReset request, the DeviceControlServer should invoke a new virtual method the DeviceControlDelegate object (e.g. CanRemoteResetDevice()) to confirm the ability to reset the device. This method should allow device code to reject the reset request with an arbitrary status code.

If a reset request is allowed, code within the DeviceControlServer should take steps to ensure the response is received by the client before initiating the reset. Specifically:

• If the request was received over a Weave connection (TCP or WoBLE), the device should respond with a StatusReport containing the code DeviceControl:ResetSuccessCloseCon. It should then close the connection non-destructively (e.g. by using the Close() API, rather than Abort()). After this it should wait a short period of time (on the order of 500ms, compile-time configurable) before initiating the reboot.
• If the request was received over UDP, the device should respond with a StatusReport containing Common:Success. If using WRM over UDP, the device should wait for the WRM ACK for the StatusReport. After this, the device should wait a short period of time before initiating the reboot, as it does with TCP.

The DeviceControlServer should initiate the reset action by calling a new virtual method on the DeviceControlDelegate (e.g. ResetDevice()).

(This issue corresponds to WEAV-3179).

Dear,
I am getting Build Error:
libtool: Version mismatch error. This is libtool 2.4.2, but the
libtool: definition of this LT_INIT comes from libtool 2.4.6.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2
libtool: and run autoconf again.

Dear,

I follow the instructions on 'https://openweave.io/guides/build' Project Linking, after staging, there is not a /include directory under [openweave-output], there are /etc, /lib and /usr instead, could you confirm?

Best Regard,
Kevin Zhu

GitHub will be the source of truth for all OpenWeave guides and tutorials going forward, and content will later be synced to openweave.io.

Create a documentation style guide for OpenWeave contributors in order to keep consistent style and formatting for all doc content.

After merge PR #182
I did not see logs uploaded to my gcs bucket, but same code worked for my repo jenniexie/openweave-core
next step:

1. I will open bug to Travis-CI and ask them if any clue.
2. I get repo access to openweave/openweave-core, and start to test on branch of openweave/openweave-core and see if it works.