Fix Pirania issue/1206 and overall captive portal stability

[usg-ishimura]

This PR addresses issue #1206, before this changes when a client connected to a secondary node's AP, the primary node's (wan) nftables received the source mac address of the secondary node itself instead of the client's, blocking in fact internet access for the client even after the authentication process via voucher or read for access. I chose an hybrid solution to the problem checking that ips and macs of the clients are in the authorized lists and adding secondary nodes ips and macs to the whitelists by default. So when a client connects to a secondary node AP the elements in the whitelists should be the mac address of the secondary node and the ip of the client, when a client connects to a primary node AP the elements in the whitelists should be the mac address of the client and the ip of the client. This PR contains the commits from #1219 so i'm closing that one.

This PR can be tested adding this repo in the feeds
src-git libremesh https://github.com/usg-ishimura/lime-packages.git;issue/1206

The update works with my GL-AR300M16 routers on OpenWrt v23.05.5 but it needs further testing for sure.

[ilario]

@luandro @henmohr @tdruiva @bvianna

[henmohr]

Hey, nice work @usg-ishimura!
Just changed gateway.info to thisnode.info (because it's kinda standard for LiMe), copied files to Xunlong Orange Pi R1 Plus LTS running LiMe 2024.1 2024.1 Fantastic Forwarder ((no branch) rev. a9488ae 20250209_1659) , enabled captive portal via lime app, created a voucher and seems to work fine. Need more testing with more devices but it's very proeminent!

[usg-ishimura]

Hi @henmohr,
thanks for testing, the only reason I used gateway.info in the code is because thisnode.info can take the value of both the primary and secondary node, while gateway.info points only to the primary node address, the one that is wan connected. You can see the value that gateway.info take in pirania-mesh-sync

[Jadhav-Dhanashri]

Hello maintainers ,
I'm new to freifunk.net open source contribution & this would be my first issue. I'd like to work on this if it's available & learn from the process. Could you please assign it to me?
Thank you !

[ilario]

Hello maintainers , I'm new to freifunk.net open source contribution & this would be my first issue. I'd like to work on this if it's available & learn from the process. Could you please assign it to me? Thank you !

As I mentioned in #886 (comment) "This is being tackled by some people right now".

[usg-ishimura]

I saw the recent hackathon activity around Pirania going on in #1239 unfortunately that week I was fully booked with work, so I couldn’t really join or follow the implementation details.

I just wanted to leave one concrete observation that came up during my tests and that might be relevant to the ongoing work, without diving into the current code changes:

When a client connects through a secondary mesh node and successfully enters a voucher, the primary (WAN) node appears to receive traffic with the MAC address of the secondary node, not the client’s MAC. Since Pirania relies on MAC-based authorization at the WAN side (nftables), the voucher is accepted by the portal but the traffic remains blocked because the primary node never sees the client’s MAC in the authorized set.

This seems to be why voucher access works when connecting directly to the primary node, but fails when clients attach to secondary nodes.

Just wanted to share this behavior in case it helps align the authorization logic with what the WAN node actually sees.

[henmohr]

Hey @usg-ishimura you are totally right! Your script does an amazing job, thanks for putting a lot of effort in helping us to solve this!
We are currently looking forward to use shared-state as a source of truth, because shared-state sync authorized vouchers in the mesh. So we think would be simpler to populate the mac set here with the source-of-truth being the shared state. What do you think?

Thanks!!

[usg-ishimura]

Hey @henmohr, thanks for the feedback!

I totally agree that using shared-state as a source of truth makes a lot of sense for a mesh architecture. Having a distributed database that automatically syncs across all nodes is definitely the right approach, and I can see how it would simplify a lot of the complexity I was trying to handle manually.

My script was essentially a workaround to solve the immediate problem I was facing: getting clients connected through secondary nodes to actually access internet after voucher activation. It works in my test setup, but I recognize it's more of a patch than a proper architectural solution.

Looking forward to seeing the final solution merged!

[catuaba07]

Hey all!!!
Thank you for your work to get pirania back to track.

Seems shared-state is doing its job. I tested here with 2 routers, both of them using the package shared-state-pirania and all vouchers got sync.

About adding neighborhood nodes to a whitelist, what was done at #1239 is to control only the interface where clients' traffic are going to flow. Mesh and cable interface are not controlled by pirania.