* 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.
- Implicit MBR still allowed during mount
- maintains storage compatibility
- Not needed
- MBR utility is not exposed through the FAT filesystem,
so the only used partition was always the first. Omitting
the MBR is functionally equivalent
- Saves a few blocks on storage for MBR + offset
for FAT alignment
- Duplicated with MBRBlockDevice
- The implicit MBR actually prevents nesting a FAT filesystem
in the MBRBlockDevice
Thread device needs to wait for connectivity:
-routers will create new network and get local connectivity
-end device will get connectivity once attached to existing network
-devices without network settings gets connectivity once
commissioned and attached to network
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.
Hasnain Virk
Kevin Bracey
Sam Grove
Christopher Haster
Jimmy Brisson
Kari Severinkangas
Seppo Takalo
Arto Kinnunen
Yogesh Pande
Martin Kojtal
Michel Jaouen
Andrzej Puzdrowski
Bartek Szatkowski
adustm
jeromecoutant