Auteur Sujet: Livebox 5 Pro + IP Fixed - remplacer par UDM Pro ? (Lu 80766 fois)

fgero · « **Réponse #276 le:** 03 juin 2023 à 01:37:21 »

Citation de: mamatdv le 02 juin 2023 à 22:05:24

Hello, pas de nouvelle du ticket de mon côté mais tu as plus de chance de voir le tiens aboutir car beaucoup complet et précis. Enfin … j’espère

Après quelques échanges/précisions, j'ai eu :

Citer

Thank you for providing an update.
In order to resolve your issue as quickly and satisfactorily as possible, we've flagged this ticket to our Escalations Team. One of our experts will contact you shortly.

En attendant, à vos crontab pour le kill -USR1

mamatdv · « **Réponse #277 le:** 03 juin 2023 à 02:28:29 »

Citation de: fgero le 03 juin 2023 à 01:37:21

Après quelques échanges/précisions, j'ai eu :
En attendant, à vos crontab pour le kill -USR1

Sans vouloir abuser peux tu me détailler comment tu mets en place un crontab sur un UDM ?
Merci d’avance pour ta réponse

fgero · « **Réponse #278 le:** 03 juin 2023 à 06:33:18 »

Citation de: mamatdv le 03 juin 2023 à 02:28:29

Sans vouloir abuser peux tu me détailler comment tu mets en place un crontab sur un UDM ?
Merci d’avance pour ta réponse

Pas certain de comprendre le sens de la question, mais j'ai bêtement fait comme d'habitude avec un Linux (ici en ssh dans l'UDR) :
Je tape "crontab -e" (je suis root), puis je saisis dans mon cas pour une exécution les lundi, mercredi et samedi 2h34 :

Code: [Sélectionner]

34 2 * * 1,3,6 /persistent/fgscripts/renew.sh
Mais ça tu le savais déjà sans doute : peut-être parlais-tu du fait que cette crontab ne survit pas à un upgrade de firmware (voire à un reboot) ?
Je pourrais certainement le résoudre en installant le package udm-boot (https://github.com/unifi-utilities/unifios-utilities/blob/main/on-boot-script/README.md) et en créant un 25-add-cron-jobs.sh dans /data/on_boot.d/
Ou encore en faisant un ssh depuis le cron d'une machine externe à l'UDR.
Mais j'ai eu la flemme, je préfère attendre le fix avec le ticket, et d'ici là remettre ma crontab dans les rare cas où elle saute - évidemment si le fix ne vient pas ou trop lentement, j'appliquerai une des solutions permettant de persister cette crontab (ou bien encore si j'avais besoin de udm-boot pour d'autres raisons).
J'espère avoir répondu.

fgero · « **Réponse #279 le:** 03 juin 2023 à 18:31:12 »

En buildant une version client odhcp6c openwrt, qui dispose de l'option (issue d'un commit tout récent) "-K <priority>" pour poser la CoS 6, je parviens presque (je crois) sur mon UDR à obtenir une IP v6 en plus de la v4, j'ai cette log lorsque je down/up mon interface WAN eth4.832 :

Code: [Sélectionner]

2023-06-03T18:20:59+02:00 UDR odhcp6c[527816]: (re)starting transaction on eth4.832
2023-06-03T18:21:00+02:00 UDR odhcp6c[527816]: Starting SOLICIT transaction (timeout 4294967295s, max rc 0)
2023-06-03T18:21:00+02:00 UDR odhcp6c[527816]: Failed to send SOLICIT message to ff02::1:2 (Cannot assign requested address)
2023-06-03T18:21:01+02:00 UDR odhcp6c[527816]: Got a valid ADVERTISE after 1089ms
2023-06-03T18:21:01+02:00 UDR odhcp6c[527816]: IA_NA 0001 T1 0 T2 0
2023-06-03T18:21:01+02:00 UDR odhcp6c[527816]: IA_PD 0001 T1 92975 T2 483840
2023-06-03T18:21:01+02:00 UDR odhcp6c[527816]: 2a01:cb00:647:6c00::/56 preferred 604800 valid 604800
2023-06-03T18:21:02+02:00 UDR odhcp6c[527816]: Starting SOLICIT transaction (timeout 4294967295s, max rc 0)
2023-06-03T18:21:02+02:00 UDR odhcp6c[527816]: Got a valid ADVERTISE after 13ms
2023-06-03T18:21:02+02:00 UDR odhcp6c[527816]: IA_PD 0001 T1 92975 T2 483840
2023-06-03T18:21:02+02:00 UDR odhcp6c[527816]: 2a01:cb00:647:6c00::/56 preferred 604800 valid 604800
2023-06-03T18:21:03+02:00 UDR odhcp6c[527816]: Starting REQUEST transaction (timeout 4294967295s, max rc 10)
2023-06-03T18:21:03+02:00 UDR odhcp6c[527816]: Send REQUEST message (elapsed 0ms, rc 0)
2023-06-03T18:21:03+02:00 UDR odhcp6c[527816]: Got a valid REPLY after 179ms
2023-06-03T18:21:03+02:00 UDR odhcp6c[527816]: IA_PD 0001 T1 92975 T2 483840
2023-06-03T18:21:03+02:00 UDR odhcp6c[527816]: 2a01:cb00:647:6c00::/56 preferred 604800 valid 604800
2023-06-03T18:21:03+02:00 UDR odhcp6c[527816]: T1 92975s, T2 483840s, T3 604800s
2023-06-03T18:21:03+02:00 UDR odhcp6c[527816]: entering stateful-mode on eth4.832
2023-06-03T18:21:03+02:00 UDR odhcp6c[527816]: Starting <POLL> transaction (timeout 92975s, max rc 0)

J'ai l'impression qu'il ne manque pas grand chose, mais je n'y connais rien côté dhcp client v6 (par contre le client v4 obtient bien un bail comme d'habitude)
A l'issue de cela, je n'ai pas d'inet6 sur mon eth4.832, pourtant on dirait que j'ai un bail de 7 jours dans cette log

Est-ce que cette log montre une transaction dhcp v6 incomplète et si oui qu'est-ce que cela voudrait dire ?

J'ai ce process qui tourne, je pense les bons paramètres (j'ai essayé aussi sans le -N) :
odhcp6c -Ntry -K 6 -r11,17,23,24 -V 0000040E0005736167656D -c 00030001<macaddr> -x 11:<meme valeur que l'option 90 v4> -x 15:002B<meme valeur que l'option 77 v4) -e -v -s /usr/share/ubios-udapi-server/ubios-odhcp6c-script -D -P 64 eth4.832

