Networking

[AdrianSoundy]

Description

This is the initial commit for the Networking stack. It includes the complete socket interface and Network debugger interface. The Network Debugger compiles but is not being included as it requires other CLR changes and to be started. (i.e. ComDirector.cpp included)

This code was ported over from NetMF with some types changed and some code rearranged. The network debugger was split out from main code into separate code file.

Currently the Network Information and Load/Save config have been commented out.
For the Network Information extra options need to be set in the LwipOpts.h to enable the NetInfo methods.

I have not looked at whats required for Load/Save config

I have added the networking to ESP32 and the STM32 targets ST_NUCLEO144_F746ZG and ST_STM32F769I_DISCOVERY. The STM32 targets build but run out of available flash. Link script needs to change to make more flash available.

The stack is initialized from the targetHAL.cpp nanoHAL_Initialize() method by calling the Network_Initialize();

A targetHAL_Network.cpp has been added to allow the individual initialization of the network stack(LWIP) and any other ethernet interface setup. This is called from Network stack instead of calling the LWIP init.

As the CLR runs as 1 thread it can not be just stopped using semaphores etc. All the networking uses a non block/polling method. The normal socket interface to LWIP requires threads to wait on semaphores. For the this reason the original changes to LWIP where ported over. The changes add a call to setting a CLR socket event when certain functions complete. The original code called the CLR methods EVENTSET method from withing the LWIP code, I changed this to call a callback which is set during the initialisation. See TargetHAL_Network. The reason for this was to allow the LWIP to be built separately and not have any requirement to include CLR headers.

The patched files have been moved to a separate LWIP directory under each target and included in the LWIP compile. The patches are very small so to to port anothe lwip should be straight forware( i.e v2.0.3 in latest Chibios )

ToDo list

Currently the System.Net is in the same place as other i.e targets\CMSIS-OS\ChibiOS\nanoCLR\System.Net and and targets\FreeRTOS\ESP32_DevKitC\nanoCLR\System.Net.
As this is a common Mangaed code interface it should be moved to a common location.

Look at optimising the Socket calls as the current structure has about 4 levels to have a rigid separation between CLR -> PAL -HAL -> Lwip. In most of these levels it just passes the parameters down to next level.

i.e SOCK_connect -> Socket_lwip::Connect -> HAL::Connect -> Lwip_socket::Connect -> Lwip_Connect()

We should be able to change this so reducing memory use and increasing performance.

Set up the LwipOpts.h to

• Enable the NetInfo methods
• The number of sockets need to match whats configured for Nanoframwork so needs to use same parameter( See SOCKETS_MAX_COUNT in targetHAL.h )

Esp32

• Change build to build from soure the Lwip library so the configuration can be changed easily and to include patches for LWIP files.

Managed code

I have gone down the path of keeping System.Net and not trying to include that functionality in the Windows.Networking.Sockets. It can be included later if that’s what wanted.
Windows.Networking.Sockets can depend on System.Net for its sockets interface.
So if someone wants to use existing code and it just uses System.net then porting over will be simpler. To use the UWP Windows.Networking.Sockets classes
like StreamSocket, StreamSocketListener and Datagram these can will all need an underlying socket interface so can just depend on Syste.Net.Socket.
There is no equivalent class for the NetworkInformation that exists NetMF as Microsoft.SPOT.NetworkInformation. This class is used for setting up the network interfaces and loading/saving configuration. The System.Net. NetworkInformation is very different to this class.
So at the moment I suggest we create a nanoFramework. NetworkInformation class with the same functionally as Microsoft.SPOT.NetworkInformation. This class will be needed to.

Security

The next big area is security. For anything useful as an IOT device the nanoFramework will need to support the latest security. It will need as a minimum to support the X509 Certificate management and the SSL/TLS socket stream.
We will need a way in the Visual Studio extension to deploy a certificate to a device. Although this could be done in an external application like before.
The ESP32 framework includes the open source MBedTLS which is an Apache licensed product unlike the latest Chbios which includes WolfSSL which is a GPL license and requires an extra license to be bought for commercial use. I suggest using mBedTLS for ChiBios and then we will have a common code based between ChiBios and Esp32.
The .NetMF used the Microsoft.SPOT.net.Security for this functionality which includes CertificateStore, SslStream and the X509Certificate. We can either use the same classes as Nanoframework.net.securty or look at splitting it out.
System.Net.Security for SSlStream
System.Security.Cryptography. X509Certificates for X509Certificate or X509Certificate2
Not sure if there is a equivalent class for CertificateStore.
Or are there UWP equivalent classes ?

How Has This Been Tested?

The testing was done by addng some extra code to the ESP32 target to allow it to connect to an Access point.

The the following where tested using Sysytem.Net and found to be working:-

Socket TCP connect
Socket TCP listen / Accept / Recv / Send
Socket UDP send Unicast

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

Signed-off-by: adriansoundy [email protected]

[nfbot]

Hi @AdrianSoundy,

I'm nanoFramework bot.
Thank you for your contribution!

A human will be reviewing it shortly. 😉

[ghost]

Awesome work !

[josesimoes]

Awesome work (as usual! ;) )! 👏 💯
I'm merging this PR into a new branch to keep the initial work here separated from the stable branch.