Voici un premier post car jusque la je m’en sortais pas trop mal tout seul mais je coince. J’utilise Jeedom v4.0.61 sur un RPI3 avec tout un tas d’équipement divers et varié. Courant décembre, suite à une mise à jour de ma Box Red SFR, je suis passé en IPv6, j’avais donc des notifications mais plus aucun accès extérieur, j’ai essayé différente manip mais en vain. J’ai alors demandé à repasser en IPv4, ce qui a pris du temps mais a été fait. Malheureusement pour moi L’ip avait changé. Je reparamètre ma box (ouverture de port …) j’ai accès à jeedom avec l’ip depuis l’extérieur, l’application mobile me permet d’accéder aux cameras… Presque tout marche… Presque…
Je me suis d’abord aperçu que sur l’app mobile je n’ai plus de notification, mais j’ai accès à tout en wifi comme en 4g. Puis je me suis aperçu que je ne pouvais plus faire de mise à jour :
Erreur curl sur : https://market.jeedom.com/core/api/api.php. Détail :Could not resolve host: market.jeedom.com
Mon ip etait bien configurer, … j’ai chercher, je me suis connecter au market par internet puis dans mes Box j’ai retrouver mon jeedom mais avec une ancienne IP j’ai essayer de l’actualiser… mais je n’ai pas trouver comment faire, j’ai donc essayer de supprimer cette box ce qui a marcher et de me reconnecter via jeedom au market pour que celle-ci réapparaisse mais rien toujours le même message d’erreur…
J’ai également des bugs sur les plugins Meross et Bosch Indego, mais je pense que tout est lié.
Merci d’avance aux experts… et Meilleurs vœux à tous
J’utilise assez intensivement IPv6 et n’ai pas de problème particulier sur Jeedom. Je ne sais pas si SFR te l’a vraiment désactivé, ça semble plus probable qu’ils aient bricolé quelque chose pour le bloquer…
As-tu vérifié si tu résous bien les DNS en ssh sur le PI ? Essaye la commande ping www.google.fr puis ping market.jeedom.com et regarde ce que tu obtiens comme réponse.
Il n’est pas impossible que tu aies encore une IPv6 et des DNS IPv6 sur ton PI. Essaye la commande ip addr et regarde s’il t’en reste une ou plusieurs, si c’est le cas, un reboot du pi devrait nettoyer tout ça, sinon c’est qu’ils ont bricolés… En règle générale, vérifie tes DNS (par défaut l’IP de ta box doit relayer, sinon essaye celui de Cloudflare 1.1.1.1 ou Google 8.8.8.8).
Tu peux aussi désactiver complètement IPv6 sur le Pi, si tu es sur que tu ne veux vraiment plus jamais l’utiliser (tuto ici : Désactiver IPV6 sur son raspberry - tutox.fr).
Mais j’aurais plutôt tendance à t’inciter à trouver comment le faire marcher avec IPv6 actif : entre autre avantage, plus besoin de NATer des ports pour y accéder depuis l’extérieur (j’utilise ça fréquemment en 4G, où des IPv6 sont distribuées nativement).
Meilleurs voeux à tous les deux.
Bad peux tu expliquer quelle méthode tu as suivi pour accéder à Jeedom en IPv6.
J’accède à mon Jeedom en IPv6 ou IPv4 suivant ce qui est disponible du côté client.
J’ai publié un RTEX sur ce sujet. (Lien ici: (RTEX) Accéder à son Jeedom en IPv6 )
Bonjour,
J’ai installé un Raspberry Pi chez ma soeur qui est chez SFR.
La box est passée récemment en IPV6 et les règles NAT (redirection ports 80 et 22) ont donc sauté.
Comment faire pour accéder de nouveau à jeedom depuis l’extérieur ?
Est-ce qu’en utilisant les DNS Jeedom ça marcherait (si pas possible autrement) ?
Sympa ton tuto ! Je fais globalement la même chose que toi :
IPv6 statique sur jeedom dans le range attribué par l’opérateur
enregistrement AAAA sur la même entrée de mon DNS que le A (je n’utilise pas de DNS dynamique pour ça, mais ça doit marcher aussi)
Par contre, je porte les IPv4 publiques et le réseau interco IPv6 avec les opérateurs sur un firewall, donc pas de filtrage opérateur coté WAN et pas de souci port. Je publie depuis mon FW le sous-réseau pouvant être utilisé par les machines en interne et tout le monde chope une IPv6.
Ensuite, je limite les IPv* pouvant se connecter chez moi à celles déclarées en France et d’hosts connus (bye bye la Chine et la Russie), soupoudré d’un peu d’antiDDoS. Une règle de NAT 4-4 en entrée et une route IPv6 plus tard, le tour est joué
Merci pour ton explication. Effectivement, nous suivons plus ou moins la même méthode.
Je confirme DDNS pour IPv6 fonctionne très bien. Il faut juste que le client DDNS s’exécute sur Jeedom.
Bonsoir , je regarderai cela un soir cette semaine… Merci pour vos réponses. Pour henribi j’avais encore un ipv4 mais il m’était impossible de NATer les ports donc j’avais des notifications sur mon téléphone sans pouvoir avoir accès aux caméras, contacteurs d’ouverture… j’ai essayé de passer par l’IPv6 mais je n’ai rien réussi à faire… Mais comme je l’ai dit je ne suis pas informaticien.
pi@raspberrypi:~ $ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=15.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=13.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=12.9 ms
Bon, c’est bien un problème de résolution de nom sur ton PI :
Tu as bien une IPv4 privée :
inet 192.168.1.100/22 brd 192.168.3.255 scope global eth0
Uniquement une IPv6 de lien local, donc ça c’est good :
inet6 fe80::5094:114f:55ea:ce32/64 scope link
Et le routage IPv4 fonctionne :
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=15.3 ms
Le masque en /22 sur ton IPv4 est normal ? Tu as configuré ça sur ta box ou ton routeur ?
C’est assez inhabituel (mais pas forcement problématique)…
Tu peux me donner le contenu du resolv.conf, dnchpcd.conf et wpa_supplicant.conf stp ?
(enlève les mot de passe, ou autre trucs trop perso si tu en vois)
pi@raspberrypi:~ $ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 2a02:842a:7b:c501::1
pi@raspberrypi:~ $ cat /etc/dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private
# Example static IP configuration:
interface eth0
static ip_address=192.168.1.100/22
#static ip6_address=fd51:42f8:caae:d92e::ff/64
static routers=192.168.1.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1
# fallback to static profile on eth0
#interface eth0
#fallback static_eth0
pi@raspberrypi:~ $ cat /etc/wpa_supplicant/wpa_supplicant.conf
cat: /etc/wpa_supplicant/wpa_supplicant.conf: Permission denied
Bon, la bonne nouvelle c’est que je pense avoir identifié ton pb :
pi@raspberrypi:~ $ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 2a02:842a:7b:c501::1
Tu récupères un nameserver, « serveur de nom » aussi appelé DNS, par IPv6 (via slaac pour les puristes qui voudraient me corriger), alors que tu n’as pas de connectivité IPV6, et tu n’as pas de DNS IPv4, donc ça marche pas, en termes technique « prout ».
Il y a deux lignes commentées dans le dhcpcd.conf, c’est la source de ton pb :
Il faut donc juste que tu rajoutes une lignestatic domain_name_servers=192.168.1.1 et tu devrais réussi à ping www.google.fr puis ping market.jeedom.com.
Par contre, QUI a fait cette configuration ?
Vu les IPv6 en place ça ne peut pas marcher.
C’est aussi là qu’on retrouve le fameux /22 qui m’interpelle…
Faut pas bricoler avec ces trucs sinon c’est les pb assurés.
Parfait ca marche !!! Un gros merci !! j’ai compris de très loin ce que j’ai fait… lol
sudo su
nano /etc/dhcpcd.conf
J’ai rajouter la ligne un Ctrl+O et un Ctrl+X puis reboot…
Merci encore
Pour la question du Qui a fait ça … moi je pense mais je n’ai pas touché à tout ça donc je n’en suis pas sur…
