Proper operating class definition for class 137?

[Pablo MARTIN-GOMEZ]

On 04/02/2026 17:15, Johannes Berg wrote:
> On Wed, 2026-02-04 at 17:00 +0100, Pablo MARTIN-GOMEZ wrote:
>>>       /* IEEE P802.11be/D5.0, Table E-4 (Global operating classes) */
>>> -    { HOSTAPD_MODE_IEEE80211A, 137, 31, 191, 32, BW320, NO_P2P_SUPP },
>>> +    { HOSTAPD_MODE_IEEE80211A, 137, 1, 233, 64, BW320, NO_P2P_SUPP },
>> I'm going with: both code are incorrect but by chance both work.
>>
>> The "correct" change would be:
>>
>> -    { HOSTAPD_MODE_IEEE80211A, 137, 31, 191, 32, BW320, NO_P2P_SUPP },
>> +   { HOSTAPD_MODE_IEEE80211A, 137, 1, 233, 32, BW320, NO_P2P_SUPP },
>>
>> [`32` is not the size of a channel, it's the increment to go to one
>> channel to the next, one particularity of op class 137 is its channels
>> overlap, so yes a channel stops at +64, but the next (overlapping)
>> channel starts at +32]
> Why 1/233 though? Table E-4 (as of REVmf D2.0 at least) literally says
> center frequencies are channel 31, 63, 95, 127, 159, 191 which is
> covered by the original definition, no?

Ok, so I did some git archeology and it's a mess, I'm just confused now 
and I'm sharing my confusion with you...

Here is the struct that we are talking about:

struct oper_class_map {
[...]
     u8 op_class;
     u8 min_chan;
     u8 max_chan;
     u8 inc;
[...]
};

`min_chan` is the first channel of the channel set, `max_chan` the last 
channel of the channel set, and `inc` the increment to go to one channel 
to the next for that operation class. This is used to recreate a channel 
set with only 3 u8. That works perfectly for operation classes that uses 
"channel set", but less, for op class that uses "channel number of the 
center frequency"... When this struct was added 
(7d46f586debf2b36cce934913e7def92fee3d404), the 3 op classes that used 
"channel number of the center frequency" had the following [secret sauce 
?] definition "for simplicity" (according to the comment):
{ HOSTAPD_MODE_IEEE80211A, 128, 36, 161, 4, BW80, P2P_SUPP },  // that 
generates all the 20MHz channels from U-NII-1 to U-NII-3 (minus chan 32 
and 165)
{ HOSTAPD_MODE_IEEE80211A, 129, 50, 114, 16, BW160, P2P_SUPP }, // that 
generates channels 50, 66, 72, 88, 104 [?!]
{ HOSTAPD_MODE_IEEE80211A, 130, 36, 161, 4, BW80P80, P2P_SUPP },  // 
that generates all the 20MHz channels from U-NII-1 to U-NII-3 (minus 
chan 32 and 165)

When the first 6GHz op class (131) was added 
(d7c2c5c98c4f62b06e46262b7bb0e6a068c4b8d4) for BW20, it was correctly 
set up as follow:
{ HOSTAPD_MODE_IEEE80211A, 131, 1, 233, 4, BW20, P2P_SUPP },   // that 
generates all the 20MHz channels contained in the 6GHz band

The missing 6GHz op classes were added 
(79e3f08d3c2749fb58bb07910306495331ee0198), the min and max channel were 
kept identical to the first 6GHz op classes:
{ HOSTAPD_MODE_IEEE80211A, 132, 1, 233, 8, BW40, NO_P2P_SUPP }, // that 
generates all the `lowest 20MHz channel` of all the 40MHz channels
{ HOSTAPD_MODE_IEEE80211A, 133, 1, 233, 16, BW80, NO_P2P_SUPP }, // that 
generates all the `lowest 20MHz channel` of all the 80MHz channels
{ HOSTAPD_MODE_IEEE80211A, 134, 1, 233, 32, BW160, NO_P2P_SUPP },   // 
that generates all the `lowest 20MHz channel` of all the 160MHz channels
{ HOSTAPD_MODE_IEEE80211A, 135, 1, 233, 16, BW80P80, NO_P2P_SUPP },   // 
that generates all the `lowest 20MHz channel` of all the 80MHz channels
{ HOSTAPD_MODE_IEEE80211A, 136, 2, 2, 4, BW20, NO_P2P_SUPP },  // single 
channel

The definition for the op class 129 was creating issues for P2P and it 
was changed with 21fdb454df8478f869053db41af39e7e9b291d27:
{ HOSTAPD_MODE_IEEE80211A, 129, 36, 128, 4, BW160, P2P_SUPP },  // that 
generates all the 20MHz channels contained in all 160MHz (including 
U-NII-2B)

The support for U-NII-4 was then added 
(833cdbe97dd4a7c6c225a5fc0ac2eceb0799c9d8):
{ HOSTAPD_MODE_IEEE80211A, 128, 36, 177, 4, BW80, P2P_SUPP },  // that 
generates all the 20MHz channels from U-NII-1 to U-NII-4 (minus chan 32)
{ HOSTAPD_MODE_IEEE80211A, 129, 36, 177, 4, BW160, P2P_SUPP },  // that 
generates all the 20MHz channels from U-NII-1 to U-NII-4 (minus chan 32)
{ HOSTAPD_MODE_IEEE80211A, 130, 36, 177, 4, BW80P80, P2P_SUPP },  // 
that generates all the 20MHz channels from U-NII-1 to U-NII-4 (minus 
chan 32)

Then there was an attempt to reverse engineer the definition for the op 
class that uses "channel number of the center frequency" and stated that 
the definition was "lowest 20 MHz channel" (which is the case for the 
6GHz op classes).

So with my proposed change was keeping with the "lowest 20 MHz channel" 
definition like the other 6GHz op classes. But I'm not sure that is the 
best course of action given the surrounding mess.

> I think maybe the change was intended for U-NII-9 but then that should
> only make it 31, 223, I'd guess? But not sure how that's being handled
> as far as the spec is concerned.
>
> johannes

Best regards,

Pablo MG