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

Add ffbs-parker-nextnode #139

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

SmithChart
Copy link
Contributor

@SmithChart SmithChart commented Nov 6, 2024

Thia adds ffbs-parker-nextnode - a package of the parker-flavor of Gluon.

This package provides ebtables-rules that redirect traffic to the
localnode IPs on the node itself.

This is needed in networks where the localnode addresses are outside the client network - for example when
using with parker.

In Freifunk Braunschweig, for example, the localnode address is 2001:bf7:382:0::1.
But the IP addresses of routers and clients are in 2001:bf7:381::.
With this rule traffic to the localnode address is always forwarded to the router.

(The service on the router should redirect the client to one of routers public addresses - otherwise the TCP connection
would break when the client roams to another node with the same redirect.)

Previously this package has been managed in
https://gitli.stratum0.org/ffbs/ffbs-packages under the name gluon-ffbsnext-nextnode.
Last commit-id: 2241cee3e4be96ded955f6bfd40a42cd9b7e53ac

TODO:

Thia adds ffbs-parker-nextnode - a package of the *parker*-flavor of
Gluon.

Previously this package has been managed in
https://gitli.stratum0.org/ffbs/ffbs-packages under the name
`gluon-ffbsnext-nextnode`.
Last commit-id: 2241cee3e4be96ded955f6bfd40a42cd9b7e53ac
@SmithChart SmithChart requested a review from grische November 6, 2024 20:51
local macaddr = client_bridge.next_node_macaddr()

if next_node.ip4 then
rule('PREROUTING -p IPv4 -d ! ' .. macaddr .. ' --ip-dst ' .. site.next_node.ip4() .. ' -j dnat --to-dst ' .. macaddr .. ' --dnat-target ACCEPT', 'nat')
Copy link
Contributor

Choose a reason for hiding this comment

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

Is the usage of next_node.ip4 and site.next_node.ip4() intentional? Same for ip6.


define Package/ffbs-parker-nextnode
TITLE:=gluon-nextnode config for parker
DEPENDS:=+ffbs-parker-nodeconfig
Copy link
Contributor

Choose a reason for hiding this comment

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

As #142 is still WIP, is this name fixed?

Copy link
Member

Choose a reason for hiding this comment

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

I would rather remove the depends here, and add a dependency to ffbs-parker-nextnode on ffbs-gluon-mesh-vpn, as this package is quite standalone, but the other can only be used efficiently in combination with this package.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't see why anyone would use this package without ffbs-parker-nextnode (aka the ffbs-parker-vpn-provider). But you are right regarding the direction of the dependency.

Copy link
Contributor

@grische grische Dec 8, 2024

Choose a reason for hiding this comment

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

Let's change it then and drop the DEPENDS. We can add the new DEPENDS to ffbs-mesh-vpn-parker .

$(CP) ./files/* $(1)/
endef

$(eval $(call BuildPackage,ffbs-parker-nextnode))
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe use BuildGluonPackage here

@blocktrron
Copy link
Member

@rotanid briefly discussed the compatibility of this package with unpatched gluon - are there plans on upstreaming the necessary core changes to gluon?

@SmithChart
Copy link
Contributor Author

@rotanid briefly discussed the compatibility of this package with unpatched gluon - are there plans on upstreaming the necessary core changes to gluon?

tl;dr: Yes, we plan to do so.

Long answer: It will take some more steps:

Make sure parker is usable for other communities.
To do so we bring all our packages into community-packages and also start to maintain a fork of gluon that provides a patched base-gluon for others to use.
We at FFBS will keep our gluon modifications away from this in our Gitlab.
We will also need to move our Gluon packages fork with modifications to Github, so others can contribute.

This is where we are at now.

Test the new system, at least in our network (maybe even in other communities)
This way we can make sure that we did not break anything during refactoring.

Fix fallout
Well, I am sure we will break something 😁

Discuss how the patches from our fork can be brought into Gluon
Most of our changes will probably need some compile-time switches in packages built in gluon. This will very likely take some time. And thb I am not sure if I am the right person to handle this.

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

Successfully merging this pull request may close these issues.

4 participants