hsd92

Hello à tous, Effectivement, le tuto et les scripts vont arriver incessamment. Manque juste un peu de temps pour les valider. En effet, il faut tout remettre d'origine, relancer les scripts pour s'assurer que ça va fonctionner pour tout le monde et ça prend du temps. Je pense que personne ne souhaite faire les frais d'une erreur sur son MMI:-) La rédaction de la proc est sur la fin, hein Frankiegom? En revanche, pour Aballister, je ne sais pas quel est ton problème, mais pas certain que cette solution le règle.

Bonjour à tous, Bon maintenant, que tout fonctionne sans passer par l'AMI, juste en Wifi, je vais commencer à publier. Pour commencer, ce soir c'est l'activation du trafic online par script. https://dl.orangedox.com/HYdriTQep6iGBBU1V0/MMI-3GP-trafic-online.zip

Hello à tous, Enfin, les scripts Ontika ont révélés leurs secrets. Plusieurs points importants: - l'adresse MAC ne sert à rien. C'est juste pour éviter de réutiliser leur script sur un autre MMI. - ils ont contourné le problème du demon qui reconfigure en boucle de façon intelligente (mmemauncher) - plus besoin de câble pour activer le trafic on line. Ils ont utilisé le même principe que le script d'activation du Green Menu. Dans tous les cas, ça va servir y compris pour la procédure standard via AMI. Ce sera à disposition dans quelques jours.

pas de ratio en équipe. @arima hsd92, c'est pourtant simple. HS, mon état. D, initiale de mon nom et 92 ,je te laisse deviner. C'est super original! Envoyé de mon iPhone en utilisant Tapatalk

Qu'est-ce qu'est la protubérance à l'arrière ? une antenne GPS? 4G? Envoyé de mon iPhone en utilisant Tapatalk

Sur la R8 Gordini, le système de navigation est certes un peu rudimentaire mais fiable et surtout imbriquable. Il suffit de suivre les lignes du capo, elles indiquent toujours la bonne direction. :-) Ci-joint un lien pour une mise à jour de la dernière cartographie. http://www.ebay.fr/itm/like/150904821991?lpid=97&chn=ps

en fait, les 2 en même temps, la route reste celle de l'en5. J'ai beau la modifier, elle revient. Il y a donc un demon qui reconfigure en permanence. 192.168.1.1 = MMI uap0 192.168.1.23 = mon pc 172.16.1.100= MMI en5 172.16.1.254= routeur sur en5 (ethernet) 192.168.1.254 = routeur sur uap0 (wifi) 172.16.250.248 = sais pas encore 10.0.0.100 = MMI mam0 Exemple des cnx uniquement avec l'AMI: self tcp 127.0.0.1:65501 -> 127.0.0.1:4444 ESTABLISHED:ESTABLISHED self tcp 192.168.1.1:23 <- 192.168.1.23:53877 ESTABLISHED:ESTABLISHED self tcp 172.16.1.100:65491 -> 173.194.40.96:80 CLOSING:ESTABLISHED self tcp 172.16.1.100:65467 -> 173.194.40.135:80 CLOSING:ESTABLISHED self tcp 172.16.1.100:65460 -> 216.58.208.238:80 ESTABLISHED:ESTABLISHED self udp 172.16.1.100:65024 -> 8.8.8.8:53 SINGLE:NO_TRAFFIC self udp 255.255.255.255:67 <- 172.16.250.248:68 NO_TRAFFIC:SINGLE self udp 172.16.1.100:65025 -> 172.16.1.254:53 SINGLE:NO_TRAFFIC self udp 172.16.250.248:65031 -> 172.16.1.254:53 SINGLE:NO_TRAFFIC self udp 239.255.255.250:1900 <- 172.16.1.254:50403 NO_TRAFFIC:SINGLE self udp 255.255.255.255:68 <- 172.16.1.254:67 NO_TRAFFIC:SINGLE self udp 172.16.250.248:68 -> 255.255.255.255:67 SINGLE:NO_TRAFFIC Avec les 2 routeurs juste avant que la route par défaut soit reconfiguré via l'en5 self tcp 192.168.1.1:65403 -> 192.168.1.23:2869 FIN_WAIT_2:FIN_WAIT_2 self tcp 192.168.1.1:23 <- 192.168.1.23:53877 ESTABLISHED:ESTABLISHED self tcp 192.168.1.1:65414 -> 173.194.45.41:80 CLOSING:ESTABLISHED self tcp 192.168.1.1:65416 -> 173.194.40.110:80 CLOSING:ESTABLISHED self udp 172.16.1.100:64699 -> 8.8.8.8:53 MULTIPLE:SINGLE self udp 172.16.1.100:64703 -> 172.16.1.254:53 SINGLE:NO_TRAFFIC On observe un mixte des flux via les 2 routeurs. les flux DNS continuent à passer par l'en5.

