frankiegom

Je pense qu' exover fait référence aux MiFi, ces espèces de savonnettes qui se connectent en 3G ou 4G et le partagent via un hotspot WiFi. Mais pour pouvoir l'utiliser il faudrait qu'il dispose d'un port ethernet.

ça me rappelle que j'ai aussi eu un moment des problème avec un cable USB pas assez costaud (j'avais commandé le plus court possible, sans réaliser qu'il fallait qu'il puisse passer le courant aussi) et le modem 4G qui consomme un peu trop, avec le routeur qui rebootait intempestivement quand ça tirait un peu trop de jus. Je me suis fait un cable court "à la main" depuis. C'est assez moche, avec le scotch électrique mais ça bne prend pas de place et plus de problème de ce côté là. Pour améliorer la réception j'ai essayé de mettre le routeur dans le coffre, mais c'est trop loin du hotspot, il n'y a pas le débit en WiFi... Peut-être à l'avant sous le capot, je regarderai s'il y a un emplacement...

Clef 4G Huawei E3276 dans un routeur TP-Link tp-wr703n connecté au hotspot de la voiture. Si tu n'as pas besoin de libérer l'AMI, alors l'adatateur USB/Ethernet raccordé au routeur est un peu plus simple à configurer.

Double post!

Il vaudrait mieux, sinon Audi va avoir du mal à vendre ses abonnements, mais... - imopssible de trouver aucune info sur les conditions de réabonnement, les tarifs, toussa (même pour quelqu'un ayant pris l'option kivabien) - tous ceux qui sont ici et dans ce cas, ont appliqué une des procédures "sauvages" d'activation du traffic en ligne, car leur voiture n'est pas connue (d'Audi) comme supportant ce service - je sais pour avoir essayé de configurer le compte myaudi pour pouvoir transférer des itinéraires sur ma voiture, que c'est imopossible par la procédure standard sur leur site (l'option n'apparait tout simplement pas quand on rentre son VIN) et qu'ayant contacté Audi ils ne savent pas m'aider J'ai eu des cas de déconnections initialement quand j'étais connecté à l'AMI, en particulier lors d'un long parcours sur autoroute. Je le mettais jusque là sur le compte d'une mauvaise couverture radio combinée à une moins bonne réception dans l'accoudoir. Dans ces cas là je pouvais voir que la clef 4G avait beaucoup de mal à se synchroniser sur le réseau. Depuis que je suis passé en WiFi, à part Google Earth, ça à l'air de marcher beaucoup mieux, mais il faudra encore faire le test de l'autoroute en rase campagne pour confirmer.

Janvier 2012plus 3 ans ça fait janvier 2015. Le compte n'y est pas quelle que soit la méthode de calcul...

Il d'active pour 3 ans sauf. .. ...quand il s'active pour moins. De fin octobre 2014 à début juillet 2015 dans mon cas. :(

C'est effectivement assez curieux... Et tu as plus de connexions, en particulier en provenance de uap0 (WiFi) quand seul l'AMI est connecté au routeur? Mais ça n'a pas de sens, ça devrait être l'inverse!

Utf8 n'a absolument rien à voir avec ça, car c'est un jeu de caractères supporté par linux et Windows. Ce qui est vrai c'est que sous Linux les sais de lignes sont codés LF (linefeed ou saut de ligbe, code Ascii 12) alors que sous Windows c'est CR plus LF (CR c'est chariot return ou retour chariot, code Ascii 13). Mais ça n'a pas d'incidence sur l'exécution des scripts sous Linux.

Et si tout en ayant le routeur en WiFi sur MMI tu branche l'AMI mais remodifie la route par defaut sur 192.168.1.254, tu vois quoi? Des requêtes dns venant de en5? Rien? Désolé je ne me souviens pas d'un post sur le chiffrement du run.sh...

Oui, 10s de plus, soit 70s. Pour l'instant ça à l'air d'aller. Je suppose que je ne devais pas être loin, vu qu'à 60s ça marchait, ou pas! ;) J'observe et ajusterai au besoin. Quand au firewall, tu veux dire que tu vois les connections s'établir pour écouler le traffic Google Earth, mais que les packets n'essayent pas de passer par là? As-tu essayé de regarder le type de traffic qui traverse le routeur dans le cas qui fonctionne (sur Ethernet en5)? Ca permettrait d'avoir une référence à comparer... Une autre manière de tester... le routeur connecté à la fois en WiFi et en Ethernet. C'est possible, je l'ai fait, et quand on reconnecte le routeur sur l'AMI, la route par défaut est reconfigurée et comme le DNS est déjà correct ça marche tout seul. Et il suffit de remodifier la route par défaut pour repasser par le WiFi et comparer. Mais évidemment ça marcherait mieux avec de quoi tracer, un tcpdump ou équivalent. Je peux essayer, mais je reste bloqué par mon manque d'expérience sur tout ce qui est firewall (moi c'est plutôt sur le routage que je kiffe)!

Sleep à 10s depuis hier soir, ce matin pas de problème (mais pas de problème hier soir avant le changement non plus, donc le problème reste en observation)... Ce matin j'ai changé pf.conf comme tu le conseilles mais à priori ça ne change rien encore. A noter, Google Earth ne marche pas mais street view lui est OK...

Le con! Un coup ça passe, un coup ça casse... Le pire c'est que je me suis posé la question dans la matinée, et je me suis empressé d'oublier! :( Je vais mettre 10s de plus déjà pour voir

Je n'ai pas observé de problème de connection encore, mais ça ne fait que trois jours que je suis configuré comme ça... Une fois le problème Google Earth corrigé, il va falloir se pencher un peu sur cette histoire de route add qui parfois ne passe pas (à vue de nez, c'est la commande qui échoue dans certains cas de figure, mais je n'ai pas encore bien compris pourquoi).

Et pour finir en beauté, ce soir en rentrant du boulot, encore une fois la route par défaut est restée vide. Mais cette fois j'étais prêt avec les commandes nécessaires sur une SDcard, ce qui m'a permis de reconfigurer le système en roulant! :D Tout ça en attendant de comprendre pourquoi ça ne marche pas à tous les coups...

J'ai comparé les règles et ce sont les mêmes dans les deux cas... Considérant que GE fonctionne quand on est connecté par l'ethernet (interface en5), peut-on imaginer qu'en dupliquant ces règles sur l'interface wifi (uap0 en principe) ça suffirait à faire fonctionner Google Earth? Par contre, je ne suis pas prêt à tester ça maintenant... Je ne connais pas assez packet filter pour prendre le risque de tout coincer (surtout après le coup de chaud de ce matin!). François

Alors c'était fun aujourd'hui... Ce matin encore, pas de connection. Vérification dans le menu vert, la route par défaut n'était pas là (même problème qu'hier), mais comme le _CS_RESOLVE était lui bien présent j'en déduit que c'est le add route qui coince parfois (pas de problème pour rentrer chez moi hier). J'ai fait une paire de reboot pour voir, mais rien! Arrivé au boulot, j'ai reconnecté le router à l'AMI sans rien changer et validé que Google Earth était OK. J'ai fais un nouveau dump des paramètres du packet filter (à la fin de ce post), puis j'ai voulu mettre des traces dans le rc.local pour voir si la modification de route par défaut se passait bien (redirection de l'output de la commande dans un fichier) et c'est là que c'est devenu intéressant... Après reboot, plus d'accès telnet, rien, j'ai du reconnecter le cable réseau et passer rar là pour reprendre la main et restaurer le fichier rc.local. Pas possible, /mnt/efs-system était resté read-only!!! :( J'ai été coincé comme à un bon quart d'heure (extinction de la voiture, reboot du MMI, rien n'y faisait). Finalement, après être allé faire un saut à mon bureau prendre mes messages, je suis retourné à la voiture et la au redémarrage j'ai enfin pu modifier le fichier et revenir au statu quo ante. Je suppose que le power off du MMI n'est effectif qu'après plusieurs minutes... Enfin bon, va falloir comprendre pourquoi l'ajout de la route par défaut ne marche pas à tous les coups. Je vérifie l'état du système ce soir avant de partir. (on avait bien dit que c'était dangereux, telnet, hein!) François =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.06.17 08:04:53 =~=~=~=~=~=~=~=~=~=~=~= ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 pflog0: flags=100<PROMISC> mtu 33192 mam0: flags=843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1008 address: 00:00:00:00:01:00 inet 10.0.0.100 netmask 0xffffff00 broadcast 10.0.0.255 mhp0: flags=842<BROADCAST,RUNNING,SIMPLEX> mtu 1500 address: 00:00:00:00:01:00 uap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 address: 00:1c:d7:2b:84:11 media: <unknown type> autoselect inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 link 00:00:00:00:00:00 en5: flags=80008a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: 58:6d:8f:b4:33:ca media: Ethernet 10baseT full-duplex status: active inet 172.16.12.140 netmask 0xffffff00 broadcast 172.16.12.255 # netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Mtu Interface default 172.16.12.1 UG 10 1225 - en5 10.0.0/24 link#3 UC 0 0 - mam0 127.0.0.1 127.0.0.1 UH 2 67 33192 lo0 172.16/16 172.16.12.1 UGS 0 0 - en5 172.16.12/24 link#6 UC 1 0 - en5 172.16.12.1 08:57:00:4c:dc:00 UHLc 6 0 - en5 192.168.1/24 link#5 UC 4 0 - uap0 192.168.1.1 00:1c:d7:2b:84:11 UHLc 1 0 - lo0 192.168.1.109 e0:9d:31:5a:3c:48 UHLc 3 178 - uap0 192.168.1.110 f4:09:d8:d3:6a:e9 UHLS 0 2 - uap0 192.168.1.254 08:57:00:4c:dc:00 UHLc 0 0 - uap0 192.168.1.255 link#5 UHLc 1 1 - uap0 239.255.255.250/32 192.168.1.1 UGS 0 14 - uap0 # pfctl -sa TRANSLATION RULES: nat on ppp0 from <natRangeTable> to any -> (ppp0) round-robin nat on en5 from <natRangeTable> to any -> (en5) round-robin rdr-anchor "dnsRedirect1" all rdr-anchor "dnsRedirect2" all rdr-anchor "dnsRedirect3" all rdr-anchor "dnsRedirect4" all FILTER RULES: scrub in all no-df fragment reassemble scrub out on mam0 all max-mss 968 fragment reassemble pass out all keep state pass in quick on mam0 all keep state pass in quick on mep0 all keep state pass in quick on mhp0 all keep state pass in quick on en5 all keep state block drop in on uap0 all block drop in quick on uap0 from any to (mam0:network) block drop in quick on uap0 from any to (mhp0:network) block drop in quick on uap0 from any to (ppp0) block drop in quick on uap0 from any to (en5:network) pass in quick on uap0 inet proto udp from any port = bootpc to 255.255.255.255 port = bootp keep state pass in quick on uap0 inet from any to 255.255.255.255 keep state pass in quick on uap0 inet proto udp from any to 239.255.255.250 port = 1900 keep state pass in quick on uap0 proto tcp from any to any port = 8100 keep state pass in quick on uap0 inet from any to 224.0.0.0/4 keep state pass in quick on uap0 proto udp from any to (uap0) port 49152:65535 anchor "dialUpTrigger" all pass in quick inet proto icmp all icmp-type echoreq keep state No queue in use INFO: Status: Disabled for 0 days 00:31:27 Debug: Urgent Hostid: 0xc7e39f50 State Table Total Rate current entries 0 searches 86 0.0/s inserts 30 0.0/s removals 30 0.0/s Counters match 56 0.0/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 0 0.0/s state-mismatch 0 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s TIMEOUTS: tcp.first 120s tcp.opening 30s tcp.established 86400s tcp.closing 900s tcp.finwait 45s tcp.closed 90s tcp.tsdiff 30s udp.first 60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 10s adaptive.start 0 states adaptive.end 0 states src.track 0s LIMITS: states hard limit 10000 src-nodes hard limit 10000 frags hard limit 5000 TABLES: natRangeTable OS FINGERPRINTS: 345 fingerprints loaded

Alors.... matinée un peu mouvementée Ce matin, pour aller bosser ça n'a pas marché. ONLINE n'apparaissait pas sur l'écran, Audi Connect ne fonctionnait pasa, pas de traffic online. Une fois arrivé, j'ai constaté que le MMI ne pouvait pinger le routeur, et vérification faiet sur le routeur celui-ci n'avait pas récupéré son adresse par DHCP! :( Du coup je suis passé en addressage fixe, comme toi sur 192.168.1.254 (autant faire simple, d'autant que j'ai fini par réaliser que le DHCP servait des IP décroissantes à partir de 192.168.1.110), et ai changé le script pour positionner la route par défaut sur cette nouvelle adresse. Suite à un reboot ça ne marchait toujours pas, les IP étaient bien définie, mais un ping du routeur me donnait une erreur: # ping 192.168.1.254 PING 192.168.1.254 (192.168.1.254): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down ... Ca s'est finalement mis à fonctionner après mise hors tension du système (power off, pas le simple reboot aux boutons), ouf! côté packet filter je n'ai pas eu le temps de revenir complètement en arrière, du coup, mais j'ai exécuté les commandes que tu m'as demandées avec packet filter activé et désactivé mais je ne vois pas trop la différence (j'essaye de sortir la même chose avec l'ethernet demain matin): # pfctl -sr scrub in all no-df fragment reassemble scrub out on mam0 all max-mss 968 fragment reassemble pass out all keep state pass in quick on mam0 all keep state pass in quick on mep0 all keep state pass in quick on mhp0 all keep state pass in quick on en5 all keep state block drop in on uap0 all block drop in quick on uap0 from any to (mam0:network) block drop in quick on uap0 from any to (mhp0:network) block drop in quick on uap0 from any to (ppp0) block drop in quick on uap0 from any to (en5:network) pass in quick on uap0 inet proto udp from any port = bootpc to 255.255.255.255 port = bootp keep state pass in quick on uap0 inet from any to 255.255.255.255 keep state pass in quick on uap0 inet proto udp from any to 239.255.255.250 port = 1900 keep state pass in quick on uap0 proto tcp from any to any port = 8100 keep state pass in quick on uap0 inet from any to 224.0.0.0/4 keep state pass in quick on uap0 proto udp from any to (uap0) port 49152:65535 anchor "dialUpTrigger" all pass in quick inet proto icmp all icmp-type echoreq keep state # pfctl -sn nat on ppp0 from <natRangeTable> to any -> (ppp0) round-robin nat on en5 from <natRangeTable> to any -> (en5) round-robin rdr-anchor "dnsRedirect1" all rdr-anchor "dnsRedirect2" all rdr-anchor "dnsRedirect3" all rdr-anchor "dnsRedirect4" all # pfctl -sa TRANSLATION RULES: nat on ppp0 from <natRangeTable> to any -> (ppp0) round-robin nat on en5 from <natRangeTable> to any -> (en5) round-robin rdr-anchor "dnsRedirect1" all rdr-anchor "dnsRedirect2" all rdr-anchor "dnsRedirect3" all rdr-anchor "dnsRedirect4" all FILTER RULES: scrub in all no-df fragment reassemble scrub out on mam0 all max-mss 968 fragment reassemble pass out all keep state pass in quick on mam0 all keep state pass in quick on mep0 all keep state pass in quick on mhp0 all keep state pass in quick on en5 all keep state block drop in on uap0 all block drop in quick on uap0 from any to (mam0:network) block drop in quick on uap0 from any to (mhp0:network) block drop in quick on uap0 from any to (ppp0) block drop in quick on uap0 from any to (en5:network) pass in quick on uap0 inet proto udp from any port = bootpc to 255.255.255.255 port = bootp keep state pass in quick on uap0 inet from any to 255.255.255.255 keep state pass in quick on uap0 inet proto udp from any to 239.255.255.250 port = 1900 keep state pass in quick on uap0 proto tcp from any to any port = 8100 keep state pass in quick on uap0 inet from any to 224.0.0.0/4 keep state pass in quick on uap0 proto udp from any to (uap0) port 49152:65535 anchor "dialUpTrigger" all pass in quick inet proto icmp all icmp-type echoreq keep state No queue in use STATES: self tcp 127.0.0.1:65510 -> 127.0.0.1:4444 ESTABLISHED:ESTABLISHED self tcp 192.168.1.1:23 -> 192.168.1.108:49186 ESTABLISHED:ESTABLISHED self tcp 192.168.1.1:23 -> 192.168.1.108:65339 FIN_WAIT_2:FIN_WAIT_2 self udp 224.0.0.252:5355 <- 192.168.1.108:58265 NO_TRAFFIC:SINGLE self udp 224.0.0.252:5355 <- 192.168.1.108:49584 NO_TRAFFIC:SINGLE INFO: Status: Enabled for 0 days 00:00:03 Debug: Urgent Hostid: 0xc7e39f50 State Table Total Rate current entries 5 searches 1069 356.3/s inserts 144 48.0/s removals 139 46.3/s Counters match 225 75.0/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 15 5.0/s proto-cksum 0 0.0/s state-mismatch 0 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s TIMEOUTS: tcp.first 120s tcp.opening 30s tcp.established 86400s tcp.closing 900s tcp.finwait 45s tcp.closed 90s tcp.tsdiff 30s udp.first 60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 10s adaptive.start 0 states adaptive.end 0 states src.track 0s LIMITS: states hard limit 10000 src-nodes hard limit 10000 frags hard limit 5000 TABLES: natRangeTable OS FINGERPRINTS: 345 fingerprints loaded

Ouch! C'est vrai. .. J'essaye de trouver le temps un de ces quatre matins....

Il faudrait réussir à implémenter tcpdump sur le routeur, quitte à repasser en usb/ethernet temporairement pour voir ce qui se passe.

Mais les règles de NAT ne devraient elles pas jouer uniquement pour le trafic entrant? En général c'est ce qui est fait par défaut...

Que veux-tu dire par là? Je suis rentré du boulot tout à l'heure et n'ai rien remarqué... Oooh... peut-être parce que j'avais complètement désactivé le firewall? Ou alors, c'est vrai, parce que je ne suis pas sorti du cache. En tous cas, pour le reste, je suis super content. J'ai pu écouter la musique sur mon iPod et surprise! Le son est bien meilleur qu'avec les mêmes fichiers directement sur le disque dur. J'ai du mal à y croire, mais c'est le jour et la nuit :D

Surtout que même par rapport aux références QNX il y a des différences assez sensibles...

le problème, c'est de trouver comment le configurer dans le MMI... vu que c'est lu iqui donne l'IP au routeur Maintenant qu'on est connecté sans fil, ne reste plus qu'à trouver le meilleur endroit pour cacher le routeur... J'ai bien envie d'essayer dans le coffre avec une paire d'antennes externes ;)

Pourquoi se prendre la tête avec le routeur et une IP dynamique? Parce que pour moi ce n'était pas vraiment une prise de tête... J'ai l'habitude des DHCP qui se "souvienne" de leurs clients et le reassignent systématiquement la même addresse, et franchement dans le peu de temps que j'avais ce matin, c'était le chemin de moindre pente (le chemin des anes, comme on dit en Corse! ;) ) Après, quand j'aurais de nouveau du temps de cerveau disponible, je passerai sans doute en IP fixe, parce que c'est plus propre. Utiliser le dhcp du TP-Link, c'est bien et pas bien à la fois. Le jour ou tu vends la voiture, si tu ne fourgues pas le routeur avec, c'est la merde si tu oublies de revenir en arrière sur la config. Et je ne sais pas comment l'acheteur lambda réagira au petit discours technique pour lui "vendre" l'option. Donc pource qui me concerne, je resterai sur le DHCP du MMI. A moins bien sûr qu'on se rende compte d'une sévère limitation des autres clients qui seraient facilement levée en passant sur le routeur. A voir donc... Vivement ce soir, pour constater que ça marche toujours (I wish!). :) François (les collègues, au bureau, ils me prennent pour un extra terrestre)