Bonjour @joogo,

C’est un bon début :smileyhappy:

Sur Mac j’utilise Textwrangler, un logiciel gratuit. Il peut interpréter divers codes et langages de programmation et de script et les afficher en conséquence. Utile avec json, car l’imbrication devient parfois déroutante. Textwrangler possède même un client FTP. Vous pouvez télécharger le fichier directement depuis l’éditeur. Sous Windows, j’utilise Notepad++

À cause de la version du contrôleur : je n’ai pas encore mis à jour vers la 0.6.9, mais cela ne devrait pas avoir d’importance. En gros, vous pouvez toujours utiliser la dernière version (5.5.x ou 5.6.x), sauf si vous souhaitez travailler sur la ligne stable. Les versions stables sont fournies avec la version du contrôleur. Avec une telle mise à jour vous revenez toujours à cette version, la vôtre est désormais 5.4.16 stable si je ne me trompe pas. Ensuite, vous devez installer manuellement au moins le même (5.5.17) qu’avant. La raison est MongoDB. Malgré la réinitialisation, il reste sur la version DB (5.5.17 dans votre cas) qui a été exécutée en dernier. La rétrogradation n’est pas possible, même si cela semble être le cas. Soyez patient après une mise à jour ; le contrôleur peut prendre jusqu’à 15 minutes pour fonctionner à nouveau. Jusqu’à ce que vous reveniez à la version 5.5.17 ou supérieure, le contrôleur ne fonctionnera pas et ne sera pas provisionné. Vous pouvez voir l’état de la touche cloud dans le menu, qui est maintenant probablement arrêté.

Maintenant, cela dépend de ce que vous réinitialisez. vous pouvez maintenant commencer avec la version 5.4.16, adopter tous les appareils, puis restaurer la sauvegarde. Si tout fonctionne, vous pouvez passer à 5.5.x (écrivez x maintenant, il est possible que quelque chose de plus récent soit disponible d’ici là).

Votre fichier de configuration fonctionne, il vous suffit de remettre votre contrôleur en marche.

Salutations

Roli

Salut BurningRoli

Merci pour les conseils avec les deux éditeurs de texte. Textwrangler (Mac) est certainement intéressant. Je vais le télécharger et l’explorer un peu quand j’en aurai l’occasion.

Mon statut est actuellement :

Je n’ai pas pu réparer l’échec des adoptions, j’ai donc réinitialisé à nouveau l’USG, l’USW, l’UAP et CloudKey, fonctionnant à l’origine avec Controller 5.5.17 / fw 0.6.9) sans Swisscom TV 2.0 fonctionnel.

J’ai ensuite configuré à nouveau manuellement la configuration réseau, les règles de pare-feu et le config.gateway.json avec le contrôleur version 5.4.16 / fw 0.6.4. Plus aucune adoption n’a échoué. Le test ultérieur avec Swisscom TV 2.0 a montré « Malheureusement, aucun signal TV n’est actuellement disponible sur cette chaîne ».

Puisque MongoDB est à 5.5.17, j’ai maintenant mis à niveau le firmware vers 0.6.8 puis vers 0.6.9, puis le contrôleur vers 5.5.17, ainsi que l’USW et l’UAP.

Mais Swisscom TV 2.0 ne fonctionne toujours pas. Tout le reste va bien.

Ensuite, j’ai effectué une restauration à partir de la sauvegarde que j’ai créée dimanche avec 5.5.17. Cette tentative a également échoué, Swisscom TV 2.0 ne fonctionne pas.

Dimanche dernier, je n’ai probablement pas attendu assez longtemps (15 minutes). La mise à jour n’est peut-être pas encore terminée.

Je me demande si je dois installer le logiciel du contrôleur sur le Mac sans CloudKey. Et créez à nouveau toute la configuration sur un « site greenfield ».

Ou vous pouvez effectuer une réinitialisation d’usine sur le CloudKey et y réinstaller le logiciel du contrôleur.

BurningRoli que pourriez-vous me recommander ? Ou existe-t-il un moyen plus simple ?

Peut-être voyez-vous d’autres possibilités. Je serais très heureux de recevoir du soutien.