Via l'en5 je vois les flux dns depuis l'ip de l'en5. Ce qui me laisse penser que notre pb n'est plus au niveau du pf. J'ai le sentiment que suivant le mode fair ou non, google earth doit etre configuré sur une interface ou l'autre (en5 ou ppp0) Il va donc falloir éplucher tout ça. Ps: personne pour me ré aiguiller sur le post qui parle du chiffrement du copie_run.sh? Envoyé de mon iPhone en utilisant Tapatalk

tu veux dire à 10s de plus ? J'ai mis 120s pour les tests et ça marche à tous les coups. Bon définitivement le Mmi est tordu. J'ai joué avec un fichier de conf du pf, je vois les connexions sans que les flux passent??? Il doit y avoir un truc qui fixe une partie de la conf sur l'interface de l'ami. Il y a forcément un truc à trouver. J'ai été sur un forum russe et écrit à des contributeurs qui travaillaient sur le sujet. Sans réponse pour l'instant. Ca m'agace de ne pas trouver... Il y a plusieurs semaines, j'ai lu un post qui expliquait comment était chiffré le copie_run.sh. Je suis curieux de le retrouver, il me semble que c'est sur ce forum. Cela permettrait de tenter de déchiffrer les script d'Ontika. Je pense que si le script s'exécute sur un système Unix, on doit pouvoir le lire... Envoyé de mon iPhone en utilisant Tapatalk

essaye de rallonger le sleep. C'est peut-être trop juste. Envoyé de mon iPhone en utilisant Tapatalk

Hello on voit la même chose car les scripts chargent des variables et notre super pfctl édite les noms des variables plutôt que leur valeur. Je vais réessayer ce we. Je pense ajouter dans le pf.conf: pass in quick on uap0 all keep state commenter les block (c'est déjà fait pour moi) et rdr on uap0 proto udp from any to any port 53 -> 8.8.8.8 ou (pas les 2 en même temps) rdr pass on uap0 proto udp from any to any port 53 -> 8.8.8.8 Je trouve sur le web les 2 formes et même chose pour toutes les interfaces (mam0...) Ca permettra de regarder le comportement depuis un autre client wifi. À priori, le serveur dhcp devrait nous envoyer 192.168.2.100 et 101 comme DNS. Dans leurs scripts ils font du PAT pour les flux dns mais seulement en udp??? (bon c'est juste pour la remarque) la commande pour recharger après modif (à vérifier) pfctl -f /mnt/efs-system/pss/nws/usr/bin/pf-conf Je mettrai bien cette commande dans notre rc.local Il n'y a pas de risque à toucher au pf car si tu te bloques, tu lances un pfctl -d via la sd. Par ailleurs, j'ai remarqué que la version huntman du routeur avait parfois du mal à se reconnecter à l'AP du MMI. Les versions (non stable) ultérieure fonctionnent mieux mais pour moi ont un problème avec mon modem. Envoyé de mon iPhone en utilisant Tapatalk