zoc · « **Réponse #280 le:** 03 juin 2023 à 21:00:10 »

Orange assigne un préfixe et manifestement là c’est le cas dans les logs. Après en IPv6 le port WAN n’a pas forcément besoin d’avoir une IPv6 globale ("publique") pour fonctionner.

mamatdv · « **Réponse #281 le:** 03 juin 2023 à 23:53:34 »

Citation de: fgero le 03 juin 2023 à 06:33:18

Mais ça tu le savais déjà sans doute : peut-être parlais-tu du fait que cette crontab ne survit pas à un upgrade de firmware (voire à un reboot) ?
Je pourrais certainement le résoudre en installant le package udm-boot (https://github.com/unifi-utilities/unifios-utilities/blob/main/on-boot-script/README.md) et en créant un 25-add-cron-jobs.sh dans /data/on_boot.d/
Ou encore en faisant un ssh depuis le cron d'une machine externe à l'UDR.
Mais j'ai eu la flemme, je préfère attendre le fix avec le ticket, et d'ici là remettre ma crontab dans les rare cas où elle saute - évidemment si le fix ne vient pas ou trop lentement, j'appliquerai une des solutions permettant de persister cette crontab (ou bien encore si j'avais besoin de udm-boot pour d'autres raisons).
J'espère avoir répondu.

C'était surtout cette partie qui m'intéressait mais je pense que tu as raison et qu'il est plus sage d'attendre le correctif unifi

Merci pour ta réponse

fgero · « **Réponse #282 le:** 04 juin 2023 à 09:44:11 »

Citation de: zoc le 03 juin 2023 à 21:00:10

Orange assigne un préfixe et manifestement là c’est le cas dans les logs. Après en IPv6 le port WAN n’a pas forcément besoin d’avoir une IPv6 globale ("publique") pour fonctionner.

Effectivement, pas besoin, car une fois activé le dhcp v6 sur le réseau LAN concerné, mon iMac obtient une IP v6
Je pense que j'ai maintenant un double stack v4+v6 sur l'UDR...c'était juste pour voir, si je voulais le garder, il reste à régler la conservation au reboot de mon odhcp6c substitué au "vieux" odhcp6c livré par Unifi

mamatdv · « **Réponse #283 le:** 05 juin 2023 à 00:43:52 »

Hello,
Une fois ton ticket sur le problème de renew ipv4 résolu, tu pourrais ouvrir un second ticket pour leur soumettre tes recherches et solutions ?

fgero · « **Réponse #284 le:** 05 juin 2023 à 07:04:32 »

Citation de: mamatdv le 05 juin 2023 à 00:43:52

Hello,
Une fois ton ticket sur le problème de renew ipv4 résolu, tu pourrais ouvrir un second ticket pour leur soumettre tes recherches et solutions ?

Je crains que mon ticket, malgré leur "One of our experts will contact you shortly.", reste lettre morte, mais bon...
Quant à odhcp6c, Unifi est tellement loin d'une solution (ajouter les bonnes options dhcp v6 sans saisir en double, les accepter en argument, récupérer le CoS de l'upstream openwrt, etc..) que je vais me débrouiller seul.
j'ai fait un script qui récupère automatiquement les options de DHCPv4 (saisies dans l'UI) et les mappe sur les bonnes options DHCPv6 Orange (et ajoute les préfixes), il n'y a plus besoin de les entrer en double ou en dur. Ce script prend la place de /usr/sbin/odhcp6c et fait un exec du odhcp6c supportant le CoS, c'est totalement transparent.
Ne me reste que l'histoire de remettre ce hack au reboot/firmware, mais ça attendra le we prochain.

frozeus · « **Réponse #285 le:** 05 juin 2023 à 18:06:34 »

Pour info le sujet a été ouvert coté Ubiquiti: https://community.ui.com/questions/DHCP-renew-unicast-is-not-perform-with-the-CoS-parameter/2e457186-54ca-4cdf-88cf-90e2427ed85f

fgero · « **Réponse #286 le:** 05 juin 2023 à 19:50:40 »

En attendant, j'ai pu valider udm-boot (en modifiant un peu le package).
Ce qui permet de conserver ce qu'on veut au reboot.
Notamment on garde après reboot :
1) les crontabs qu'on veut, donc par exemple le kill forcé pour renew DHCPv4
2) la modif de odhcp6 pour avoir le double stack DHCPv4+v6 avec paramètres V6 calculés automatiquemnt
Si jamais ça intéresse (mais la population intéressée/concernée doit être minuscule, alors..), je peux faire un post pour le udm-boot avec la cron et le dhcpv6 qui marche .

frozeus · « **Réponse #287 le:** 06 juin 2023 à 13:00:23 »

Quelqu'un a un UDM PRO SE et veut/peut tester le fix de Ubiquiti? J'envoie le lien par MP