Lets talk about usteer

[Ramon]

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);

[el_charlie]

Thanks.

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

[noblem]

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);
 }

[el_charlie]

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).

[NilsRo]

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

[danielschwab]

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'

[morhimi]

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!

[NilsRo]

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'

[morhimi]

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

[NilsRo]

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.

[Sylvan]

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.

[wolerine]

Manually install usteer-ng from GitHub and install luci-app-usteer as follow

opkg install luci-app-usteer --nodeps

[morhimi]

The problem is that snapshots have moved from opkg to apk

I don't know how to install the GitHub artifact on my openwrt instances

[Ityns]

Please merge this: https://github.com/openwrt/usteer/pull/10

[klipz]

Agreed. NilsRo put a fair amount of effort into that PR. I use usteer on my APs and would love to see improvements, especially when it’s served up on a silver platter PR like this one.

He answered all reviewers concerns and the PR still sits.

[eR2022]

Same here, usteer-ng seems very promising

[pensioner600]

@NilsRo

Actually

useer-ng + luci-app-usteer. I keep seeing strange devices in my Hearing map that I don't have and never have had on my network. What's going on? Are these incompatibility bugs between useer-ng and luci-app-usteer?

[ImmortAlex]

I think it's just people passing by or neighbors. These MAC addresses can probably be seen elsewhere in the interface. I live in a private house, and my router reaches the sidewalk. So I get quite a few of these addresses all the time.

[pensioner600]

There are no passersby. Also, no one knows my Wi-Fi password. Right now, only five of my devices are connected. But there are a whole bunch of them in the Hearing Map. This can't be normal, can it?

[ImmortAlex]

They don't know your password and aren't trying to connect. They were simply exchanging low-level messages with your access point. A routine network scan. For example, on Android, as far as I remember, it's enabled by default. So any phone that accidentally overheard your access point could show up with its MAC address on this list.