The procedure should be terminated whenever the server returns an error not equal
to ATTRIBUTE_NOT_FOUND. The block was effectivelly terminated but the
procedure was not. As a result the discovery was operating on already
freed memory.
In LoRa TX power value 0 means the maximum allowed TX power and values >0
are limiting the allowed TX power to lower.
tx_config was incorrectly checking the power level and causing the maximum
TX power to be always used. Lora gateway can request node to use lower TX
power with LinkAdrReq MAC command.
Paths such as the following were causing issues:
/tea/hottea/.
/tea/hottea/..
Unfortunately the existing structure for path lookup didn't make it very
easy to introduce proper handling in this case without duplicating the
entire skip logic for paths. So the lfs_dir_find function had to be
restructured a bit.
One odd side-effect of this is that now lfs_dir_find includes the
initial fetch operation. This kinda breaks the fetch -> op pattern of
the dir functions, but does come with a nice code size reduction.
* Updates driver library to v2.3.1 (2018q1) for bugfixes and convenience functions
* Provides library in correct format (2-byte wchar_t flag) for compiling with ARMCC (#6695 uncovered by #6577)
* Reverts to using a statically-allocated packet buffer since malloc is not thread-safe (and the asserts have been turned on)
As pointed out by davidefer, the lookahead pointer modular arithmetic
does not work around integer overflow when the pointer size is not a
multiple of the block count.
To avoid overflow problems, the easy solution is to stop trying to
work around integer overflows and keep the lookahead offset inside the
block device. To make this work, the ack was modified into a resetable
counter that is decremented every block allocation.
As a plus, quite a bit of the allocation logic ended up simplified.
One of the big simplifications in littlefs's implementation is the
complete lack of tracking free blocks, allowing operations to simply
drop blocks that are no longer in use.
However, this means the lookahead buffer can easily contain outdated
blocks that were previously deleted. This is usually fine, as littlefs
will rescan the storage if it can't find a free block in the lookahead
buffer, but after changes that caused littlefs to more conservatively
respect the alloc acks (e611cf5), any scanned blocks after an ack would
be incorrectly trusted.
The fix is to eagerly scan ahead in the lookahead when we allocate so
that alloc acks are better able to discredit old lookahead blocks. Since
usually alloc acks are tightly coupled to allocations of one or two blocks,
this allows littlefs to properly rescan every set of allocations.
This may still be a concern if there is a long series of worn out
blocks, but in the worst case littlefs will conservatively avoid using
blocks it's not sure about.
Found by davidefer
Compile: lwip_stack.c
In file included from ../features/FEATURE_LWIP/lwip-interface/lwip_stack.c:41:0:
../features/FEATURE_LWIP/lwip-interface/lwip_stack.c: In function 'mbed_lwip_bringup_2':
../features/FEATURE_LWIP/lwip-interface/ppp_lwip.h:58:44: warning: statement with no effect [-Wunused-value]
#define ppp_lwip_disconnect() ERR_IF
^
../features/FEATURE_LWIP/lwip-interface/lwip_stack.c:858:21: note: in expansion of macro 'ppp_lwip_disconnect'
ppp_lwip_disconnect();
^~~~~~~~~~~~~~~~~~~
../features/FEATURE_LWIP/lwip-interface/ppp_lwip.h:58:44: warning: statement with no effect [-Wunused-value]
#define ppp_lwip_disconnect() ERR_IF
^
../features/FEATURE_LWIP/lwip-interface/lwip_stack.c:875:21: note: in expansion of macro 'ppp_lwip_disconnect'
ppp_lwip_disconnect();
^~~~~~~~~~~~~~~~~~~
Contains one error fix:
IOTCLT-2469 CoAP UDP retransmission does not work for blocks after first one for requests (Eg. registration POST)
NOTE! These are internal changes required for cloud client. This has no direct relevance to any mbed-os functionality.
Bug was reported by @tpet93 and it was correctly diagnosed that channels
were not being set in the phy_params structure. This commit fixes the bug
and sets up channels correctly.
This is a fix for issue #6391
max_eirp and antenna_gain are floating point variables. Values of these
were incorrectly read from MIB as integer and therefore incorrect values
were set.
- Fixes error: IOTCLT-2539 Block wise messaging call-backs not working logically
- Allow TCP+TLS transport method to send larger messages without blockwising.
NOTE! These are internal changes required for cloud client. This has no direct relevance to any mbed-os functionality.
Glue code was inspecting lwIP's netconn "type", checking directly for
NETCONN_UDP and NETCONN_TCP.
Unfortunately the type byte has some flag bits like
"IPv6", which means the tests fail if it's an IPv6 socket. So, for
example, TCP socket options were rejected for IPv6.
Add the necessary NETCONNTYPE_GROUP macros to fix this.
Like most of the lfs_dir_t functions, lfs_dir_append is responsible for
updating the lfs_dir_t struct if the underlying directory block is
moved. This property makes handling worn out blocks much easier by
removing the amount of state that needs to be considered during a
directory update.
However, extending the dir chain is a bit of a corner case. It's not
changing the old block, but callers of lfs_dir_append do assume the
"entry" will reside in "dir" after lfs_dir_append completes.
This issue only occurs when creating files, since mkdir does not use
the entry after lfs_dir_append. Unfortunately, the tests against
extending the directory chain were all made using mkdir.
Found by schouleu