MMI 3GP, Audi Connect et WiFi

[hsd92]

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.

[frankiegom]

Enorme! C'est déjà énorme...

Quand tu dis firewall, c'est le packet filter, c'est ça?

L'adresse IP du routeur, tu la fixes dans le routeur direct, ou tu changes le DHCP du MMI pour qu'il donne toujours la même au routeur?

 

Pour ce qui est de la route par défaut qui ne survit pas au reboot, le problème est le même pour le DNS normalement, en tous cas c'est ce que j'avais vu. As-tu pensé à regarder du côté de QNX pour celà? Je suis sous QNX 6.3.2, et ici je trouve ça:

• /etc/system/sysinit

script that starts up the main system services. In order to edit this file, you must log in as root.

• /etc/rc.d/rc.sysinit

The /etc/system/sysinit script runs /etc/rc.d/rc.sysinit to do local initialization of your system.

• rc.local

As described above, rc.sysinit runs /etc/host_cfg/$HOSTNAME/rc.d/rc.local or /etc/rc.d/rc.local, if the file exists and is executable.

 

etc...

 

Je ne sais pas si les fichiers en question doivent suivre un format particulier, en particulier sysinit (qui n'est pas sur mon MMI), ou s'il suffit de le créer avec les commandes qu'on veut (mais alors on ne suivra pas le déroulement du boot tel que décrit dans le document bien sûr...). Et ça explique en tous cas que le rc.local que tu as créé ne s'exécute pas, vu qu'il est au mauvais endroit et que le fichier sysinit n'existe pas sur nos systèmes!

 

Je pense que tu n'es plus loin du tout!

 

François

[frankiegom]

Et accessoirement, je serai intéressé par les modifications que tu as faites au packet filter (accès telnet par le hotspot du MMI ou du TP-Link, et pour la nouvelle route par défaut...). ;)

[hsd92]

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.

[hsd92]

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.

[frankiegom]

J'avais pensé à un truc similaire avec le script sysinit, mais la fin justifie les moyens...

 

Bons paramètres dhcp? Pour distribuer la nouvelle route par défaut, ou donner au routeur l'adresse .254?

Tu as mis une IP fixe dans le routeur pour l'instant?

[hsd92]

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

[frankiegom]

Bon,

 

j'ai trouvé un peu de temps ce matin en arrivant au boulot un peu plus tôt (je suis en parking souterrain à la maison, un peu chaud pour les essais live)...

 

Donc, j'ai créé le fichier rc.local comme toi en y rajoutant juste "pf -d" (ça efface toutes les règles j'imagine) et en utilisant 192.168.1.110 pour la route par défaut (c'est l'adresse allouée par le MMI), et ajouté la ligne dans le startDumper.sh

Ensuite, j'ai reconfiguré le routeur pour le connecter au hotspot de l'Audi et rebooté le MMI.

 

premier coup de chaud, rien ne se passe, pas d'accès Internet et pas d'accès telnet par le hotspot. Je vais dans le menu vert et pas de route par défault et pas de DNS dans _CS_RESOLVE, rien.

 

Là, j'ai réalisé que je n'avais pas rendu rc.local exécutable!

 

Donc, un petit chmod +x rc.local et second reboot du MMI.

Ayé too! :roi:

 

Dernière étape, je sors l'iPod et son cable AMI de la boite à gant et le branche à la place de l'adaptateur ethernet et rien! :(

Sauf que dans la boite à gant depuis 6 mois, la batterie de l'iPod s'était complètement déchargée, mais heureusement après 10s il s'est allumé et a été détecté.

 

Heureux, je suis! Pas testé si un device connecté au hotspot MMI à l'accès par contre, pas eu le temps ce matin.

 

Ne reste plus qu'à faire un zip avec tous les fichiers pour configurer un MMI proprement et automatiquement... ;)

Et peut être aussi changer le DHCP pour être 100% sûr que le routeur récupère toujours la même adresse (192.168.1.254?)

 

Bravo!

[Thierry-13]

Impressionnant, bravo.

 

Pour le DHCP il suffit de faire une réservation basée sur l'adresse MAC.

[hsd92]

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.

[frankiegom]

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)

[frankiegom]

Impressionnant, bravo.

 

Pour le DHCP il suffit de faire une réservation basée sur l'adresse MAC.

 

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 ;)

[Thierry-13]

OK my bad je pensais que vous parliez du DHCP du routeur :ripeer:

 

C'est certain que sur un linux normal c'est facile de faire une réservation par @MAC, mais sur ce QNIX à la onesgainpipolyou c'est raide

[frankiegom]

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

[hsd92]

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

[frankiegom]

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

[hsd92]

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

[frankiegom]

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...

[hsd92]

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

[frankiegom]

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

[hsd92]

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.

[frankiegom]

Ouch! C'est vrai. ..

J'essaye de trouver le temps un de ces quatre matins....

[frankiegom]

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

[frankiegom]

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

[frankiegom]

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

[frankiegom]

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...

[hsd92]

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

[frankiegom]

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).

[hsd92]

essaye de rallonger le sleep. C'est peut-être trop juste.

 

 

Envoyé de mon iPhone en utilisant Tapatalk

[frankiegom]

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

[frankiegom]

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...

[hsd92]

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

[frankiegom]

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)!

[hsd92]

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

[frankiegom]

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...

[hsd92]

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.

[frankiegom]

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!

[hsd92]

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.

[frankiegom]

You da man! :roi:

 

:winner:

[Arima]

Bravo ! :race: