cdlog2

Re Re: Retour expérience.

Bonjour,

Je reviens sur l’utilisation du service DDNS du GL-MT300N-V2. J’avais cru avoir réussi à faire fonctionner le DDNS du petit routeur GL.Inet en tant que Client LAN du Routeur associé à ma BOX FAI connecté en ADSL et ayant une IP Dynamique Public.

L’appel DDNS http://xxxxyy.glddns.com a bien fonctionné 2 jours mais lorsque j’ai voulu refaire des essais, bizarrement les tentatives de connexions échoues à 80% ? alors que l’IP public de ma BOX n’a pas encore changée ?.

J’ai joint par Mail le service support de GL.Inet pour voir s’il avait un problème avec leur Serveur DDNS. Il me confirme rapidement, sans me donner des explications sur leur Routeur DDNS, que leur petit GL-MT300N-V2 doit être en Frontal en direct sur le WAN du Modem ADSL afin de récupérer l’IP public de l’ADSL et non derrière le Routeur du Modem et dont le serveur DHCP fourni une IP locale ???.

Ils n’ont pas insisté et non pas donné d’explication sur le fait que cela à pu fonctionner un moment et presque plus maintenant ! Echange mail pas très ouvert au dialogue !

Ce petit routeur GL-MT300N-V2 fonctionne sous une plateforme Linux et c’est la distribution OpenWrt en Open source qui gère l’ensemble des applications de communication. J’ai trouvé le GitHub avec les fichiers sources du firmware OpenWrt de ce petit routeur GL.Inet:  https://github.com/openwrt/packages/.

Les diverses interfaces du GL-MT300N-V2 sont gérées via des applications de OpenWrt sous forme de Plugins élaborés pour la plus part en BASH Script Shell. Voici le dossier des Plugins et applications Réseau: https://github.com/openwrt/net/

On trouve parmi, le package ddns-scripts qui contient les Sources qui gèrent le DDNS du GL.Inet. Ce que ne comprend pas, c’est que la fonction (Script Shell ) dédié à trouver l’IP Public de la BOX FAI, a du mal actuellement à trouver cette IP à travers le Gateway du Routeur de la BOX en tant que Client LAN directement associé au Routeur.

Je sais que l’Interface Linux cURL est installé car certains Scripts OpenWrt l’utilisent. Il y a une commande simple avec cURL qui permet de récupérer très facilement l’IP Public ADSL d’une BOX FAI à travers son Routeur, si vous êtes Client LAN DHCP direct de ce même Routeur.

Si ce Client LAN est un PC ou Micro Contrôleur (Raspberry pi, etc) sous Linux Ubuntu, Débian, Raspbian etc.., avec cUrl installé, comme c’est le cas du GL-MT300N-V2, si vous lancez la commande suivante via un Script Bash ou manuellement depuis une Console :

~# sudo curl http://ifconfig.me

cUrl vous renvoie immédiatement l’IP Public Dynamique de la BOX aussi simplement !

A priori, GL-MT300N-V2 permet de charger ou de modifier un Plugins OpenWrt existant. Je vais voir à étudier comment rajouter ce Test cUrl dans le Script dédié à la recherche de l’IP Public du plugin DDNS et lorsque la recherche de cette IP Public n’aboutit pas avec le Script de base..

J’ai soumis l’idée de rajouter ce simple test Bash cURL aux support Chinois de GL.Inet. Jusqu’à présent ils ne m’ont pas répondu !
Mais à l’origine c’est OpenWrt qui gère mal la recherche de l’IP Public dans son package ddns-scripts dans le cas de figure décrit plus haut.

Cdt

Ok pour tout.

Joignez Nicolas par Mail comme il vous le propose : contact@cartelectronic.fr

Bonne soirée,

Cdt

Ok Parfait.

Néanmoins surveillez votre alim qu’elle ne chauffe pas trop avec tous les Relais sur On et en naviguant sur les pages du WES !

Si vous constatez parfois des blocages ou perturbations du WES ou bizzareries avec vos capteurs, pensez à votre Alim avant d’incriminer autre chose.

Bonne journée,

Cdt

Bonjour,

Si je comprends bien, votre alimentation de 17V 1,5A alimente le WES et votre carte à 8 Relais.

Je suis persuadé que c’est la cause à votre problème. Le WES consomme environ 1A voir plus selon l’ajout du dongle Radio 868 Mhz et LCD. Votre carte 8 Relais consomme environ 0,7A. Les différents capteurs connectés au WES consomment aussi leur part.

Il faudrait changer votre ALIM par une autre plus puissante. Celle présentée en lien ci-dessous ferait l’affaire et vous auriez de la marge pour faire des extensions comme rajouter une autre Carte à 8 Relais si besoins :

https://www.cartelectronic.fr/alimentations-piles/69-alimentation-12vdc-125a-rail-din.html

Les résistances de Pul-lUp de 4.7K se connectent entre le +Vcc et le 1W du bus 1Wire et doivent se raccorder au plus près du dernier composant 1W en bout d’une ligne 1Wire.

Pour votre carte 8 Relais vous pouvez vissez directement une 4.7K sur son bornier 1W. Vous pouvez aussi rajouter une autre résistance de 4.7K sur une autre branche éloignée si vous avez un câblage en étoile, donc cela peut résoudre le PB de vos 2 Sondes qui ne répondent plus.

Cdt

Re: Un complément d’info. Je pense que vous l’avez vue, au chapitre 3 de la config DDNS dans la DOC du GL.Inet, on vous indique
que vous pouvez tester votre DDNS afin de voir s’il est opérationnel avant même de le configurer.

Depuis votre PC qui doit être un Client du GL.Inet (Wifi ou Lan) , Il suffit d’ouvrir une Console CMD sous Windows ( taper CMD dans la barre de recherche de Windows ) et dans la fenêtre noire ouverte vous tapez : nslookup wqxxxxx.glddns.com 8.8.8.8

ou wqxxxx est votre Identifiant DDNS visible dans le texte de la Config Cloud au dessus de la config DDNS .
La réponse à cette commande devrait être :

Serveur :   dns.google
Address:  8.8.8.8

Réponse ne faisant pas autorité :
Nom :    wqxxxxx.glddns.com
Address:  176.184.xx.xx

Ou Adresse est l’IP Public Dynamique ou l’IP Privé 4G utilisé par le DDNS et dont sa présence confirme que le DDNS est fonctionnel.
Dans le cas contraire vous devriez lire : *** dns.google ne parvient pas à trouver wqxxxxx.glddns.com : Non-existent domain

Si la réponse est positive avec une Adresse IP, alors essayé de configurer à nouveau votre routeur avec le DDNS et ne tenez pas compte du message :  » Mais ce routeur est derrière NAT ou vous n’avez pas d’adresse IP publique  »

J’ai aussi ce message lors du TEST DDNS mais tout fonctionne correctement. Il ne faut pas tenir compte de ce message. ( Possible Bug logiciel de l’Admin ).

Assurez vous de mettre la Config Réseau du WES en Mode DHCP=ON. car s’il est coincé avec une adresse Static comme par exemple 192.168.1.110, votre WES ne répondra pas. Vous pouvez modifier la config réseau du WES directement depuis son fichier de config RESEAU.CFG situé dans le dossier CFG de la carte mémoire (FTP ou Clé USB). Il suffit de mettre la rubrique DHCP=1 dans le Fichier. Par contre il faut rebooter le WES pour que la config soit prise en compte.

Veillez aussi à ouvrir les Ports Utilisés ainsi que les redirections entre la BOX et le GL.Inet et entre le GL.Inet et le WES.

Essayez ma config NAT avec la redirection du Port Entrant 9100 vers le Port Sortant 9100 pour l’IP du GL.Inet dans la config du Routeur de la BOX et configurer la redirection (Onglet Port Forward  )  du Port Entrant 9100 vers le Port Sortant 80 pour l’IP du WES dans la rubrique Pare-Feu du GL.inet.

N’oubliez pas d’ouvrir les Ports 80 , 443, 9100 pour TCP/UDP dans la config : Onglet Port ouvert sur le routeur, toujours dans la rubrique Pare-Feu du GL.Inet.

