Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Created PPP interface and PPP service classes to netsocket #10974
Created PPP interface and PPP service classes to netsocket. This allows that both lwip and nanostack can use a common PPP service for cellular connectivity. Lwip PPP protocol is separated from lwip and moved under netsocket as an independent entity. PPP offers much similar interface for (onboard) network stack as the EMAC and L3IP. PPPInterface class has been created as similar helper class as the EMACInterface and L3IPInterface are.
The "nsapi_ppp.h" interface is kept same, and the implementation for it is in ppp service file "ppp_nsapi.cpp". Cellular classes using the "nsapi_ppp.h" interface should not need updates. Existing ppp configuration under lwip mbed_lib.json is still supported, although configuration under ppp service should be used instead.
Most major changes to internal structure of PPP were, to replace its interface to lwip netif with new one and to make PPP to use network stack's memory manager for memory allocations, instead of direct access to lwip memory buffers.
Pull request type
Add Cellular PPP connection support to Nanostack. Support is made by creating a common PPP service class that both lwIP and Nanostack can use for cellular connectivity.
Affected components are lwIP and Nanostack on board IP stacks, new netsocket PPP interface and PPP service class. Cellular network interface, cellular classes and "nsapi_ppp.h" interface are not modified. No changes are required from the users of the Cellular network interface to continue using the lwIP as the default IP stack.
To use the Nanostack IP stack with the Cellular network interface instead of the lwIP stack, cellular application configuration must be modified in following way:
Set the default stack to nanostack
Configure PPP to IPv6 only mode (Nanostack does not support IPv4)
kjbracey-arm left a comment
Architecturally, I'm extremely impressed. This pulls together a whole bunch of Mbed OS concepts that have been partially formed since 5.7 and 5.9, and extends them very elegantly to cover this generic PPP engine,
The whole set-up looks fantastic now, and
My only real concern is the forking out of the PPP core from lwip, and what the plan is to track any upstream lwIP PPP changes in future. Do we have the tooling to do that elegantly? I guess git subtree squash might still manage to handle the file renamings - it's just a merge, ultimately, and that can sometimes...?
Created PPP service class that encapsulates the PPP protocol. Class is similar to EMAC and L3IP classes with additional methods to read IP and DNS server addresses negotiation using PPP and to set PPP specific parameters (file handle for modem access etc.). PPP service can use on its own thread or in run in mbed os event Queue thread. Added ppp_nsapi.cpp module that implements the nsapi_ppp.h services. Added ppp_nsapi.cpp module that implements the nsapi_ppp.h services.
PPP service encapsulates the PPP protocol. PPP interface can be used as helper class to bind PPP protocol with network stack (similar to EMAC and L3IP interface). Added PPP interface to onboard network stack class.
Created (a new) PPP interface for PPP service. Removed lwip dependencies to PPP (memory allocations etc.). Moved PPP configuration options away from lwIP mbed_lib.json to new PPP service. For backwards compatibility, using the old options is also currently supported.
Created PPP interface for PPP service. Re-used the ethernet tasklet and PHY driver structure for PPP.
If PPP interface is the lwIP default interface, adds the PPP DNS servers to default DNS server storage. If PPP is not default interface, then adds DNS servers to interface specific storage.
Corrected PPP thread stack size for RZ_A1_EMAC, CYW943012P6EVB_01, CY8CPROTO_062_4343W, CY8CKIT_062_WIFI_BT and CY8CKIT_062S2_43012 that have special configuration for PPP thread size. Removed pppInterface() helper call from network interface. It causes binary compatibility break with precompiled network interface classes. Call is helper function to check network interface type in case it is unknown, and is not mandatory or used with PPP.