maximushugus

On croise les doigts que tout se passe bien

Les kernel sont des programmes plus petits pour faire fonctionner le routeur, mais sur des partitions différentes que le firmware (de ce que j'ai compris, je ne suis pas un expert). Normalement, le kernel0 n'est pas modifié lors de l'installation de la méthode via le tuto, puisque'on rentre uniquement la commande : mtd write openwrt-ramips-mt7621-mir3g-squashfs-kernel1.bin kernel1

Je ne crois pas qu'il y ait besoin du kernel0 pour retourner au firmware stock. On a juste besoin de ce firmware sur une clé formatée en FAT32, et de le renommer en miwifi.bin

Est ce que tu n'aurais pas fixé manuellement ton adresse IP sur ta carte réseau Ethernet ? Ca expliquerait que tu ne puisse pas accéder au routeur après avoir changé son IP et que tu ne puisse accéder à ta box depuis son changement d'IP à elle aussi.

Je n'ai pas bien compris ta question. Tu as réussi à mettre OpenWrt, mais tu veux revenir au firmware stock : c'est en suivant le lien que tu as cité. Sur cette même page il y a un lien pour télécharger le firmware stock si c'est ce que tu cherches.

Concernant ton PC qui n'arrive plus à se connecter à ta box après le changement d'IP, ça ressemble à un problème de table ARP : essaye tout simplement de redémarrer ton PC. D'ailleurs il est sous quel OS ?

Excellente idée, je n'y avais pas pensé. C'est effectivement possible sur les box SFR (via un menu caché je crois mais le lien est trouvable sur Google de ce que je me rappelle). La seul chose, si je me souvient bien, c'est que si un partage d'imprimante est configuré sur les box SFR et qu'on change leur IP, ce partage peut moins bien/pas fonctionner. Oui une fois l'interface graphique installée, dans les paramètre réseau puis LAN, on peut changer l'adresse IP

Oui les box SFR sont sur 192.168.1.1

Sinon juste par curiosité @Lenoil, pourquoi est ce que tu voulais installer OpenWRT ?

Quand je disais de débrancher internet, c'est juste de débrancher le cable ethernet entre la box et le port wan du routeur. Sinon oui effectivement, le changement d'IP peut se faire après. Mais si ça se trouve tu n'as pas besoin de changer l'IP de ton routeur : tu as quelle box (quel opérateur) ? Elle est sur quelle adresse IP ? Le tout c'est qu'elle ne soit pas sur 192.168.1.1 (car c'est l'adresse qu'à de base les routeurs OpenWRT, c'est pour ça que dans le tuto je dis de changer l'IP)

Donc la le routeur est réinitialisé c'est ça ? Essaye de le débrancher de la box pour éliminer un éventuel conflit. Puis de le redémarrer en débranchant rebranchant l'alimentation. Le ssd en 192.168.1.1 devrait être disponible. Puis changer son IP comme sur le tuto. Puis se reconnecter avec Putty sur l'IP qu'on vient de lui donner. Si ça ne fonctionne toujours pas, le redémarrer en le débranchant rebranchant. Et essayer de se reconnecter via l'IP qu'on lui a spécifié. Si tout fonctionne et qu'il a bien sa nouvelle IP, on peut le rebrancher à la box.

Il faut que tu sois en mode fail safe. C'est un peu technique. Ce serait peut être plus simple d'essayer de reprendre le tuto de la première page pour installer OpenWrt ?

Lorsque tu essayes de le réinitialiser normalement, le routeur est allumé. Il faut appuyer (avec un trombone ou autre) sur le bouton reset pendant environ 10 secondes. La LED en façade se met à clignoter rapidement pendant quelque temps (environ 1 minute de ce que je me rappelle) mais il ne faut pas débrancher le routeur, sinon le reset ne se fait pas totalement. Le routeur devrait redémarrer tout seul sans rien faire, et la LED être de nouveau bleue fixe. Si ce n'est pas le cas, il y a un problème.

Essaye de le réinitialiser avec le bouton reset derrière. En principe si le voyant devant le routeur ne clignote pas jaune, tu ne devrait pas avoir brické ton routeur et il n'y a aucune raison que tu ne puisse pas accéder via ssh au 192.168.1.1 Si tu veux tout de même retourner sur la rom stock et que tu avais suivi le tuto en première page pour installer OpenWRT, il faut effectivement te connecter en ssh (ou bien souder un connecteur sur la carte mère pour pouvoir se connecter via le port série)

Leur site est un peu capricieux, il faut tenter de recharger plusieurs fois la page, et il faut vérifier, comme expliqué dans le tuto, qu'une fois connecté sur le site, que l'adresse est bien en https et rajouter le "s" le cas échéant. Je viens de réussir à me connecter à l'instant.

Lorsque tu changes l'IP de ton routeur puis que tu tentes de te reconnecter dessus, tu spécifies bien la nouvelle adresse IP de ton routeur dans Putty ? Lorsque tu le réinitialise et donc que le routeur reprends son IP en 192.168.1.1, tu arrives à te reconnecter ? Sinon pour retourner sur la rom stock, il faut suivre le tuto sur cette page dans l'onglet "recovery to stock"

De quel lien parles-tu ? En principe si tu as suivi le tuto, la partition ou il y a kernel0 n'est pas effacée. Lors de ton brick elle a été supprimée ? Voici un lien pour le kernel0.bin que j'ai trouvé sur le forum de LEDE du Mi R3G : kernel0.bin mais j'ai aucune idée s'il fonctionne.

Alors moi personnellement, j'ai configuré mon E3372h en Stick sur un routeur OpenWrt, en le configurant en NCM. Si tu veux rester en firmware HiLink, je te conseille plutôt le firmware d'origine HiLink (22.180.05.00.00) Si tu essaye de configurer ta clé 4G en firmware HiLink sur ton routeur OpenWrt, est ce que tu utilise bien le protocole RNDIS : cf cette partie du tuto : https://lecrabeinfo.net/installer-firmware-openwrt-sur-routeur-wi-fi.html#protocole-rndis Si cela ne fonctionne pas, je pense qu'il faudra que tu essaye de passer en firmware Stick, puis configurer le multimode pour OpenWrt, puis l'installer sur ton routeur via le protocole NCM

Déja tu peux mettre l'interface en français avec les commandes suivantes en SSH : opkg install luci-i18n-base-fr opkg install luci-i18n-firewall-fr Pour ta clé 4G E3372, tu as installé un firmware HiLink ou Stick ?

J'ai l'impression que tu n'as pas installé Luci, qui est justement cette interface graphique web (il y a des routeurs sur lesquels le firmware OpenWrt n'a pas ce programme installé automatiquement). Pour cela tu dois te connecter au routeur en SSH (avec le logiciel Putty par exemple) : sur l'interface sur rentre l'IP du routeur, tu vérifie que tu a bien coché SSH et tu te connectes. Tu vas atterrir sur une interface en ligne de commande. Il va te demander ton login qui sera surement "root", puis s'il te demande ton mot de passe essaie avec "root". Entre les commandes suivantes : opkg update opkg install luci-ssl Dis moi si tu vois des erreurs. Normalement après ça, si tu vas dans ton navigateur sur l'adresse IP du routeur, tu devrais avoir l'interface graphique. L'autre problème qu'il peut se poser c'est que ton routeur pourrait avoir la même IP que ta box opérateur et donc créer un conflit IP. Il faudrait que tu vérifies ça.

J’ai oublié d’expliquer dans la partie J) (si un modo peut mettre ce message à la fin du 2ème message, juste après la dernière commande ce serait cool ), que sur les PC Windows, le pare-feu de base bloque les entrées de connexion provenant du VPN : ainsi si vous configurez votre serveur VPN de façon à ce qu’il donne comme serveur DNS l’adresse IP de votre routeur, vous n’arriverez pas à avoir la réponse du serveur DNS, et n’arriverez donc pas à aller sur internet. De même le pare-feu bloque le ping entrant depuis le VPN : les PC de votre réseau local ne peuvent pas faire de ping sur les PC connectés à distance sur le VPN. Nous allons remédier à cela en créant une règle d’autorisation dans le pare-feu Windows. Si vous utilisez un autre pare-feu, la méthode sera un peu différente. Pour ajouter cette exception, appuyer sur les touches Windows + R. Une fenêtre apparaît alors. Dans le champ, entrez la commande suivante : « wf.msc » puis appuyez sur Ok. La page de configuration du pare-feu Windows s’ouvre alors : Cliquez dans la colonne de gauche sur « règle de trafic entrant » puis sur la page qui apparaît, dans la colonne de droite sur « nouvelle règle. Une page apparaît alors : Sélectionnez « personnalisée » puis faites suivant. Sur la page suivante, laissez « tous les programmes » et faites suivant. Sur la page suivante, dans la liste « type de protocole », vous devez sélectionner « ICMPv4 » et cliquer sur le bouton « perso… » en bas. Dans la fenêtre qui apparaît, il faut cocher « Certains types ICMP » puis « requête d’écho » et faire Ok. Cliquez 4 fois de suite sur suivant, puis dans la dernière page, donnez un nom à votre règle : par exemple « autoriser OpenVPN » et cliquez sur « Terminer ». Votre pare-feu est maintenant correctement configuré pour accepter les requêtes DNS entrantes.

