CC3100: Getting SL_FS_ERR_NO_ENTRIES_AVAILABLE (-24) while creating TLS

Hi Akhi,

How many files do you have in the file system when this happens? I believe this error is related to not having storage blocks available.

Jesu

Hi,

I think 11, by checking the path as the suffix was 11. Also, what I saw that while creating the new TLS, new path is assigned and files are being written at new place which means old path and files are still there. Deleting tls does not delete the old files.

Could you help me understand why you are creating a new file every time you create a TCP/TLS socket? I don't think this is necessary and I believe this might be causing the file system error.

Jesu

Hi Jesu,

No, I am not creating each time new TLS. 

Actually, the scenario is this-

For HTTPS, I am using the only root CA and is working fine. (created only once)

For MQTT, for the first time itself, I have root CA, device cert, and device private key. When I am creating TLS for MQTT first time itself, in this, root CA is successfully written (checked twice). But when the execution goes to write a device cert file, I am getting this error (-24).

In this, the path was tls_net_sl1. For the same, root CA was written successfully but device cert was failing (-24).

Let me know about this.

Thanks

Please share your flashFile funtion implementation. I don't this is related to using MQTT vs HTTP. I think it has to do with how you are writing files. Previous support effort shows customers who get this error is because they run out of storage space.

Jesu

Hi Jesu,

I have not implemented this function directly as it is provided ti rtos 2.16.01.14 itself. 

static int flashFile(const char *path, const uint8_t *buffer, uint32_t len)
{
long ret;
long fileHandle;

if (!path || !buffer) {
return (-1);
}

ret = sl_FsOpen((unsigned char *)path,
FS_MODE_OPEN_CREATE(len, _FS_FILE_PUBLIC_WRITE), NULL,
&fileHandle);
if (ret == 0) {
ret = sl_FsWrite(fileHandle, 0, (unsigned char *)buffer, len);
}

sl_FsClose(fileHandle, NULL, NULL, 0);

return (ret);
}

static int flashFile(const char *path, const uint8_t *buffer, uint32_t len)
{
    long ret;
    long fileHandle;

    if (!path || !buffer) {
        return (-1);
    }

    ret = sl_FsOpen((unsigned char *)path,
            FS_MODE_OPEN_CREATE(len,  _FS_FILE_PUBLIC_WRITE), NULL,
            &fileHandle);
    if (ret == 0) {
        ret = sl_FsWrite(fileHandle, 0, (unsigned char *)buffer, len);
    }

    sl_FsClose(fileHandle, NULL, NULL, 0);

    return (ret); // it returns -24
}

It happens only in the case of the client certificate file, root ca is flashed successfully.

Also, in some devices, this issue comes after a certain no of TLS create the procedure. Though I am creating tls once only, but after rebooting the device, again TLS will be created. 

Thanks

Hello,

I think you are creating too many files. Please answer the following questions:

1. So TLS_create calls flashFile correct?
2. How many MQTT connections are you trying to make?
3. Does TLS_delete the files from the flashFile call? Is your application ever calling this? 
4. Are you using ethernet as well in your application?
5. Are you using your own TLS stack or the one built into the NWP?

If you are done with a socket you should make sure TLS_delete is getting called. I'm pretty sure your problem is related to how many file you are writing.

Jesu

Hi Jesu,

1. So TLS_create calls flashFile correct?

   Yes. Since I am using httpvli library, I just used TLS_create.

2. How many MQTT connections are you trying to make?

I am making 1 MQTT connection, 1 https connection, and 2 for FTPS (command and data connection)

3. Does TLS_delete the files from the flashFile call? Is your application ever calling this?

No, I don't think TLS_delete deletes the file. Here is the code for TLS_delete-

void TLS_delete(TLS_Handle *tls)
{
    TLS_SlContext *tlsHdl = (TLS_SlContext *) *tls;

    xfree(tlsHdl->caPath);
    xfree(tlsHdl->certPath);
    xfree(tlsHdl->keyPath);
    xfree(tlsHdl->dhkeyPath);
    xfree(tlsHdl);

    tls = NULL;
}

4. Are you using ethernet as well in your application?

Yes, using the same library. But in ethernet, everything is in heap memory so I am not facing this issue there. I am managing my heap memory very carefully.

5. Are you using your own TLS stack or the one built into the NWP?