Merci beaucoup pour votre aide.

Salutation

Ouais

Bonjour @joogo,

Si vous réinitialisez le Cloudkey, vous disposerez à nouveau d’une base de données exécutable. Il s’agit de la version avec laquelle le firmware Cloudkey est fourni. Désolé si je me suis trompé/inexact.

Puisque la clé cloud est à nouveau vierge, il n’y a plus de json.

Soit vous accédez à la version 5.5.x souhaitée avec le contrôleur nu, puis effectuez la configuration, soit effectuez d’abord la configuration et ajoutez le firmware plus tard. Important, effectuez toujours des sauvegardes et attendez que le contrôleur soit à nouveau en ligne.

Au début, je ne savais pas si je devais choisir la variante Cloudkey ou macOS, d’autant plus que j’ai un serveur macOS en cours d’exécution qui gère le DNS pour moi. J’ai opté pour le CK afin de disposer d’un environnement opérationnel sécurisé (le 2e DNS est l’USG). Il n’est pas nécessaire que le contrôleur soit en ligne en permanence, mais la manipulation est plus facile s’il est toujours en ligne.

PS : si vous mettez un @ devant le nom, la personne recevra un email l’informant qu’elle a été mentionnée dans un fil de discussion.

Salutations Roli

Salut @BurningRoli

J’ai enfin SwisscomTV 2.0 qui fonctionne derrière l’USG/USW. Regardez Swisscom TV plus longtemps sans aucun problème.

Comme vous l’avez découvert, il s’agit d’un problème de contrôleur.

J’ai effectué les étapes suivantes.

Réinitialisez à nouveau le contrôleur 5.5.17 et supprimez le fichier Json, puis redémarrez USG / USW.

Rechargez ensuite le config.gateway.json sur le contrôleur. Aucun provisionnement automatique n’a lieu.

La surveillance IGMP est désactivée dans le réseau, USG/USW sont fournis. Le gouvernement américain a redémarré. Ensuite, IGMP est à nouveau activé dans le réseau >> USG / USW sont fournis.

Ensuite, SwisscomTV 2.0 a fonctionné pour moi.

Nouveau statut actuel :

Appareils UniFi FW/SW :

Micrologiciel CloudKey v0.6.9

Contrôleur CloudKey 5.5.17

Gouvernement américain 4.3.41.4975503

ETC8 150W 3.8.2.6573

Je peux donc désormais m’occuper de l’installation de l’UAP et de la configuration des VLAN que je souhaite.

Merci BurningRoli.

Sans votre soutien, je ne serais pas arrivé aussi loin.

Salutation

Ouais

Bonjour à tous

Je possède également les appareils correspondants d’Unifi.

Je n’ai pas compris exactement sur quel appareil je dois copier le fichier “config.gateway.json”.

J’ai ajusté le pare-feu.

1) Sur Cloudkey -> ça ne semble pas fonctionner là-bas

2) Ou sur USG Security Gateway, je n’y ai pas d’autorisations d’écriture

L’accès est possible avec WinSCP

Micrologiciel CloudKey v0.6.9

Contrôleur CloudKey 5.5.11

Gouvernement américain 4.3.48.4994101

Merci beaucoup pour l’aide

Salutations Lorenz

Bonjour @Lori77,

La réponse 1) est correcte. La configuration est fournie par le contrôleur à l’USG.

Le chemin sur le CK est /srv/unifi/data/sites/default/, où /default représente le 1er site. Ce fichier n’existe pas encore à ce stade.

Vérifiez que le fichier de configuration est au format Unix et que l’encodage est pur UTF-8, sans BOM ni autre chose. Si cela ne convient pas, il n’y aura pas de provisionnement. Il s’agit d’une erreur courante qui n’a rien à voir avec la validation JSON.

Utilisez un éditeur comme Notepad++ qui peut enregistrer en toute sécurité UTF-8.

Salutations

Roli

Salut Roli

Merci beaucoup pour le conseil.

J’ai chargé l’éditeur++

Maintenant, j’ai une image en direct pendant environ 11 secondes, puis elle s’arrête. au moins plus qu’avant.

