Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

default iw package missing 'set plink_action' #726

Open
goofus opened this issue Aug 29, 2019 · 16 comments
Open

default iw package missing 'set plink_action' #726

goofus opened this issue Aug 29, 2019 · 16 comments

Comments

@goofus
Copy link

goofus commented Aug 29, 2019

To ignore a 802.11s mesh point as described here, the 'set plink_action' setting has to be available in 'iw'. However, the default version doesn't support that: iw.txt

Please include the 'iw-full' package as the default.
iw-full.txt

@SvenRoederer
Copy link
Contributor

as described here

What's "here"?

@goofus
Copy link
Author

goofus commented Aug 29, 2019

as described here

What's "here"?

Sorry about that, forgot to add the actual link

@SvenRoederer
Copy link
Contributor

Excluding node from the mesh seems to be an uncommon / unwated intention / border-case, as also mentioned by the Gluon-guys. So changing the package-list will not be done in 1st place.
But you can install the iw-full packkage directly from the openwrt-build-server and test.

@goofus
Copy link
Author

goofus commented Sep 2, 2019

Ok, that's actually surprising for me. I thought meshing via LAN is common. Now, if two routers see each over the air shouldn't they stop meshing over wifi to save airtime?
In my opinion 802.11s is a central technology and hence all settings should be adjustable by default (as it was in latest stable).

@goofus
Copy link
Author

goofus commented Sep 3, 2019

But you can install the iw-full packkage directly from the openwrt-build-server and test.

root@router:~# opkg install iw-full
Installing iw-full (4.14-1) to root...
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mips_24kc/base/iw-full_4.14-1_mips_24kc.ipk
Collected errors:

  • check_data_file_clashes: Package iw-full wants to install file /usr/sbin/iw
    But that file is already provided by package * iw
  • opkg_install_cmd: Cannot install package iw-full.

Edit: Ok, it's possible to force remove iw and install iw-full, this changes the necessity of including it in default.

@mweinelt
Copy link
Contributor

mweinelt commented Dec 26, 2019

As far as I remember we considered this in Gluon, but the plink_action is not persisted across reconnects of mesh links.

The plink_action is stored in the station entry¹, so if the station goes missing in its entirety so does the plink_action. For this package to work we'd currently need a userspace application managing the blocklist and tracking station events via nl80211.

[1] https://elixir.bootlin.com/linux/v5.0-rc3/source/include/net/cfg80211.h#L981

freifunk-gluon/packages#118 (comment)

@nickbash11
Copy link

I did it that way

@SvenRoederer
Copy link
Contributor

@mweinelt Any idea if hostapd is working on this?

@nickbash11 your package makes it quite nice to use this function, even the bash script might not be the most ressource effective solution. I see some use for it and this package might provide a solution for the scenario mentioned by @goofus in comment #726 (comment).

@nickbash11
Copy link

nickbash11 commented Jul 9, 2020

@SvenRoederer I use it to prevent uninvited guests and any pests, because authsae decreases common speed of mesh network as I wrote in this post. It looks like an incompatibility with ath9k (HT40 mode) I think.

@mweinelt
Copy link
Contributor

mweinelt commented Jul 9, 2020

@mweinelt Any idea if hostapd is working on this?

Not to my knowledge.

@PolynomialDivision
Copy link

@goofus u can use my fork https://github.com/Freifunk-Spalter/packages and build your own freifunk image with full iw package using openwrt image builder.
If u have any questions how to use it, just mention me in matrix channel.

@SvenRoederer
Copy link
Contributor

Ok, that's actually surprising for me. I thought meshing via LAN is common. Now, if two routers see each over the air shouldn't they stop meshing over wifi to save airtime?
In my opinion 802.11s is a central technology and hence all settings should be adjustable by default (as it was in latest stable).

By theory when meshing over LAN and meshing over WiFi, the Routing-daemon should prefer the wired link. That's what I would expect. So on the wireless link there should only be "hello" traffic, which should not have a huge impact. But in case the LAN-link fails, the Wifi-link should jump in quite quickly.
Also as @mweinelt mentioned excluding a client will need need to be done on every reconnect.

@PolynomialDivision not sure how your mixup-feed will help with the initial issue of @goofus . I suggest to have a freifunk-berlin image with iw-full embedded to:

  • clone the freifunk repo
  • download freifunk-berlin-imagebuilder
  • unpack the imagebuilder
  • copy the iw-full*.ipk into the packages folder
  • tar.xz the folder again
  • modify an existing .package file in the packagelists folder to include iw-full in place of iw
  • run the Makefile to use a preexisting imagebuilder (https://github.com/freifunk-berlin/firmware#customizing-make)

This should build an image with with iw-full in just some minutes. Alternatively you can just modify a .package file and recompile all yourself.

@PolynomialDivision
Copy link

@PolynomialDivision not sure how your mixup-feed will help with the initial issue of @goofus .

It is more a tidied-up feed. ;) That is exactly the usecase why I forked, since I wanted to build my own images with imagebuilder and easily add packages, compile stuff, or install things with opkg.

@SvenRoederer
Copy link
Contributor

@SvenRoederer I use it to prevent uninvited guests and any pests, because authsae decreases common speed of mesh network as I wrote in this post. It looks like an incompatibility with ath9k (HT40 mode) I think.

As you talk on authsae: have a look at freifunk-gluon/gluon#1636 (comment) which references that authsae was dropped upstream, as it was not working well.

@nickbash11
Copy link

Anyway, devices with ath9k do not work properly with SAE.

@SvenRoederer
Copy link
Contributor

Not sure if we should capture this issue to discuss on SAE, esp for ath9k.

@goofus Not sure if my suggestion in #726 (comment) will fit your needs and I don't see a great interest in switching to iw-full. But feel free to open a PR, I don't see a reason for vetoing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants