Hello,

EDIT : 03/03/2021. Cette version est compatible jusqu'à la version EdgeRouter ER-4/ER-6P/ER-12/ER-12P: Firmware v2.0.9-hotfix.1.

Je vous propose en dhclient patché avec la priorité 6 (kernel) sur base de la version 2.0.8-hotfix1 du firmware de l'er-6p. J'en avais marre des règles iptables pour dhcp et/ou du marquage via le switch.

J'ai compilé sur base du patching des sources qui se trouve ici https://github.com/shisva/USG_Orange et déposé par mike78530 dans le tuto https://lafibre.info/remplacer-livebox/le-guide-complet-pour-usgusg-pro-internet-tv-livebox-ipv6/
zoc a posté un patch ici pour le firmware 1.9.1 : https://lafibre.info/remplacer-livebox/en-cours-remplacer-sa-livebox-par-un-routeur-ubiquiti-edgemax/msg562531/#msg562531.

Seul problème que je rencontre actuellement, qui n'est pas obligatoirement lié à ce patch, c'est la récupération des DNS du DHCP (set service dns forwarding dhcp ethx.832) --> je suis donc obligé de forcer les DNS avec set service dns forwarding name-server x.x.x.x
Il faut donc remplacer le fichier (après avoir fait un backup) se trouvant /sbin/dhclient3 par celui fourni et ajouter le droit d'exécution (sudo chmod +x /sbin/dhclient3). Ensuite, par rapport à ma configuration, il faut aussi ajouter l'egress-qos 6:6 à l'interface WAN (ethx.832).

Patch fourni par dmfr pour le firmware 2.0.6 (iscdhcp_priority.vyatta-dhcp3_4.1-ESV-R15.patch)
https://lafibre.info/remplacer-livebox/dhclient-patche-er-6p-2-0-8-hotfix1/?action=dlattach;attach=87074
Post:
https://lafibre.info/remplacer-livebox/dhclient-patche-er-6p-2-0-8-hotfix1/msg781287/#msg781287

Merci encore pour les infos et bonne soirée à tous.

tu pourais partager le patch final? J'aimerais pouvoir compiler le mien. Tu qs fait quel changement dans le fichier discover.c?

Bonsoir.
C'est à mike78530 qu'il faut demander, je n'ai fait que reproduire ce qu'il a fait pour la version de mon EdgeRouter. Toutefois, j'ai généré le patch et je l'ai ajouté à mon post principal.

Bizarre, le patch est quand même très similaire au mien (avec exactement les mêmes commentaires ). Les modifications sont vraiment simples (et ne concernent pas que discover.c): Après avoir créé une socket, on configure sa priorité (SOL_PRIORITY) à 6, ce qui correspond à une priorité NOYAU. Ensuite, avec la ligne egress-qos de la configuration d’EdgeOS on mappe cette priorité noyau sur une priorité 802.1p.

Quand j’ai fait le patch, je ne me suis pas emmerdé à analyser à quels endroits les changements étaient nécessaires, je l’ai fait pour toutes les sockets sans distinction...

Bon sinon tu l’as généré à l’envers (il devrait y avoir des lignes débutant avec + car on rajoute de code au lieu de - qui indique qu’on supprime des lignes).

dans discover.c le suci du diff est cette ligne là:
@@ -454,6 +458,10 @@
  return 0;
  }
 
+        /* Set Kernel Priority to 6 */
+        int val = 6;
+        setsockopt(ifaces->sock, SOL_SOCKET, SO_PRIORITY, &val, sizeof(val));
+
 #ifdef DHCPv6
  if (local_family == AF_INET6) {
  ifaces->fp6 = fopen("/proc/net/if_inet6", "r");
qui a disparu. Quand tu dis " je ne me suis pas emmerdé à analyser à quels endroits les changements étaient nécessaires" c'est à dire à chaque fois qu'un nouveau socket est créte (appel à  socket()) ?

Bizarre, le patch est quand même très similaire au mien (avec exactement les mêmes commentaires ). Les modifications sont vraiment simples (et ne concernent pas que discover.c): Après avoir créé une socket, on configure sa priorité (SOL_PRIORITY) à 6, ce qui correspond à une priorité NOYAU. Ensuite, avec la ligne egress-qos de la configuration d’EdgeOS on mappe cette priorité noyau sur une priorité 802.1p.

J'ai corrigé mon post avec le lien vers ton patch 1.9.1, peut-être que tu es à l'origine de tous les patchs dhclient dispos sur le forum ^^ Perso, j'ai juste recherché/ajouté dans le code source de la 2.0.8 les fonctions où le SO_PRIORITY a été ajouté sur base des infos dans le fichier "patch". Il y a tellement d'info sur le forum, dur de s'y retrouver parfois ^^

J'ai retrouvé ton post et effectivement les patchs se ressemblent très fortement ! J'ai 2 différences :
1) Dans lpf.c, j'ai ajouté int val; qu'il n'y a ni dans ton patch ni celui de mike78530
2) Dans discover.c, il y a un set ton patch il n'y a pas la déclaration "int val" et il y a 1 setsockopt en plus

D'ailleurs, pour info, j'avais testé uniquement avec la correction du fichier lpf.c et c'était suffisant (mais je préfère le mettre partour, ca ne coute aps grand chose) :/

merci pour le patch. Je l'ai remis dans l'orde pour ceux que cela interesse:

--> J'ai corrigé mon fichier après la remarque de zoc, vous allez trop vite, j'ai pas le temps de répondre !!!

En passant, est-ce que tu as déjà rencontré le problème que je mentionne avec le dns forwarding (via DNS du DHCP Orange) ? Par contre, ce matin, je regarde mon fichier /etc/resolv.conf et les serveurs sont revenus ^^
cat /etc/resolv.conf
#line generated by /opt/vyatta/sbin/vyatta_update_resolv.pl
domain          home.loc
nameserver      81.253.149.13           #nameserver written by /opt/vyatta/sbin/vyatta_update_resolv.pl
nameserver      80.10.246.5             #nameserver written by /opt/vyatta/sbin/vyatta_update_resolv.pl

@zoc : merci encore pour tout le temps que tu consacres sur lafibre.info ! Parce que même si c'est simple, il faut prendre le temps pour analyser le code et tester après les builds.

/etc/resolv.conf et les serveurs sont revenus ^^

J'avais remarqué un problème similaire lors du passage à dhclient pour l'IPv6 :
https://lafibre.info/remplacer-livebox/ubiquiti-er-ipv6-dhcp6-en-2-x/msg684705/#msg684705

En revanche, sur les connexions FTTH Orange de mon périmètre, j'ai récemment fait la migration inverse, c-a-d utiliser des switchs Cisco au lieu du client patché.

Tu en aurais un pas trop cher à conseiller?