Si le Pare-Feu du routeur de votre BOX est activé, il faut aussi débloquer et autoriser ces même Port Entrant et Sortant selon la config disponible.

Tester votre liaison avec : http://wqxxxxx.glddns.com:9100/

Je croise les doigts !

Cdt

Correction : Dans la config Client du GL.Inet j’ai activé la mise en Static de cette IP 192.168.8.177 du WES avec le bouton de droite mis en Vert.

Surtout ne pas faire, j’avais mal compris, cela BLOC la liaison !! Mais cela n’est pas visible de suite ?

Par ailleurs, j’ai remarqué que toute la config n’est réellement prise en compte qu’après avoir coupé le 5 volt quelques seconde et au redémarrage après avoir fait un Reset avec le bouton sur le côté du GL.Inet. ??

Bonjour,

J’ai reçu mon tout petit routeur modèle GL-MT300N-V2. Je vous donne mon retour d’expérience.

J’ai connecté la RJ45 WAN du GL.Inet sur une des RJ45 LAN de ma BOX ( FAI ).
J’ai connecté un PC via le WIFI en tant que Client WIFI du GL.Inet. j’accède sans problème au menu Admin via l’adresse 192.168.8.1. Le GL.Inet lui à fourni l’IP local 192.168.8.101

J’ai configuré la config Câble (WAN) du GL.Inet sur DHCP, MA Box lui à donné l’IP 192.168.1.39. Via l’ADMIN du GL.Inet, J’ai fait la mise à jour de son Firmware à la dernière version 3.102.

Comme j’ai un 2eme WES qui me sert de test,  j’ai configuré sa propre config Réseau en mode DHCP=ON. J’ai connecté la RJ45 du WES à la prise RJ45 LAN du GL.Inet. Le WES à reçu l’IP locale du GL.INET 192.168.8.177. Dans la config Client du GL.Inet j’ai activé la mise en Static de cette IP 192.168.8.177 du WES avec le bouton de droite mis en Vert.

Dans ma BOX j’ai forcé l’IP locale 192.168.1.39 fourni au GL.Inet en Mode Static afin d’être assuré d’avoir toujours cette IP affecté au GL.Inet depuis ma BOX. Toujours dans ma Box, j’ai configuré le NAT afin de laisser passer le Port Ext: 1900 vers le Port Int. 9100 associé à l’IP et MAC du GL-Inet. soit IP 192.168.1.39 et Mac xx:xx:xx:xx:xx:xx

Dans la config Pare-Feu du GL.Inet, dans la rubrique Port Forward, J’ai autorisé pour l’IP local 192.168.8.177 (WES) la redirection du Port 1900 vers le Port 80.

Toujours dans le Pare-Feu du GL.Inet, dans la rubrique Port entrant sur le routeur, j’ai autorisé les Port 80. 443, 22 et 9100 comme Port Entrant. Je n’ai pas configuré le DMZ qui permet toutefois un trafic dans les deux sens et sans dicris des Ports.

Dans le menu Application du GL.Inet, rubrique Accès à Distance, J’ai Activé le DDNS avec les protocole HTTP, HTTPS, SSH. J’ai testé la liaison DDNS par Test DDNS du bandeau Texte bleu.

Il trouve l’IP Dynamique Publique de ma BOX mais m’affiche comme Vous le message :  Votre DDNS est réglé en tant que 176.184.xxx.xxx. Mais ce routeur est derrière NAT ou vous n’avez pas d’adresse IP publique.

J’ai revérifié toute ma config, et comme vous je ne comprends pas pourquoi cela ne répond pas au TEST vue que tout est bien configuré.
J’ai vue juste au dessus du DDN Dynamique la config Gestion du Cloud. Je n’ai pas activé cette gestion Cloud mais dans le texte en bleu de cette rubrique on me dit que mon identifiant d’appareil est: wqxxxxx.

Juste par curiosité j’ai voulu tester le DDNS du GL.Inet et j’ai lancé depuis mon navigateur : http://wqxxxxx.glddns.com:9100/

Et Plouf je tombe sur le login du WES, je me logue et j’accède au WEB du WES : Cela Fonctionne !