No, I am using the TLS provided by NWP. Actually, this httpcli library uses NWP below it. 

Yes, I used to call TLS_delete but with that, I was facing an issue with the ethernet because of heap memory (fragmentation was happening). But now, I am creating the TLS for each one only 1 time after boot-up and using the same TLS again and again. 

In ethernet, everything is working fine on all devices. But in wifi, the issue varies with the device. In some devices, I am not even able to create the first MQTT TLS. And in some, this issue comes when I am trying to delete the TLS and creating again. 

I also think this is related to the file path not available. But I don't know how to clear up flash and make things available. 

In the TLS_create function, I read through the document that the parameters which we are passing will delete the already written file there and create a new one. This is something I am not getting. Id it is not deleting, then how to delete the files from the flash of cc3100?

Let me know as I am stuck here.

Thanks

Typically you should not have to write a file every time you create a TLS connection. Traditionally our customers use the Sl_SetSockOpt API to associate the certificates already in the file system for the secure socket. I'm not experienced with the TI NDK you are using but it appears it's functionality is to always try creating the file (flashFile) unless it already exist. 

I think what is happening in flashFile is sl_FsOpen is returning -24. Could you confirm it is this function specifically in flashFile that returns this error? Refer to this excerpt from the programmer's guide about sl_FsOpen:

This operation enables creation of a non-existing file. Upon creation request, the device
checks for available space on the serial flash. Failing to allocate space for the new file
generates an error. Additionally, creating an already existing file generates an error.

Do you call sl_FsOpen with the same exact parameters for MQTT every time? If you do it should not be trying to allocate space for a new file entry and you should be getting SL_FS_ERR_FILE_ALREADY_EXISTS error instead.

Jesu

Hi Jesu,

As ethernet is totally different, let's not talk about it. 

As I said, in wifi, in some devices, even when I am creating the first TLS for MQTT, I am getting this error. And, in my application code, I am creating TLS only one time that too after boot-up, but after boot-up, it will again create TLS. 

Yes, sl_FsOpen  is returning this error. I checked it.  As I said, I am getting this error even for the first time TLS creation for MQTT.

The excerpt which you mentioned above is a bit confusing because, even I create and delete the TLS for https multiple times, everything runs fine. I tried to delete and create TLS for https with exactly the same parameters (root ca) and it worked fine.

I can't think of anything specific to MQTT that would cause file related issues.

Are you creating new files anywhere else in your application before MQTT? Also, how many secure sockets are you using in the CC3100?

Keep in mind the flash contains the service pack, MCU image, configuration files, user files etc... Do you know how much of the flash you are using already?

Jesu

No, I am not creating anywhere else MQTT files. I am using 2 secure sockets at a time that is specified in the cc3100 document. 

Is there any way to know how much flash I am using? Because this issue comes in some devices, not in all.

Hi,

To be clear I'm asking if you are creating files anywhere else in your application for anything else? Not asking about files specific to MQTT. 

I don't think there is a way to check the file system content at runtime. You will have to use the "List File System" feature built into Uniflash.

Jesu

Yes. SSID file, https root ca file.

In some different device, I am getting the different issue.  After creating https root ca file and ssid file, I tried to create tls for mqtt (root ca, cert and key). At first it worked and then I deleted the tls and creating again and then while connecting, I was getting the error -458.

Everything was same, root ca, cert and private key. I debugged a bit more and found out this time the files were /ti_net_tls2/ca.der, cert.der and key.der. There was no error while flashing these files but the error was coming while connecting. 

I also tried to manually delete all the files by this-

I tried deleting all the files at path /ti_net_tlsx/ca.der, /ti_net_tlsx/cert.der and /ti_net_tlsx/key.der where x varies from 0 to 126. At some path I was getting success and at some, error -11. After that I tried again MQTT and first time I was able to connect and then I deleted the TLS and next time while connecting, I was getting -458 which is bad private key file.

Why is this so? I mean there is always some error while deleting and creating new tls in wifi even I deleted all the file manually?

