The function _eth_arch_low_level_input() is meant to pass data into
LWIP and to prepare the ethernet buffers to receive more data.
If the LWIP heap is empty and the call to pbuf_alloc() in
_eth_arch_low_level_input returns null, the ethernet receive buffers
are not updated to receive data. Because of this the ethernet RX
interrupt will not fire. Since the RX interrupt is the only thing that
triggers a call to _eth_arch_low_level_input(), the receive buffers
will never get cleared, and the device stops receiving data.
To prevent this from happening, this patch ensures that the function
_eth_arch_low_level_input() clears the receive buffers even if a new
pbuf for the data couldn't be allocated.
This issue can be reproduce by running the test
"features-feature_lwip-tests-mbedmicro-net-udp_echo_parallel"
and on the same machine running the below python script to flood the
device with UDP broadcast packets:
MY_IP = #ADD your local IP here
from socket import *
s = socket(AF_INET, SOCK_DGRAM)
s.bind((MY_IP, 1234))
s.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
s.setsockopt(SOL_SOCKET, SO_BROADCAST, 1)
for _ in range(1000):
s.sendto("test data", ('255.255.255.255', 1234))
print("Message sent")
This creates a macro for the UUID length used by Greentea. This cuts
down on the use of "magic numbers" in test cases that use
the GREENTEA_SETUP_UUID function.
This is a workaround for IAR's lack of flexibility with memory regions.
Otherwise these tests would use very little heap and be mostly global
allocations.
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.
Before, the UDP test was very strict on the number of packets it would
try to match before failing. Now it will keep trying for the whole test
to get enough passing packets. It also includes the test's UUID so you
can validate which packets are being received.
The dtls test already has the ability to retry upon a UDP failure.
However the sockets are currently configured to be blocking and to wait
forever. I added a timeout of 1.5 seconds in order the test to correctly
timeout.
Based on lwip_ethernetif.c skeleton file,
use init, receive and transfer
functionality of SMSC9220 Ethernet driver
for the lightweight IP stack.
Receive mechanism is interrupt driven.
HW buffer sizes:
Tx = 4608 bytes (MTU)
Rx = 10560 bytes
lwIP fine tuning:
mbed-os/features/FEATURE_LWIP/lwip-interface/lwip/src/include/lwip/opt.h
Change-Id: I0ea95650c65fb32cafb5c2d3dde11420c61dba66
Signed-off-by: Gabor Kertesz <gabor.kertesz@arm.com>
The semaphore xTXDCountSem had the count to match the number of
resources available, but was being used as a binary semaphore in a
loop to listen for events. This patch updates the logic to make use of
the resource count.
With RTX5 the OS traps with an error if the a semaphore is released
more times than its count with an error similar to
"Semaphore 10000e6c error -17". Because xTXDCountSem is being used
as a binary semaphore it triggered this trap. With this patch the
semaphore is no longer used as a binary semaphore and no longer traps.
External EMAC drivers are currently directly attaching to lwip_stack.c
via mbed_lwip_bringup et al. Restore the original prototypes to avoid
compatibility breakage.
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.
* state machine corrections
* adding various standard API methods
* Addition/revision/enhancement of the nsapi_ppp glue layer
* Turning off debug by default
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.
POSIX poll() provides a mechanism to attach a POLL_HUP event
if the modem or device hangs up on you. POLL_HUP and POLL_OUT are
mutually exclusive. We poll in the PPP_input() routine if the modem
hung up. If it did we stop the data consumption, close PPP and go back
to the driver for reserruction of AT parser and subsequent retries or
application specific actions.
This is achieved by attaching an interrupt to the DCD line of the modem.
When DCD line goes high (off), we have lost the carrier. So we record an
POLLHUP event using _poll_change().
In case of carrier lost, we would like to inform PPP data pump.
That involved setting up link status flag down semaphores.
mbed_lwip_bringup() and mbed_lwip_bringdown() had been Ethernet specific only.
We extend these routines to support PPP as well. Currently we support only one interface
at a time. However, future enhancement to multi interface support should be trivial.
mbed_ppp_init() is extended to take a function ptr.
ppp_lwip will call this callback upon a change in ppp link status.
in the beginning, the Ublox driver waits until the PPP link is established properly.
We introduce here mbed_trace to ppp_lwip shim layer.
If for some reason, FEATURE_COMMON_PAL is not included in the build,
dummies for trace functions are provided.
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.
This is a glue layer between LWIP PPP implementation and a device type FileHandle
stream. This enables an external interface which has a FileHandle, utilize LWIP network
stack via PPP, e.g., Cellular device, WiFi chips etc.
Its totally transparent to external device. Only thing this layer is interested in, is a
FileHandle. Similar is true for for the external device, it just hands over its stream to this
PPP layer and rest of the magic is done by this layer.
Sam Grove
Russ Butler
Martin Kojtal
Brian Daniels
Christopher Haster
gabker01
Mika Leppänen
Tony Wu
Yuguo Zou
Kevin Bracey
Hasnain Virk