Reduce RAM consumption so all tests can still be built when using
CMSIS/RTX5. Also reduce clutter by removing the per target stack size
defines in the tests.
lwip now uses mbed client random library under common pal when available.
Ported lwip reference TCP initial sequence number handling to mbed-os
lwip stack. Handling is based on RFC 6528.
mbed_lwip_set_mac_address calls mbed_mac_address to get hwaddr
from device, but device may not be accessible until it is powered
up and initialized.
This patch delays mbed_lwip_set_mac_address call until device is
ready.
Signed-off-by: Tony Wu <tonywu@realtek.com>
Define tcpip-thread-stacksize and default-thread-stacksize in
lwip's mbed_lib.json, and use them accordingly in lwipopts.h.
Signed-off-by: Tony Wu <tonywu@realtek.com>
Originally the ethernet ISR would be linked in to all mbed-os based
firmware because it was named ENET_IRQHandler() so that it would be
automatically placed in the FLASH image's interrupt vector table. This
meant that programs which made no use of the lwIP stack still pulled in
this ISR.
This commit changes the name of the routine so that the ISR isn't
automatically placed in the interrupt vector table at link time but is
instead dynamically placed in the interrupt vector table at runtime
when the lwIP stack is initialized. Now the ethernet ISR is only linked
in when it is actually needed.
Example arm-none-eabi-size output for a simple LED blinking program
showing the before and after size results:
text data bss dec hex filename
13208 148 7784 21140 5294 LPC1768/HelloWorld.elf
text data bss dec hex filename
12700 148 7468 20316 4f5c LPC1768/HelloWorld.elf
From opt.h:
IP_SOF_BROADCAST_RECV (requires IP_SOF_BROADCAST=1) enable the broadcast
filter on recv operations.
The IP_SOF_BROADCAST_RECV option does not enable or disable recieving
broadcast packets, it only enables a software filter.
mbed_lwip_socket_recv() takes one netbuf at a time from the netconn API,
and it holds a partially-read netbuf if necessary in order to present as
a stream for TCP.
This held netbuf was not being freed when the socket was closed.
Sometimes when under heavy load, the CI machines can take a significant
amount of time to bring up a python process (~10s). The timeouts for
the network tests were chosen without much thought, and didn't leave
much room for this sort of delay.
This patch brings up timeouts for ntetwork tests 20s -> 60s
The speed of packets on the local network exceeds even the speed of
the ethernet hardware on some of the less powerful devices. Adding
a small delay which can be expected from a real DTLS handshake prevents
this condition from occuring.
This commit reduces the thread stack from 2k to 1k for each thread in
the parallel network tests. This allows the test to run on more
constrained devices (like the LPC1768).
*_packet_pressure_parallel tests are useful for checking for synchronization
errors, but push the practical limitations of the network stack. Failing
these tests is not unreasonable.
*_packet_pressure tests are a little bit less unreasonable, but also
push the practical limitations of the network stack. Hopefully these
will become stable in the near future.
Generalized handling of dns servers when brought up with both ipv4 and
ipv6 addresses. Falls back to google dns servers if not dns server is
found through dhcp.
Also added support for the `add_dns_server` method to lwip to support
custom servers.
Despite being able to buffer an arbitrary stream of data,
TCP send is still limited by the available buffer space in the
network stack. Errors from TCP send are perfectly reasonable
and should be handled by reducing the buffer that is attempted.
These tests could adopt the dynamically sized buffers used for the
packet-pressure tests, however throughput is not an important feature
of these tests.
Printing out dropped packets caused significantly more overhead in the
parallel tests due to increased noise on the network. This noise would
push the tests past their provided timeouts.
Dynamic buffers gives the network stack the maximum throughput while
still supporting smaller devices. This should expose the largest number
of issues across differently sized platforms.
Additionally, restructured the UDP tests to avoid unintentionally flooding
the recieving side with bad data after failed packets.
Also, added a bit more documentation
A larger buffer gives the network stack the best options for maximizing
throughput. However, the initial buffer size did not fit on small
targets. Resized 8192 -> 1024.
Added test for the pattern of packets used during the DTLS
handshake. This pattern (5x ~300 byte packets) has been very
problematic for new network interfaces.
Attempt to maximize the devices bandwidth with an exponentially growing
transaction of random sequences. Also prints the time taken and bandwidth
reached during the tests.
condition posix error mbed error
good host, closed port ECONNREFUSED NSAPI_ERROR_NO_CONNECTION
bad host EHOSTUNREACH NSAPI_ERROR_NO_CONNECTION
bad network ENETUNREACH NSAPI_ERROR_NO_CONNECTION
cd60f73 Merge branch 'mbed-os-lwip-rc2-maint' into mbed-os-lwip-rc2-maint-prefixed
3a50479 fixed bug #49676 (Possible endless loop when parsing dhcp options) & added unit test for that
git-subtree-dir: features/FEATURE_LWIP/lwip-interface/lwip
git-subtree-split: cd60f73f110829e00df46593fea5db26bcfb1662
Previously, exhausting hardware buffers would begin blocking the lwip
thread. This patch changes the emac layer to simply drop ethernet
frames, leaving recovery up to a higher level protocol.
This is consistent with the behaviour of the emac layer when unable
to allocate dynamic memory.
- cc.h@57,1: "BYTE_ORDER" redefined
- lwip_inet_chksum.c@560,44: passing argument 1 of 'thumb2_checksum'
discards 'const' qualifier from pointer target type
- lwip_pbuf.c@1172,9: variable 'err' set but not used
- SocketAddress.cpp@293,1: control reaches end of non-void function
This was actually several bugs colluding together.
1. Confusion on the buffer-semaphore paradigm used led to misuse of the
tx semaphore and potential for odd behaviour.
2. Equality tests on tx_consume_index and tx_produce_index did not
handle overflow correctly. This would allow tx_consume_index to catch
up to tx_produce_index and trick the k64f_rx_reclaim function into
forgetting about a whole buffer of pbufs.
3. On top of all of that, the ENET_BUFFDESCRIPTOR_TX_READ_MASK was not
correctly read immediately after being set due to either a compiler
optimization or hardware delays. This caused k64f_low_level_output
to eagerly overrun existing buff-descriptors before they had been
completely sent. Adopting the counting-semaphore paradigm for 1 avoided
this concern.
As pointed out by @infinnovation, the overflow only occurs in the rare
case that the 120MHz CPU can actually generate packets faster than the
ENET hardware can transmit on a 100Mbps link.