Updates Roaming and Band-Steering by NilsRo · Pull Request #10 · openwrt/usteer

NilsRo · 2025-02-16T08:10:28Z

Adds some central new functions:

flexible setting how aggressive the roaming is done - works better with some devices like some Intel Wifi Cards and also Apple
band steering could be checked more frequently as the steering depends on the quality change of the signal itself
Small fixes like DEAUTH reason, etc.
Additional log message to understand roaming behavior easier from user perspective

ynezz

Overall LGTM, but the commits needs to be reworked and cleaned up.

Its hard to review currently, because some of the Git commits are usually mixing several topics, the changes are not described or the description is not sufficient enough, thus making the proper review time consuming, impossible.

Additionally it looks like some changes like aggressive_all in 85f87fb are later reworked in 07a7af9 to aggressiveness so making the number of commits/changes unnecessarily bigger, could be squashed etc.

main.c

ubus.c

band_steering.c

policy.c

ubus.c

band_steering.c

openwrt/usteer/files/etc/config/usteer

NilsRo · 2025-03-17T21:38:45Z

Overall LGTM, but the commits needs to be reworked and cleaned up.

Its hard to review currently, because some of the Git commits are usually mixing several topics, the changes are not described or the description is not sufficient enough, thus making the proper review time consuming, impossible.

@ynezz Many thanks for the detailed review. I worked mostly on my own in my projects so I am happy with everything that could be done better with Git. :-) Would it fine if the single commits could not be compiled as there are some dependencies in between for a better review?

ynezz · 2025-03-18T04:40:40Z

I worked mostly on my own in my projects so I am happy with everything that could be done better with Git. :-)

There is https://openwrt.org/submitting-patches#in-depth_process_of_preparing_and_submitting_code_to_openwrt basically based on https://www.kernel.org/doc/html/latest/process/submitting-patches.html, so once you start following this, you should be good for most, if not all, open source projects contributions.

Would it fine if the single commits could not be compiled as there are some dependencies in between for a better review?

Usually the Git commit itself should stand on its own, tackle single topic/logical change only, so it should compile. For some reason its not stated explicitly in the OpenWrt guide, but in the kernel's there is:

When dividing your change into a series of patches, take special care to ensure that the kernel builds and runs properly after each patch in the series. Developers using git bisect to track down a problem can end up splitting your patch series at any point; they will not thank you if you introduce bugs in the middle.

NilsRo · 2025-04-02T09:19:45Z

@ynezz : Please take a look. I rebased the commits and separated it by function and also as it can "live" on its own.

ynezz

LGTM, thanks!

openwrt/usteer/files/etc/init.d/usteer

policy.c

Djfe · 2025-04-02T13:55:59Z

I'm really looking forward to trying out usteer this year (for the first time).
Looking forward to see how well this works. Thank you so much!

You don't have to apply the following changes, I suggested. It's up to you.
This is testament to me really liking your PR and wanting to contribute to
this being a success, so I kindly ask you to not take my corrections personally :)

First commit message

Improve roaming through different levels of aggressiveness

Add some new options and also fix the inconsistent
disassociation_timer/_imminent call to have a better roaming experience.
This is necessary for some Intel WiFi cards because they do not understand
the current transition request frames due to expecting a combination of
disassociation_timer and disassociation_imminent = true here.
According to posts on the OpenWrt forum this behavior isn't limited
to just Intel WiFi cards. Affected stations
respond with BSS-TM-RESP status=1 (error) and refuse to roam.

- Add new aggr. levels combined with station specific configuration
- Set disassociation imminent and timer as default option to have a better roaming by default
- Use abridged flag to put priority on neighbors provided
- Take care of correct disassociation_timer corresponding to kick_time
- Let Disassociation Timer run a countdown before dissassociating the station
  if roam_kick_delay is longer than validity_period like defined in IEEE.
  Fix validity_period to 100 beacon intervals.
- Add new logging messages (verbose and debug) to visualize the station behaviour

Second commit message

802.11 Mgmt: DEAUTH reason more accurate

Improve deauthing stations. Previous reason codes sent to stations were
inaccurate. Respond with correct DEAUTH reason codes in order to give
stations better control over their roaming decisions.

