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

gluon-alt-esc: add client + provider package #1094

Closed
wants to merge 1 commit into from

Conversation

T-X
Copy link
Contributor

@T-X T-X commented Apr 13, 2017

The client package allows to create a new wifi interface with direct access
to the local Freifunk network but with alternative exit gateways for internet
connectivity. A custom ESSID can be chosen.

The provider package is the counterpart to the client package and
configures the firewall of the selected Gluon node to grant permission to
route packets between the client and wan zone.

Note that the Gluon Alt-ESC provider package is not mandatory for the
Gluon Alt-ESC client package. In fact, any client device in the mesh network
can be chosen and configured to provide internet access for the Alt-ESC
client package.

@T-X
Copy link
Contributor Author

T-X commented Apr 13, 2017

Pictures for provider side:

01-altesc-provider-off

02-altesc-provider-stilloff

03-altesc-provider-on

Pictures for client side:

11-altesc-client-off

12-altesc-client-on

13-altesc-client-onv4only

@T-X
Copy link
Contributor Author

T-X commented Apr 13, 2017

I guess the question will arise, so trying to answer it beforehand:

Why an extra ESSID?

Two reasons:

  1. Friendly co-existence with neighboring nodes: Avoiding roaming issues, not everyone wants to use your or a potentially broken gateway.
    -> The idea is to keep the option to always choose the community maintained gateways
  2. But also de-etanglement concerning the (partial) commercial interests which arose in the past years. This would allow hotels, cafes, backeries etc. to choose an alternative exit independent of the community infrastructure (as long as they do not use the word "Freifunk" in the new, extra ESSID) while still contributing to it. Such a cleaner separation might become necessary if the charitable nature of Freifunk were to be accepted by the German government?

@T-X T-X added the 3. topic: package Topic: Gluon Packages label Apr 13, 2017

PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)

include $(INCLUDE_DIR)/package.mk
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be include ../gluon.mk with LEDE based builds. Same applies to the provider package.

@belzebub40k
Copy link
Contributor

/var/gluon/firewall.wan-nat6 should be located in /lib/gluon/firewall.wan-nat6 or even better /lib/gluon/alt-esc/iptables.rules like in gluon-mesh-vpn-core

https://github.com/freifunk-gluon/gluon/pull/1094/files#diff-d015fd309cc74651d3e87ac021f94017R66

local name = "altesc_" .. radio

if enabled.data then
local macaddr = util.get_wlan_mac(radio, index, 4)
Copy link
Contributor

@belzebub40k belzebub40k Apr 13, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

get_wlan_mac() changed and now needs the UCI config as additional parameter c4613c4

uci:commit('gluon-alt-esc-client')

i=0
util.iterate_radios(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

iterate_radios() changed and now needs the UCI config as additional parameter f48d10b

@jplitza
Copy link
Member

jplitza commented Apr 13, 2017

Wow. That's huge, both technically (haven't had a closer look yet but am baffled how this works) and politically. Thank you so much!

Politically, I partially disagree with your reasoning for a (forced) separate ESSID. I would vote for the option to be a regular gateway, unset by default, as this still satisfies argument 2 I think, and doesn't blindly force your gateway onto others by default. That first argument actually is quite weak IMO, because it is technically possible to set up a gateway that will be chosen by neighbors (and without radv-filterd even by everybode in the mesh in the case of IPv6).



