Subject: [Capwap] Issue 238: Additional Firmware Download Change Requests

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 25 Jan 2007 20:35:02 -0800

Based on the discussion during the interim meeting, the following were
agreed 
upon:
- Have a method to indicate the file size, and a hash of the image prior
to 
the download
- No longer use < 1024 to indicate end of file, and instead have an
explicit 
method to indicate the download is at an end
- Provide diagrams depicting the image transfer message exchanges 

Issue 238 has been created. 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 26 Jan 2007 10:53:06 -0800

All,

Please find below proposed text for this issue:

4.5.24.  Image Data

   The image data message element is present in the Image Data Request
   message sent by the AC and contains the following fields.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Opcode    |                  value ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   24 for Image Data

   Length:   >= 1

   Opcode:   An 8-bit value representing the transfer opcode.  The
      following values are supported:

      1 -  Image data is included

      2 -  Last Image Data Block is included (EOF)

      5 -  An error occurred.  Transfer is aborted

   Value:   The Image Data field contains up to 1024 characters.  If the
      block being sent is the last one, the opcode is set to 2.  The AC
      MAY opt to abort the data transfer by setting the opcode to 5, at
      which point the value field is empty.
[...]

4.5.26.  Image Information

   The image information message element is present in the Image Data
   Response message sent by the AC and contains the following fields.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           File Size           |              Hash             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              Hash                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              Hash                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              Hash                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Hash             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   26 for Image Information

   Length:   18

   File Size:   A 16-bit value containing the size of the file that will
      be transfered by the AC to the WTP.

   Hash:   A 16 octet hash of the image.  The hash is computed using
      MD5, using the following pseudo-code:

           #include <md5.h>
           CapwapCreateHash(char *hash, char *image, int image_len)
           {
                   MD_CTX context;

                   MDInit (&context);
                   MDUpdate (&context, buffer, len);
                   MDFinal (hash, &context);
           }
[...]
9.1.  Firmware Management

   This section will describe the firmware download procedures used by
   the CAPWAP protocol.  Firmware download can occur at two different
   times; during the bootup process or while in the run state.

   Figure 4 provides an example of a WTP that performs a firmware
   upgrade while in the Image Data state.  This phase only occurs as
   part of the WTP bootup process.  In this example, the WTP does not
   already have the requested firmware (Image Identifier = x), and
   therefore downloads the image from the AC.

             WTP                                               AC

                                Join Request
         -------------------------------------------------------->

                     Join Response (Image Identifier = x)
         <------------------------------------------------------

              Image Data Request (Image Identifier = x)
         -------------------------------------------------------->

                Image Data Response (Result Code = Success,
                                     Image Information = {size,hash},
                                     Initiate Download)
         <------------------------------------------------------

                Image Data Request (Image Data = Data)
         <------------------------------------------------------

                Image Data Response (Result Code = Success)
         -------------------------------------------------------->

                                  .....

                Image Data Request (Image Data = EOF)
         <------------------------------------------------------

                Image Data Response (Result Code = Success)
         -------------------------------------------------------->

                     (WTP enters the Reset State)

                  Figure 4: WTP Firmware Download Case 1

   Figure 5 provides an example whereby the WTP finds that during the
   bootup process it already has the image specified by the AC in its
   non-volative storage.  The WTP opts to NOT download the firmware and
   immediately reset.

             WTP                                               AC

                                Join Request
         -------------------------------------------------------->

                     Join Response (Image Identifier = x)
         <------------------------------------------------------

                     (WTP enters the Reset State)

                  Figure 5: WTP Firmware Download Case 2

   Figure 6 provides an example of a WTP that performs a firmware
   upgrade while in the Run state.  This mode of firmware upgrade allows
   the WTP to download its image while continuing to provide service.
   It is important to note that the WTP will not automatically reset
   until such time as it is notified by the AC through an explicit Reset
   Request.

             WTP                                               AC

                Configuration Update Request (Image Identifier = x)
         <------------------------------------------------------

            Configuration Update Response (Result Code = Success)
         -------------------------------------------------------->

              Image Data Request (Image Identifier = x)
         -------------------------------------------------------->

                Image Data Response (Result Code = Success,
                                     Image Information = {size,hash},
                                     Initiate Download)
         <------------------------------------------------------

                Image Data Request (Image Data = Data)
         <------------------------------------------------------

                Image Data Response (Result Code = Success)
         -------------------------------------------------------->

                                  .....

                Image Data Request (Image Data = EOF)
         <------------------------------------------------------

                Image Data Response (Result Code = Success)
         -------------------------------------------------------->

                                  .....

                (administratively requested reboot request)
                   Reset Request (Image Identifier = x)
         <------------------------------------------------------

                  Reset Response (Result Code = Success)
         -------------------------------------------------------->

                  Figure 6: WTP Firmware Download Case 3

   Figure 7 provides another example of the firmware download while in
   the Run state.  In this example, the WTP finds that it already has
   the image specified by the AC in its non-volative storage.  The WTP
   opts to NOT download the firmware.  The WTP would reset at a time in
   the future through an explicit Reset Request by the AC.

          WTP                                               AC

             Configuration Update Request (Image Identifier = x,
                                           Image Information =
{size,hash},
                                           Initiate Download)
      <------------------------------------------------------

   Configuration Update Response (Result Code = Already Have Image)
      -------------------------------------------------------->

                               .....

             (administratively requested reboot request)
                Reset Request (Image Identifier = x)
      <------------------------------------------------------

               Reset Response (Result Code = Success)
      -------------------------------------------------------->

                  Figure 7: WTP Firmware Download Case 4

Pat Calhoun

> -----Original Message-----
> From: Pat Calhoun (pacalhou) 
> Sent: Thursday, January 25, 2007 8:35 PM
> To: [email-masked]
> Subject: [Capwap] Issue 238: Additional Firmware Download 
> Change Requests
> 
> Based on the discussion during the interim meeting, the 
> following were agreed
> upon:
> - Have a method to indicate the file size, and a hash of the 
> image prior to the download
> - No longer use < 1024 to indicate end of file, and instead 
> have an explicit method to indicate the download is at an end

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 29 Jan 2007 19:08:03 -0500

Hi All,

Sorry for the confusion.  At the interim meeting, we also agreed that  
issue #238 (Additional firmware download change requests) would be  
closed, based on the changes that were included in the message I sent  
earlier today entitled "CONSENSUS CONFIRMATION:  Firmware-related  
issues".

If you have any blocking objection to closing issue #238 as a result  
of those changes, please respond with your concerns by February 5th.

Thanks,
Margaret