Network improvements

Network connections are a key feature for use case scenarios that require… connectivity. Nothing too surprising so far, right?

Because of this, being able to easily handle network connection and configurations is something that developers working on such projects value a lot.

Today we would like to present some improvements that have just been added to the .NET nanoFramework network API and features list.

Device Certificate storage

It is now possible to store a device certificate in the device internal storage.

Device certificates can be used to authenticate a device when connecting to Azure IoT Hub, for example. Or, if the device is acting as a web server, to present itself as the valid device to connect to.

Up until now, to use device certificates, one would have to store them in a removable storage or if the certificate was in the application resources, it would require compiling a different application for each device.

To upload a device certificate, you need to go to Device Explorer in Visual Studio, open the Network Configuration dialog and move to the last tab.

We are looking into improving the nanoff CLI to allow automated uploading of these in production scenarios.

Use of A device certificate

The next question might be “how to use this device certificate?”

We have given some thought to this in order to make it as easy as possible, and not disruptive at all.

Because the device certificate is usually a secret, we would not want to expose it unnecessarily. Adding to this and because the storage of the certificate can be in a secure location (depending on the target), it had to be handled at the lowest possible level.

With all these constrains and not wanting to change the well-known APIs like AuthenticateAsClient(…) and AuthenticateAsServer(…) the choice was to add a new property to the SslStream class: UseStoredDeviceCertificate.

When this is set to true, the magic happens at the lowest possible level, deep in the network layer at the firmware. How? When the SslStream is setting up the authentication step, it will try to retrieve the device certificate stored and use it.

Note that “try” is used in the sentence above. The code will really attempt to retrieve the certificate from the device storage and use it. If it is not there, it will continue as if no certificate was provided and whatever the outcome is, it will be handled by the application.

It is worth noting that setting this new property and parsing a certificate in any of the API calls above, will have the effect that the certificate parsed in the parameter will be ignored and the one stored internally will be used. This is valid for both server and client.

Improved information about network availability

Currently, in order to know if there is an active network connection, the options available by our API were limited to subscribing to the NetworkAvailabilityChanged event or checking if there was an IP address assigned to the network interface.

The event is nice to have during the application execution but is not that useful at boot time because, for most devices and network connections, the network connection will become available almost instantaneously and, when it fires the event, the application may not have had time yet to setup the event handler, so it goes unnoticed.

The System.Net.NetworkInformation namespace in full .NET has an API to help with this: NetworkInterface.GetIsNetworkAvailable(). Now we have it too!
Oh yes: to know if network is available at any time, it is a simple matter of calling this method. Convenient, isn’t it?

This call will return true if there is a network connection available on any of the network interfaces in the system. Considering that the vast majority of .NET nanoFramework devices and applications has (or uses) a single network interface, this means that calling it will be all that is needed to know if the device has an active network connection or not!

Easy access to device IP address

Another pain point was the ease of access to the device IP address. With what was available, in order to find out the current IP address of the device, one would have to go the usual (and lengthy) act of: 1) grab the network interfaces collection 2) loop through them to access the IP address 3) extract the IP address. Works fine, but I think we are all in agreement that it could be easier…

So, again, and looking at the full .NET API, there is a method to help with that too. That is IPGlobalProperties.GetUnicastAddresses(). Because we are the nanoFramework and we do not need all the fancy stuff that is there, we came up with a similar call that provides the IP addresses of all the network interfaces in the device: IPGlobalProperties_GetIPAddress(). Which, again, because most devices will have only one, will provide straightforward access to the IP address of the only network interface available.

Performance (and size) improvements

If there is a matter where there are (usually) no disagreements: that is performance. Everyone prefers that the application runs quicker and smoothly.

Now, in the process of adding all these new features, debugging them and all that, several code blocks that where begging for improvement where spotted. This resulted in a review and a complete rewrite of a couple of cases. In the end, a performance improvement on several subsidiary calls (like Parse() and ToString()) was accomplished along with a significant decrease of several hundred bytes in the size of the library code. All this without any penalty in the native code.

mbedTls updated to latest available version

And last, but not the least, mbedTls was updated to the latest available version (v2.26.0). Being a security related component, it is important to keep it updated for the obvious reasons. And here it is: the latest and greatest improvements and fixes are now available in .NET nanoFramework firmware.

Samples have been updated to reflect and benefit from the changes. The network helper class, in particular has been simplified because of these new APIs.

All in all, these are small but important improvements that will make life easier to everyone working with network. Enjoy it!

Network capabilities in nanoFramework: check!!

As they say: better late than never! This post is a belated announcement of networking capabilities being added to nanoFramework. Some of you may already have noticed that during last week networking capabilities were officially added to our development branch.

With this, nanoFramework has – definitely – reached a major milestone. I’m sure we are all in agreement that providing network connectivity is a must have for any decent framework out there that aims to compete in the IoT space.

A lot has already been accomplished and know that we are just getting started! 🙂
Let me guide you on a tour of what’s available today.

Managed class libraries

The Nuget packages nanoFramework.System.Net, nanoFramework.Networking.Sntp and Windows.Devices.WiFi include already a ton of methods that allow developers to accomplish a lot. Without trying to be exhaustive, one can find there: interface management, DNS services, SNTP service, Sockets, Secure Sockets, Cryptography and Wi-Fi network management (this one for ESP32 targets only).

Security

This is probably one of the paramount features that are requested when embedded developers ask about networking. Yes, we’ve made it 😎 (and we are very proud of it)!
Support for SSL v3.0, TLS 1.0, 1.1 and 1.2 is available right now!

Supported targets

We provide ready to burn images including network support for the following reference targets: ST NUCLEO144 F746ZG, ST STM32F769I DISCOVERY and (of course!) ESP32 DevKit C.

Sample projects

Some work has been done here too. There are available samples showing how to connect to a SSL server; using a client certificate and validating the server certificate; resolve an address by querying a DNS service; adjust the RTC from an SNTP server; scan Wi-Fi networks in range and a couple of others.

Last but, by far, not the least we are working closely with the AMQPNetLite project to add support for nanoFramework and, very soon, an official Nuget package with this library will be published. Feel free to give it a try now, just go ahead and fork our fork.
A PR is also imminent to Paolo Patierno MQTT library. Same goes with this one: feel free to give it a try and do so by forking our fork.

 

How cool is all this? And we are just getting started!! HTTP client and server, web sockets and others are queued up to add more network capabilities to nanoFramework.

What are you waiting for? Go get all this, connect your device and start coding your next networked project! 😉