"Exceeded MaxStartups" : erreur du monitoring sur des services ouverts sur le monde en SSH… jamais vu.
En fait il s'agit d'une limite pour éviter les DoS, ajoutée dans OpenSSH en… 2000, MaxStartups. En gros un mécanisme pour limiter puis interdire les nouvelles connexions lorsqu'il y en a trop d'ouvertes mais pas abouties simultanément.
J'ai passé le minimum de déclenchement de 10 à 15. À voir si ça suffit.
Et oui c'est sur un port différent de 22 (trolls proof). Et oui il y a déjà fail2ban, mais il faut croire qu'il a pas le temps de réagir.

Attention : si on modifie la commande forcée liée à la clef SSH (command=) utilisée pour la connexion ControlMaster, il faut relancer la connexion, le fichier n'est pas relu.

Ne pas oublier que pour un service systemd, stdin est /dev/null… sinon on peut passer du temps de debug bizarre au moment où on veut passer un script en service systemd… ici socat, qui y est très sensible puisque c'est son seul taff (de gérer des flux).

Je voulais pouvoir fournir un flux d'informations d'un script shell (bash) à quiconque voudrait le recevoir et jouer avec.
Forcément, on pense à un fifo en premier, mais les write sont bloquants. A priori pas simple le O_NONBLOCK en bash.
Ensuite on pense à des socket UNIX, sauf que c'est celui qui écoute qui la crée, et on ne peut pas écouter à plusieurs.
Ce thread fait un peu le tour. Une proposition parle de détourner UDP pour ça, car en mode datagram les paquets sont envoyés sans connexion, donc peuvent être perdus.
Avec socat c'est très facile (udp-datagram / udp-recv). Et l'envoi n'est effectivement pas bloquant. Par contre si on écoute à plusieurs sur le port, en mode reuseport, on n'a pas de duplication mais un balancing. La duplication s'effectue en mode broadcast (possible sur 127.255.255.255 par exemple).

socat udp-recv:3333,reuseport -
socat - udp-datagram:127.255.255.255:3333,broadcast <<< coucou

Ho sympa ça, l'implémentation OpenSSH permet de créer une connexion persistante "ControlMaster" qu'on pourra utiliser par la suite pour aller taper régulièrement sur un serveur sans à chaque fois refaire la connexion à zéro (et donc spammer les logs, manger la latence etc.).

Lancée via autossh, on a donc une sorte de connexion permanente et qui doit être résiliente en cas de coupure (volontaire ou panne).

Donc WDS c'est le nom d'une "techno" pas standardisée, que beaucoup de fabriquants d'antennes (wifi) implémente à sa sauce mais donc pas compatible entre eux. J'ajouterai que si t'es un gros malin comme moi et l'active d'un côté de ton pont wifi mais pas de l'autre, bah ça pas marche non plus :)

En gros ils se débrouillent pour rendre les antennes transparentes sur le LAN, en ne modifiant pas l'adresse MAC des paquets alors que les antennes sont en réalité en intermédiaire. Comme un switch quoi.

J'ai testé avec et sans, et effectivement avec j'ai bien la MAC du client derrière le pont d'antennes qui remonte jusqu'au bout. Pourquoi pas, c'est toujours ça de charge en moins et ça aide au débug.

Debug résal des deux derniers jours, on a (re)vu plein de notions, et appris quelques commandes/sysctl sympas !

Depuis le temps que je bidouille du /e/n/i je n'avais jamais eu à mettre plusieurs IP au même bloc iface… en fait c'est simple (apparemment depuis iproute2), il suffit de mettre 2 blocs iface. Même que ça marche (sous Buster) !

Pour faire un gros transfert (plusieurs centaines de To), j'ai tenté d'après cette réponse le coup de tar + mbuffer. Avec de gros buffers côté mbuffer, c'est vraiment pas mal. Et mbuffer gère lui-même la partie réseau (avec -I et -O). On pourrait peut-être imaginer compresser en plus ou éviter les header de tar mais c'est déjà pas si mal je trouve.
Sur réseau 10 Gbps, on arrive à monter à du 250 Mo/s avec le vent dans le dos : c'est probablement un des systèmes de fichiers distribué qui traine, le transfert tourne alors que tout est en prod, etc. En tous cas c'est beaucoup plus rapide qu'un simple rsync (encore heureux). Mais forcément on ne peut pas reprendre s'il y a un crash…

Notes de mon approche pour passer sur une fibre Orange du vieux PPPoE à DHCP. Le principal problème étant que dans ma zone il est nécessaire de taguer les paquets DHCP avec la bonne priorité VLAN… j'ai donc patché busybox et odhcpc6.

À noter qu'au passage, j'ai de l'IPv6 native, un débit qui passe de 100/100 à 400/400 et je ne remonte plus forcément à Paris (donc meilleur routage vers Francfort par exemple et géoloc au bon endroit). Et aussi, plus de changement d'IP systématique toutes les semaines, même si l'IP risque de changer quand même en cas de coupure prolongée.

… en tous cas sur un Tplink Archer C7 v4, le hardware offloading fonctione avec OpenWRT 19.07 ! Je suis passé de environ 350 mbps avec iperf3 à 750 mbps (donc proche de la limite à 800 de mon abonnement fibre). C'est pas mal de savoir qu'un firmware libre arrive à ces débits sur du NAT sur un routeur grand public.

À savoir que l'offload se fait à coup de règles iptables, se configure donc au niveau du firewall (et si on utilise l'interface luci, ce sont des cases à cocher : Système -> Firewall -> software offload et hardware offload).

Exemple :
FLOWOFFLOAD all -- anywhere anywhere / !fw3: Traffic offloading / ctstate RELATED,ESTABLISHED FLOWOFFLOAD hw