Auteur Sujet: Remplacement de la Livebox par un routeur Openwrt (Lu 645940 fois)

basilix · « **Réponse #1416 le:** 27 septembre 2026 à 20:50:42 »

Citation de: zoc

Franchement vous vous faites des nœuds au cerveau pour rien... Ça fait 6 ans que j'ai la même chaîne d'authentification.

Je constate des zones d'ombres qui ne sont pas documentées. Cela n'aide pas à avancer et « tout bouge autour ».
De plus, personne ne me l'expliquera. Je trouve cela gênant.

L'IA a sorti un petit script. Mais il y a encore des choses qui m'échappent car je ne parviens pas à me représenter le
fonctionnement global. Je comprends le script.

Code: [Sélectionner]

#!/bin/sh

set -e

LOCK=/run/dhcp-auth-refresh.lock
AUTH=/etc/dhcp/authentication.conf
TMP="${AUTH}.tmp.$$"

exec 9>"$LOCK"
flock -x 9

trap 'rm -f "$TMP"' EXIT

ubus call network.interface.wan down
ubus call network.interface.wan6 down

while pidof udhcpc >/dev/null 2>&1 ||
      pidof odhcp6c >/dev/null 2>&1
do
    sleep 1
done

/usr/local/sbin/generate-dhcp-auth.sh > "$TMP"

chmod 600 "$TMP"
chown root:root "$TMP"

mv -f "$TMP" "$AUTH"

ubus call network.interface.wan up
ubus call network.interface.wan6 up

flock -u 9

Dans le fond je m'en fous un peu de trouver comment renouveler l'info d'authentification. C'est plus pour ne pas
être embêté.

basilix · « **Réponse #1417 le:** 01 octobre 2026 à 07:10:58 »

J'ai relu le RFC2131 car j'en ai besoin pour bien comprendre les sources d'odhcpd. L'idéal aurait été de réaliser une capture sur le réseau Orange pendant plusieurs jours
mais il aurait fallu que je reconfigure entièrement mon routeur sur l'étagère.

Phase d'initialisation (INIT) : allocation d'une adresse réseau

Il est spécifié que le message DHCPREQUEST doit réutiliser le xid du message DHCPOFFER.

Citer

If the ’xid’ of an arriving DHCPOFFER message does not match the ’xid’ of the most recent DHCPDISCOVER message, the DHCPOFFER message
must be silently discarded. Page 36.

Citer

The DHCPREQUEST message contains the same ’xid’ as the DHCPOFFER message. Page 38.

Phase d'initialisation (INIT-REBOOT) : initialisation avec une adresse réseau connue

Citer

The client generates and records a random transaction identifier and inserts that identifier into the ’xid’ field. Page 39.

Phase de renouvellement (RENEW, REBIND)

Citer

Any DHCPACK messages that arrive with an ’xid’ that does not match the ’xid’ of the client’s DHCPREQUEST message are silently discarded. Page 40.

Ce n'est pas précisé. Mais on peut considérer qu'il s'agit d'une nouvelle transaction. En effet, le principe est que le serveur peut refuser de renouveler le bail.

Synthèse

Le même type de message DHCP peut être utilisé dans des transactions diverses. Voir le diagramme de transition d'état page 35.

Exemple : INIT-REBOOT --> REBOOTING --> BOUND ou INIT-REBOOT --> REBOOTING --> INIT.

[size=14]Conclusion[/size]

Il faudrait réaliser une capture réseau pour confirmer ou infirmer. Il semblerait que l'identifiant de transaction soit l'indicateur du changement d'info. d'authentification.

ochbob · « **Réponse #1418 le:** **Hier** à 22:28:12 »

La table netdev, vous n'avez pas des erreurs de syntaxe ?

Je test celle indiquée par unipo dans son repo: https://github.com/luneth/OpenWRT-Livebox#le-pare-feu

unipo · « **Réponse #1419 le:** **Hier** à 23:33:21 »

@ochbob
Tu as bien ceci? Avec kmod-nft-netdev d'installé et en modifiant correctement eth0 en fonction de ton device WAN?

Code: [Sélectionner]

table netdev orange-rules
flush table netdev orange-rules

table netdev orange-rules {
        chain orange-rules-chain {
                type filter hook egress device "eth0" priority 0; policy accept;
                vlan type ip6 udp dport 547 vlan pcp set 6 ip6 dscp set cs6 counter accept
                vlan type ip6 icmpv6 type { echo-request, echo-reply, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit } vlan pcp set 6 ip6 dscp set cs6 counter accept
                vlan type ip6 ip6 dscp set cs0 counter accept
                vlan type ip udp dport 67 vlan pcp set 6 ip dscp set cs6 counter accept
                vlan type ip ip dscp set cs0 counter accept
                vlan type arp vlan pcp set 6 counter accept
        }
}