Je propose une petite suite du tuto. Les deux parties que je propose dans cette suite sont indépendantes. Ces parties ne sont absolument pas nécessaire pour que votre serveur OpenVPN sur votre routeur fonctionne : pour cela le premier message de ce sujet est suffisant, mais les deux parties de ce message sont des améliorations possibles. I) Configurer le serveur VPN en TCP sur le port 443 Lorsque nous avons configuré le serveur OpenVPN dans le premier message de ce sujet, nous l’avons configuré pour qu’il écoute sur le port 1194, avec le protocole UDP. Cette configuration, en plus de sa simplicité, permet d’utiliser le port 1194 qui est, de base, réservé au protocole OpenVPN : on n’utilise pas un port qui sert ou pourrait servir à autre chose. De plus le protocole UDP est (censé être) plus rapide que le protocole TCP : il n’y a pas de vérification et donc les échanges de paquets sont plus rapides. Mais cette configuration a un inconvénient : si vous cherchez à utiliser votre VPN depuis certaines connexions d’entreprises, d’écoles, voire même certains pays qui brident/censure internet, vous pourriez ne pas pouvoir vous connecter à votre serveur VPN. Vous perdez dans ce cas tout l’intérêt de votre serveur VPN. En effet, il est possible sur ces réseaux, de bloquer via le pare-feu du routeur de ces connexions, le port 1194 voire même le protocole UDP complet. Il existe une parade à ce blocage : utiliser le port 443 et le protocole TCP. Pourquoi cette association-là ? Et bien par ce qu’il s’git tout simplement du port et du protocole utilisé pour accéder à une page internet en HTTPS. Ainsi il est très rare que le port 443 avec le protocole TCP soit bloqué, sous peine de bloquer une très grande partie des sites web : cette situation n’arrive pour ainsi dire jamais. Ainsi en configurant votre serveur VPN sur le port 443 en TCP, vous faites passer votre connexion VPN cryptée parmi toutes les autres connexions cryptées sur le port 443 (qui, elles sont des connexions à des sites web) : vous vous fondez dans la masse des données cryptées. Pour pouvoir permettre cette configuration il va valoir modifier plusieurs paramètres : 1) Modifier le NAT de votre box internet : Dans la partie G) du premier message de ce sujet, vous avez configuré le NAT pour rediriger ce qui arrive en entrée sur le port 1194 en UDP vers l’adresse IP de destination qui est celle de votre routeur OpenWrt sur le port 1194 en UDP. Vous allez devoir modifier ce NAT pour qu’il fonctionne de cette façon : Rediriger le port 443 en TCP vers l’adresse IP de votre routeur sur le port 1194 en TCP. De cette façon, sur votre routeur OpenWrt, vous n’aurez pas à modifier le port sur serveur OpenVPN (car le problème du port 443 sur votre routeur OpenWrt c’est qu’il est déjà utilisé par Luci, l’interface graphique web d’administration du routeur). Je profite que vous soyez dans la configuration du NAT de votre box pour vous dire qu’il pourrait être judicieux de configurer « en protection » une redirection également du port 80 en TCP et UDP vers votre routeur OpenWrt sur un port que vous n’avez pas ouvert sur l’interface WAN (si vous n’avez pas modifié le pare-feu de base d’OpenWrt, vous pouvez configurer la redirection du port 80 en TCP et UDP vers le port 80 sur l’IP du routeur OpenWrt, puisque son pare-feu bloque l’entrée sur l’interface WAN sauf pour les ports que vous n’avez pas spécifiquement ouvert). Ainsi si le DDNS que vous avez configuré sur votre box internet permet l’accès à distance de son interface de configuration, il ne sera plus possible d’accéder à cette interface via l’adresse obtenue via le DDNS. 2) Configurer le pare-feu sur le routeur OpenWrt Connectez-vous en SSH à votre routeur OpenWrt, entrez votre identifiant et votre mot de passe. Il faut trouver le numéro de de là règle que vous avez créée pour autoriser OpenVPN dans le premier message de ce sujet, dans la partie D). Pour cela entrez la commande suivante : uci show firewall La liste de toutes les règles du pare-feu apparaît. Vous devez trouver la liste qui sera sous cette forme : Notez le nombre en question et entrez la commande suivant en remplaçant NOMBRE par le celui-ci : uci set firewall.@rule[NOMBRE].proto=’tcp udp’ uci commit /etc/init.d/network reload /etc/init.d/firewall reload Le pare-feu de votre routeur OpenWrt est maintenant configuré pour autoriser la connexion TCP (et UDP si vous souhaitez retourner sur la configuration du premier message) sur le port 1194. 3) Configurer le serveur OpenVPN Pour reconfigurer votre serveur OpenVPN, il faut rentrer les commandes suivantes lors d’une session SSH sur votre routeur, en remplaçant « NOMDEVOTRESERVEURVPN » par le nom que vous avez donné à votre serveur dans la partie F) : uci set openvpn.NOMDEVOTRESERVEURVPN.proto=’tcp-server’ uci commit /etc/init.d/openvpn start /etc/init.d/openvpn enable Votre serveur OpenVPN est maintenant configuré pour utiliser le protocole TCP sur le port 1194 (qui est lui-même redirigé via le port 443). 4) Changer le fichier de configuration des clients Vous devez modifier le fichier « client.ovpn » que vous avez créé dans la partie H) du premier message, de façon à spécifier aux clients de se connecter sur votre serveur via le bon port avec le bon protocole. Pour cela, dans ce fichier, remplacez les lignes : par Vous devrez reconfigurer vos clients avec ce nouveau fichier (sur les smartphone avec l’application OpenVPN, vous devez supprimer la configuration que vous avez crée puis importer le nouveau fichier « client.ovpn ») Normalement tout devrait fonctionner, mais cette fois-ci sur le port 443 en TCP. Votre connexion VPN devient ainsi très difficile à bloquer. J) Configurer le serveur DNS de votre connexion VPN Dans la partie F) du premier message, nous avons configuré le serveur OpenVPN de façon à ce qu’il donne au client d’adresse des serveurs DNS qu’il doit utiliser. Comme vous l’avez vu, nous avons spécifier ceux d’OpenDNS. Mais vous pouvez si vous le souhaitez, sélectionner celui de votre routeur OpenWrt, qui redirigera à son tour les requêtes DNS vers les serveurs DNS que vous aurez configurés. Les avantages de cette configuration sont : Être sur que les requêtes DNS passent bien via le tunnel du VPN (normalement c’est déjà le cas, mais là on en est encore plus sur puisqu’on spécifie une adresse IP interne, accessible uniquement via le VPN) Pouvoir gérer avec un seul paramètre les serveurs DNS des appareils sur votre réseau local connectés à votre routeur OpenWrt et ceux connectés sur votre serveur OpenVPN. Ainsi si vous décidez de changer de serveur DNS, ou si vous souhaitez utiliser un serveur DNS crypté, ou créer votre propre serveur DNS sur votre routeur, les paramètres seront directement appliqués à votre réseau local, mais aussi à votre réseau VPN. Pour mettre en place ce système, connectez vous en SSH à votre routeur OpenWrt, et entrez la commande suivante en remplaçant « NOMDEVOTRESERVEURVPN » par le nom que vous avez donné à votre serveur dans la partie F) et « ADRESSEIPDUROUTEUR » par l’adresse IP de votre routeur OpenWrt : uci set openvpn.NOMDEVOTRESERVEURVPN.push='persist-key' 'persist-tun' 'user nobody' 'topology subnet' 'route-gateway dhcp' 'redirect-gateway def1' 'dhcp-option DNS ADRESSEIPDUROUTEUR' 'block-outside-dns' uci commit /etc/init.d/openvpn start /etc/init.d/openvpn enable Vous pouvez vérifier, lorsque vous êtes connecté à votre VPN, en allant sur https://www.dnsleaktest.com/ et en cliquant sur « standard test », que les serveur DNS utilisés sont bien ceux spécifiés pour votre routeur OpenWrt (sur l’interface Luci, dans l’onglet « réseau » puis « interfaces » puis « WAN », sous onglet « Paramètres avancés », champs « utiliser des serveurs DNS spécifiques »). Si vous avez des questions, n’hésitez pas ?

