SSL, MFDeploy, Memory leaks, Fez Spider, and general networking

I need to get SSL to work with the Fez Spider, and have spent at least about 60 hours researching just the SSL portion, and have some questions that I just can’t seem to find the answers for. I’m not scared to keep digging, as I was able to find a workaround for the GIF bug that allows me to use transparencies, but just looking to be pointed in the right direction.

  1. I am acutely aware of the memory leak with the SSL portion of the framework. The first reference to the bug that I’ve been able to locate is with the 4.2 framework. Did it work prior to that, as between Microsoft providing an example, and another example showing up in the 2nd edition of "expert .net micro framework’, I am wondering if I can go back to an earlier framework?

  2. The memory leak at its simplest form occurs when I create the SslStream, and then release it. Can I create a SslStream, and just not release it, but use it for multiple transactions? Will I still loose the memory, as I’ve been able to keep a stream open, and send out data with an acknowledgement from the server on the other end, but the server doesn’t get the data at the application level (although I also don’t loose the memory). After reading thru the source, I discovered that when creating a webrequest, it looks to see if a destination socket is open, and if it is then it uses it. I then sent out a successful post webrequest, but seem to use the memory. I know it has to be using the established socket / stream, because I do not provide the webrequest the certificate again. So the root question, is if I manually assemble a byte array, and send it out the established SslStream, will I loose the memory?, As that is a task in of itself…

  3. Is there any way to call update SSL seed without using MFDeploy. It seems like everytime I have a major, um crash for lack of a better term, using an improperly formatted message to the SslServer on the remote end, I have to update the Seed.

  4. When I first initialize the network, the first thing I do is a debug.print the network addresses associated. What I have noticed is that there is a tendency at times for it to remember the addresses between builds. I’ve actually had it display addresses that haven’t been in the source code for at least two deploy’s, then straighten out as the network comes up, (or I do something stupid like forget to update the default Gateway). This tells me, it has to be writing these addresses to Non-Volatile Memory. What else is being written and saved, as I suspect its in the same area the Ssl seed is being saved? Incidentally, they all reset to 0’s after one of those major ‘crashes’.

  5. What is the difference between using the J11D module, and the getallinterfaces(0) to start the network interface. I’m slowly starting to get a feeling for the flow of this, but is there a general guideline somewhere on when to use which library, as I’ve found some of the functionality tends to get repeated. I’ve also noticed there is a difference between the libraries on what gets written to the non-volatile memory, and the length of time it takes for items to initialize.

  6. After one of those major crashes, I can still deploy assemblies to the device, but it won’t reboot on it’s own, I have to manually reset it. If I enable the watchdog timer, will it reset the device in this inconsistent state?

Any help on these would be appreciated, as its getting to the point that when I do searches, I just end up re-reading the same information over & over… (although I do keep learning)…

@ michaelb -

  1. I’m not sure when the leak was introduced.

  2. has some information on the leak, when we last looked into it, it occurred when sslStream.AuthenticateAsClient was called. If you are not opening and closing connections often the leak of a few hundred bytes a time should be manageable.

  3. We do not offer a way to update the seed without MFDeploy or FEZ Config at this time.

  4. The network configuration is saved to the configuration are in flash, as is the ssl seed.

  5. The J11D module performs additional initialization in our firmware. Using GetAllInterfaces on its own is not enough. We actually wrap the value returned by that call in our network interface objects. It’s exposed as the NetworkInterface property on the BaseInterface class, which EthernetJ11D derives from.

  6. The watchdog should reset the device.


My device constantly publishes information to the Azure IoT over HTTPS, and badly leaks memory - every requests leaks around 30000 bytes. The frequency of such requests is pretty high, once every 10 seconds, and pretty often the device just hangs as it’s out of memory. I am running using 2016 R1 SDK on Cobra II (couldn’t use SSL on 2015 SDK, even with SSL seed update). Are there any plans to fix this SSL leak? Or should I start considering moving away from GHI products?

Some extra information:
[ul]leak happens only when WebRequest.GetRequestStream() or GetResponseStreams() are called.[/ul]
[ul]leak happens with any HTTPS web site that do not require any authentication - try testing with[/ul]


@ vigen1980 - Unfortunately the SSL leak in question is in Microsoft’s code, not ours. So we are waiting on them for a fix. tracks the issue.

One possible, though unideal, work around until it is fixed is to reboot the device every so often based on the rate of your memory exhaustion.

So basically means that it is never going to be fixed in NetMF 4.3…

@ networkfusion - I am curious to know what would Microsoft’s opinion be on this topic. I will try to ping somebody.

We might have the fix for the memory leak