Increasing ev.type by one for these event types works due to the order
of the elements in enum uevent_type, but makes the code harder to
understand and debug. Imagine seeing the following event log:
Mon Jun 27 22:08:43 2022 user.info usteer: usteer event=probe_req_deny node=hostapd.wl24-iot sta=e4:5f:01:00:92:b6 reason=better_candidate signal=-79 assoc=1 load=27 select_reason=signal remote=fe80::b2a7:b9ff:fecb:eeba#hostapd.wl24-iot remote_signal=-39 remote_assoc=13 remote_load=20
Trying to find probe_req_deny (UEV_PROBE_REQ_DENY) in the code will not
yield any useful results. Assigning the enum element to ev.type makes it
much easier to find where exactly the above log event comes from.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: David Bauer <mail@david-bauer.net>
out:
switch (type) {
case EVENT_TYPE_PROBE:
- ev.type = UEV_PROBE_REQ_ACCEPT;
+ ev.type = ret ? UEV_PROBE_REQ_ACCEPT : UEV_PROBE_REQ_DENY;
break;
case EVENT_TYPE_ASSOC:
- ev.type = UEV_ASSOC_REQ_ACCEPT;
+ ev.type = ret ? UEV_ASSOC_REQ_ACCEPT : UEV_ASSOC_REQ_DENY;
break;
case EVENT_TYPE_AUTH:
- ev.type = UEV_AUTH_REQ_ACCEPT;
+ ev.type = ret ? UEV_AUTH_REQ_ACCEPT : UEV_AUTH_REQ_DENY;
break;
default:
break;
}
- if (!ret)
- ev.type++;
-
if (!ret && si->stats[type].blocked_cur >= config.max_retry_band) {
ev.reason = UEV_REASON_RETRY_EXCEEDED;
ev.threshold.cur = si->stats[type].blocked_cur;