ochbob · « **Réponse #1420 le:** **Aujourd'hui** à 00:11:01 »

Yes, exactement celui ci, je vois les erreurs au boot dans /var/log/messages

Problème sur l'indentation peut être ?
Je referai un test demain.

unipo · « **Réponse #1421 le:** **Aujourd'hui** à 00:14:26 »

Non, remplace "vlan id 832 [...]" par "vlan type [...]"

Je me suis planté quand j'ai copié les règles en expérimentant avec "vlan id"...

Ou alors si tu veux appliqué en fonction du vlan, les correctes règles sont:

Code: [Sélectionner]

table netdev orange-rules {
        chain orange-rules-chain {
                vlan id 832 ip6 nexthdr udp udp dport 547 vlan pcp set 6 ip6 dscp set cs6 counter accept
                vlan id 832 ip6 nexthdr icmpv6 icmpv6 type { echo-request, echo-reply, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit } vlan pcp set 6 ip6 dscp set>
                vlan id 832 ip6 dscp set cs0 counter accept
                vlan id 832 ip protocol udp udp dport 67 vlan pcp set 6 ip dscp set cs6 counter accept
                vlan id 832 ip dscp set cs0 counter accept
                vlan id 832 vlan type arp vlan pcp set 6 counter accept
    }
}

Je vais mettre à jour le repo dans la journée

ochbob · « **Réponse #1422 le:** **Aujourd'hui** à 06:58:42 »

Merci Unipo, je vais tester ça !

basilix · « **Réponse #1423 le:** **Aujourd'hui** à 07:09:53 »

L'expression est malformée. Lire le premier paragraphe de Simple Rule Management.

Première expression : VLAN HEADER EXPRESSION

Code: [Sélectionner]

vlan id 832

Seconde expression incomplète : IPV6 HEADER EXPRESSION

Code: [Sélectionner]

ip6

Comment sélectionner en fonction du protocole encapsulé dans un paquet IPv6 ? Voir « Rappel IPv6 » ci-après.

Troisième expression : UDP HEADER EXPRESSION

Code: [Sélectionner]

udp dport 547

Analyse

Ce que l'on veut c'est sélectionner les paquets IPv6.

Code: [Sélectionner]

vlan type ip6

Attention : l'expression vlan type est surchargée. Voir « Ambivalence de l'expression vlan type ».

Rappel IPv6

Il faut utiliser l'expression meta l4proto en IPv6 pour correspondre au protocole encapsulé.

Code: [Sélectionner]

nft describe meta l4proto | grep icmp
        icmp                            1
        ipv6-icmp                       58

On peut utiliser l'expression abrégée icmpv6 type <data type>.

Citer

If you specifically want to match on the ICMPv6 type, then nftables creates an implicit meta l4proto dependency that is not shown, therefore, there is no need for being verbose in your notation, ie.

Code: [Sélectionner]
% nft add rule filter input icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
Hyperlien : Matching IPv6 headers

~~Ambivalence de l'expression vlan type~~

Code: [Sélectionner]

vlan type 8021ad vlan type 8021q vlan type ip6 counter

~~Cette expression représente explicitement une trame VLAN 802.1ad et une trame 802.1Q (enchaînement QinQ).~~

Code: [Sélectionner]

vlan type ip6 counter

~~Cette expression représente implicitement une trame VLAN 802.1q.~~

~~L'ambivalence apparaît dans la signification du type EtherType.~~

09:18

Finalement, il semblerait que mon interprétation soit fausse. J'ai essayé dans des espaces de nommages. nftables transforme la règle en :

Code: [Sélectionner]

table netdev test_qinq {
        chain ingress {
                type filter hook ingress device "veth_recv" priority filter; policy accept;
                ether type 8021q vlan type 8021ad vlan type 8021q vlan type ip6 counter packets 0 bytes 0 meta nftrace set 1
        }
}

09:31

Je crois que j'ai compris.

Code: [Sélectionner]

- VLAN support:

   # payload statement
   ip saddr 10.1.1.1 icmp type echo-request vlan id set 321

   # payload expression (QinQ matching)
   ether type 8021ad vlan id 10 vlan type 8021q vlan id 100 vlan type ip accept

Hyperlien : https://lwn.net/Articles/982283/

Code: [Sélectionner]

$ nft describe vlan type
payload expression, datatype ether_type (Ethernet protocol) (basetype integer), 16 bits

pre-defined symbolic constants (in hexadecimal):
        ip                              0x0800
        arp                             0x0806
        ip6                             0x86dd
        8021q                           0x8100
        8021ad                          0x88a8
        vlan                            0x8100

Code: [Sélectionner]

$ nft describe ether_type
datatype ether_type (Ethernet protocol) (basetype integer), 16 bits

