Si quelqu’un peut me donner un petit coup de main. J’utilise networkd pour le remplacement de la livebox ( https://lafibre.info/remplacer-livebox/remplacer-la-livebox-par-systemd-networkd-nftables/ ). J’ai des soucis de déconnexion depuis le passage en Trixie. J’ai ouvert d’ailleurs des bugs chez Debian et systemd pour des choses qui ne fonctionnent pas ou mal.

Là, j’envoie un Solicit en DHCPv6. Le paquet semble bien formé (tout est ok dans wireshark), mais je n’ai pas de réponse. Je précise que la prio est bien à 6 et le DSCP à CS6.

DHCPv6
    Message type: Solicit (1)
    Transaction ID: 0x837bb2
    Identity Association for Prefix Delegation
        Option: Identity Association for Prefix Delegation (25)
        Length: 12
        IAID: dc60dc26
        T1: 0
        T2: 0
    User Class
        Option: User Class (15)
        Length: 45
        User Class suboption
            Length: 43
            Suboption: 46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7835
    Option Request
        Option: Option Request (6)
        Length: 4
        Requested Option code: SOL_MAX_RT (82)
        Requested Option code: Captive Portal (103)
    Client Identifier
        Option: Client Identifier (1)
        Length: 10
        DUID: 0003000144a6xxxxxxxx
        DUID Type: link-layer address (3)
        Hardware type: Ethernet (1)
        Link-layer address: 44:a6:xx:xx:xx:xx
        Link-layer address (Ethernet): IngramMicroS_xx:xx:xx (44:a6:xx:xx:xx:xx)
    Vendor Class
        Option: Vendor Class (16)
        Length: 11
        Enterprise ID: SAGEMCOM SAS (1038)
        vendor-class-data: sagem
    Authentication
        Option: Authentication (11)
        Length: 70
        Protocol: 0
        Algorithm: 0
        RDM: 0
        Replay Detection: 0000000000000000
        Authentication Information: xxxxxx
    Elapsed time
        Option: Elapsed time (8)
        Length: 2
        Elapsed time: 655350ms
Vous voyez un truc qui ne va pas ?

L'option 15 semble avoir un problème. Une valeur comme :

Code: [Sélectionner]

0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7835devrait fonctionner.

C’est Wireshark qui l’affiche comme ça. Mais le 002b est bien envoyé avant la chaine. La chaine hexa complète qui correspond au User Class est 000f002d002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7835 .

Est-ce que mon souci pourrait venir du fait que l’IAID a changé, du fait que je ne l’avais pas mis fixe avant, et que j’ai touché à des paramètres (le DUID entre autre) et que systemd-networkd en a généré un nouveau ? Si c’est ça, vous avez une astuce sur comment faire ? Sachant que je ne peux pas retrouver l’ancien IAID désormais.

Si quelqu’un peut me donner un petit coup de main. J’utilise networkd pour le remplacement de la livebox ( https://lafibre.info/remplacer-livebox/remplacer-la-livebox-par-systemd-networkd-nftables/ ). J’ai des soucis de déconnexion depuis le passage en Trixie. J’ai ouvert d’ailleurs des bugs chez Debian et systemd pour des choses qui ne fonctionnent pas ou mal.

Là, j’envoie un Solicit en DHCPv6. Le paquet semble bien formé (tout est ok dans wireshark), mais je n’ai pas de réponse. Je précise que la prio est bien à 6 et le DSCP à CS6.

Code: [Sélectionner]

DHCPv6
    Message type: Solicit (1)
    Transaction ID: 0x837bb2
    Identity Association for Prefix Delegation
        Option: Identity Association for Prefix Delegation (25)
        Length: 12
        IAID: dc60dc26
        T1: 0
        T2: 0
    User Class
        Option: User Class (15)
        Length: 45
        User Class suboption
            Length: 43
            Suboption: 46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7835
    Option Request
        Option: Option Request (6)
        Length: 4
        Requested Option code: SOL_MAX_RT (82)
        Requested Option code: Captive Portal (103)
    Client Identifier
        Option: Client Identifier (1)
        Length: 10
        DUID: 0003000144a6xxxxxxxx
        DUID Type: link-layer address (3)
        Hardware type: Ethernet (1)
        Link-layer address: 44:a6:xx:xx:xx:xx
        Link-layer address (Ethernet): IngramMicroS_xx:xx:xx (44:a6:xx:xx:xx:xx)
    Vendor Class
        Option: Vendor Class (16)
        Length: 11
        Enterprise ID: SAGEMCOM SAS (1038)
        vendor-class-data: sagem
    Authentication
        Option: Authentication (11)
        Length: 70
        Protocol: 0
        Algorithm: 0
        RDM: 0
        Replay Detection: 0000000000000000
        Authentication Information: xxxxxx
    Elapsed time
        Option: Elapsed time (8)
        Length: 2
        Elapsed time: 655350ms
Vous voyez un truc qui ne va pas ?

C'est de la merde networkd. J'ai testé, et c'est caca. Je conseil de rester sur du bon ifup/ifdown + dhcpd.
J'avais fait un grand test pour passer de Debian Trixie ifup/ifdown+dhcpd à networkd. Il y a rien d'aussi bien. Rien ne fonctionne comme prévu, impossible de passer des valeur dynamique dans les config (via en var), etc... Une catastrophe. Je suis vite retourné sur le bon vieux system de network.
Pour info je suis l'auteur du tuto Orange  + Debian. (cf: https://lafibre.info/remplacer-livebox/bypass-orange-g-ponxgs-pon-sur-debian-explications-pas-a-pas/)

Si j'ai une recommandation pour toi : stop networkd, tu vas te prendre la tête pour rien. Cette partie de systemd ne devrait même pas être considéré comme en beta tellement les fonctionnalitées sont absentes et non fonctionnelles.
J'avais d'ailleurs évoquer l'ensemble des problèmes dans ton post : https://lafibre.info/remplacer-livebox/remplacer-la-livebox-par-systemd-networkd-nftables/msg1128733/#msg1128733
Et pourtant je l'ai tester fort fort et j'ai tellement voulu que ça soit bien. Mais non ... c'est terriblement moyen voir très passable.

Bonjour à tous,

J'essaie de faire les choses bien et donc d'avoir une génération aléatoire de mes options 11/90, mais il y a un point que j'aimerai éclaircir, puisque je lis les 2 avis et je n'ai pas trouvé une réponse tranchée.
D'une part, faut-il envoyer la meme valeur entre les 2 options ?

D'autre part, j'ai un peu de mal a capter à quel moment il faut les mettre à jour. J'ai un mikrotik, j'ai vu pas mal de solutions ou on ajoute un script qui s'execute avec le client DHCP/DHCPv6.
Ce script est-il appelé à chaque renew ?
Mais dans ce cas, même s'il existe 2 versions du script (une qui met une valeur différente dans le 11 et le 90, et une version qui met la même valeur), vu que les renew v4 et v6 n'ont pas forcément lieux en meme temps, on transmet alors 2 valeurs différentes...

Je finis par me dire qu'un scheduler qui met à jour la valeur des 2 champs toutes les 24h seraient peut-être plus simple, mais comme je ne suis pas certain de mes connaissances sur le DHCP, ce n'est peut-être pas la bonne façon de faire.

Merci de vos lumieres !

Je sais bien, et c'est aussi mon cas, mais là je l'ai mis en place au taf et donc je veux prévenir d'une éventuelle coupure internet le jour ou Orange devient plus restrictif

C'est marrant, on en parle aussi Remplacement de la Livebox par un routeur Openwrt

Pour confirmation, faut changer d'auth a chaque renew? Dans ce sujet basilix à déterré la RFC2131, savoir si quand change la TransactionID.

Parce-que, comme on en parle également dans le sujet, si on se base sur les revew pour régénérer la chaine d'auth, les baux dhcp4/6 n'ont pas la même durée de vie, donc je comprends pas trop;
Si renew de v4, il faudrait donc un hook qui régénère l'XAUTH & l'insérer dans les config v4 et v6 avant le RENEW du v4 et forcer un INIT-REBOOT du v6. Et vice versa avec un renew v6
Car on ne peux pas avoir les deux stacks avec des chaines d'auth differentes.

Pour le moment je régénère uniquement au démarrage du routeur et en cas de perte de connections avec les premières passerelles v4/v6,