Fix an issue where CellularContext::do_connect_with_retry() does not call NSAPI_STATUS_GLOBAL_UP callback and validate_ip_address() on successful connect after failed try in blocking mode.
Fix an issue where CellularContext::do_connect_with_retry() does not call NSAPI_STATUS_GLOBAL_UP callback on successful connect after failed try in blocking mode.
The functions smsc9220_receive_by_chunks and smsc9220_send_by_chunks are
supposed to implement receiving and sending packets by chunks. However,
the functions SMSC9220_EMAC::low_level_input and SMSC9220_EMAC::link_out,
which call them respectively, already require or assemble the full packet.
Also, smsc9220_receive_by_chunks doesn't implement the "chunks" part.
This commit renames the functions to smsc9220_receive_packet and
smsc9220_send_packet. The functions now do their operations by word
instead of by bytes. The functions SMSC9220_EMAC::low_level_input and
SMSC9220_EMAC::link_out already handle allocation, continuity and word
alignment of the packet buffer.
The function SMSC9220_EMAC::low_level_input should create a heap for the
packet equal to the size of the message (most of which are couple hundred
bytes). The current code uses maximum frame size (1522 bytes) for each
packet. This will cause the heap to quickly fill up. In fact, the default
memory size (lwip.mem-size) used for this heap is 1600 bytes. This means
that once you have one other packet allocated (extremely common), the
heap allocation will always fails.
Also, it is recommend to increase the default lwip.mem-size because that
amount is very small especially if you send or receive a few large packets
in the network. This is NOT done in current commit.
The Cordio stack uses a single CSRK. It can be used by a
malicious device to track the Mbed OS application if signed
writes are used.
Signed-off-by: Vincent Coubard <vincent.coubard@arm.com>
The commit will address the test failure of connectivity-netsocket-tests-tests-network-interface.
In the test, serial channel will break with the sequence: ESP8266Interface::connect() > disconnect() > connect()
In the first connect, both board's and ESP8266's serial flow control default to disabled, and then enabled.
In the second connect, board's serial flow control keeps enabled but ESP8266's resets to disabled, causing inconsistency between two ends.
The approach: Explicitly disable board's serial flow control on re-power or reset in (re-)connect
On interop test 1.2.2.4, Join Request retransmission is expected to be 6
s + worst case air transmission. This delay is to accommodate for
JoinAccept through RX2.
The `call_in` in process_reception_timeout of RX2-window adds 500 ms
delay between RX2 symbol-interrupt-timeout and the next join request
retransmission. This is an isolated change and only affect the
retransmission of Join Request.
Adding this delay improves the chance of succeeding test
1.2.2.4 (subset of 1.2.2)
Fixed issue on LoRaWANStack based on lorawan v1.0.2 specification page
24 line 25-27. The specification mentioned that that end-device shall
stop retransmission when receiving ANY downlink on RX1 or RX2 window.
- Removed conflicting behavior in
LoRaWANStack::post_process_tx_with_reception()
- Updated comment section of nb_trials at lorawan_data_structures.h
A bug was detected when the uint8_t SUBGRF_GetFskBandwidthRegValue( uint32_t bandwidth )
is called and the bandwith argument has a value of 0.
Comparing the code to the STMCubeWL 1.1 we can see that an if statement is missing to
address the condition where bandwith is equal to 0.
Added the if statement to the radio driver to account for this edge case.
Some LoRaWAN modem like SX1272 can receive downlink packets with RSSI level less than -127. So "int8_t" is not enough for store all possible RSSI values. For example, SX1272 has sensitivity at -137 dBm.
Problem was manifested in the file "SX1272_LoRaRadio.cpp" at SX1272_LoRaRadio::handle_dio0_irq() method.
When value of _rf_settings.lora_packet_handler.rssi_value calculated incorrect RSSI will be stored. Example case:
Value readen from register REG_LR_PKTSNRVALUE _rf_settings.lora_packet_handler.snr_value equals -47.
Value readen from register REG_LR_PKTRSSIVALUE equals 17.
RSSI_OFFSET equals "-139", snr equals "-11".
For case MODEM_LORA value calculated by formula:
_rf_settings.lora_packet_handler.rssi_value = RSSI_OFFSET + rssi + (rssi >> 4) + snr;
and result value will be "124" because of int8_t overflow so it's not correct value (too high).
Correct value must be:
-139 + 17 + (1) + (-11) = -132.
Another motivation: at all other places int16_t type used to store RSSI value.
As a default implementation is already provided by
NetworkStack, stub implementations in the child classes
are not required. Furthermore, they return unsupported for
all cases instead of redirecting to the non-control API,
which is plainly wrong.