Is AutoUpdate (UDP) Safe?

[kackle123]

I have made a product based on the SB70LC and deployed dozens of these units afar. Most are behind various kinds of firewalls. Although I use AutoUpdate.exe on our LAN all the time, I have only used it once to update through a firewall, which was successful.

I read that TcpUdate.exe is preferred when going through firewalls. Why is this? Can the UDP updates corrupt the SB70LCs? I looked at the source code for AutoUpdate.exe and it seems only a SUM algorithm is utilized for checking integrity - am I correct?

[dciliske]

The reason that TCPUpdate is preferred for remote operation is that: a) a lot of firewall will reject unsolicited UDP messages, b) TCP is reliable by protocol, unlike UDP, and c) the big I Internet is unfriendly and can sometimes be flaky.

-Dan

[kackle123]

The second half of my questioning can be summed up by asking: If AutoUpdate says that my update is complete and without errors, can I rest assured that it updated properly, or is there a good chance that a missing/corrupted/out-of-order UDP packet has broken the SB70LC?

[kackle123]

Anybody? If AutoUpdate says that my update is complete and without errors, is it assured?

[roland.ames]

I've never used SB70LC, but from experience with MOD5270, MOD5282, MOD5234,MOD54415 i think the answer is yes.
autoupdate uses a checksum to verify the complete image.

[dciliske]

What roland said is correct; the device performs a checksum over the image and compares with the checksum it was given. If the checksums match, the image is good and it sends a completed message to Autoupdate. If Autoupdate says that it programmed without errors, it got this message and the everything went fine. Every Netburner device with sufficient memory to buffer the image (aka, not the L2Es) will only program a valid image (your app may be broken... but the image won't be).

-Dan

[kackle123]

Thank you all for your replies. It is a long jet plane ride to the SB70LCs in question, so I wanted to avoid "bricking" them.

Although AutoUpdate's checksum algorithm is only a summation:

Code: Select all

      DWORD csum = 0;

      for ( unsigned int i = 0; i < pCurRecord->dwDataLength; i += 4 )
      {
         csum += *( ( DWORD * ) ( ( pCurRecord->pData ) + i ) );
      }

      if ( csum == pDr->dwThisLen )
      {
         pDr->bAction = UPDATE_RESULT_ACK;
         AUPRINT( DB_AU, "Final Program ACKed\r\n" );

it seems the data order is monitored too:

Code: Select all

   if ( pDr->dwThisAddr != ( pCurRecord->dwLastRxAddr ) )
   {
      AUPRINT( DB_AU, "Out of Sequence SB:" );

so it is very unlikely (1 in a 32-bit number?) that such a corruption can occur. Thanks again!

(Actually, I think that's 1 in a 32-bit number multiplied by every data packet!)

[roland.ames]

On top of the checksum verification done by the NB autoupdate code (over the entire compressed image), the UDP protocol has its own 16-bit checksum verification on each packet.

[kackle123]

Excellent point! That's what I wanted to know; thank you very much.