Je sais qu'on est dans un topic NO MODS, mais ça n'est malheureusement pas encore possible pour la TV...
Pour compléter ce tuto, j'ai donc fait un petit script à installer sur la gateway pour la configurer.

Il est disponible là : https://github.com/jbbodart/orange-iptv

J'ai essayé de le garder le plus léger possible. Il sera nécessaire tant qu'Unifi ne permettra pas la configuration de plusieurs VLAN sur le WAN 

Je viens de tester et ca fonctionne a merveille merci infiniment !
Pour ma part comme j'utilise adguard home en DNS j'ai ajouter une config client qui utilise les DNS de orange (récup par mon routeur sur le WAN), ca me permet de garder le DoT et DoH de adguard pour les autres clients.

Encore merci

Hm Si tu as la souscription "CyberSecure" tu mets les DNS en auto : les appareils de ton LAN vont utiliser ton routeur UNIFI pour DNS. Et dans la partie CyberSecure / Encrypted DNS en auto ça utilise le DoH sur Cloudflare mais tu peux mettre ceux que souhaitent dans la partie Predefinied dont les Adguard

WARNING si tu utilises la partie Content Filter (genre pour tes gamins) ca va détruire TOUTES les requêtes DNS qui passent en dehors des DNS de ton routeur Unifi et tu es obligé de diffuser les DNS de ton routeur unifi a tes équipements.

Le DNS coté LAN est en configure manuellement pour pointer vers mes des Adguard. Je n'utilise pas le dns crypté de unifi mais directement les DNS de quad9 et Cloudflare dans adguard comme upstream.
Le DNS coté WAN en revanche est en auto, ca me remonte les DNS de orange par DHCP sur le routeur.

Donc tout roule, je n'utilise aucun filtrage ou fonctionnalité de unifi, je les trouves pas assez personnalisable comparativement a adguard ou tu peux carrément avoir des config spécifique par client plus le DoT

Tout d'abord, merci à tous ceux qui partagent et font vivre ce forum !

En découvrant ce sujet, je me suis dit que j'allais tenter l'upgrade de mon installation.

Jusqu'à présent, la config est la suivante :
- fibre Sosh (avec Livebox 5 dans son carton)
- config fonctionnelle en IPv4 avec un USG-3P + LEOX LXT-010G-D (sur lequel ont été flashés les options GPON_SN / PON_VENDOR_ID / HW_HWVER)

Je souhaiterais passer à l'UCG Ultra (mis à jour avec la dernière version d'UniFi OS), mais je n'arrive pas à mettre en place une configuration fonctionnelle.
J'ai suivi le guide et j'ai paramétré :
- le VLAN 832
- le clonage d'adresse MAC
- les 3 options 60 / 77 / 90 en recopiant les mêmes valeurs qui sont actuellement utilisées avec l'USG-3P
- le CoS DHCP à 6

Malgré cela, je n'arrive pas à établir de connexion.
Y a-t-il une étape que j'aurais loupée ?

Merci par avance pour votre aide.

Hello,

Pourrais tu faire un screen de te pas page de config internet (la même que dans mon post initial). Est ce que tu obtiens une IP de park 172... ou autre chose ?

Bonjour à tous,
Merci pour ces indications, qui permettent de mettre en place simplement le bypass.

Je fonctionne avec un WAS110, configuré d’après le WIKI, pas de souci depuis vendredi, et ce matin surprise coupure à 2h10 du mat, obligé de redémarrer l’UDM à l’instant pour retrouver une connexion.

Avant de redémarrer, j’ai voulu vérifier le statut du WAS et je vois que je n’arrive plus à l’atteindre (sur 192.168.11.1), j’ai pourtant bien la route static, et cela fonctionnait vendredi après la fin de mise en place, étant donné que j’avais pu voir le statut 5.1 associated.

Je ne sais pas si ce post à sa place sur ce topic ou plutot sur ceux relatif au WAS, mais pour moi, c’est plus côté UDM que ça bloque pour acceder. Est-ce que ça peut venir du VLAN ? (Genre il faudrait que je sois sur un port sur le même VLAN et sur le CIDR 11.0/24 ?)

Merci

Bah pour joindre 192.168.11 depuis 192.168.1 il te faut un "tuyau" : routage aller et retour  et/ou regles de firewall qui le permettent aller et retour. Possiblement le WAS peut n'accepter que les IP sources en 192.168.11 parce qu'il a pas de route par defaut à joindre pour balancer ses réponses.

Oui, c'est pour ça que j'ai mis une route static vers l'interface WAN et qui pointe sur le 192.168.11.0/24, je pense que c'est le tag VLAN 832 sur cette interface qui pose problème, même si par défaut tous les port sont en VLAN ALL, le VLAN 832 n'éxistant pas sur l'UDM, je vais essayer de le créer.

