Auteur Sujet: Remplacer la livebox avec DHCP+DHCPv6-pd (linux/openbsd) (Lu 264755 fois)

Mikachu · « **Réponse #516 le:** 01 mai 2022 à 15:43:28 »

Citation de: hj67 le 01 mai 2022 à 13:35:00

J'ai aussi mon routeur sous debian.
Il faut que je vois si j'ai encore l'ancienne config quelque part quand je rentre chez moi car maintenant j'ai un switch qui modifie la COS à 6 pour les paquets dhcp.
Le fait que tu obtiennes une IP en 172.x , c'est que quelque chose n'est pas bon.

A première vue, le nom de l'option qui envoie sagem n'est pas bonne dans ton dhclient.conf :
Code: [Sélectionner]
send vendor-class-identifier "sagem"; #option 60 send dhcp-client-identifier xx:xx:xx:xx:xx:xx:xx; #option 61 send user-class "+FSVDSL_livebox.Internet.softathome.Livebox4"; #option 77 send rfc3118-authentication xx:xx; #option 90 (chaine complete)
Dans ton /etc/network/interfaces , mettre l'adresse mac de la box (hwaddress) n'est pas utile.

J'ai changé l'option dhcp envoyée en mettant celle que tu indiques et j'ai retiré le hwaddress dans le /etc/network/interfaces et malheureusement j'ai toujours le même retour: un DHCPOFFER pour une ip en 172.16.x.x et pas de réponse aux DHCPREQUEST.

EDIT: j'ai changé le

Code: [Sélectionner]

up /bin/ip link set dev enp0s31f6.832 type vlan egress 0:6 1:0 2:2 3:3 4:4 5:5 6:6 7:7

en pre-up et maintenant je reçois bien une réponse à mes DHCPREQUEST et je peux prendre mon ip en 172.16.91.18.
Reste à savoir si j'ai internet derrière et si orange redirige bien mon ip publique vers cette addresse.

hj67 · « **Réponse #517 le:** 01 mai 2022 à 15:58:15 »

A mon avis pas d'Internet si tu es en 172.x.
Lu dans un autre topic, si tu obtiens une IP en 172.x c'est que la COS n'est pas bonne pour tes requêtes DHCP.
En page 1 de ce topic, il y a quasiment toutes les commandes liées à la COS.

Mikachu · « **Réponse #518 le:** 01 mai 2022 à 16:56:32 »

Citation de: hj67 le 01 mai 2022 à 15:58:15

A mon avis pas d'Internet si tu es en 172.x.
Lu dans un autre topic, si tu obtiens une IP en 172.x c'est que la COS n'est pas bonne pour tes requêtes DHCP.
En page 1 de ce topic, il y a quasiment toutes les commandes liées à la COS.

En effet, impossible de faire quoi que ce soit avec cette adresse en 172.x
Pour ce qui est de la COS la commande normalement ce que je fais respecte ce qui est indiqué comme fonctionnant dans le premier message du topic:

Code: [Sélectionner]

/bin/ip link set dev enp0s31f6.832 type vlan egress 0:6 1:0 2:2 3:3 4:4 5:5 6:6 7:7

changer la priorité de la file 0 à 6 et celle de la file 1 à 0 et laisser les autres files avec une priorité "par défaut"
et

Code: [Sélectionner]

/etc/iptables-orange.sh

ajouter les règles iptables préconisées dans le premier message.

Mikachu · « **Réponse #519 le:** 01 mai 2022 à 18:39:53 »

Je confirme par contre que c'est effectivement un soucis de COS/DSCP, mes DHCPDISCOVER/REQUEST sont envoyées avec un DSCP 4 au lieu de 6.
J'ai lu à plusieurs endroits qu'il faudrait utiliser un dhclient patché, est-ce toujours le cas ?

zoc · « **Réponse #520 le:** 01 mai 2022 à 18:43:32 »

On s'en fout du DSCP (priorité IP) encore une fois. Ce qui est important c'est la priorité 802.1p (priorité VLAN).

Sur les scripts postés je ne vois pas trop ce qui cloche, à vérifier tout de même une seconde fois que le nom de l'interface réseau dans les scripts correspond bien au nom de l'interface physique de la machine... Le dhclient patché n'est pas nécessaire avec les règles iptables du script iptables-orange.sh?

Mikachu · « **Réponse #521 le:** 01 mai 2022 à 18:55:34 »

Citation de: zoc le 01 mai 2022 à 18:43:32

On s'en fout du DSCP (priorité IP) encore une fois. Ce qui est important c'est la priorité 802.1p (priorité VLAN).