Les flux n'arrivent pas jusqu'au routeur. Difficile de naviguer en aveugle, car le MMI embarque peu d'outil (même pas un traceroute ni un nslookup) Bon je pense que ce n'est pas bien méchant. Il y a bien une interface sur le MMI en 10.0.0.100 (mam0) qui est un serveur local. C'est celle-ci qui doit faire les requêtes DNS uniquement pour Google earth. Avec les commandes : # Show Firewall Rules: pfctl -sr # Show NAT rules pfctl -sn # Show all pfctl -sa On devrait voir quelles sont les règles lorsque ça fonctionne et les ajouter dans le fameux rc.local avec la bonne translation. Ca devrait faire l'affaire. En revanche, pour moi pas tout de suite. je vais manquer de temps dans les prochains jours.

on fait du nat dans le sens que l'on veut. Dans notre cas, il est possible que l'application Google earth ait un fonctionnement particulier. Imaginons que l'application utilise un serveur Web local et nécessite un serveur DNS dans le même sous réseau. c'est moche mais tout est possible. je trouve dans des scripts des règles qui nat du 192.168.2.100 vers un dns allemand ou celui configuré. Je ne suis pas un spécialiste des systèmes embarqués, mais je n'ai jamais vu un bricolage pareil. il faudrait identifier tous les exécutés lors de la connexion Ethernet. Envoyé de mon iPhone en utilisant Tapatalk

c'est le cache sans doute. Sans le firewall, les règles de nat ne peuvent plus fonctionner. A priori, Google Earth nécessite ces règles et ce qui est amusant, c'est que Street View fonctionne parfaitement. Tout ce que je vois dans les scripts, le nat ne vaut que pour les flux DNS. va falloir plancher un peu plus! Envoyé de mon iPhone en utilisant Tapatalk

bad new! Google earth ne fonctionne pas.... Audi connect et street view oui mais pas earth. Il y a du nat la dessous....Le cache fait que je n'ai pas vu... J'épluche leurs scripts pour regarder les règles de nat à mettre dans le packet filter. Envoyé de mon iPhone en utilisant Tapatalk

Pourquoi se prendre la tête avec le routeur et une ip dynamique ? La fixer va très bien. En revanche, je n’ai pas encore trouvé/cherché la conf du DHCP. Idéalement, je désactiverai bien le serveur DHCP du MMI pour utiliser celui du TP-Link. De ce que j’ai pu voir dans différents scripts il suffirait de supprimer le fichier « usedhcp » quelque part (c’est un fichier vide). A tester. Pour le firewall la commande –d le désactive complètement. Est-ce grave pour la sécurité? Non, puisque c’est le TP Link qui assure la connexion internet et interdit tout flux entrant et que j'espère être en confiance avec tous ceux qui se connecteront à ce réseau :-) . Me concernant, je l’ai laissé avec quelques règles complémentaires.

l'histoire du DHCP, c'est uniquement pour les autres clients. Du côté du MMI c'est terminé. Envoyé de mon iPhone en utilisant Tapatalk

re ayé Je me résigne à ne pas comprendre certaines choses. J'ai fait un script /mnt/efs-system/scripts/rc.local #!/bin/ksh sleep 60 setconf _CS_RESOLVE "nameserver_8.8.8.8" route add default 192.168.1.254 et dans le script /mnt/efs-system/usr/bin/startDumper.sh (c'est le seul dont je sais qu'il s'exécute dès le démarrage) j'ai ajouté à la fin /mnt/efs-system/scripts/rc.local & et voila...reste plus que le serveur DHCP à modifier pour qu'il distribue les bons paramètres.

Le firewall du MMI c'est bien le PacketFilter. En fait, le système utilise bien les path classiques pour fonctionner comme /etc et par exemple en créant /mnt/efs-system/etc/rc.d/rc.local, je le vois bien en /etc/rc.d/rc.local. Même en m'assurant qu'il soit exécutable, mais rien. Je viens d'essayer le sysinit et pareil. Le problème du MMI c'est que c'est un enchevêtrement de scripts. Il faudrait que je trouve l'un des derniers à s’exécuter pour y insérer mes petites commandes. Je prendrai le temps de documenter tout ça...pour l'instant, tu peux insérer dans un run.sh sur SDCARD la commande pfctl -d. ça te permet la connexion. Pour la route c'est route add default 192.168.1.254.