Regarder des enregistrements est possible, cela fonctionne via un autre produit.

Et j’ai l’IB sur le réseau IP 172.16.1.1

J’ai aussi mis le DMZ sur l’USG là-bas.

Et l’USG fonctionne sur 192.168.2.1

Mais quelque part, je fais une erreur parce que je n’ai pas d’image en direct. Peut-être que j’ai aussi un problème avec le fichier de configuration, qui ne fait que 739 bits.

Merci beaucoup pour votre aide Lorenz

Salut Lorenz @Lori77,

Mon fichier fait environ 900 octets. Je suppose que tu voulais aussi dire octet. Alors 739, c’est ok !

Il semble que le proxy IGMP ne fonctionne pas. As-tu les lignes suivantes dans la configuration ?

{
“protocoles”: {
“igmp-proxy”: {
“interface”: {
“eth0”: {
“alt-subnet”: [ “0.0.0.0/0” ],
“role”: “en amont”,
“seuil”: “1”
},
“eth1”: {
“alt-subnet”: [ “0.0.0.0/0” ],
“role”: “en aval”,
“seuil”: “1”
}
}
}
}
}

Avez-vous un USG 3P ou 4 pro ? Le 4Pro nomme les ports différemment. Voir mon post du 7 mai 2017 à 16h06 et les suivants.

Si la config n’est pas au bon format, alors elle ne sera pas prise en compte.

Comme je l’ai dit, format UNIX et UTF-8 pur. Vérifiez ceci avec Notepad++

Si ça ne marche pas, préviens-moi. Je t’ai envoyé mon adresse email par MP.

Salutations

Roli

Salut Roli

Le TV-Box fonctionne désormais parfaitement, il y avait toujours une erreur dans le pare-feu. Sans votre grande aide, je n’aurais jamais obtenu le résultat.

Merci beaucoup pour tout.

Salutations Lorenz

Bonjour les amis

Samedi, j’ai également connecté mes appareils SCTV 2.0 à l’USG 4 et je suis également aux prises avec le problème de multidiffusion avec la télévision en direct. J’ai configuré correctement les règles du pare-feu d’après les captures d’écran publiées par @BurningRoli. La surveillance IGMP est également activée et le fichier config.json est intégré dans le chemin décrit dans le contrôleur de clé cloud. Après le provisionnement, rien ne change. Message sur le téléviseur « la chaîne n’est actuellement pas disponible » ou quelque chose comme ça. Maintenant, la question demeure : le fichier json doit-il s’appeler « config.gateway.json » ou « config.gateway.json.txt » ? Et comment puis-je vérifier l’état d’activation du proxy ? J’ai essayé les deux fichiers mais rien n’a été fait ? modifié.

Salutations Marcel
P.S. Écrit depuis un iPhone.

@BurningRoli Merci beaucoup pour le code.json.

J’ai d’abord dû réinitialiser la clé cloud aux paramètres d’usine par défaut, puis télécharger le fichier config.gateway.json. J’ai ensuite immédiatement utilisé votre code terminé et tout a fonctionné parfaitement tout de suite. J’ai dû abandonner toute la configuration réseau pour cela, mais les quelques ports pour le NAS et les SSID ont été rapidement reconfigurés.

Merci beaucoup pour votre aide rapide !

Salutations Marcel

@BurningRoli

Est-il possible que des règles de pare-feu créées ultérieurement puissent être créées avec votre fichier config.gateway.json mais ne puissent plus être modifiées ?

Salutations Marcel

Salut Marcel @salihoi1,

Je l’ai testé plusieurs fois maintenant, je peux à tout moment supprimer les règles de pare-feu que j’ai moi-même créées.

Dans la vue des appareils de l’USG / Propriétés / Configuration / Gérer les appareils / se trouve l’élément « Forcer le provisionnement ». Faites cela 1 à 2 fois. J’ai déjà eu le même problème. Quel firmware USG utilisez-vous ?

Je reviendrai plus tard avec une mise à jour de config.gateway.json

Salutations

