Après avoir contribué à l'initiative pour Orange, j'ai décidé de mettre les mains dans le cambouis et de proposer une adaptation pour les abonnés Bouygues Telecom.
L'idée reste la même, mais adaptée aux spécificités du réseau de Bouygues : remplacer votre Bbox par un simple conteneur Docker.

Le projet est basé sur un fork de docker-livebox (https://github.com/Raraph84/docker-livebox) et permet de gérer l'authentification et la connexion directement depuis votre machine Linux (testé sous Debian).

Le projet est actuellement en phase "test++". Il demande encore quelques retours d'expérience pour être parfaitement stable dans toutes les configurations.
De mon côté, les tests ont été concluants sur deux environnements distincts Baremetal et en Virtualisation

Comme pour le projet initial, le but ici est d'avoir le système le plus "legacy" possible : votre IPv4/IPv6, un NAT et... bah rien d'autre


Lien vers le repo : https://github.com/TheHecateII/docker-bbox


Un grand merci à :

@Raraph84 : Pour la création du projet original.
@Mastah : Pour la tonne de ressources disponibles sur sa documentation. (Normalement pour Orange mais bien pratique dans mon cas)
Et l'ensemble des membres du forum

En travaillant sur l'adaptation pour Bouygues Telecom, je suis tombé sur un bug qui affecte le marquage de priorité CoS sur les interfaces VLAN.
Avec certains drivers réseau (comme bcmgenet sur Raspberry Pi ou virtio_net sur les VMs), utiliser nftables pour marquer la priorité CoS corrompt les paquets DHCP. L'adresse IP source se retrouve décalée de 2 octets.
Concrètement, un DHCP Discover qui devrait partir avec 0.0.0.0 part avec 0.0.255.255.
Chez Orange pas de souci, on peut envoyer sans problème un DISCOVER avec comme wildcard 0.0.255.255 en source, le DHCP nous répondra quoi qu'il arrive. Bouygues, de son côté, ne daignera même pas vous répondre :'(
De mon côté, passer la VM sur des cartes Intel E1000 depuis Proxmox fixe le souci.
Je ne pense pas que ce soit utile à grand monde, je le note ici au cas où ^^

Petite suite de mon post précédent, j'ai finalement trouvé un fix logiciel pour éviter de changer le matériel.

Plutôt que de patcher le kernel directement (J'ai absolument pas la compétence pour le faire...), je suis parti sur un petit programme eBPF attaché en TC egress sur l'interface VLAN.

Le truc c'est que dans le pipeline réseau Linux, le hook netdev egress de nftables s'exécute avant le TC egress. Du coup je laisse nftables faire son boulot de marquage CoS, et juste derrière je corrige ce qu'il a cassé avant que ça parte au driver.

Le programme en lui-même vérifie si un paquet UDP port 67 part avec 0.0.255.255 en source, on remet 0.0.0.0 et on recalcule le checksum IP de façon incrémentale.
L'avantage par rapport à un patch kernel c'est qu'on a pas besoin de recompiler quoi que ce soit, ça se charge au démarrage avec un tc filter add et ça vit dans le conteneur.
(corriger un bug kernel avec de l'eBPF qui tourne après nftables c'est pas franchement élégant  mais ça évite de se taper un patch kernel à maintenir)



À titre d'information, tout ce joyeux bazar tourne sur une VM Debian 13 avec 2 vCPU, 2 Go de RAM et avec des NIC VirtIO (yeepee)
Niveau performances ça juste marche, je sature bien mon Gbps : https://www.speedtest.net/my-result/d/86e1f0ac-c88c-43d9-82f0-8968872f791f