Code for manually deleting all the certs file. I ignored the errors because I don't know where the file was actually flashed. 

	_u8 DeviceFilePath[] = "/ti_net_tls";
	_u8 *File[] = {"/ca.der", "/cert.der", "/key.der"};
	_i32 RetVal;
	_u32 Token = 0;
	char countPath;

	for(countPath = 0; countPath < 127; countPath++){
		_u8 DeviceFileName[30] ="";

		sprintf(DeviceFileName,"%s%d%s", DeviceFilePath, countPath, File[0]);
		RetVal = sl_FsDel(DeviceFileName, Token);
		if(RetVal != 0){
			logInt("**** Error is %d", "", RetVal);
			logInt("**** at path %d CA", "", countPath);
		}

		sprintf(DeviceFileName,"%s%d%s", DeviceFilePath, countPath, File[1]);
		RetVal = sl_FsDel(DeviceFileName, Token);
		if(RetVal != 0){
			logInt("**** Error is %d", "", RetVal);
			logInt("**** at path %d CERT", "", countPath);
		}

		sprintf(DeviceFileName,"%s%d%s", DeviceFilePath, countPath, File[2]);
		RetVal = sl_FsDel(DeviceFileName, Token);
		if(RetVal != 0){
			logInt("**** Error is %d", "", RetVal);
			logInt("**** at path %d KEY", "", countPath);
		}
	}

Hi,

For the -458 error, I noticed this customer reported very similar behavior to yours (he is using AWS as well). It turns out there was a problem with how we was creating private key file. Do you find this thread helpful?

Jesu

Hi Jesu,

Certs and keys are all correct as I am not creating them, AWS is creating them for me. Even let's assume it is faulty, then why I was able to connect in first time? The issue comes in second time only after deleting and creating new TLS. 

ALso, previous error, when I format the flash and re-flashed the service pack, the -24 error has gone now. This -458 is coming in a different device. 

Good point. Interesting that formatting the flash makes the original -24 error go away. My guess is that there was not enough space.

The new error you are getting could mean that the key file is missing or that it's not in the correct format. DER format is the correct format which I think you have by looking at your code. Have you verified that the private key in the file system matches the certificate? Since you can connect the first time it should be okay but maybe something causes it to change the second time. Check the state of the files after the second time and verify the key matches the cert. 

Jesu

Hi,

That -458 was because of code. My cert buffer was getting corrupted in 2nd time, I resolved that. 

And regarding that, -24, I tried to again and again delete and create TLS and once I am getting -24 error, I am manually deleting all the file and then again creating the TLS and it is working now. 

Code for manually deleting all the files, CA, cert and key file-

			_u8 DeviceFilePath[] = "/ti_net_tls";
			_u8 *File[] = {"/ca.der", "/cert.der", "/key.der"};
			_i32 RetVal;
			_u32 Token = 0;
			char countPath;

			for(countPath = 0; countPath < 127; countPath++){
				_u8 DeviceFileName[30] ="";

				sprintf(DeviceFileName,"%s%d%s", DeviceFilePath, countPath, File[0]);
				RetVal = sl_FsDel(DeviceFileName, Token);
				if(RetVal != 0){
					logInt("**** Error is %d", "", RetVal);
					logInt("**** at path %d CA", "", countPath);
				}

				sprintf(DeviceFileName,"%s%d%s", DeviceFilePath, countPath, File[1]);
				RetVal = sl_FsDel(DeviceFileName, Token);
				if(RetVal != 0){
					logInt("**** Error is %d", "", RetVal);
					logInt("**** at path %d CERT", "", countPath);
				}

				sprintf(DeviceFileName,"%s%d%s", DeviceFilePath, countPath, File[2]);
				RetVal = sl_FsDel(DeviceFileName, Token);
				if(RetVal != 0){
					logInt("**** Error is %d", "", RetVal);
					logInt("**** at path %d KEY", "", countPath);
				}
			}

This will delete all the files, CA, cert and key from directory 0 to 126. I am ignoring the errors because I don't know which path contains file and which does not. 

With this, everything is working fine. 

Thanks

Hi,

It's good that you are not having problems anymore but I am concerned about the flash endurance you will have. Do you expect to do this repeatedly in your application? Is flash endurance a concern for you? I don't know if you are doing this for a personal project or mass producing a product...

Jesu

Hi,

I know this is not a good solution. But this issue should not come in fresh devices. These are the devices that we use for testing too much. SO maybe that's the issue. Anyway, in one boot cycle, we are creating only 1 TLS. We are not deleting that.

What would you like to suggest and what is your main concern about flash endurance? Can you explain a bit more?