Edit: bon bah même en créeant ce VLAN, pas plus de succès

Ceux qui utilisent le WAS110 avec l’UDM, vous faites comment pour y acceder une fois la connexion fibre fonctionnelle ?

En ssh avec cette commande en remplaçant X par le numéro du port

Code: [Sélectionner]

ip route add 192.168.11.0/24 dev ethX

Merci Elerako, en effet cela fonctionne, quelle est la différence avec une route static avec les mêmes paramètres ?

Sinon, même problème ce matin qu’hier, coupure internet vers 4h du matin, obligé de reboot l’UDM pour retrouver un accès. Comme je n’avais pas accès à ta réponse, je n’ai pas pu voir l’état du SFP avant reboot, je verrai la prochaine fois.

Par contre, dans les journaux du sfp, j’ai ce genre de chose (Dec 5 correspond à ce matin, je n’ai reglé la date qu’à l’instant) :
Thu Dec  5 11:43:33 2024 kern.info kernel: [324782.414630] sw-multicast: port 1(gem1) entered disabled state
Thu Dec  5 11:43:33 2024 daemon.notice netifd: Interface 'lct' is now down
Thu Dec  5 11:43:33 2024 daemon.notice netifd: Interface 'lct' is disabled
Thu Dec  5 11:43:33 2024 daemon.notice netifd: Network device 'eth0_0_1_lct' link is down
Thu Dec  5 11:43:33 2024 daemon.notice netifd: Interface 'lct' has link connectivity loss
Thu Dec  5 11:43:33 2024 kern.info kernel: [324782.625435] device pmapper1 left promiscuous mode
Thu Dec  5 11:43:33 2024 kern.info kernel: [324782.629248] sw1: port 2(pmapper1) entered disabled state
Thu Dec  5 11:43:33 2024 kern.info kernel: [324782.635317] device eth0_0 left promiscuous mode
Thu Dec  5 11:43:33 2024 kern.info kernel: [324782.638953] sw1: port 1(eth0_0) entered disabled state
Thu Dec  5 11:43:33 2024 kern.err kernel: [324782.644144] br_info NULL: pmapper1
Thu Dec  5 11:43:33 2024 kern.err kernel: [324782.647492] br_info NULL: pmapper1
Thu Dec  5 11:43:33 2024 kern.err kernel: [324782.650952] br_info NULL: pmapper1
Thu Dec  5 11:43:33 2024 kern.err kernel: [324782.654456] br_info NULL: pmapper1
Thu Dec  5 11:43:33 2024 kern.err kernel: [324782.657857] br_info NULL: pmapper1
Thu Dec  5 11:43:33 2024 kern.err kernel: [324782.661374] br_info NULL: pmapper1
Thu Dec  5 11:43:34 2024 kern.info kernel: [324782.763690] device gem1 left promiscuous mode
Thu Dec  5 11:43:34 2024 kern.info kernel: [324782.767121] sw-multicast: port 1(gem1) entered disabled state
Thu Dec  5 11:43:34 2024 kern.info kernel: [324782.787452] device eth0_0_2 left promiscuous mode
Thu Dec  5 11:43:34 2024 kern.info kernel: [324782.791156] sw-multicast: port 2(eth0_0_2) entered disabled state
Thu Dec  5 11:43:35 2024 daemon.crit dropbear: Network interface 'lct' is not available!
Thu Dec  5 11:43:36 2024 authpriv.info dropbear[2399]: Early exit: Terminated by signal
Thu Dec  5 11:43:36 2024 daemon.notice netifd: Interface 'lct' is enabled
Thu Dec  5 11:43:36 2024 daemon.notice netifd: Interface 'lct' is setting up now
Thu Dec  5 11:43:36 2024 daemon.notice netifd: Interface 'lct' is now up
Thu Dec  5 11:43:37 2024 daemon.notice netifd: Network device 'eth0_0_1_lct' link is up
Thu Dec  5 11:43:37 2024 daemon.notice netifd: Interface 'lct' has link connectivity
Thu Dec  5 11:43:37 2024 user.notice firewall: Reloading firewall due to ifup of lct (eth0_0_1_lct)
Thu Dec  5 11:43:38 2024 daemon.info dropbear: Using network interface 'lct' (network device 'eth0_0_1_lct') for direct binding
Thu Dec  5 11:43:39 2024 user.info : Binding to interface 'eth0_0_1_lct'
Thu Dec  5 11:43:39 2024 authpriv.info dropbear[29363]: Not backgrounding
Thu Dec  5 11:43:39 2024 daemon.info 8311: Starting ping to: 192.168.11.2
Thu Dec  5 12:00:02 2024 kern.info kernel: [325770.918487] sw1: port 1(eth0_0) entered blocking state
Thu Dec  5 12:00:02 2024 kern.info kernel: [325770.922325] sw1: port 1(eth0_0) entered disabled state
Thu Dec  5 12:00:02 2024 kern.info kernel: [325770.928629] device eth0_0 entered promiscuous mode
Thu Dec  5 12:00:02 2024 kern.info kernel: [325770.932882] sw1: port 1(eth0_0) entered blocking state
Thu Dec  5 12:00:02 2024 kern.info kernel: [325770.937605] sw1: port 1(eth0_0) entered forwarding state
Thu Dec  5 12:00:02 2024 kern.info kernel: [325771.172392] sw-multicast: port 1(gem1) entered blocking state
Thu Dec  5 12:00:02 2024 kern.info kernel: [325771.176957] sw-multicast: port 1(gem1) entered disabled state
Thu Dec  5 12:00:02 2024 kern.info kernel: [325771.183863] device gem1 entered promiscuous mode
Thu Dec  5 12:00:02 2024 kern.info kernel: [325771.220111] sw-multicast: port 1(gem1) entered blocking state
Thu Dec  5 12:00:02 2024 kern.info kernel: [325771.224615] sw-multicast: port 1(gem1) entered forwarding state
Thu Dec  5 12:00:02 2024 kern.info kernel: [325771.335764] sw-multicast: port 2(eth0_0_2) entered blocking state
Thu Dec  5 12:00:02 2024 kern.info kernel: [325771.340638] sw-multicast: port 2(eth0_0_2) entered disabled state
Thu Dec  5 12:00:02 2024 kern.info kernel: [325771.347786] device eth0_0_2 entered promiscuous mode
Thu Dec  5 12:00:02 2024 kern.info kernel: [325771.352009] sw-multicast: port 2(eth0_0_2) entered blocking state
Thu Dec  5 12:00:02 2024 kern.info kernel: [325771.357915] sw-multicast: port 2(eth0_0_2) entered forwarding state
Thu Dec  5 12:00:03 2024 kern.info kernel: [325771.982319] sw1: port 2(pmapper1) entered blocking state
Thu Dec  5 12:00:03 2024 kern.info kernel: [325771.986321] sw1: port 2(pmapper1) entered disabled state
Thu Dec  5 12:00:03 2024 kern.info kernel: [325771.992926] device pmapper1 entered promiscuous mode
Thu Dec  5 12:00:03 2024 kern.info kernel: [325771.997009] sw1: port 2(pmapper1) entered blocking state
Thu Dec  5 12:00:03 2024 kern.info kernel: [325772.002132] sw1: port 2(pmapper1) entered forwarding state
Thu Dec  5 12:00:03 2024 kern.info kernel: [325772.572380] device pmapper1 left promiscuous mode
Thu Dec  5 12:00:03 2024 kern.info kernel: [325772.576169] sw1: port 2(pmapper1) entered disabled state
Thu Dec  5 12:00:03 2024 kern.info kernel: [325772.626468] sw1: port 2(pmapper1) entered blocking state
Thu Dec  5 12:00:03 2024 kern.info kernel: [325772.630504] sw1: port 2(pmapper1) entered disabled state
Thu Dec  5 12:00:03 2024 kern.info kernel: [325772.637069] device pmapper1 entered promiscuous mode
Thu Dec  5 12:00:03 2024 kern.info kernel: [325772.641166] sw1: port 2(pmapper1) entered blocking state
Thu Dec  5 12:00:03 2024 kern.info kernel: [325772.646279] sw1: port 2(pmapper1) entered forwarding state
Thu Dec  5 13:37:40 2024 daemon.err uhttpd[2363]: luci: accepted login on / for root from 192.168.0.158
Thu Dec  5 14:00:27 2024 authpriv.info dropbear[13794]: Child connection from 192.168.0.161:65234
Thu Dec  5 14:00:27 2024 user.info : Binding to interface 'eth0_0_1_lct'
Thu Dec  5 14:01:11 2024 authpriv.notice dropbear[13794]: Password auth succeeded for 'root' from 192.168.0.161:65234
Mon Oct 27 06:28:19 2025 cron.err crond[2244]: time disparity of 468971 minutes detected
Mon Oct 27 06:46:13 2025 authpriv.info dropbear[13794]: Exit (root) from <192.168.0.161:65234>: Disconnect received
Une idée ? La connexion est stable le reste du temps, mais cela fait 2x que cela tombe pendant la nuit.
(Installation vendredi aprem, première coupure mardi 2h puis de nouveau mercredi 3h45)

D’après une analyse ChatGPT, cela pourrait venir du fait que le SFP ping la 192.168.11.2 regulièrement pour keepalive, et bascule le bridge, et ça fait perdre le lien WAN à l’UDM qui ne refait pas le DHCP/PPPoE correctement après ce flap.

Solution, rendre accessible l’adresse 192.168.11.2 sur l’interface wan via : ip addr add 192.168.11.2/24 dev eth9
On va voir si ça tient.