Hello, Ayé....ça marche. Une fois mes déboires réglés avec mes routeurs, c'est opérationnel. En résumé, le MR3020 est connecté en tant que client sur l'AP du MMI. Equipé d'un modem 3/4G, le MR3020 assure la connexion et le routage vers internet. Je lui ai fixé son IP en 192.168.1.254. C'est tout pour le routeur. Sur le MMI, j'ajoute la route par défaut 192.168.1.254. J'ai modifié le firewall pour laisser passer tout ces flux. Sur les autres clients wifi du MMI, pour l'instant en statique fonctionnent aussi (ontika dit que ça ne fonctionne pas mais c'est une règle du FW qui bloquait). Il reste que pour l'instant je n'arrive pas à fixer la route par défaut. Je ne trouve pas de script qui s'exécuterait à chaque démarrage. J'ai même créé le très conventionnel rc.d/rc.local mais sans effet.

on est doué ou on ne l'est pas! Je le suis. Je brick du Mmi, du routeur...je me lance dans la maçonnerie. J'ai commandé avant hier et reçu aujourd'hui celui la: https://www.amazon.fr/dp/B00R76SCJ6/ref=cm_sw_r_awd_3OkEvb01AHRJ6 Ne me manque plus que la foutue résistance. Raison pour laquelle je ne joue pas avec celui qui fonctionne. Sinon pour le modem, j'ai commandé la Huawei e8278. J'ai compris qu'elle se connectait plus rapidement, puisque autonome dès lors qu'elle avait l'alimentation. J'ai pris également une antenne externe. Je manque également de temps pour jouer, car c'est un vrai jeu (de geek sans doute). Mais bon, une heure par ci, une heure par là ça le fera tôt ou tard. Envoyé de mon iPhone en utilisant Tapatalk

I'm the best. J'ai réussi.... à bricker le mr3020... pffff. Heureusement qu'il y a une procédure pour tout. http://www.ediy.com.my/index.php/blog/item/78-recover-bricked-tl-mr3020-wireless-n-router Bon, pas beaucoup de participants sur ce thread! Envoyé de mon iPhone en utilisant Tapatalk

non, rien de plus qu'avec une version openwrt. Je me corrige, mais je pense que ce qui connaissent le MMI l'avaient fait, ce n'est pas Audi qui l'a conçu, mais Harman/Becker. J'ai modifié le packet filter qui permet désormais la connexion en telnet depuis l'AP du MMI. Le fichier de configuration est /mnt/efs-system/pss/nws/usr/bin/pf.conf Dans ce même répertoire, il y a des scripts qui s’exécutent à différents moments. (activation DHCP, ethenet UP, ethernet down...)

C'est sûr prudence car il s'agit d'un système Unix plus que bricolé (oui, j’affirme que même chez Audi, on bricole, on bidouille...ils doivent absolument recruter des ingés système et pas que des développeurs). J'ai même des noms :-). ils n'ont pas pu s'empêcher de signer un peu partout dans le système. Par conséquent, on ne connaît pas tous les impacts du moindre changement sur le système ou les applications. Alors, soyez rigoureux et documentez toutes vos modifications. Autre nouvelle, je viens de récupérer le contenu de la SD livrée par Ontika, y compris l'img du raspberry. Des amateurs? Grosse déception, ils ont codé les commandes dans le copie_scr.sh. Quelqu'un sait avec quoi c'est codé? Ils ne communiquent pas le root du raspberry non plus. Pfff! quand je fais un pas en avant, je recule de deux.

Pour ceux que ça intéressent, voici le script qui permet de modifier le mot de passe root du MMI. Vous pouvez le changer en utilisant par exemple cette page ICI. Dans mon script c'est :123456 le script ICI Pour mémoire, vous pouvez accéder à la console du MMI en telnet via l'interface connectée à l'AMI. Pour ceux qui ont suivi le tuto l'IP sera 192.168.0.100. Pour les autres, c'est votre subnet (24bit) avec le dernier octet à 100.