neocturne / fastd Goto Github PK

Hello,

I wanted to ask if there is a keepalive mechanism like WireGuard have. If no, this should be a feature request.

A keepalive mechanism is useful when one peer is publicly reachable but the other is behind a NAT / firewall. Assuming both are not communicating regularly, the NAT or firewall forgets the Conntrack entry and the public peer can no longer reach the other peer. Therefore a keepalive mechanism would be nice.

This could be implemented by sending a kind of ping every X (adjustable) seconds.

This is a reminder to take care of the OpenWrt init script before the next fastd release:

• Add support for multitap mode and multiple peers in TUN mode
• USE_PROCD
• Possibly other issues

Hi, as I’m not a skilled Linux coder, could you check if fastd could be used with MP-DCCP for multipath application (like Peplink Speedfusion)? MP-DCCP doesn’t offer any encryption, so the idea is to use fastd for this.
https://multipath-dccp.org/
https://multipath-dccp.org/encapsulation_framework.html
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-multipath-dccp/

Thanks!

Neither the readme, the wiki, nor the docs answer the question, “What is fastd?” I've read most of them and I still don't know.
I suggest adding an introduction section or just the sentence, “fastd is ________.” at the top.

Hello,

I created a simple docker based test setup (https://github.com/freifunkstuff/fastd-test). When running on a multi-core VPS, I can acieve up to 25mByte/s with encryption and 30 mByte/ss without encryption which both saturates one CPU core per client/server.

When I switch to l2to offloading, I the the maximum from my VPS (100 mByte/s) without any relevant CPU usage which is phantastic.

Do you see any chance to implement encryption over l2tp offloading? Or if not on l2tp offloading, is there maybe another kernel module (like wireguard or ipsec) that allows kernel offloading + encryption together?

IMO this is an extremely important feature to communities like "freifunk" which build L2 networks on top of fastd. There are other workarounds out there that uses wireguard + a L2 layer on top which adds a lot of complexity.

Hey there, I'm working on packaging this for gentoo right now, and in the process I'm writing openrc and systemd services. Would you be interested in me upstreaming them here? I'm happy to work with you if you have any qualms with the way I implement them too.

https://github.com/rlei/fastd-android says it was merged in but I don't see https://git.universe-factory.net/fastd/tree/doc/build-fastd-android.sh

Is this repo a fork?

Hi,

I'd like to propose an idea for load-balancing fastd connections over a set of know end-points.

We (Freifunk Hochstift) are setting up more POPs with different upstreams and I would like to steer client connections from CPEs to the nearest POP (for whatever definition of near, see strategies below).

The general idea is do set up (a number of) fastd LBs/controllers where the fastd "client" will connect to if configured to do so and will be pointed to it's nearest server. For security reasons the server will be specified as a string which has to be part of the clients fastd.conf (FQDN + port or IP + port). (Maybe the check against the config can be deactivated with a config option in the client, if people would want to see that, really.) The fastd client will then connect to the hinted server (if found within it's config) or any peer if there was no match.

The only role of the LB/controller will be to hint a client to a fastd peer and it will never see any traffic. Redundancy will be achieved by having multiple controllers configured in the client config and allowing multiple DNS-RRs for one FQDN. The controller should allow implementing multiple strategies the first one will be "same AS" where for example CPEs with an IP from $ISP will be directed to a peer within the same ASN. It would probably be cool to allow using multiple strategies in a configured order (first match wins). There might by other ideas for what useful strategies are like "bandwidth available", "CPU usage", etc. (where ever this information will come from is left as an exercise for the operator).

What I'm unsure about is how to handle multiple "sites", "domains" or how ever those are called, as in a Freifunk setup not all peers might have all sites/domains configued for various reasons. So the client has to specify the site/domain or the controller has to listen on multiple ports and deduce this information from there (we use different ports for different sites/domains).

I propose a text only protocol like
getBestPeer [SITE]
which will return
peerId IDENTIFIER
and/or
peerInfo FQDN PORT
one per line.

This whole endeavor will obvious increase the time to set up a connection but will most likely improve the performance and latency afterwards. I intend to hack together a PoC for the LB in Python shortly and if that turns out to be anything like I hope I guess I guess I will implement a more production ready one in Golang and contribute patches for fastd.

I would welcome feedback on this, especially on the site/domain part :)

