Hi, Recently I found on my company network that CAPWAP protocol packets sent from different access points (registered in a Cisco Wireless Controller) to the address 255.255.255.255 were decoded like Malformed Packets. After "googling it" I found several forums where other engineers found that was due to an (by default) unchecked option called "Cisco Wireless Controller Support" in the menu Edit/preferences/protocols/CAPWAP. It was true, when I enabled this options Wireshark didn't show the error "Malformed Packets" any more. My question is: why are these packets considered malformed if this check is not enabled since they are necessary packets for the WLC access points functioning? Some forums consider this like a bug but, from my point of view is not a bug because the option Cisco Wireless Controller Support decodes well packets. The point is that I don´t understand the necessity of this option, I´m assuming that has some sense the possibility of check/uncheck the option. If I´m right I would like to know why is implemented on this way. Thanks in advance. asked 02 May '15, 03:54  Francisco To... |
One Answer:
Because in your case the packets conform to a Draft-8 version of the protocol what was to become CAPWAP. With equipment that is CAPWAP compliant these specific packets look different. Unfortunately it's not possible to know automagically which version of the CAPWAP protocol these packets adhere to ("Is it really Draft-8 compliant or is it an error?") so you have to decide, though a preference. answered 02 May '15, 14:20  Jaap ♦ |
Thanks for your comments, Jaap. The problem was affecting only to CAPWAP Control Messages (Type: Primary Discovery Request). After reviewing RFC 5415 (CAPWAP Protocol Specification) I saw that this protocol status is still a proposed standard however, if, I'm not misunderstanding it, Cisco implementation is not being unconditionally compliant with the "proposed standard" and that´s why Wireshark adds the option "Cisco Wireless Controller Support". Considering the message type of these packets I think that should´t depend on protocol version implemented, a primary discovery request format should be always the same irrespective of the access controller type. As additional note, one of RFC 5415 authors (P. Calhoun) worked for Cisco when proposed standard was created.
Your answer has been converted to a comment as that's how this site works. Please read the FAQ for more information.
Well, that's a welcome to the ugly world of standardization. When you develop a technology/protocol and work it into a standard two things can happen. Either you get incompatible changes with respect to the pre-standard equipment you put out in the market, or you get standards with numerous optional features. The latter opens the gate to all kinds of standard compliant but incompatible equipment. When that happens they start putting together so called profiles, to define proper selections of optional features to implement for a specific application. Try to figure that one out is a bit of a nightmare.