HT and VHT indicators not distributed

[turboproc]

Observing a strange issue in a 4 AP setup, all based on Netgear R7800 devices running (if I'm right) latest DAWN version.

Issue being that the AP where a STA is connected to (say AP#1) notices the HT and VHT capability but a remote AP, AP#2, (sharing it's information with AP#1) does not forward the HT and VHT capability. Consequence is that the score calculation by AP#1 remains too long in favor of AP#1 and hence the STA is send only late to AP#2.

Example below:

Mon Jun 27 21:07:39 2022 daemon.info dawn: AP BSSID A0:40:A0:7C:00:01: Looking for candidates to kick
Mon Jun 27 21:07:39 2022 daemon.debug dawn: Current AP score = 115 for:
Mon Jun 27 21:07:39 2022 daemon.debug dawn: bssid_addr: A0:40:A0:7C:00:01, client_addr: 8C:F5:A3:B7:XX:XX, signal : -70, freq : 5500, counter: 14, vht: 1, min_rate: 48, max_rate: 48
Mon Jun 27 21:07:39 2022 daemon.debug dawn: Candidate score = 115 from:
Mon Jun 27 21:07:39 2022 daemon.debug dawn: bssid_addr: 14:59:C0:34:00:02, client_addr: 8C:F5:A3:B7:XX:XX, signal : -59, freq : 5500, counter: 0, vht: 0, min_rate: 0, max_rate: 3
Mon Jun 27 21:07:39 2022 daemon.debug dawn: Not a better AP after full evaluation

Any suggestion where to fix this?

[protectivedad]

I've also always had this problem, I just thought it was a feature not implemented yet :)

[Brain2000]

I believe this is in the msghandler.c file:

static const struct blobmsg_policy prob_policy[__PROB_MAX] = {
        [PROB_BSSID_ADDR] = {.name = "bssid", .type = BLOBMSG_TYPE_STRING},
        [PROB_CLIENT_ADDR] = {.name = "address", .type = BLOBMSG_TYPE_STRING},
        [PROB_TARGET_ADDR] = {.name = "target", .type = BLOBMSG_TYPE_STRING},
        [PROB_SIGNAL] = {.name = "signal", .type = BLOBMSG_TYPE_INT32},
        [PROB_FREQ] = {.name = "freq", .type = BLOBMSG_TYPE_INT32},
        [PROB_HT_CAPABILITIES] = {.name = "ht_capabilities", .type = BLOBMSG_TYPE_TABLE}, //ToDo: Change to int8?
        [PROB_VHT_CAPABILITIES] = {.name = "vht_capabilities", .type = BLOBMSG_TYPE_TABLE}, //ToDo: Change to int8?
        [PROB_RCPI] = {.name = "rcpi", .type = BLOBMSG_TYPE_INT32},
        [PROB_RSNI] = {.name = "rsni", .type = BLOBMSG_TYPE_INT32},
};

It looks like BLOBMSG_TYPE_TABLE may be the wrong type. If you run ubus call dawn get_hearing_map you can see that the values are boolean. Perhaps BLOBMSG_TYPE_INT8, which it uses blobmsg_get_u8( ) to read it later on in the file.

This is definitely an issue, because the only time you see HT/VHT set to true is from the access point when you run "get_hearing_map", and all the rest of the access points will show false. But then if you run this from a different access point, it will show true for it's own readings, and everyone else will show up as false.

So adding weights for HT/VHT can cause unpredictable results until they all share the same values.