From fca4b8742097e1d0023a09f5303d4c87c6585155 Mon Sep 17 00:00:00 2001 From: Stijn Tintel Date: Mon, 27 Jun 2022 22:05:12 +0300 Subject: [PATCH] policy: improve readability 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 Acked-by: David Bauer --- policy.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/policy.c b/policy.c index 6738c99..e6dc9e1 100644 --- a/policy.c +++ b/policy.c @@ -223,21 +223,18 @@ usteer_check_request(struct sta_info *si, enum usteer_event_type type) 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; -- 2.30.2