Lets talk about usteer

Installing and Using OpenWrt Network and Wireless Configuration
248

try syslog-ng then use a filter to filter the messages (that is what I did).

try something like this in syslog-ng.conf:

filter f_beacon {
         not( program("hostapd") and message("BEACON-*") );
 };

 log {
         source(src);
         source(net);
         source(kernel);
         filter(f_beacon);
         destination(messages);
249

Thanks.

On the link I put before, there's a workaround to change hostapd to log level 4 (Errors only).

250

If you're building from source and prefer your logs to have a bit more info, then the below patch would work to downgrade the beacon log messages to debug. Just save as a .patch file in package/network/services/hostapd/patches...

--- a/src/ap/rrm.c	2024-03-10 09:33:24.772906338 +0000
+++ b/src/ap/rrm.c	2024-03-10 09:34:26.065696337 +0000
@@ -87,7 +87,7 @@ static void hostapd_handle_beacon_report
 	report[0] = '\0';
 	if (wpa_snprintf_hex(report, sizeof(report), pos, len) < 0)
 		return;
-	wpa_msg(hapd->msg_ctx, MSG_INFO, BEACON_RESP_RX MACSTR " %u %02x %s",
+	wpa_msg(hapd->msg_ctx, MSG_DEBUG, BEACON_RESP_RX MACSTR " %u %02x %s",
 		MAC2STR(addr), token, rep_mode, report);
 	if (len < sizeof(struct rrm_measurement_beacon_report))
 		return;
@@ -676,7 +676,7 @@ void hostapd_rrm_beacon_req_tx_status(st
 {
 	if (len < 24 + 3)
 		return;
-	wpa_msg(hapd->msg_ctx, MSG_INFO, BEACON_REQ_TX_STATUS MACSTR
+	wpa_msg(hapd->msg_ctx, MSG_DEBUG, BEACON_REQ_TX_STATUS MACSTR
 		" %u ack=%d", MAC2STR(mgmt->da),
 		mgmt->u.action.u.rrm.dialog_token, ok);
 }
1 Like
251

Au contraire my friend, I want to see less log info. The beacon requests and responses from hostapd were flooding my sytem log; and even if on the WiFi device I set the log to 4 (errors and fatal only), hostapd will always output level 2 (info, warnings and errors).

252

Perhaps you should provide this to the hostap repo itself. Logging all beacon request is perhaps a little too much info. :slight_smile:

253

Thanks @NilsRo for your effort. I just installed usteer-ng on my single dump AP with 2.4GHz and 5GHz on the same SSID (wlan) for improving band steering towards 5GHz. Is my config below sufficient for my use case?

BTW: I added list ssid_list 'wlan' because I have a third SSID for IOT devices on 2.4GHz only.

config usteer
   option 'network' 'lan'
   option 'syslog' '1'
   option local_mode '0'
   option 'ipv6' '0'
   option 'debug_level' '2'
   option roam_scan_snr '-65'
   option signal_diff_threshold '8'
   list ssid_list 'wlan'
254

Hi,
Is there a simple guide on how to install usteer-ng on the nightly builds?
there is no opkg anymore on the nightly snapshots

Thanks!

255

You are fine in general. If you like you can reduce the band steering interval as it will be adapted dynamically now. I use 30s but if you like to move your device much earlier it would not be a problem anymore.

    option band_steering_interval '30000'
256

@NilsRo any clue how to install usteer-ng on nightly?

257

Actually I did not spend time on it as I hope it will be fixed automatically if merged into the main repository. But if anyone knows how to build packages I would be happy to merge a pull into my usteer-ng repo.

258

I did it as follows in my case:

  1. uninstall usteer and luci-app-usteer.
  2. download the appropriate .ipk file for the respective architecture >>here<<.
  3. unpack the .ipk with tar xvf. Among other things, you get a file data.tar.gz.
  4. unpack this data.tar.gz again. You will receive the relative folder structure of the files to be installed for root.
  5. basically just copy the contents of the data folder to root (so that the files are copied to the corresponding folders).
  6. install luci-app-usteer and ignore the usteer dependency (don't know how to do this with apk)
  7. start and activate usteer-ng via service usteer start && service usteer enable && service usteer status.