Capwap Mailing List: Re: Wrong place for "Image data" state

[Scott G. Kelly (s.kelly]

Hi David,

> The state machine shows that the "image data" state is 
> entered after the "configure" state. However, the description 
> of the state machine doesn't really match this. As currently 
> specified, I believe that it would be clearer for the "Image 
> Data" state to be entered from the "Join" state instead of 
> the "Configure"
> state.

This change was made as part of the state machine revisions resulting from DTLS 
integration. The single exit from the Join state to the Configure state was 
chosen for simplicity, and because which image(s) the WTP has available (and 
which image should be the active one) really is a matter of system 
configuration. I know someone on this list argued that this is not 
configuration, but looking at it this way provides a certain consistency and 
clean logic that is hard to deny.

What I think is more important though, and as you've noted in previous posts, 
is that we have not clearly defined the criteria for transitioning to image 
download. I think (based on your earlier post) that you have very definite 
ideas on how this should be managed, and I think what you've suggested makes 
sense. 

It seems like your suggestions would work fine with the state machine as 
specified - in this case, the WTP sends the Configure Request with it's current 
config, and that includes a list of available images, and the current "active" 
image; if the AC wants the WTP to reboot with a different image, this is 
accomplished by changing the current "active" image in a Config Rsp message.

If the AC wants the WTP to download a new image, it can follow the same 
procedure, i.e. set the appropriate version for the current active image; when 
the WTP determines that it does not have this image stored locally, it 
transitions to the Image Data state, fetches the new image, and reboots.

I know there are a few missing details here, but does this address your 
concerns in general?

Scott


Scott