(Originally raised in freifunk-gluon/gluon#2019)

Currently fastd needs one syscall to obtain/deliver a every packet from/to the kernel. The idea is to avoid this by obtaining and delivering multiple packages per syscall.

@NeoRaider wrote:

With Kernel 5.4, we have everything we need in io_uring, making any sendmmsg/recvmmsg-based solution inferior (and we don't need additional kernel patches). So if we make the effort to rework the way fastd handles packets, it should be based on io_uring.

A preliminary test using recvmmsg/sendmmsg showed a performance gain of approximately 30% on a small mips based router with a batch size of 64 (see original thread for details).

The interface value in the peers dictionary is null for connections that use null@l2tp and l2tp offload, and populated for those with other ciphers, like salsa2012+umac.

Relevant config settings:

interface "peer-%k";
persist interface no;
mode multitap;
offload l2tp yes;

Given the interface pattern fastd should be aware of all interface names.

Happens on 22-2~bpo11+1.

Hello,
using fastd21 on openwrt master.

/etc/init.d/fastd start results in

Syntax: /etc/init.d/fastd [command]

Available commands:

        show_key        shows the public keys of the instances given as
                        additional arguments
        generate_key    generates the private keys for the instances given as
                        additional arguments and saves them in the configuration
                        (when there in no key configured yet)
        running         Check if service is running
        status          Service status
        trace           Start with syscall trace

as does /etc/init.d/fastd start myinstance, or restart, or enable.

Hello,

I would like to know which encryption variants offers PFS in fastd?

Unfortunately I haven't found a forum or anything similar, so I'm posting my question here as an issue. If this is the wrong place for it, I'm sorry.

If my calculations are correct, this is the best base MTU: Visual packet size calculator — Daniil Baturin

If I want to add batman futher, I have to add another ethernet frame and IP on top of it, so the new MTU would be like this: Visual packet size calculator — Daniil Baturin

I'm not sure if I made the calculations wrong

Hello,

I'm using fastd v18 on ubuntu 20 and debian 10
have 5 nodes
tap interfaces
switch mode
two on nodes has "forward yes" setting, other - no
this setup works stable
as soon as I change at any of other three nodes forward from "no" to "yes" I get arp flood like this

15:03:28.800343 ARP, Request who-has 10.10.99.225 tell 10.10.99.10, length 28
15:03:28.800432 ARP, Request who-has 10.10.99.225 tell 10.10.99.10, length 28
15:03:28.801812 ARP, Request who-has 10.10.99.225 tell 10.10.99.10, length 28
15:03:28.801893 ARP, Request who-has 10.10.99.215 tell 10.10.99.10, length 28
15:03:28.801904 ARP, Reply 10.10.99.215 is-at d2:7f:ba:10:91:fd, length 28
15:03:28.802356 ARP, Request who-has 10.10.99.215 tell 10.10.99.10, length 28
15:03:28.802365 ARP, Reply 10.10.99.215 is-at d2:7f:ba:10:91:fd, length 28
15:03:28.806504 ARP, Request who-has 10.10.99.225 tell 10.10.99.10, length 28
15:03:28.837806 ARP, Request who-has 10.10.99.225 tell 10.10.99.10, length 28
15:03:28.837913 ARP, Request who-has 10.10.99.215 tell 10.10.99.10, length 28
15:03:28.837923 ARP, Reply 10.10.99.215 is-at d2:7f:ba:10:91:fd, length 28
15:03:28.839092 ARP, Request who-has 10.10.99.225 tell 10.10.99.10, length 28
15:03:28.842301 ARP, Request who-has 10.10.99.225 tell 10.10.99.10, length 28
15:03:28.844137 ARP, Request who-has 10.10.99.215 tell 10.10.99.10, length 28
15:03:28.844154 ARP, Reply 10.10.99.215 is-at d2:7f:ba:10:91:fd, length 28
15:03:28.844230 ARP, Request who-has 10.10.99.225 tell 10.10.99.10, length 28
15:03:28.846769 ARP, Request who-has 10.10.99.215 tell 10.10.99.10, length 28
15:03:28.846779 ARP, Reply 10.10.99.215 is-at d2:7f:ba:10:91:fd, length 28
15:03:28.850793 ARP, Request who-has 10.10.99.225 tell 10.10.99.10, length 28
15:03:28.856999 ARP, Request who-has 10.10.99.225 tell 10.10.99.10, length 28
15:03:28.879528 ARP, Request who-has 10.10.99.225 tell 10.10.99.10, length 28
15:03:28.883158 ARP, Request who-has 10.10.99.215 tell 10.10.99.10, length 28
15:03:28.883174 ARP, Reply 10.10.99.215 is-at d2:7f:ba:10:91:fd, length 28
15:03:28.886000 ARP, Request who-has 10.10.99.225 tell 10.10.99.10, length 28
15:03:28.887729 ARP, Request who-has 10.10.99.225 tell 10.10.99.10, length 28
15:03:28.887837 ARP, Request who-has 10.10.99.215 tell 10.10.99.10, length 28
15:03:28.887847 ARP, Reply 10.10.99.215 is-at d2:7f:ba:10:91:fd, length 28
15:03:28.889483 ARP, Request who-has 10.10.99.215 tell 10.10.99.10, length 28
15:03:28.889492 ARP, Reply 10.10.99.215 is-at d2:7f:ba:10:91:fd, length 28
15:03:28.889547 ARP, Request who-has 10.10.99.225 tell 10.10.99.10, length 28

is it bug or feature?

According to bridge
https://man7.org/linux/man-pages/man8/bridge.8.html

We can try to do

ip link add <ifaceName> type vxlan \
  id <randomID> \
  dstport <bindPort> \
  local <listenAddr>
bridge fdb append 00:00:00:00:00:00 dev vxlan100 <peer1addr> port <peer1port>
bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst <peer1addr> port <peer2port>

In fact I believe this is what Calico and Flannel does behind the scene

👋 running into the build issue with fastd 20 and 21 releases. The error is as follows:

==> ninja -v
[1/67] clang -Isrc/fastd.p -Isrc -I../src -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Wextra -std=c99 -O3 -D_GNU_SOURCE __APPLE_USE_RFC_3542 -MD -MQ src/fastd.p/main.c.o -MF src/fastd.p/main.c.o.d -o src/fastd.p/main.c.o -c ../src/main.c
FAILED: src/fastd.p/main.c.o 
clang -Isrc/fastd.p -Isrc -I../src -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Wextra -std=c99 -O3 -D_GNU_SOURCE __APPLE_USE_RFC_3542 -MD -MQ src/fastd.p/main.c.o -MF src/fastd.p/main.c.o.d -o src/fastd.p/main.c.o -c ../src/main.c
clang: error: no such file or directory: '__APPLE_USE_RFC_3542'

Full error log in here, https://github.com/Homebrew/homebrew-core/runs/1324700334
relates to Homebrew/homebrew-core#62644

Fastd, last version compiles fine on OpenBSD 6.6 (October 2019 release).

Configuring with tap interface

mode tap;
interface "tap2" ;

complains with an error:

2019-10-25 18:18:08 +0200 --- Error: config error: tap2 doesn't seem to be a TUN device

I think issue is related to the tun/tap equivalence on the past OpenBSD versions.
Now tap(4) is a separate device.

Hi!
I have a simple installation, so far to test how fastd fits my needs: 2 Ubuntu VMs in QEMU, both with white IPs, with several vlans.
The idea is to bridge those vlans on both sides with fastd tap interfaces and make a single L3 network per-vlan.

The daemons start, and as far as I see in syslog, connect successfully. I tested different MTU and cyphers - if they are different, the connection fails, so, they DO speak to each other.

But when I bridge them with existing interfaces in vlans, no traffic goes through. Even if I set an IP to fastd tap interface, they do not ping each other. The TX grows, RX stays zero.
And also, is it ok that the macaddr of interfaces on both vms is the same? Can I set it manually?

Every day the offloader in our hackspace reconnects to a gateway and the link ends up down, because the establish hook is not called. This connection always uses null@l2tp and we are using a multitap setup.

May 05 12:23:30 gw02.darmstadt.freifunk.net fastd@dom1_1312[4775]: received handshake from <64283-darmstadt.ccc.de>[[hidden]:56205]
May 05 12:23:30 gw02.darmstadt.freifunk.net fastd@dom1_1312[4775]: responding handshake with <64283-darmstadt.ccc.de>[[hidden]:56205]...
May 05 12:23:30 gw02.darmstadt.freifunk.net fastd@dom1_1312[4775]: received handshake finish from <64283-darmstadt.ccc.de>[[hidden]:56205] using fastd v22
May 05 12:23:30 gw02.darmstadt.freifunk.net fastd@dom1_1312[4775]: handling handshake finish with <64283-darmstadt.ccc.de>[[hidden]:56205]...
May 05 12:23:30 gw02.darmstadt.freifunk.net fastd@dom1_1312[4775]: [hidden]:56205 authenticated as <64283-darmstadt.ccc.de>
May 05 12:23:30 gw02.darmstadt.freifunk.net fastd@dom1_1312[4775]: initializing L2TP offload device...
May 05 12:23:30 gw02.darmstadt.freifunk.net fastd@dom1_1312[4775]: L2TP offload device `peer-5227d2430a' initialized.
May 05 12:23:30 gw02.darmstadt.freifunk.net fastd@dom1_1312[4775]: new session with <64283-darmstadt.ccc.de> established using method `null@l2tp'.
May 05 12:23:30 gw02.darmstadt.freifunk.net fastd@dom1_1312[4775]: invalidating old session with <64283-darmstadt.ccc.de>
May 05 12:23:30 gw02.darmstadt.freifunk.net fastd@dom1_1312[4775]: cleaning left handshakes with <64283-darmstadt.ccc.de>
May 05 12:23:30 gw02.darmstadt.freifunk.net fastd@dom1_1312[4775]: received packet from offloaded session

The configuration roughly looks like this:

interface "peer-%k";
persist interface no;
mtu 1312;
mode multitap;
offload l2tp yes;

on establish async "/etc/fastd/hooks/establish dom1-peers";
on disestablish async "/etc/fastd/hooks/disestablish";

secret "...";

method "null@l2tp";
method "null";
method "salsa2012+umac";

and a successful connect looks like so:

May 05 19:11:21 gw05.darmstadt.freifunk.net fastd@dom1_1312[3144]: generating new handshake key
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd@dom1_1312[3144]: received handshake from <64283-darmstadt.ccc.de>[[hidden]:35872]
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd@dom1_1312[3144]: responding handshake with <64283-darmstadt.ccc.de>[[hidden]:35872]...
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd@dom1_1312[3144]: received handshake finish from <64283-darmstadt.ccc.de>[[hidden]:35872] using fastd v22
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd@dom1_1312[3144]: handling handshake finish with <64283-darmstadt.ccc.de>[[hidden]:35872]...
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd@dom1_1312[3144]: [hidden]:35872 authenticated as <64283-darmstadt.ccc.de>
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd@dom1_1312[3144]: initializing L2TP offload device...
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd@dom1_1312[3144]: L2TP offload device `peer-5227d2430a' initialized.
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd@dom1_1312[3144]: connection with <64283-darmstadt.ccc.de> established.
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd@dom1_1312[3144]: new session with <64283-darmstadt.ccc.de> established using method `null@l2tp'.
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd@dom1_1312[3144]: cleaning left handshakes with <64283-darmstadt.ccc.de>
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd[437330]: peer-5227d2430a::establish: Waiting for interface
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd[437330]: peer-5227d2430a::establish: Disabling accept_ra
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd[437330]: peer-5227d2430a::establish: Setting MTU to 1312
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd[437330]: peer-5227d2430a::establish: Waiting for bridge
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd[437330]: peer-5227d2430a::establish: Connecting to bridge
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd[437330]: peer-5227d2430a::establish: Isolating bridge port
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd[437330]: peer-5227d2430a::establish: Pulling link up
May 05 19:11:21 gw05.darmstadt.freifunk.net fastd@dom1_1312[3144]: child process 437328 finished

clang -Isrc/liblibfastd.a.p -Isrc -I../src -I/opt/homebrew/Cellar/libuecc/7/include/libuecc-7 -I/opt/homebrew/Cellar/json-c/0.15/include -I/opt/homebrew/Cellar/json-c/0.15/include/json-c -I/opt/homebrew/Cellar/[email protected]/1.1.1k/include -I/opt/homebrew/Cellar/libsodium/1.0.18_1/include -fcolor-diagnostics -Wall -Winvalid-pch -Wextra -std=c99 -O3 -D_GNU_SOURCE -D__APPLE_USE_RFC_3542 -MD -MQ src/liblibfastd.a.p/handshake.c.o -MF src/liblibfastd.a.p/handshake.c.o.d -o src/liblibfastd.a.p/handshake.c.o -c ../src/handshake.c
../src/handshake.c:293:14: error: implicit declaration of function 'htobe16' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
.length = htobe16(sizeof(header)),
^
1 error generated.

relates to

• Homebrew/homebrew-core#80211

full build log:
https://github.com/Homebrew/homebrew-core/runs/2939005147

Coming from a distributed computing perspective, I find it curious why can't we use a DHT to store all the peers' information -- like using Kademlia or even Raft to advertise/announce its IP addresses/available point of contacts, then we could do full mesh using this kind of dynamic configuration rather than statically placing peers ahead-of-time.

In fact, I'm about to experiment this with a FUSE filesystem that peers could self-exchange their network information, and use the include peers feature of fastd to dynamically reload them. Then I try to use any routing protocol like BATMAN-adv, OSPF or even BGP to calculate network paths -- to achieve high availability and fault tolerance during unusual network conditions.

The only problem left is how the would the nodr self-test their available endpoints. Some system of mine is behind NAT and do not have any port forwarding open, and some hole punching tech like WebRTC, STRN or TURN maybe needed. This would complicate routing though as the node information is likely transparent to the control plane at this point. What about having a gossip protocol?