@BurningRoli
Bien Abig
J’ai le firmware 4.3.49.5001153 sur l’USG.
Et le contrôleur SW 5.5.20 se trouve dessus dans la clé cloud. J’ai forcé le provisionnement via l’application mobile. Je vérifierai à nouveau la situation demain matin.

Merci pour le conseil.

Salutations Marcel

Bonjour à tous,

La configuration évoquée dans les articles précédents présente un défaut : lors du changement de chaîne TV, des artefacts apparaissent dans l’image pendant une courte période.

J’ai redécouvert un fil de discussion sur le forum ubnt et copié sa solution dans le fichier config gateway.json intégré.

Pour moi, les artefacts ont disparu et les canaux changent subjectivement plus rapidement. La synchronisation avec les flux multicast respectifs semble s’être améliorée.

Au sujet de la configuration/optimisation, @Tux0ne Report m’est venu à l’esprit sur sa page d’accueil. Il y décrit les paramètres du commutateur Netgear, notamment le fait que la validation de l’en-tête IGMP doit être désactivée.

Vous en apprendrez davantage à ce sujet dans un autre fil de discussion que je suis sur le forum ubnt. Un conseil a récemment été publié sur la manière dont cela se déroule à l’USW.

La désactivation s’effectue à l’aide d’une entrée dans le fichier config.properties. Ce fichier se trouve au même emplacement que config.gateway.json et a pour tâche de configurer les fonctions qui ne peuvent pas être définies dans l’interface graphique. Analogue à config.gateway.json, créez le fichier config.properties, créez une entrée, téléchargez et provisionnez le etc.

Les paramètres USW peuvent être vérifiés comme suit :

- ssh vers un USW ou ouvrez la ligne de commande debug dans la configuration du périphérique, cela ressemble alors à ceci, les commandes sont rouges :

BusyBox v1.19.4 (2017-08-24 09:14:22 PDT) shell intégré (cendre)
Entrez « aide » pour une liste de commandes intégrées.

___ ___.__________.__
| | |____ |__\ ____/__|
| | / \ __) | | c) 2010-2017
| | | | \ \ | | Réseaux Ubiquiti, Inc.
|______|___| /__||__/ |__|
|_/ http://www.ubnt.com

  Bienvenue chez UniFi USW-16P-150 !

US.v3.8.11# telnet localhost

Passer en mode caractère
Le caractère d’échappement est ‘^]’.

Avertissement!
Les modifications peuvent perturber les paramètres du contrôleur et ne seront efficaces que jusqu’au redémarrage.

(UBNT) >activer

(UBNT) #afficher igmpsnooping

Mode administrateur…………………………… Désactiver
Nombre de trames de contrôle de multidiffusion………….. 0
Validation de l’en-tête IGMP……………………………. Désactivé
Interfaces activées pour la surveillance IGMP……Aucune
VLAN activés pour la surveillance IGMP………….. Aucun

(UBNT) #show igmpsnooping

Mode Administrateur…………………………… Activer
Nombre de trames de contrôle de multidiffusion………….. 37
Validation de l’en-tête IGMP……………………….Activé
Interfaces activées pour la surveillance IGMP……Aucune
VLAN activés pour la surveillance IGMP………….. 1

Ce qui est intéressant, c’est que même si la coche IGMP Snooping est cochée sur le réseau, IGMP Snooping n’était pas actif. Éteignez/enregistrez/provisionnez d’abord -> allumez/enregistrez/provisionnez - la surveillance IGMP du VLAN1 a été définie. Cela semble toujours être un bug.

Voici les fichiers de configuration :

config.propriétés

config.system_cfg.1=switch.igmp.header_checking=false

config.gateway.json pour USG4