Sur les scripts postés je ne vois pas trop ce qui cloche, à vérifier tout de même une seconde fois que le nom de l'interface réseau dans les scripts correspond bien au nom de l'interface physique de la machine... Le dhclient patché n'est pas nécessaire avec les règles iptables du script iptables-orange.sh?

J'ai rechecké et normalement le nom est bon partout
Les règles d'egress et iptables ont l'air ok au vu de ce que j'ai pu lire, cf:

Code: [Sélectionner]

sudo cat /proc/net/vlan/enp0s31f6.832
enp0s31f6.832  VID: 832	 REORDER_HDR: 1  dev->priv_flags: 1021
         total frames received         1048
          total bytes received       428998
      Broadcast/Multicast Rcvd            3

      total frames transmitted          113
       total bytes transmitted        15658
Device: enp0s31f6
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings: 0:6 1:0 2:2 3:3 4:4 5:5 6:6 7:7

et

Code: [Sélectionner]

# Generated by iptables-save v1.8.7 on Sun May  1 18:52:12 2022
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o enp0s31f6.832 -j CLASSIFY --set-class 0000:0001
-A POSTROUTING -o enp0s31f6.832 -p igmp -j CLASSIFY --set-class 0000:0006
-A POSTROUTING -o enp0s31f6.832 -p icmp -j CLASSIFY --set-class 0000:0006
-A POSTROUTING -o enp0s31f6.832 -m dscp --dscp 0x2e -j CLASSIFY --set-class 0000:0005
-A POSTROUTING -o enp0s31f6.832 -p udp -m udp --dport 67 -j CLASSIFY --set-class 0000:0006
COMMIT
# Completed on Sun May  1 18:52:12 2022

Y'a moyen de checker quelquepart la priorité 802.1p en sortie ? (j'ai pas trouvé de champ pertinent dans un tcpdump/wireshark, mais j'ai peut être mal cherché et/ou ça se passe à trop bas niveau pour eux ?)

zoc · « **Réponse #522 le:** 01 mai 2022 à 19:34:45 »

Avec Wireshark il faut sniffer l'interface physique, à priori enp0s31f6, et pas enp0s31f6.832, afin de voir la priorité 802.1p dans l'entête Ethernet.

Mikachu · « **Réponse #523 le:** 01 mai 2022 à 19:48:36 »

Citation de: zoc le 01 mai 2022 à 19:34:45

Avec Wireshark il faut sniffer l'interface physique, à priori enp0s31f6, et pas enp0s31f6.832, afin de voir la priorité 802.1p dans l'entête Ethernet.

En effet, et du coup la priorité était bonne.

Je viens de trouver le coupable en comparant option par options les requetes de la box et celles de ma machine: une typo s'était glissée dans mon identifiant.
Merci encore pour votre aide et votre patience !

hj67 · « **Réponse #524 le:** 02 mai 2022 à 01:15:48 »

Parfait

cyayon · « **Réponse #525 le:** 18 octobre 2022 à 18:35:18 »

Hello,

dhclient (ISC) est en fin de vie. Est-ce que certains d'entre vous ont une conf fonctionnelle a base de dhcpcd ? (ipv4+ipv6)

merci.

kgersen · « **Réponse #526 le:** 19 octobre 2022 à 14:59:51 »

merci de l'info. J'ai mis a jour l'index en précisant que donc que c'est EOL pour Linux. A priori dhclient (ISC) continu sur OpenBSD.
Je n'ai pas vu de position officielle des principales distro Linux a ce sujet.

ISC abandonne de fait leur code DHCP d'origine (client, relais et serveur) pour se focaliser que sur leur nouveau serveur (Kea DHCP server).

Le timing : https://www.isc.org/blogs/dhcp-client-relay-eom/
L'annonce officielle : https://www.isc.org/blogs/isc-dhcp-eol/

pitalugue · « **Réponse #527 le:** 29 octobre 2022 à 00:12:44 »

Reponse en retard mais non OpenBSD ne continue pas dhclient qui avait deja ete bien modifie il y a des annees.
Il est deprecie au profit d'autres mecaniques, syntaxiquement un simple inet/inet6 autoconf, (toute la couche DHCP / resolveur local a ete reecrite recemment). Actuellement dhclient n'est qu'une coquille vide redirigeant vers le nouveau comportement. Il y a eu plusieurs releases de glissement pour ne pas casser directement les mises en place.
Pour des comportements particuliers comme ceux dont on peut avoir besoin dans ce fil, OpenBSD pointe vers dhcpcd qui, d'ailleurs, a leur sandboxing en place.