get_gw_hosts() {
for gw in `batctl gwl | tail -n +2 | sed "s/.* \(..:..:..:..:..:..\) (.*/\1/"`; do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since batman-adv 2017.0 the header of batctl gwl consists of 3 lines.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also the output of batctl tg changed completely. The following works for my.

get_gw_hosts() {
	for gw in `batctl gwl | tail -n +3 | sed "s/.* \(..:..:..:..:..:..\) (.*/\1/"`; do
		batctl tg | egrep "^ \* .*$gw"
	done | tr -s ' ' | sed -r -e 's/\( +/\(/g' | cut -d ' ' -f 3 | sort | uniq
}

@SimJoSt
Copy link
Contributor

SimJoSt commented Apr 13, 2017

As the English language, contrary to the German language, likes to repeat itself, I would recommend:

I am brave and I know what I am doing.

@Adorfer
Copy link
Contributor

Adorfer commented Apr 14, 2017

i would suggest a renaming of this package to BoSE (S stands for steel, E for Exit).
(no, this was not completely serious.)

@T-X
Copy link
Contributor Author

T-X commented Apr 14, 2017

Thanks for all the feedback and eager bug hunting so far! Found one more and I hope they are fixed now (@belzebub40k, can you check that the new regex-ing works for you and your compat15 setup, too?).

@T-X
Copy link
Contributor Author

T-X commented Apr 14, 2017

@jplitza: Thanks for your valuable input! I like the idea of extending Alt-ESC with an option to provide an exit mesh wide for the standard ESSID. Yes, that should satisfy argument 2.

However, so far I couldn't think of a way to use the DNAT-ing trick for that without causing potential roaming issues for the standard ESSID. If you have an idea, maybe we can discuss that on IRC or the Gluon mailinglist?

@Adorfer
Copy link
Contributor

Adorfer commented Apr 15, 2017

If i understand correct, this will only affect (ap-)clients of the local node, correct?
In other words: clients in my local mesh network will still use the "domain wide" gateways.

If so, i would preferr an option, to signalize this exit with a very low bandwidth, in plus putting some additional hop penalty on the meshvpn link, so that clients in the local mesh use this local exit.
(if somebody want's to make it more complex, a 2nd batman mesh network using v(x)lan on wifi and ethernet may be a solution in "keep up the roadming", in order to have 2 different client ssids entirely in the local mesh cloud.

@belzebub40k
Copy link
Contributor

@T-X the sed statement to get the MACs from transglobal still does not work. With sed "s/^ \* \(..:..:..:..:..:..\) .*/\1/" I get the correct value.

@rotanid rotanid added the 0. type: enhancement The changeset is an enhancement label May 2, 2017
@Adorfer
Copy link
Contributor

Adorfer commented Jun 29, 2017

does this exist as an "optional package" somewhere for simply integration via site.mk?

@rotanid rotanid added the 2. status: merge conflict The merge has a conflict and needs rebasing label Jun 29, 2017
@rubo77
Copy link
Contributor

rubo77 commented Jul 28, 2017

I am also interested, it there is there an easy way to use this as external package, that we could add to our site.mk and modules?

It seems there are only two changes in other files in gluon. Why do you have to change this here in package/gluon-client-bridge/luasrc/lib/gluon/upgrade/310-gluon-client-bridge-local-node
https://github.com/freifunk-gluon/gluon/pull/1094/files#diff-76d6016c2161c4e59d20e3451e433bc7R22
and here in package/gluon-mesh-batman-adv/luasrc/lib/gluon/upgrade/320-gluon-mesh-batman-adv-client-bridge?
https://github.com/freifunk-gluon/gluon/pull/1094/files#diff-10c633ba2041d28348384ade31fb2f1cR34

@rubo77
Copy link
Contributor

rubo77 commented Jul 28, 2017

I created a standalone package at:

https://github.com/rubo77/gluon-alt-esc

these are the needed changes in our site.conf to include this package from my rubo77-repository: freifunk-kiel/site-ffki@ab47b6b...db9e873

@@ -19,8 +19,7 @@ uci:section('network', 'device', 'local_node_dev', {
local ip4, ip6

if site.next_node.ip4 then
local plen = site.prefix4:match('/%d+$')
ip4 = site.next_node.ip4 .. plen
ip4 = site.next_node.ip4 .. '/32'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you remove site.prefix4:match('/%d+$') ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The br-client needs a more specific route than the local-node one (/24 vs. /32) as otherwise the kernel would select the wrong interface for outputting de-nat'ed packets coming back.

@rubo77
Copy link
Contributor

rubo77 commented Jul 29, 2017

I renamed the upgrade files umbenannt: one number higher. 311 and 321 with the new content. this is a bit ugly, but should work and keep most of the original PR in the external package for now.

The firmware is build sucessfully and is running. Now I wonder what are the correct settings I have to put into config mode.

Can I just copy the Mac from the provider-section into the client section? And do I have to activate all checkboxes?

What about mesh-VPN, do I have to enable that if I want to use the alt-esc?

The router starts now in normal mode. And i can connect to the alternative ESSID ;)

Seems to run fine! 🎉

@rubo77
Copy link
Contributor

rubo77 commented Jul 30, 2017

I changed the texts, so they are more intuitive for not so advanced users: rubo77/gluon-alt-esc@e6c5246#diff-68586350a587e33d8e4ec7b3ca599fbdR43

Maybe you can take these changes into account in your PR?

alt-esc-client
alt-esc-provider

@jerix777
Copy link

jerix777 commented Jul 30, 2017

This is a great job ! Does it works like this http://paste.debian.net/hidden/8866b304/ ?

Alt-ESC is a Point-to-MultiPoints wireless link. So if the uplink node die all downlink nodes will be unreachable.
It could be more usefull to make it works with mesh link loop avoidance.

@rubo77
Copy link
Contributor

rubo77 commented Oct 17, 2017

@jerix777 your paste is not accessible. what is your question?

@rubo77
Copy link
Contributor

rubo77 commented Oct 17, 2017

@T-X: Good Idea! You pointed out in IRC

  1. that we should use the long texts "Mac of the node, that serves as..." should be placed as hints below the fields. the same style like "(unchangeable,...)"

  2. the wording "bypassing the Freifunk-Gateeways" must be replaced with "bypassing the community gateways"

  3. "via this node via Alt-ESC-Client" add a "for instance"

@rubo77
Copy link
Contributor

rubo77 commented Oct 17, 2017

I updated my standalone package at https://github.com/rubo77/gluon-alt-esc

New screenshots:

auswahl_127

auswahl_126

@Tarnatos
Copy link

Nice +1

@T-X
Copy link
Contributor Author

T-X commented Jul 8, 2018

@CodeFetch: See @MPW1412's question here:

#1094 (comment)

And my response here:

#1094 (comment)

Anything to add to that?

@CodeFetch
Copy link
Contributor

@T-X Yes, you need to filter 172.16.0.0/12, 10.0.0.0/8, 192.168.0.0/16 and maybe also compatibility/dummy addresses 192.0.0.8/32 and 192.0.0.0/29.

@T-X T-X force-pushed the pr-gluon-alt-esc branch from 56a9cc4 to 99f178c Compare July 11, 2018 16:11
@T-X
Copy link
Contributor Author

T-X commented Jul 11, 2018

Changelog v3:

  • Rebase to master / v2018.1:
    • Switched BuildPackage to BuildPackageGluon for simplified Makefiles
    • Changed ebtables calls to ebtables-tiny
    • Changed util.iterate_radios() to util.foreach_radio()
    • Changed "radio" in Lua code to "radio['.name']" to fetch the radio device name
    • Moved luasrc/lib/gluon/web/ folder to luasrc/lib/gluon/config-mode/

Dependencies: #1472 and packages/#191

T-X added a commit to freifunk-luebeck/site-ffhl that referenced this pull request Jul 11, 2018
I'm using the (still pending) gluon-alt-esc package [0] here
in Lübeck and for that it'd be nice to have the extra_prefixes6
added.

Another potential user of this value is the
gluon-ebtables-source-filter package. However that one is not
in use in Lübeck by anyone so far as far as I know.

[0]: freifunk-gluon/gluon#1094
@rubo77
Copy link
Contributor

rubo77 commented Jul 11, 2018

@T-X : can you add your changes to my repo here? https://github.com/rubo77/gluon-alt-esc/commits/2018.1.x

@christf
Copy link
Member

christf commented Nov 10, 2018

marking this as needs work as per discussin in #1472

The client package allows to create a new wifi interface with direct access
to the local Freifunk network but with alternative exit gateways for internet
connectivity. A custom ESSID can be chosen.

The provider package is the counterpart to the client package and
configures the firewall of the selected Gluon node to grant permission to
route packets between the client and wan zone.

Note that the Gluon Alt-ESC provider package is not mandatory for the
Gluon Alt-ESC client package. In fact, any client device in the mesh network
can be chosen and configured to provide internet access for the Alt-ESC
client package.

Signed-off-by: Linus Lüssing <[email protected]>
@T-X T-X force-pushed the pr-gluon-alt-esc branch from 99f178c to 3d6cd44 Compare November 15, 2018 01:10
@T-X
Copy link
Contributor Author

T-X commented Nov 15, 2018

Changelog v4:

  • Rebase to master:
    • "local site = require 'gluon.site_config'" -> "local site = require 'gluon.site'"
      => not available anymore since f1f2bae
      ("gluon-core: remove obsolete gluon.site_config library")
    • "... = site.site_code" -> "... = site.site_code()"
    • firewall: renamed zone "client" to "mesh"
      => renaming introduced by 1c1c9f8
      ("gluon-core: firewall rework, make base policy more restrictive")
  • moved dependency for KERNEL_BRIDGE_EBT_DNAT and KERNEL_BRIDGE_EBT_REDIRECT from gluon-ebtables to gluon-alt-esc-client as requested in gluon-ebtables: build kernel with ebt_dnat and ebt_redirect #1472

Note, that this pull-request should now only be merged after #1472 and #1568 were merged. This pull-request was retested together with #1472 and #1568 on top of current master.

@rotanid rotanid added 2. status: blocked Marked as blocked because it's waiting on something and removed needs work labels Nov 15, 2018
@rotanid
Copy link
Member

rotanid commented Nov 15, 2018

thanks. i removed the "needs work" label and added the "blocked" label (as both of the other PRs have to be merged before this one) and the "needs testing" label

@rotanid rotanid added the 5. needs: testing Testing of the changes is necessary label Nov 15, 2018
@yanosz
Copy link
Contributor

yanosz commented Aug 13, 2019

I like your idea <3 - unfortunatly, I won't be able to test it in the next weeks.

At a quick glance, the UX appears a little bit complicated, but that won't be a problem for a first try.

@mweinelt
Copy link
Contributor

mweinelt commented Nov 4, 2019

This package is intended for the community repository, which is soon to be created.

@2tata
Copy link
Contributor

2tata commented Nov 4, 2019

@mweinelt sharing of the local internet connection could be a nice core feature! In combination with ddhcp or xlat. So people can be able to easy turn a gluon node into a supernode.

@mweinelt
Copy link
Contributor

mweinelt commented Nov 4, 2019

It could be, what we're not quite there yet. And alt-escape being in community packages will not make that impossible either.

If this use case turns out to be practical there is not much that would prevent a package to migrate from community repos to the main repo.

A current issue we have with this package is that it makes use of L2 NAT via ebt_dnat, which we consider to be a hack.

@rubo77
Copy link
Contributor

rubo77 commented Nov 4, 2019

Are all changes in Gluon accepted, so this can become a stand-alone package?

@mweinelt
Copy link
Contributor

mweinelt commented Nov 4, 2019

It looks like they will be, we've just discussed what is necessary and what needs to be reviewed again.

Blockers are here:

@mweinelt
Copy link
Contributor

mweinelt commented Jun 8, 2021

Closing as we will not accept this into the core repository, as stated above.

@mweinelt mweinelt closed this Jun 8, 2021
@rubo77
Copy link
Contributor

rubo77 commented Aug 1, 2021

That really is a pitty.

Is there another way, how we could re-implement a local exit then this into gluon?

@smoe
Copy link
Contributor

smoe commented Aug 5, 2021

I followed @AlylonPrime's link in response to my feature request to this module and, well, what can I say, it reads fantastic. And I wish this thread had a Hollywood ending.

So, I can only second @rubo77 and ask for just anything, really :o/

@Adorfer
Copy link
Contributor

Adorfer commented Aug 6, 2021

Is there another way, how we could re-implement a local exit then this into gluon?

the blockers statet by mweinelt in #1094 (comment) were quite clear.
Adressing them might have helped.
If there is an alternative route? Who knows? Probably there might be issues too, but perhaps less.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0. type: enhancement The changeset is an enhancement 2. status: blocked Marked as blocked because it's waiting on something 3. topic: package Topic: Gluon Packages 5. needs: testing Testing of the changes is necessary
Projects
None yet
Development

Successfully merging this pull request may close these issues.