Essaye de débrancher et rebrancher le routeur pour le faire redémarrer, puis tente de nouveau d'y accéder via SSH. Si cela ne fonctionne pas, tente de faire de nouveau un reset. Lorsque tu as fais ton premier reset, tu n'as pas remarqué d'anomalie lorsque les LED en façade flashaient ?

Salut ! Projet intéressant ! Donc si on résume voici la configuration matérielle que tu as : caméra(s) -----wifi------> routeur 4G. Est ce que tu as réussi à configurer le DDNS sur ton routeur ? S'il est bien configuré, en désactivant le NAT que tu as déja paramétré dans ton routeur, tu devrait pouvoir, via l'adresse obtenue par DDNS, accéder via internet à la page d'administration de ton routeur. Est ce que ton NAT est bien configuré ? Tu as bien sélectionné les bons ports pour la redirection (car de ce que j'ai compris tu as utilisé l'UPNP, mais du coup est ce que tu as pu trouver quels ports étaient utilisés par ta (tes) caméra(s) ? Et est ce que la redirection NAT est faite vers la bonne adresse IP interne de ta caméra ? Est ce que sur ton routeur tu as un pare-feu ? Si oui, est ce que tu as autorisé l'entrée des ports utilisés par ta caméra depuis le WAN (ou WWAN comme tu passes par de la 4G, tout dépend de la configuration de ton routeur) vers LAN ? Est ce que tout simplement ton routeur 4G fonctionne ? Si tu te connectes en Wi-Fi sur ce dernier, est ce que tu arrives accéder à internet ?

Alors t'as réussi à résoudre ton problème ? Je serais curieux d'avoir un retour de l'efficacité de ton antenne 4G