- policy: send correct DEAUTH reason to the station
- ubus: add reason code to method usteer_ubus_kick_client
- usteer: clearly define reason codes as enums

Third commit (overall fine, I adjusted some things slightly)

Add dynamic signal threshold to band-steering

Avoid ping-pong between bands by adding a dynamic signal threshold.
If 5Ghz band is below roaming threshold (e.g. -70) and 2,4Ghz over
band-steering threshold (e.g. -50) this adds a dynamic threshold
depending on the signal level when station has connected. It adapts to
worser signal slowly. This allows to reduce the check interval to
lower values like 30s as new standard.

- band_steering: add dynamic signal threshold
- main: add config option band_steering_signal threshold which specifies
  the difference until a signal is defined as "better" and band steering
  is triggered
- main: reduce interval to 30000ms to make use of the dynamic threshold
  more often and react snappier to sudden changes. It is not neccessary
  anymore to "wait" as long to avoid flip-flopping stations.

Fourth commit

802.11 MBO - added reassoc_delay and reason code

Multi Band Operations (MBO) provide stations with additional information
about roaming requests. Reassociation delay avoids ping-pong between APs.
By default reassociation is delayed for 30s.
MBO code 5 defines signal quality as a reason for roaming. This could be
enhanced in the future by responding with other dynamically defined
reasons to improve further how transitions are handled by stations.

- ubus: add reason code to bss_transition request (actually static only)
- ubus: add reassociation delay to let the station know how long it's supposed
  to remain with the new AP. This is derived from station block timeout.
- main: add config option for reassociation delay with 30s as default

JFroch · 2025-05-07T18:43:31Z

@ynezz Is there still something that prevents this PR from getting merged? If not, can you do that, or do we need to ping someone?

KanjiMonster

Can't really say if code itself is good, but a few nitpicks.

Also AFAIU roaming is something the STA does and not the AP, so this isn't about roaming more aggressive but steering more aggressive, right? The naming and messages should be updated.

Also some of the lines are far too long and should be broken up.

KanjiMonster · 2025-05-07T18:55:06Z

ubus.c

 	}
 	blobmsg_add_u8(&b, "abridged", abridged);
 	blobmsg_add_u32(&b, "validity_period", validity_period);
+	blobmsg_add_u32(&b, "mbo_reason", 5);


This definitely needs to be a #define so it is obvious what this means and where it comes from.

Please clarify this? This is an additional roaming information for the AP which is not necessary to have it optionally.

I mean something that explains to someone looking at the code what 5 means without having to look up the standard. E.g.

#define MBO_REASON_I_DONT_LIKE_YOU 5

at an appropriate place and then use that define here. Something like hostapd does.

choosing "I don't like you" could be misinterpreted by NilsRo and taken personally. Next time maybe choose something neutral instead for an example ;)

Definitely wasn't intended that way ;-)

Got it.

I would leave it like it is as it should be enhanced later. It is documented in commit message. The reason code is "better AP found" but there are also other codes like AP overload, load balancing,... which brings more attention of the STA. But I have to made some deeper changes to determine the reason of the steering so I like to do it if this version is merged. That is the reason also it is added as static line.

Commit messages should not be required to understand what code does. Please do add a define for it, or at least add a comment explaining what that value means and where it comes from (everywhere where you used it).

KanjiMonster · 2025-05-07T18:56:41Z

main.c

 	config.remote_update_interval = 1000;
 	config.initial_connect_delay = 0;
 	config.remote_node_timeout = 10;
+	config.aggressiveness = 3;


The default should be (IMHO) whatever is the current behavior. The new behavior should be opt-in, not opt-out.

Also maybe use an enum or defines for the different levels so its obvious what they mean?

In my opinion it would be better to switch to a new default to have a better roaming for everybody. According the test results in the forum roaming behave much better with the new default which is aligned to DAWNs implementation. Passive roaming is too friendly for most devices.

Anyway, I can also see a benefit to stay at the old default that nothing is changed after an upgrade but the default should be the best behavior for most cases... So open for a discussion what would be the best for the start...could be also changed later if we stay on the old behavior for the beginning.