{
“pare-feu”: {
“groupe”: {
“groupe d’adresses”: {
“IPTV_Source”: {
“adresse”: [
“224.0.0.0/4”,
“239.0.0.0/8”,
“195.186.0.0/16”
],
“description”: “Source IPTV”
},
“SCTV2_Source”: {
“adresse”: [
“213.3.72.0/24”
],
“description”: “Source de multidiffusion SCTV2”
}
}
},
“nom”: {
“WAN_IN” : {
“règle”: {
“3100” : {
“action”: “accepter”,
“description”: “autoriser la multidiffusion IPTV UDP”,
“destination”: {
“groupe”: {
“groupe d’adresses”: “IPTV_Source”
}
},
“log”: “désactiver”,
“protocole”: “udp”,
“source”: {
“groupe”: {
“groupe d’adresses”: “SCTV2_Source”
}
}
},
“3110”: {
“action”: “accepter”,
“description”: “autoriser IGMP”,
“log”: “désactiver”,
“protocole”: “igmp”
}
}
},
“WAN_LOCAL”: {
“règle”: {
“3100” : {
“action”: “accepter”,
“description”: “autoriser la multidiffusion IPTV UDP”,
“destination”: {
“groupe”: {
“groupe d’adresses”: “IPTV_Source”
}
},
“log”: “désactiver”,
“protocole”: “udp”,
“source”: {
“groupe”: {
“groupe d’adresses”: “SCTV2_Source”
}
}
},
“3110”: {
“action”: “accepter”,
“description”: “autoriser IGMP”,
“log”: “désactiver”,
“protocole”: “igmp”
}
}
}
}
},
“protocoles”: {
“igmp-proxy”: {
“interface”: {
“eth2”: {
“alt-sous-réseau”: [
“0.0.0.0/0”
],
“role”: “en amont”,
“seuil”: “1”
},
“eth0”: {
“alt-sous-réseau”: [
“0.0.0.0/0”
],
“role”: “en aval”,
“seuil”: “1”
}
}
}
}
}

Pour l’USG3P, remplacez eth2 par eth0 et eth0 par eth1 dans la section « protocoles ». Les règles de pare-feu peuvent également être définies dans l’interface graphique. Si vous avez des questions, n’hésitez pas à me le faire savoir.

Salutations

Roli

Bonjour @BurningRoli

Comment dois-je procéder lors du changement de fichiers ? Puis-je simplement supprimer l’ancien fichier config.gateway.json et copier la nouvelle version, puis prioriser et redémarrer, ou dois-je d’abord supprimer l’ancien fichier, prioriser et redémarrer et ensuite seulement installer, prioriser et redémarrer le nouveau ?

Salutations Marcel

Bonjour @salihoi1,

écrasez simplement, puis provisionnez USG. La configuration est lue lors du provisionnement. N’oubliez pas le fichier config.properties. La version de votre firmware est actuellement 5.5.20 = stable

Salutations Roli

Salut Roli @BurningRoli

Hier soir, lors du changement de config.gateway.json, j’ai eu le problème que le proxy IGMP n’était pas démarré, même après le provisionnement et le redémarrage de l’USG plusieurs fois.

J’ai ensuite supprimé les deux fichiers (config.gateway.json et config.properties), les ai provisionnés et les ai réinsérés. Depuis le réapprovisionnement sans redémarrage, cela fonctionne désormais parfaitement.

**Conclusion : Une très bonne config pour l’UniFi USG/USW
**

Je n’ai pas remarqué de différence lors du zapping des chaînes TV par rapport à la configuration SC d’origine (boitier SCTV directement sur l’IB). Encore mieux (on en a envie, bien sûr). J’ai également pu regarder un programme d’environ 45 minutes sans bégaiement, distorsion ou autre. Tout ce qui est nécessaire au bon fonctionnement du SCTV2.0 est contenu dans les deux fichiers et rend les longs tracas inutiles. Ajoutez des fichiers, provisionnez, redémarrez et profitez de SCTV 2.0.

Je ne peux que recommander le changement à tous les utilisateurs qui exécutent encore la première version de c_onfig.gateway.json et sans le fichier config.properties_. Vous remarquez vraiment une très grande différence.

**Je ne peux que recommander de pointer le marqueur de solution de ce fil vers la configuration actuelle.
**

MERCI @BurningRoli

Je voudrais vous remercier beaucoup pour le cœur et l’âme que vous avez mis dans ce fil ! Ce n’est pas quelque chose qui va de soi et je l’apprécie vraiment !

Salutations Marcel

Merci Marcel @salihoi1 pour votre retour.

Salutations

Roli