Hello, j'ai ouvert un ticket vers le support n'ayant pas eu de réponse sur leur forum ...
Peux tu me dire comment tu fais cette manip ?

C'est une peu lourd de devoir redémarrer tous les 3,5 jours

Est-ce que le ticket a un espoir d'avancer ?

En regardant le démarrage de udhcpc, il semble qu'Unifi utilisent une base de dhcpc.c v1.34.1 de busybox, donc le source se trouve ici :
https://elixir.bootlin.com/busybox/1.34.1/source/networking/udhcp/dhcpc.c
...mais je ne vois pas trace dans ce source de l'option "-y", qui permet à udhcpc Unifi de positionner une CoS/Priority lors des request dhcp client.

Je suppose donc qu'ils modifient à leur sauce ce source, ce qui laisse entrevoir un espoir d'ajouter la (potentielle) CoS manquante lors du renew automatique à mi-vie ?

Le signal USR1 se comporte très différemment du renew automatique à mi-vie :
Le renew automatique s'arrête au 1er request dhcp renew (=> pas de réponse d'Orange) et repart en attente pour la moitié du lease restant (ça se voit dans le source, goto BOUND_for_half_lease), perdant la connexion Orange apparemment.
Le kill -USR1 va plus loin : même s'il passe par le même code de request dhcp renew que l'automatique (et il échoue aussi sans réponse), il force le lease_remaining à zéro, donc ensuite il broadcaste (state REBINDING) x3 puis repart à zéro (state INIT_SELECTING). Ce qui refait la séquence discover, et qui marche à la fin (puisqu'il passe la CoS du -y comme à son démarrage je suppose).
Avec le USR1 on a par conséquent une petite interruption de réseau WAN de quelques petites secondes à cause de cette séquence.

Ce serait bien qu'Unifi utilise la valeur du paramètre "-y" aussi sur la socket utilisée pour la requête de renew automatique, si c'est bien le problème (ce que je ne sais pas).

Merci
Du coup c'est clair (enfin, je crois, dis moi si je me trompe)

Les modifs importantes sont dans networking/udhcp/packet.c, c'est à dire le positionnement du SO_PRIORITY pour la CoS (récupérée du paramètre -y)

Mais cette modif n'est faite que pour la fonction udhcp_send_raw_packet(), et pas pour udhcp_send_kernel_packet()

Or si on regarde dans dhcpc.c, on trouve cette fonction clef, à double usage :

static int bcast_or_ucast(struct dhcp_packet *packet, uint32_t ciaddr, uint32_t server)
{
if (server)
return udhcp_send_kernel_packet(packet,
ciaddr, CLIENT_PORT,
server, SERVER_PORT,
client_data.interface);
return raw_bcast_from_client_data_ifindex(packet, ciaddr);  => modifié =
}
Le paramètre "server" est à zéro lorsqu'on broadcaste, or le renew automatique fait un unicast, ce qui utilise la fonction udhcp_send_kernel_packet, qui ne passe pas de CoS, contrairement à sa petite camarade raw qui modifie SO_PRIORITY avec le patch.

1er renew (mode auto mi-vie, et aussi USR1), en unicast:
send_renew(server_id, requested_ip) => bcast_or_ucast(&packet, ciaddr, server); => udhcp_send_kernel_packet => pas modifié pour CoS
La suite, seulement pour USR1 car lease_remaining à zéro, en broadcast :
send_renew(0 /*INADDR_ANY*/, requested_ip); => raw_bcast_from_client_data_ifindex(packet, ciaddr); => udhcp_send_raw_packet => modifié pour CoS
 

ça se fait en ouvrant juste un ticket ? parce ce j'ai des doutes qu'ils écoutent un inconnu qui leur propose de patcher leur code, mais bon..je suppose que d'autres l'ont fait pour obtenir l'ajout du "-y".

A noter que la fonction non patchée CoS (udhcp_send_kernel_packet) n'est utilisée qu'à 2 endroits dans tout le code dhcp client busybox : justement le renew en unicast, ainsi que le release (unicast).
Toutes les autres interactions dhcp client (send_select, send_decline, send_discover, renew broadcasté) utilisent la version raw (udhcp_send_raw_packet), donc avec CoS positionnée.

Par contre il peut y avoir un sujet côté Unifi s'ils modifient udhcp_send_kernel_packet car elle est aussi utilisée dans le dhcpd (serveur donc) juste pour send_packet_to_relay(), ajouter une CoS pourrait poser problème, même si très peu probable. 

EDIT : ticket ouvert...on peut toujours rêver. Je leur signale quand même que cela me semble nécessaire pour fournir complètement la fonctionnalité de DHCP client CoS

Ma configuration est un peu différente de celle présentée ici sur le chat, j'essaie avec une UFIBER LOCO GPON. Le problème est que je n'arrive pas à me connecter sur le GPON, quelqu'un connaît-il le problème ? Ai-je besoin du fti/xxxxxx et du mot de passe pour le faire fonctionner ?

De plus, j'ai essayé d'appliquer tous les paramètres prévus pour l'UDM SE à mon Dream Router. Cela ne fonctionne pas, je pense que c'est certainement dû à l'absence de connexion du GPON ? En tout cas, c'est très embêtant qu'Orange ne propose pas ce genre de choses. Je travaille pour une entreprise allemande et nous n'avons ce problème dans aucun autre pays AUTREMENT AVEC un opérateur français. Dans toute l'Europe, nous obtenons une IP fixe directe. C'est vraiment dommage

Es tu sur que ton ONU se sync avec l'OLT? Pourquoi ne pas utiliser le LEOX LXT-010H-D ou LXT-010S-H. En plus tu seras bridé a 1Gbps avec les Ufiber.

je ne sais pas si c'est synchro. Comment puis-je le contrôler exactement ? y a-t-il des instructions pour configurer correctement l'UFiber pour Orange ?

Je n'ai pas encore essayé le LEOX parce que je veux essayer avec l'UFiber, 1GBIT me suffit   merci.

La synchro ONU/OLT n'est pas du tout évidente et pas dit que ça marche sans bidouiller.
Deja tu dois avoir la main sur les parametres de ton ONU, et ensuite savoir les paramétrés tu peux lire ça pour t'aider:
https://lafibre.info/remplacer-livebox/guide-de-connexion-fibre-directement-sur-un-routeur-voire-meme-en-2gbps/
et ensuite comprendre ce qui a été fait sur le LEOX
https://lafibre.info/remplacer-livebox/mise-en-route-leox-lxt-010h-d/

Un fois que tu auras une synchro tu pourras passer à la partie DHCP authentifié et CoS 6

Oui si vous lisez nos derniers échanges, l'acquisition du bail v4 fonctionne avec la version EA/beta de Network depuis plusieurs semaines, version qui dispose de la Cos 6 (et qui est maintenant publique).
Le problème réside maintenant dans la phase de renouvellement (renew) automatique à mi-bail (3,5 jours) qui provoque une déconnexion car la requête unicast renew est dépourvue de la CoS 6.
Nous avons identifié (cf les échanges récents) l'endroit du code source d'Unifi où ils ont oublié de mettre la CoS dans la création du paquet Unicast et j'ai ouvert un ticket pour demander si la modif était possible car simple...