Donc je déduis que le message rendu lors du TEST DDNS qui spécifie : Mais ce routeur est derrière NAT ou vous n’avez pas d’adresse IP publique.  veut seulement dire que logiciel de l’ADMIN du GL.INET n’arrive pas à remonter le NAT du Routeur GL.Inet ( port 1900 > 80 ) ainsi que le NAT de ma Box ( port 1900 > 1900 )

J’ai relue la Doc du GL.Inet est on peut lire en tout petit dans une image de configuration du DDNS que pour faire fonctionner le DDNS il faut une adresss IP Publique.

Note : You have to have an Internal Public IP address to use the Dynamic DNS. If this router is behind NAT you may need to set up port forward in you ISP router.

Cela veut dire que le DDNS du GL.Inet n’est pas un Serveur VPN comme je le supposais mais un Serveur de DynDNS dédié au matériel de GL.Inet comme l’est NO-IP.

Donc c’est bien la gestion GLOUD qui permet les liaisons VPN.

Je ne peux pas essayer ce Cloud car je n’ai pas deux GL.Inet. Mais je pense que votre Pb avec le protocole HTTP qui ne passe pas est du à la config et autorisation du Port 80, dans vos divers Configs.

A moins que le Cloud utilise le Port 443 (HTTPS) pour faire la passerelle (Tunneling) entre les deux Clients GL.Inet et dans ce cas il faut convertir le protocole HTTPS en HTTP. (Il faut voir les Codes retour des transactions)

En tout cas ce petit Routeur, est vraiment génial et permet pleins de configs. Comme vous l’avez démontré il peut aussi utiliser la 4G depuis un Tel: Mobil pour faire un petit réseau local et se connecter à internet en Nomade avec un PC dans le cas ou le WIFI ou Hot Spot Wifi n’existe pas.

Cdt

Bonjour,

Lorsque vous rajoutez une ligne Programme et que vous la validez par Transférer, cette nouvelle ligne est ajoutée en FIN du fichier PROG.DAT mais aussi en Zone Mémoire interne au WES.

Le WES gère ensuite la logique de programmation depuis sa Mémoire interne. Le Fichier Prog.dat ne sera utilisé que lorsque le WES Reboot.

Lorsque le WES Redémarre, il perd une partie de sa gestion mémoire et récupère Toute sa Config via les Fichiers du dossier CFG. C’est alors que le fichier Prog.Dat  intervient. Il permet au WES de retrouver Toutes les lignes de programmes enregistrés suite à un redémarrage. Donc si vous supprimez le fichier Prog.dat et que vous forcez au WES de redémarrer, au retour vous avez perdu vos lignes de PROG.

Donc si une ligne de programme que vous créez et enregistrée  ( disons la dernière ligne),  fait ensuite planter les Process qui gèrent l’ensemble des lignes de programmation, Vous constatez les malfonctions mais aussi probablement un problème pour afficher à nouveau la page Programme.

Dans ce vous aurez beau redémarrer le WES, vous  aurez toujours le même Problème puisque le WES récupère la même config Prog. depuis le Fichier Prog.dat et vous tournez en ROND.

Le seul moyen de sortir de cette situation :

— c’est soit de supprimer ce fichier Prog.dat mais dans ce cas vous perdez toutes vos lignes de Programme au redémarrage du WES,

  — Ou soit vous éditez ce fichier  Prog.dat avec un éditeur de texte lambda ( Bloc-Notes par ex:)  et vous supprimez depuis la fin du fichiers texte la ou les dernières lignes qui ont été Rajoutés et que vous pensez faire planter la Programmation. Chaque lignes dans ce fichier Prog.dat représente une ligne de programmation dans le WES.

Il faut enregistrer le fichier, puis redémarrer le WES. Si vous avez trouvez la ou les ligne(s) qui Bloque en la supprimant, Votre problème est réglé.

Ensuite à vous de voir pourquoi ces lignes programmées font planter la gestion Programme. Ex: envoie de Requête mal formatée ou pas de réponse du distant ou un capteur supposé être testé dans la programmation à été enlevé sans avis de la programmation.

Cdt