jojo

regardes dans ma signature, il y a un vieux lien qui explique comment configurer les caméras sur la HCL

full z)wave avec un BON maillage, tu auras une très bonne fiabilité. Mais ce sera toujours moins fiable que du filaire. Alors si tu dois tout refaire, que tu as le pognon, ... le NKX serait la Rolls

c'est vrai la 14" à l'ai sympa, mais je ne vois pas le prix ?

merci pour ces infos. Je cherchasi qqch compatible VESA, car j'ai déja un VESA sur le mur, donc juste 4 vis dans la nouvelle tablette, et c'est fini. Maintenant, l'allemand, ce n'est pas mon truc.... mais je tiens ça en réserve

à partir d'ici le VD est compatible v4

n'y a-t-il pas également qqch dans ma signature en v4 ?

que 2019 soit pleins de nouveautés amusantes !

dans tes multitudes de recherches n'aurais-tu pas trouvé qqch en PoE et VESA taille tablette (11-15 pouces) ?

j'ai envie de dire oui. Voici le scénario de test que j'ai fait : depuis mon syno, j'ai propagé à no-ip un fausse adresse externe j'ai testé , et pas de connexion (youpie !) j'ai fais la manip du lien ci-dessus sur mon USG j'i refait le test, et c'est ok =< c'est qu'il a eu la bonne IP

voici comment faire. J'ai testé, et ça fonctionne, sans commande CLI https://community.ubnt.com/t5/UniFi-Routing-Switching/USG-Dynamic-DNS-support-for-noip-com/td-p/1655333

comme je n'ai pas d'IP publique fixe, je suis obligé de passer par un DDNS. Et pour mon reverse proxy, ça fonctionnait, car c'était mon syno (qui fait le reverse proxy) qui mettait déjà à jour le OVH ... ah bon ? car avec mon ASUS, finger in the noze ... Je cherche chez mon autre copain (Google) pour no-ip et usg

mon DDNS était configuré sur mon autre router, et je l'ai juste reconfiguré sur mon syno, car no-ip.com n'est pas dans la liste USG. J'ai honte, tout ça pour ça ...

merci, j'ai trouvé la solution à mon problème de Port Forwarding. Je ne sais pas si j'ose dire quel était le problème, de peur de me faire bannir à vie de ce forum.

j'ai déjà activé les log sur une règle de port forwarding, mais je ne sais pas où je peux les voir

D'abord, je vousdrais que ça fonctionne car c'est supposer fonctionner. Je ne veux pas être limité. Je passe par un reverse proxy sur mon syno en effet. Je viens de modifier toutes mes commandes IFTTT qui accèdes à ma LD pour passer par le reverse (pour rassurer, il n'y a pas de mdp qui est envoyé) Je vais tester avec mes backup externes si ça passe également par le reverse. Il me restera un dernier soucis, c'est que pour accéder à l'interface de commande de ma LD, je dois renseigner DEUX ports différents, et là avec un reverse, je ne vois pas comment faire. Mais je souhaite malgré tout que la fonctionnalité fonctionne as designed ... Idées bienvenues

si tu ne vois pas les images depuis et bureau, ou depuis chez toi ? Car moi je ne les voyaient pas depuis le bureau, mais c'est ok depuis chez moi

sinon dans la config, le seul endroit où je vois qu'on parle de WAN IN et de WAN Local, c'est au niveau des FW qui sont remplies automatiquement

merci de vouloi m'aider, mais je ne comprends pas ta question, . Voici ma config

j'ai joué à l'apprentit sociers, certe, mais maintenant tout est igré. Et pour ceux qui ont le courage, il y a ceci qui pourrait être une lecture intéressante : https://openclassrooms.com/fr/courses/1561696-les-reseaux-de-zero/3199562-ladressage-cidr

j'ai pris le USG "normal". Par contre j'ai toujours des soucis avec le Port Forwardinng : Le seul qui fonctionne est le premier que j'ai mis en place pour le reverse proxy sur le port 443. Tous les autres (pour les backups à distance de mes synos, pour me connecter à ma LD, ...) ne fonctionnent pas. Dès que je remets mon ancien router, c'est ok. Donc c'est un soucis avec l'USG. Mais j'ai vérifié, pas de fautes d'IP ou de ports. La seule chose que je vois de différent entre mon reverse et les autres, c'est que le reverse (port 443), je l'ai créé en premier, et c'est un port standard. Je cherche comme un fou sans comprendre pourquoi. Si tu as d'autres bonnes idées ...

@mprinfo, In masque de sous-réseau 255.255.255.0 te permet FF host, par exemple (192.168.1.0 à 192.168.1.255 OU 192.168.2.0 à 192.168.2.255 ou 10.10.10.1 à 10.10.10.255 ou ...) En fait les groupes à 255 sont bloqués et ceux à 0 sont libres. Comme moi je voulais passer de 192.168.2.x à 192.168.1.x (ce sont à priori 2 sous réseaux différents qui ne peuvent pas se parler avec un masque 255.255.255.0, alors j'ai modifié le masque TEMPORAIREMENT (le temps que je fasse ma migration) à 255.255.0.0. pour que les 2 sous-réseaux puissent communiquer entre eux

j'avais été en effet trop rapide pour la config de mon USG, et je n'avais pas encore mis en place le port forwarding pour le port 443, qui est indispensabe pour mon reverse proxy. MERCI de la "remarque", je l'ai fait, et évidemment, ça fonctionne !

moi c'est bon, je suis toujours belge ;-)

Je confirme, quand je l'ai reçu ce pm, je l'ai installé. L'adoption s'est fait nikel, comme attendu. Mais mon revers proxy qui est sur mon syno ne fonctionne plus, il me redirige systématiquement vers la page de config de l'USG. Ca commence à devenir lourd. Allez, bon réveillon

oui, et je n'arrivais pas à l'adopter dans mon contrôleur. Après des heures pour rien avec le supports Ubiquiti, j'ai trouvé le pourquoi : c'est un bug dans le controleur : s'il est en 192.168.22.x, il ne veut pas adopter des devices en 192.168.1.x. J'ai observé ce phénomène lorsque j'ai migré toutes les IP de mes devices de 192.168.2.x vers 192.168.1.x Si mon controleur était en 192.168.2.x et un de mes AP en 192.168.1.x, il ne voulait pas s'adopter. Dès que j'ai migré mon controleur vers 192.168.1.x, l'adoption de mon AP en 192.168.1.x s'est faite immédiatement, ET mes 2 autres AP qui étaient toujours en 192.168.2.x fonctionnaient toujours. Et le masque de sous-réseau de mon serveur DHCP était à 255.255.0.0, afin que les 2 sous-réseaux puissent coexister.. C'était donc vraiment un bug du contrôleur, non connu par Ubiquiti. Donc je retente le USG, qui devrait m'arriver demain (car l'autre, je l'ai donné à un ami, et il va comme un charme chez lui)