pre-defined symbolic constants (in hexadecimal):
        ip                              0x0008
        arp                             0x0608
        ip6                             0xdd86
        8021q                           0x0081
        8021ad                          0xa888
        vlan                            0x0081

Donc, 8021ad ne devrait pas être utilisé dans l'expression vlan type mais uniquement dans l'expression ether type.

ochbob · « **Réponse #1424 le:** **Aujourd'hui** à 16:28:35 »

En fait j'utilisais la version de ton repo unipo, donc avec vlan id et pas vlan type comme je t'ai dis suite a ton retour hier soir.

Avec vlan type au lieu de vlan id 832 je n'ai plus les erreurs de syntax, ça semble bon.

Par contre dans le repo tu indique toujours la syntaxe avec vlan id en précisant le filter hook egress sur l'interface
Or dans ton message hier soir tu n'indique pas le filter hook egress.
J'avoue que ça me pertube, je ne sais pas au final quelle est vraiment la bonne syntaxe

basilix · « **Réponse #1425 le:** **Aujourd'hui** à 18:22:24 »

Où est passé votre rigueur ?

C'est navrant que mes réponses soient parsemées d'erreurs et expliquer en vain les mêmes sujets devient lassant. D'autant plus, quand on ne comprend pas le propos.
Je ressens un décalage par rapport aux autres (silence radio ou incompréhension) et cela me fait trop chier tellement je suis exaspéré. Je manque d'émulation avec si
peu de progrès émergeant d'efforts fournis mais poussé par de « grandes » ambitions. On est tous différents et il est temps que je la mette en veilleuse en changeant
de voie.

Bonne continuation !

unipo · « **Réponse #1426 le:** **Aujourd'hui** à 21:19:53 »

@ochbob

Oui j'ai bien vu, comme j'expliquais hier soir, j'expérimentais avec les "vlan id 832 [...]" suite au conseil de basilix un peu plus tôt sur ce sujet (utiliser également une règle nft pour gérer la prio pour le TV d'orange). Et j'ai poussé la mauvaise conf sur le repo...

Effectivement dans mon message d'hier j'ai zappé le filter hook egress, sorry! Comme j'étais concentré sur l'idée uniquement de remplacer les "vlan id 832" par "vlan type" j'ai juste copier le bloc des règles

Pour ce qu'y est de pousser sur le repo, je me demande si je ne vais pas plutôt partir sur les règles avec "vlan id 832 [...]", qu'on soit raccord avec la partie du tuto concernant la TV d'orange:

Code: [Sélectionner]

table netdev orange-rules {
        chain orange-rules-chain {
                type filter hook egress device "eth0" priority 0; policy accept;
                vlan id 832 meta l4proto udp udp dport 547 vlan pcp set 6 ip6 dscp set cs6 counter accept
                vlan id 832 meta l4proto icmpv6 icmpv6 type { echo-request, echo-reply, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit } vlan pcp set 6 ip6 dscp set cs6 counter accept
                vlan id 832 ip6 dscp set cs0 counter accept
                vlan id 832 meta l4proto udp udp dport 67 vlan pcp set 6 ip dscp set cs6 counter accept
                vlan id 832 ip dscp set cs0 counter accept
                vlan id 832 vlan type arp vlan pcp set 6 counter accept
        }
}

Mais si tu ne t'en sert pas, tu peux très bien utiliser les règles de mon avant dernier post, ... sans oublier le filter hook egress

@basilix
Il se peut que parfois tes posts soient technique, régulièrement édité, amené avec un vocabulaire soutenue et s'interdisant toute forme d'anglicismes, ce qui donne un combo qui peut être déroutant pour certain lecteurs. Mais cela n'enlève rien à tes contributions.
Si ton message m'était adressé, ne prend pas mes silences comme une attaque, parfois il me faut un petit moment pour traduire

Ton avis est toujours le bienvenu, une partie de ma conf est par ailleurs bien grâce à toi, merci!

Par ailleurs, à tu vu que levieux nous éclaire concernant notre interrogation, quand re-généré la chaine n'auth / à chaque xid ou non?

Citation de: levieuxatorange le Aujourd'hui à 08:55:05

Cela fonctionnerait (de changer les chaine en milieu de bail) mais la logique du DHCP est de garder les mêmes identifiant sur la session.

Il est mieux (mais pas impératif) de garder les info d'auth cohérente sur les deux stack sur la durée de la session dans le BNG. Mais là aussi ce n'est pas impératif dans l'implémentation actuelle.

Pour rappel, une session BNG est ouverte à la monté du premier stack v4 ou v6.
Et est fermée à la cloture (RELEASE ou DECO par timer) du dernier stack.
Entre l'ouverture et la fermeture du contexte BNG, on peut avoir autant de START/STOP des stack v4 ou v6 à la condition que l'un des deux reste connecté.
Le BNG considère qu'un client est "vivant" tant que l'un au moins des stack v4 ou v6 est en vie.