As I cannot reach somebody even via private email I decided to create a new package to bring new live to Usteer as I like it more compared to DAWN because of its simplicity. Will add my commits soon but if somebody like feel free to open pull requests. Perhaps it will be merged with the source version later but anyhow today this is the way to go.
NilsRo/usteer-ng: OpenWrt AP service for client steering - Usteer next generation
It is better to take as a base not the outdated official code, but the new one from the development branch. It is also abandoned, but contains a lot of new good things, which is simply necessary in my opinion. It is a pity that it was not released.
Without last commit and with several necessary fixes, I have been successfully using this code for 1.5 years in my networks.
That is a very good hint, did not know that. But let us start in small steps and migrate the commits next. My enhancements based on the official branch and the testers including me run that for 2 month. So I like to publish this first to provide a new version to all users soon.
Would be nice if you can support the migration of the development branch and test the code if we are out with a first version.
PS. Some code changes made it incompatible with the actual version of the LuCI Plugin, so let us take the time to finish it without stress.
Are those changes public?
My commits? Pushed it last night. By the way…Now preparing the makefile to add it as a new package.
@NilsRo I have a request, could you also implement a remote manual kicking interface via a ubus command?
I do not really like automatic kicking, but sometimes I manually kick a specific client off (if they are just stubborn and stick somewhere incorrectly). Would be great if this can be done by just clicking on the client in luci-app-usteer. I can update luci-app-usteer to make use of it, if needed.
Do you think of kicking a client logged into another AP? There is still an Ubus command to kick a local client Usteer is using.
Btw. the luci app is actually incompatible as there is a dependency to Usteer: Create Makefile Usteer-ng by NilsRo · Pull Request #25977 · openwrt/packages
What about having this package PROVIDE:=usteer
Unauthenticated, from LAN network, sounds like a disaster.
yes a remote client. Such that you kind of have on one location the ability to move kick clients and maybe also have the ability to "suggest" to a client to connect somewhere else, i.e. with a disconnect imminent, or BSS_transistion with a target or something.
I do agree with @brada4 that security is of concern. In my case all APs are on a management VLAN, so for me that is not an issue. So maybe we need some kind of authentication (passphrase?) or in its simplest form just an enable/disable switch to only open it up to a setup like mine?
Thank you
I am more after disabling network socket by default for single local use....
If you want complete local mode, then there is a setting for that already
Naa, it starts socket anyways.
That needs to be fixed then. At least reading that setting I would assume that it would not open a socket...
Hi,
@NilsRo: thank you for taking the ownership for usteer.
Are you planning on offering IPKs or at least compile instructions? You mention that "usteer-ng is available from the OpenWrt packages feed", but this is not the case e.g. for OpenWrt 24.10.0 on ramips/mt7621. You can have github compile IPKs for all architectures/targets for you, so the only additional effort is creating the build script/workflow one time.
PS: When compiling I get "Hash of the downloaded file does not match (file: 3d87ce13ba55de92dfbd51867021f5b690ddf1a6be9eff5b303286529d8be57c, requested: 105611ae3b6d8fc5656f710af7919e34c65bc915bec37b268eb0a8c3989f294d)" -- so you might want to update the Makefile.
This is how I compile my IPK
# Select the OpenWrt target / OpenWrt SDK you want to use
SDK_LINK=https://downloads.openwrt.org/releases/24.10.0/targets/ramips/mt7621/openwrt-sdk-24.10.0-ramips-mt7621_gcc-13.3.0_musl.Linux-x86_64.tar.zst
# Download and uncompress the respective OpenWrt SDK
SDK_FILE=$(echo $SDK_LINK | awk -F / '{print $NF}')
SDK_NAME=$(echo $SDK_FILE | awk -F .tar '{print $1}')
wget $SDK_LINK
tar -axf $SDK_FILE
rm $SDK_FILE
cd $SDK_NAME/
# Install this repository
echo 'src-git usteerng https://github.com/NilsRo/usteer-ng' >> feeds.conf.default
./scripts/feeds update -a
./scripts/feeds install usteer-ng
# Compile
make defconfig
make -j1 V=s package/feeds/usteerng/usteer-ng/compile
Best regards
Hi @NilsRo, do you have repository for luci package to support your changes in the usteer-ng?
Actually not. I am waiting if there is a possibility to merge the changes into the original repo until open new topics.
@humaita: Thanks for the skript. If you like to contribute and you know how to setup Github it would be nice to create the settings for it. This is quite new for me.
Hi, I just created a PR to
You can also setup workflows yourself under Actions > Set up a workflow yourself.
You can have github build packages under Actions > Publish > Run Workflow. And when the IPKs a compiled, you can "release all packages" and under "Releases" on the home screen you should see "1 tag(s)" that you can release (i.e. from pre-release to release).
Best regards
Works perfectly. IPKs are not available under releases.
I would also like to have a look at usteer-ng.
The pre-built ipk files make this very easy.
I just don't really know which ipk file to use for MT7621-based devices. According to >>this table<< i would probably need MIPS 1004Kc. Of all things, this is missing from the ipk list.
And otherwise a basic question: usteer-ng is intended as drop-in-replacement? So I would just have to remove usteer and then install usteer-ng?