Secure connections

[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.

[TomNB]

What are the task priorities of the touch screen interface vs the task where the negotiation takes place?

[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)

[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
      }
    }
  }
}

[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?

[SeeCwriter]

That would require a major rewrite of the firmware. Not happening any time soon.

[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.

[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?