Page 1 of 1
Secure connections
Posted: Tue Apr 11, 2023 8:46 am
by SeeCwriter
One of our products has a touch screen interface, and when a browser attempts to make a secure connection, the display freezes for 20-30 seconds during the negotiation. Is there a way to minimize that freeze-up so an operator doesn't think the unit has crashed or something?
I'm using v2.9.5 with a MOD54415.
Re: Secure connections
Posted: Tue Apr 11, 2023 2:08 pm
by TomNB
What are the task priorities of the touch screen interface vs the task where the negotiation takes place?
Re: Secure connections
Posted: Tue Apr 11, 2023 3:25 pm
by SeeCwriter
The touch screen interface is part of usermain, which has a priority of 56. The touch screen has its own processor and the interface is rs232 at around 400k baud. There is no touch screen task. I assume TCP negotiation is priority 45, but may maybe secure TCP uses priority 43. We don't use WI-FI, PPP, or ENC tasks. These are priority defaults from constants.h:
Code: Select all
#define HTTP_PRIO (45)
#define PPP_PRIO (44)
#define SECURITY_TASK_PRIO (43)
#define WIFI_STATION_TASK_PRIO (42)
#define WIFI_TASK_PRIO (41)
#define ENC_TASK_PRIORITY (41)
#define TCP_PRIO (40)
#define IP_PRIO (39)
#define ETHER_SEND_PRIO (38)
Re: Secure connections
Posted: Wed Apr 12, 2023 10:17 am
by SeeCwriter
Is it plausible to created a new task at a higher priority than the HTTPs task that would detect a connection request, send a notification to the user via the display, then let HTTPs to run?
For Example:
Code: Select all
void HTTPs_Intercept(void * pd) //create task after StartHttps()
{
static fd_set reader;
static int httpsPort = 443;
while(true)
{
int listener = listen( INADDR_ANY, httpsPort ); // listening on port 443.
if ( listener < 0 ) continue;
FD_ZERO( &reader );
FD_SET( listener, &reader );
if ( select( FD_SETSIZE, &reader, NULL, NULL, 0 ) )
{
if( FD_ISSET( listener, &reader ) ) //data available on listener, meaning incoming tcp connetion request.
{
//...
// notify user front panel will be freeze for a bit
//...
close(listener); // must close for HttpsMain task.
OSTimeDly(TICKS_PER_SECOND*10); // let httpsMain task to run
}
}
}
}
Re: Secure connections
Posted: Thu Apr 13, 2023 6:10 am
by sulliwk06
Why not just move all of your code managing the display to a task with a higher priority so it doesn't have to freeze at all?
Re: Secure connections
Posted: Thu Apr 13, 2023 7:32 am
by SeeCwriter
That would require a major rewrite of the firmware. Not happening any time soon.
Re: Secure connections
Posted: Thu Apr 13, 2023 10:44 am
by sulliwk06
If you're able to write to the display from a higher priority task, then you can:
- Add a watchdog that is pet in your main task
- Create a high priority task to check how long it has been since you pet the watchdog
- If you haven't pet the watchdog recently enough then write a message on the display saying that it's busy.
This would cover any type of lockup, not just the secure connection.
Re: Secure connections
Posted: Fri Apr 14, 2023 12:48 pm
by SeeCwriter
Testing of the HTTPs_Intercept task above successfully intercepts a secure connection attempt every time (so far), as long as the task is launched after StartHTTPs(), even though the intercept task has a lower priority (usermain-2) than the HTTPS task. I would expect that if two tasks are pending for the same resource, that the higher priority task would get it first. Is this an artifact of uC/OS?