I agree that it makes more sense to actually activate the new feature instead of leaving it deactivated. Usteer is not a default package anyway and people installing it expect it to actually make clients roam. This PR adds a new feature to improve roaming for certain clients like Intel wifi cards.
That sounds like a sensible new default to me. Leaving it deactivated leads to worse experience overall which this pr is trying to improve upon by implementing the required standard/messages for said clients.
If we don't activate a useful new part of this package then certain people won't know about it and never activate it since it's only opt-in.

Yes, it's a new kind of default and it's good to bring up that this might change how usteer works/handles certain situations (good feedback by @KanjiMonster).
But knowing how bad certain clients handle roaming on their own, I pledge for the new default.

Looking forward to hear how other people feel about this :)

I totally agree with @Djfe. This should come with new default., the release could have a breaking change note with some settings attached to be used by the people that want to keep the old behavior.

usteer.h

KanjiMonster · 2025-05-07T19:05:05Z

band_steering.c

+
+		if (si->bss_transition) {
+			si->roam_transition_request_validity_end = current_time + 10000;
+			validity_period = 10000 / usteer_local_node_get_beacon_interval(ln); /* ~ 10 seconds */


Is that comment supposed to be at the line above? And where do the 10 seconds come from? They are not explained anywhere.

No, its for the line. The validity period is calculated by beacon interval so is not exactly 10s.

Then what does the the 10000 mean? Because if you what you get when you divide it by a number (that is presumably > 1) is 10 seconds, 10000 is something larger than 10 seconds, right?

10000ms have to be split up by beacons (e.g. every 150ms). The interval could be set in hostap config. So if the result of the division has to be rounded the beacon interval count does not exactly reflecting 10s anymore.

But that means that validity_period is the number of beacons sent out during 10 seconds, right?

Also it still does not explain where the 10 seconds value come from. How was this chosen? Should this be configurable?

Yes and good question.

This is the common standard and also fixed value within e.g. DAWN. Its related to disassociation imminent timer, that if the disassociation is planned within 30s every 10s a new BSS_TM_REQ is send like a timer and to update the neighbor list if the STA moved to another place. Could make sense for experts (it is available in Cisco Controllers) to change it but not relevant for common usage in my opinion. Not everything should be configurable without need and testing. This can be done in another iteration but with this PR I do not plan to add more functionality.

KanjiMonster · 2025-05-07T19:07:57Z

policy.c

-		si->kick_time = current_time + config.roam_kick_delay;
-		usteer_roam_set_state(si, ROAM_TRIGGER_IDLE, &ev);
+		if (!candidate->node->rrm_nr)
+			MSG(VERBOSE, "Candidates node rrm nr not returned from hostapd. Neighbor list empty!");


What's the meaning of this check / message? Is the user supposed to do something about it?

This is an bug in hostap daemon that it sometimes does not return the rrm numbers which breaks supported roaming. Log messages describes the the error and not the solution as this could be different in many cases even if it are not caused by the software itself. Should be documented in OpenWrt Wiki if published but anyhow the solution must be searched in hostap. Mostly fixed with a restart of the deamon or sometimes on its own.

If it's a bug that breaks roaming does it mean it prevents STAs from connecting to a different SSID?

If it breaks stuff, then it should be probably INFO and not VERBOSE, and the message should say something of that effect. As a user, I wouldn't have any idea what rrm nr means or if that is important, so it would just be noise and confusing.

Also if it breaks stuff, shouldn't usteer then try to handle that? It doesn't make sense continuing if this won't work, right?

Also if it breaks stuff, shouldn't usteer then try to handle that? It doesn't make sense continuing if this won't work, right?

To me the bug @NilsRo found in hostapd sounds more like a follow up that can be tackled now that the behavior was noticed.
Sure, relying on something that might not work all the time can be a problem. But atleast this code change could help in finding the root cause. Or alert of an error, I agree with @KanjiMonster the message needs to be improved to be accessible by everyone.

@NilsRo Was this bug affecting usteer already before your PR and you just added a message so you could restart hostapd when it happened?

Where can the bug be reported, on this mailing list? https://w1.fi/

The rest could be better answered by NilsRo himself than me.

It described here in detail. openwrt/openwrt#16875

It breaks "controlled" steering also before the PR for DAWN, Usteer, ... The wifi controller software could not get the identifiers anymore to send the target AP to the STA. So the bss transition request if more or less a "I_DONT_LIKE_YOU" but without any additional information. I added the log message to inform the user about it. Sometimes it fixes on its own but sometimes the hostap daemon has to be restarted or whole AP.

What do you suggest to have a better understanding of the message? As it happens from time to time and fixes itself it could be irritating so I put it to VERBOSE. But anyway if this is broken in general it is not visible without changing the logging level....

ubus.c

openwrt/usteer/files/etc/config/usteer

usteer.h

openwrt/usteer/files/etc/config/usteer

NilsRo · 2025-05-08T09:41:03Z

Also AFAIU roaming is something the STA does and not the AP, so this isn't about roaming more aggressive but steering more aggressive, right? The naming and messages should be updated.

Some vendors calling it "optimized roaming" (Cisco) or also "roaming aggressiveness". I simply followed this direction but you or right. But its then an inaccuracy in general as all parameters for roaming are starting with roam even f there are AP related. But should be a change in config file so a good thing to do as it takes place for band steering and roaming.

Add some new options and also changed disassociation_timer/_imminent call to have a better roaming experience. This is necessary for some Intel WiFi cards ignoring actual transition request frames due to expecting a combination of disassociation_timer and disassociation_imminent = true. According to posts on the OpenWrt forum this behavior isn't limited to just Intel WiFi cards. Affected stations respond with BSS-TM-RESP status=1 (error) and refuse to roam. - Add new aggr. levels combined with station specific configuration - Set disassociation imminent and timer as default option to have a better roaming by default - Use abridged flag to put priority on neighbors provided - Take care of correct disassociation_timer corresponding to kick_time - Let Disassociation Timer run a countdown before dissassociating the station if roam_kick_delay is longer than validity_period like defined in IEEE. Fix validity_period to 100 beacon intervals. - Add new logging messages (verbose and debug) to visualize the station behaviour Signed-off-by: Nils Hendrik Rottgardt <n.rottgardt@gmail.com>

Previous reason codes sent to stations were inaccurate. Respond with correct DEAUTH reason codes in order to give stations better control over their roaming decisions. - policy: correct DEAUTH reason is send to the station - ubus: add reason code to method usteer_ubus_kick_client - usteer: clearly define reason codes as enums Signed-off-by: Nils Hendrik Rottgardt <n.rottgardt@gmail.com>

Avoids ping-pong between bands by adding a dynamic signal threshold. If 5Ghz band is below roaming threshold (e.g. -70) and 2,4Ghz over band-steering threshold (e.g. -50) this adds a dynamic threshold depends on the signal level when station has connected. It adapts to worser signal slowly. This allows to reduce the check interval to lower values like 30s as new standard. - band_steering: added dynamic signal threshold - main: added config option band_steering_signal threshold which specifies the difference until a signal is defined as "better" and band steering is triggered - main: reduced interval to 30000ms to get in use of dynamic threshold more often. It is not neccessary to "wait" anymore to steer a station to a higher band. Signed-off-by: Nils Hendrik Rottgardt <n.rottgardt@gmail.com>

Multi Band Operations (MBO) provide stations with additional information about roaming requests. Reassociation delay avoids ping-pong between APs. By default a delay of 30s is requested from the station. MBO code 5 defines signal quality as a reason for roaming. This could be enhanced in the future by responding with other dynamically defined reasons to improve further how transitions are handled by stations. - ubus: add reason code to bss_transition request (actually static only) - ubus: add reassociation delay to let the client know how long it should stay at the new AP dereived from station block timeout. - main: add config option for reassociation delay with 30s as default Signed-off-by: Nils Hendrik Rottgardt <n.rottgardt@gmail.com>

Ramon00 · 2025-06-14T13:36:15Z

Any chance of getting this merged?

Ramon00 · 2025-06-14T14:24:07Z

I hope it fixes all those code 7 times the STA does not respond and only finally when it gets a code 0 it does.

2025-06-14 13:39:57 notice hostapd[]: phy1-ap0: BSS-TM-RESP xx:xx:xx:xx:xx:xx status_code=7 bss_termination_delay=0
2025-06-14 13:43:59 notice hostapd[]: phy1-ap0: BSS-TM-RESP xx:xx:xx:xx:xx:xx status_code=7 bss_termination_delay=0
2025-06-14 13:46:00 notice hostapd[]: phy1-ap0: BSS-TM-RESP xx:xx:xx:xx:xx:xx status_code=7 bss_termination_delay=0
2025-06-14 13:48:02 notice hostapd[]: phy1-ap0: BSS-TM-RESP xx:xx:xx:xx:xx:xx status_code=7 bss_termination_delay=0
2025-06-14 13:50:03 notice hostapd[]: phy1-ap0: BSS-TM-RESP xx:xx:xx:xx:xx:xx status_code=7 bss_termination_delay=0
2025-06-14 13:58:08 notice hostapd[]: phy1-ap0: BSS-TM-RESP xx:xx:xx:xx:xx:xx status_code=7 bss_termination_delay=0
2025-06-14 14:00:09 notice hostapd[]: phy1-ap0: BSS-TM-RESP xx:xx:xx:xx:xx:xx status_code=7 bss_termination_delay=0
2025-06-14 14:06:13 notice hostapd[]: phy1-ap0: BSS-TM-RESP xx:xx:xx:xx:xx:xx status_code=7 bss_termination_delay=0
2025-06-14 14:08:14 notice hostapd[]: phy1-ap0: BSS-TM-RESP xx:xx:xx:xx:xx:xx status_code=0 bss_termination_delay=0 target_bssid=yy:yy:yy:yy:yy:yy:yy
2025-06-14 14:08:14 info hostapd[]: phy0-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated

NilsRo · 2025-06-14T17:51:06Z

I hope it fixes all those code 7 times the STA does not respond and only finally when it gets a code 0 it does.

It should if the aggressiveness is set higher. 7 is common if roaming request is ignored because it is friendly only.

Nmrawe · 2025-06-25T06:20:48Z

Any chance of getting this merged?

Hopefully before 2026. 🙄

BTW, usteer-ng works much better than (still) half-broken usteer.

akostadinov · 2025-07-12T20:00:04Z

Anybody still maintaining this project and can merge this?

Also the proposal in #2 appears relevant and interesting.

NilsRo · 2025-07-13T10:11:52Z

Also the proposal in #2 appears relevant and interesting.

This change is still included here and can be set in config with aggressiveness parameter.

Ramon00 · 2025-07-13T21:03:00Z

@ynezz can this be merged?

@NilsRo can you let me know if there are any changes to the configure, such that I can include them in luci-app-usteer

Ty

NilsRo · 2025-08-19T19:48:45Z

@Ramon00 : There are some new configurations available to handle new functionality but it is backward compatible. At best take a look here: https://github.com/openwrt/usteer/pull/10/files#diff-d9f0fa315a94c84c2dec48dd27f4184a89356693d724af7c3e7ea644b7ba1a83

If the PR is merged I will also add everything to the OpenWRT Wiki. If you have questions do not hesitate to contact me.

Nmrawe · 2025-09-08T22:51:12Z

@NilsRo Please consider bringing back usteer-ng as a separate package as this merging is going nowhere, it seems.

domingues · 2025-09-18T09:18:35Z

+1

maciekczwa · 2025-09-18T14:27:17Z

+1

Torbins · 2025-10-12T08:00:07Z

I have tested usteer-ng and it is working great. It would be nice, if these changes where merged before next major release of OpenWRT.

domingues · 2025-12-15T09:46:18Z

Since this PR is currently in limbo, I created a fork solely to build it with GitHub actions, and I also added the LuCI app.

https://github.com/domingues/usteer

Jonsonmon · 2025-12-23T23:47:51Z

Since this PR is currently in limbo, I created a fork solely to build it with GitHub actions, and I also added the LuCI app.

https://github.com/domingues/usteer

Please compile it so we could install it

ondrani · 2026-01-23T01:46:01Z

Hi, How do I change the aggressiveness value? I changed to 1 in config but the value remains 3 and some clients still being kicked out.

root@openwrt:~# uci get usteer.@usteer[0].aggressiveness
1

user.info usteer: band steering station 90:09:df:**:**:** disassociation timer 100, signal -53

But here is set it to 3 still

root@openwrt:~# ubus call usteer get_config
{
	"syslog": true,
	"debug_level": 2,
	"ipv6": true,
	"local_mode": false,
	"sta_block_timeout": 30000,
	"local_sta_timeout": 120000,
	"local_sta_update": 1000,
	"max_neighbor_reports": 8,
	"max_retry_band": 5,
	"seen_policy_timeout": 30000,
	"measurement_report_timeout": 120000,
	"load_balancing_threshold": 0,
	"band_steering_threshold": 5,
	"remote_update_interval": 1000,
	"remote_node_timeout": 10,
	"assoc_steering": false,
	"aggressiveness": 3,
	"aggressive_disassoc_timer": 0,
	"min_connect_snr": 0,
	"min_snr": 0,
	"min_snr_kick_delay": 5000,
	"steer_reject_timeout": 60000,
	"roam_process_timeout": 5000,
	"roam_scan_snr": 0,
	"roam_scan_tries": 3,
	"roam_scan_timeout": 0,
	"roam_scan_interval": 10000,
	"roam_trigger_snr": 0,
	"roam_trigger_interval": 60000,
	"roam_kick_delay": 10000,
	"signal_diff_threshold": 0,
	"initial_connect_delay": 0,
	"load_kick_enabled": false,
	"load_kick_threshold": 75,
	"load_kick_delay": 10000,
	"load_kick_min_clients": 10,
	"load_kick_reason_code": 5,
	"band_steering_interval": 30000,
	"band_steering_min_snr": -60,
	"link_measurement_interval": 30000,
	"interfaces": [
		"br-lan.40"
	],
	"event_log_types": [
		
	],
	"ssid_list": [
		"******",
		"******"
	]
}
}```

NilsRo · 2026-01-31T11:38:30Z

@ondrani It is perhaps a bug fixed in ng fork - synced yesterday. Will add it to the pull later, uci integration was not fully working.

domingues · 2026-01-31T13:26:55Z

Could you add this #3, if needed, to your PR? That way we could "fix" two in one.

andriej · 2026-02-02T22:04:29Z

+1

ynezz requested changes Mar 17, 2025

View reviewed changes

Djfe mentioned this pull request Mar 25, 2025

x86: enable early loading of firmware for amd/intel openwrt/openwrt#18203

Open

NilsRo force-pushed the usteer_src_pr branch 2 times, most recently from 7665172 to 56f9686 Compare April 2, 2025 09:15

ynezz approved these changes Apr 2, 2025

View reviewed changes

openwrt/usteer/files/etc/init.d/usteer Outdated Show resolved Hide resolved

Djfe reviewed Apr 2, 2025

View reviewed changes

policy.c Outdated Show resolved Hide resolved

NilsRo force-pushed the usteer_src_pr branch from 56f9686 to dfc0c1c Compare April 2, 2025 22:02

KanjiMonster reviewed May 7, 2025

View reviewed changes

NilsRo force-pushed the usteer_src_pr branch from dfc0c1c to 7207134 Compare May 8, 2025 09:32

NilsRo added 4 commits May 8, 2025 11:50

NilsRo force-pushed the usteer_src_pr branch from 7207134 to edd1f09 Compare May 8, 2025 09:53

Conversation

NilsRo commented Feb 16, 2025

Uh oh!

ynezz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

NilsRo commented Mar 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ynezz commented Mar 18, 2025

Uh oh!

NilsRo commented Apr 2, 2025

Uh oh!

ynezz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Djfe commented Apr 2, 2025

Uh oh!

JFroch commented May 7, 2025

Uh oh!

KanjiMonster left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Djfe May 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NilsRo commented Mar 17, 2025 •

edited

Loading

Djfe May 8, 2025 •

edited

Loading

NilsRo May 8, 2025 •

edited

Loading

Ramon00 commented Jun 14, 2025 •

edited

Loading

ondrani commented Jan 23, 2026 •

edited

Loading

NilsRo commented Jan 31, 2026 •

edited

Loading