I got this working. Channel width has to be 20MHz, and the extended channel determines your actual channel width. There also seems to be some problems with how the extension channel setting gets pushed to the CAP from CAPsMAN.
Take a look at the settings I had on CAPsMAN versus what the CAP reports as its channel/width settings
cap-5ghz.png
capsman-5ghz.png
See, the settings on CAPsMAN extension channel are eCee, but the CAP reports eeCe
The current way, 20 MHz channels, with options for additional extension channels (such as Ce or Ceee for a total of 40 or 80 MHz of channel usage) makes sense to me. What will the fix look like? Will 20 MHz Ce still allow for potentially 40 MHz of channel usage or will the configuration have to look something like “20/40 MHz Ce”? I don’t want to accidentally configure an interface in a manner that requires the client to connect at only 40 MHz or at only 80 MHz.
In a CAPsMAN environment, my thought is the following 7 straightforward options should be valid:
Now that’s what I’m talking about. If the CAPsMAN configurations would mirror what the config on WLANs themselves would be, that would make the most sense to me. Instead of splitting them into 2 different fields (width AND extension channel).
You use 20MHz channels, and use the “extension channel” setting for configuring where you want the extra 20MHz channels to be relative to the main channel (they’re called “extension channels” for a reason).
OK, understood. The non-CAPsMAN GUI says “20/40/80 MHz” for the triple-extension-channel mode, assuming that extension channels are included in the channel width, and it confused me.