Cisco and CAPWAP IV

The never ending story ...

After my Cisco LAP finally sent it's first join request to my CAPWAP WLC, I stepped into the next problem. The LAP said, after receiving the join response from WLC, the WLC version were not supported. A deeper look at the logs showed, that the LAP was thinking, the WLC is running a software version of 0.0.0.0, which is probably classified as too old.
I still have no idea where the version information is taken from. The version information sub-elemet type 5 (software version) in the CAPWAP ac descriptor message element seems to be ignored by the Cisco LAP. A version information sub-element type 4 (hardware version) lets the LAP ignore the whole join response message or a discovery response message respectively.
After playing around with the version information sub-elements in the ac descriptor, I found out, that the LAP shows reactions if I include a version sub-element of type 1. In CAPWAP this sub-element is not defined, but the Cisco LAP seems to read the next 4 bytes following the vendor id of this sub-element and interprets them as version to be used for its own software. I'am not really sure, if I am right, but  I can say:

• If these bytes contain the same software version as the LAP is running (for example 7, 1,2,123) the LAP is happy and feels joined to the WLC, continues with change state event request.
• If these bytes represent a higher number than the LAP's software version (for example 50,1,2,123), the LAP wants to download an image file and sends an image data request message to the AC.

So, by giving the right software version number in the type 1 sub-element,  I've got the Cisco LAP actually joined and was finally able to send a configuration update request to change the WTP's name (as proof of concept).

But before my configuration update request was accepted, there was another hurdle to overcome. First the AP responded to my configuration update request with a non-sense response message. To be exact, the AP sent a CAPWAP header without a message, not even a control header or message header was included.

The cause for this behavior is a great example for the mindset of lazy programmers in conjunction with a specification like RFC 5415. There is no statement in the specification what sequence number the first request message has to have, sent either by the WLC or LAP. So I decided that AC-Tube starts with sequence number 0 (zero), when sending its first request message to the LAP. And that was the problem, because a sequence number of zero in the first message confuses the LAP.

The reason is probably a lazy implementation of the response cache in the LAP. In CAPWAP you have to remember the last response message you have sent, and if you receive a request message which sequence number corespondents to the sequence number of your last response message, you have probably received the request message again and must  re-transmit your last response message.
But that's not true for the very first request message you receive.

So I think, the programmer at Cisco has defined a last-response-buffer, which usually holds the last response sent, which is initialized with zero, and whenever a request message is received the LAP looks into the last-response-buffer, to see if there is a is a response message with the sequence number of the received message, to eventually re-transmit the response message.
So, if the very first request message, sent by the WLC,  has a sequence number of zero, it matches the the sequence number in the last-response buffer (because it is zero-initialized), and the LAP sends the content of the last-response-buffer (as re-transmission),  which generates a non-sense message, because there is actually no message in the last-response-buffer.

The special case of the very first request message seems not to be handled by the Cisco firmware.