We currently set the lwIP pbuf pool size small - to 5 x 576-byte
buffers.
This is insufficient to hold a single DTLS handshake flight, so can
cause cloud client connections to fail. STM-based platforms are failing
handshake because of this. (K64F works because it doesn't use the pbuf
pool for reception, but lwIP does recommend drivers use the pbuf pool).
Not changing the default memory sizes here, as intended for a patch
release, but adding mbed configuration options to allow the numbers to
be adjusted for memory tuning in an application.
In a future minor revision, I would recommend increasing the default
PBUF_POOL_SIZE - we are well below lwIP's out-of-the-box default - and
offsetting by a reduction in MEM_SIZE for the drivers that don't use
PBUF_RAM.
Commit f602c936 incorrectly started defining LWIP_DEBUG as either 0 or
1.
lwipopts.h locally was changed to use #if, but all existing users
continued to use #ifdef. Therefore defining it to 0 was accidentally
enabling it for quite a few users.
This would have pulled in some unwanted lwIP code, and affected some
drivers, eg k64f_emac.c allocating an extra 2K of stack.
Correct lwipopts.h to either define it as 1 or leave it undefined, and
change the #if tests back to #ifdef, so all are consistent.
PPP is running close to the edge of its default thread stack size of 512 bytes. When it experiences an FCS error on the incoming data (for example. caused by character loss when the incoming serial rate is too high for it to process in time) it performs some additional work which overruns the thread's stack, hitting the OS "stack underflow" check. Increasing the PPP stack size to 768 bytes resolves this problem.
lwipopts_conf.h is used by target dependent Ethernet drivers for
configuring various parameters.
By default, Ethernet is enabled and in this case lwipopts_conf.h
will be included.
In case of PPP being enabled, it is desirable to not pull in any Ethernet
related code.
This matches the timeout used in linux:
https://linux.die.net/man/5/dhclient.conf
This resolves several issues noticed during testing when we
have a very large number of devices that try to get an IP address
around the same time.
For keep supporting external APIs with the same name (supposedly there are a larger
number of users of those APIs), BufferedSerial and ATParser are being renamed.
BufferedSerial becomes UARTSerial, will complement a future USBSerial etc.
ATParser becomes ATCmdParser.
* UARTSerial moves to /drivers
* APN_db.h is moved from platform to cellular/util/.
* Original CellularInterface is restored for backward compatability (again, supposedly there
are users of that).
* A new file, CellularBase is added which will now servce as the base class for all
upcoming drivers.
* Special restructuring for the driver has been undertaken. This makes a clear cut distinction
between an on-board or an off-board implementation.
- PPPCellularInterface is a generic network interface that works with a generic FileHandle
and PPP. A derived class is needed to pass that FileHandle.
- PPPCellularInterface provides some base functionality like network registration, AT setup,
PPP connection etc. Lower level job is delegated to the derived classes and various modem
specific APIs are provided which are supposed to be overridden.
- UARTCellularInterface is derived from PPPCellularInterface. It constructs a FileHandle and
passes it back to PPPCellularInterface as well as provides modem hangupf functionality.
In future we could proive a USBInterface that would derive from PPPCellularInterface and could
pass the FileHandle back.
- OnboardCellularInterface is derived from UARTCellularInterfae and provides hooks to
the target provided implementation of onbard_modem_api.h. An off-board modem, i.e, a modem on
a shield has to override the modem_init(), modem_power_up() etc as it cannot use
onboard_modem_api.h.
Some targets define MBEDTLS_md5_C in targets.json in order to force the system to use
external mbedtls instead of lwip internal crypt, i.e., polarssl.
LWIP's internal md5 mechanism is tied to PPP for some reason. In a previosly merged commit
an attempt was made to steal md5 functions by faking that PPP was turned on. However
that solution was broken in case of really turning on PPP functionality.
This commit fixes the breakage and also corrects the logic in case a target decides to use
external md5 implementation from mbedtls or otherwise (i.e, wants to stick to the internal
implementation).
GCC have not been capable enough to catch some linker errors which arose when
ethernet support for LWIP was disabled. Checks have been added to make sure that
unrefrenced code is not linked in.
nsapi_ppp glue layer is made more transparent to public cellular API. Storage of IP
addresses is removed. PPP layer already stores the addresses, so we pass the pointer back
to the upper layers.
If PPP is not used, we provide dummy functions.
Mainly reutilizing code from ublox C027 support lib.
As we are using external PDP context, i.e., an external IP stack,
we will pass username and password to underlying stack running PPP.
We only support CHAP as the authentication protocol.
Add configuration to control Ethernet, PPP and TCP support.
Replaces LWIP_TRANSPORT_ETHERNET/PPP defines formerly used by targets.
Ethernet and PPP can be enabled simultaneously.
DHCPv4 is now only enabled if IPv4 and Ethernet are both enabled - we
assume PPP uses IPCP for configuration.
PPP configuration adjusted to cope with LWIP 2.0 changes, and
optimised for RAM a little.
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.
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>
Veijo Pesonen
Kevin Bracey
Jimmy Brisson
Mika Leppänen
Rob Meades
Hasnain Virk
Christopher Haster
Sam Grove
Bartek Szatkowski
Tony Wu
Seth King
Colin Hogben
Colin Hogben
andreas.larsson