Acuatrovant

Ha pasado tiempo desde que hice esta pregunta, que quedó sin respuesta, y desde entonces el error ha seguido ahí, dejé de darle importancia, por que todo funcionaba bien.

Pero a raíz de una actualización de mapas 2019 que acabo de hacer, me ha vuelto a picar la curiosidad del error, y he encontrado esta web:

https://www.a5oc.com/forums/a5-general-q/113737-mmi-3g-3gp-navigation-28.html#post1352258

que indica cuál es el motivo de que aparezca, y es tan simple, como que no pueden estar activos a la vez el MMI BT y el MMI AUX. Desactivar el AUX (ponerlo como DISABLE 2/2) mediante el menú verde, en "DIAGNOSE/SETTINGS/AMI_AUX", y solucionado, por fín, tras dos años, ya no aparece.... (mas vale tarde que nunca)

Thanks, entonces nada, si me decido, tendré que acostumbrame a verla siempre ahí, fija.

Perdón por rescatar un hilo tan viejillo, pero me ha surgido una duda. Estoy a un par de dedos de cambiar mi A4 avant de 2012 por el nuevo de este año (una oferta que me está costando rechazar, de momento, hasta hacer números), pero me preocupa lo de la pantalla "no" escamoteable.

La razón, es por que el coche duerme en la calle , y veo demasiado goloso para los "manguis", que muchos de ellos no piensan que esa pantalla no es nada, solo pantalla. A un ladrón le llama la atención una pantalla "asomando", y la tentación de arrancarla, aunque luego no les valga para nada, supongo que es demasiado.

y mi pregunta es: ¿no existe ninguna versión, o ningún paquete, que incluya la pantalla escamoteable?

Hola, siento intervenir en este hilo, pero estoy mosca yo también con esto del 4300k o 4800k. Yo tambien tengo el "lavado-de-cara" de 2012, y también lleva las XenStart 9285 335 244 , que según todos los indicios (tirando de San Gugel como un loco), es de 4300k, no de 4800k (incluso la web oficial lo indica). Entonces, pregunto ¿de dónde sacáis que lleva 4800k? ¿acaso los de "fillips" han hecho una versión de las 9285 335 244 con 4800k exclusivo para audi? por que no me cuadra lo mire por donde lo mire, una misma referencia , pero dos intensidades.

No es que me haga falta, por que ya he cambiado mis lámparas por unas de 5000k genéricas, pero es por curiosidad, para otra vez.

Hola a todos:

Hoy he entrado en el VAGCOM a quitar un error que me dió hace unos días sobre el ESP (me decía "malfunción" o algo así, pero el ESP está bien, funciona), y al dar a escanear en visto un error que no lo quita, y lleva ahí desde que activé el GoogleMaps con la RPI

ver este hilo:

Según he visto por la red, el error 03389 lo da al haber cambiado la configuración del GoogleMaps (al activarlo) y es como un CRC de chequeo que indica un cambio no autorizado en el navegador.

He visto como resetear otros errores, como el del cambio de mapas (error 03175) pero nada sobre el 03389, excepto en foros extranjeros, pero no soy capaz de dar con el punto exacto para ponerlo a cero.

El error que me da es este:

-------------------------------------------------------------------------------
Address 5F: Information Electr. (J794)     
   Part No SW: 8R1 035 666 J    HW: 8R1 035 666 
   Component: H-BN-EU       H43 0941  

   Subsystem 1 - Part No: 8R0 060 884 DF
   Component: EUR 2016  2204 

   Subsystem 2 - Part No SW: 8R0 919 604     HW: 8R0 919 604 
   Component: DU7 High  H41 0104 

   Subsystem 3 - Part No SW: 8T0 919 611 K    HW: 8T0 919 611 B
   Component: E0380 Bedient  H02 0030 

   Subsystem 4 - Part No: 8R0 060 961 C
   Component: CD-Database  3638 

1 Fault Found:
03389 - Data Set Implausible 
            000 - -
             Freeze Frame:
                    Fault Status: 01100000
                    Fault Priority: 2
                    Fault Frequency: 1
                    Reset counter: 215
                    Mileage: 104077 km
                    Time Indication: 0
                    Date: 2017.05.23
                    Time: 12:20:14

             Freeze Frame:
                    Voltage: 12.00 V
                    Bin. Bits:      010

-------------------------------------------------------------

Los nºs de serie de elementos HARD y SOFT se refieren todos al módulo MMI 3G+, o sea, que los tiros van por ahí.

¿sabe alguien como quitarlo? Si no lo consigo, soy capaz de desactivar el GoogleMaps, por que prefiero un sistema limpio que uno con errores.

Hola a los sufridores de los Xenon.

Ya me han llegado los "nisupus" que compré. Comentaros como me ha ido, para otros que quieran intentarlo.

La Izquierda, la fundida, a la primera, solo quitar tapa, soltar cable, girar a la izquierda, y listo, poner nueva y cerrar. 10 minutos.

La del lado derecho, "jostias", menudo cristo. Primero, soltar la tapa superior del radiador, solo he soltado un lado para ahorrar tiempo, pero como son "clips" en lugar de tornillos y son de un solo uso, se me ha roto (lógico, están pensados para eso), y para mas "inri" se me ha caído abajo, a la tapa que cubre el motor por abajo y no la he podido sacar. Ahí se ha quedado. Lo he dejado sin clip.

Luego, aflojar los tornillos mas bajos (2) del faro, soltar los dos superiores y aflojar un tercero del medio, que por desgracia se me ha caído abajo. Luego, sacar el foco. He intentado no sacarlo entero, pero ha sido imposible, no había manera de hacerlo sin sacar casi entero, así que al final, he optado por sacarlo completo, soltado el cable de alimentación. Luego, poner la lámpara nueva han sido dos minutos.

Aprovechando que estaba el foco suelto, he mirado en la tapa del fondo del cubremotor y he encontrado el tornillo que se me había caído, menos mal, sino, tendría que haber soltado parte de la tapa inferior, y al ser de suspensión rebajada, no hay hijo-vecino que se meta debajo, no me entra ni la cabeza.

Poner el faro es MUY COMPLICADO, mucho, hay que acertar "a ciegas" con las guias que lleva debajo, sino, el faro queda levantado y apunta hacia arriba. Y ademas, hay que acertar con el tubo del lavafaros, que he necesitado varios intentos de "mete-saca" hasta lograr encajar las guias mas el tubo del agua. (todo con ayuda de una linterna, porque no se ve).

Pero listo, apretar, y encender, funcionan bien, alumbran con fuerza y están alineados, lo cual indica que he acertado con las guias. Total para el faro derecho, 40 minutos de penurias y miedos.

Los Xenon que he puesto, al ser "nisupus" de 6000k, son mas azuladas que las originales, y eso es un pelín feo al tener los leds blancos, pero es un mal menor, mientras funcionen. Lo de que son de 6000k no lo puedo asegurar, si parecen dar mas luz, lo que sí es seguro es que son mas azuladas.

Lo que he visto de diferente respecto a las originales, es que la guía es de plástico en lugar de metal, y supongo que con el tiempo y el calor se acabarán rompiendo, pero por lo que me han costado, como si duran solo un año, me he ahorrado 200€ (frente a los 40 de las "nisupus")

Un consejo para el que se atreva el solo ha hacer el cambio: cuando sueltes los tres tornillos superiores del faro, sujetalos con fuerza cuando están casi sueltos para que no caigan abajo.

hace 3 horas, Mivi36 dijo:

Hoy me funciona bien sin licencia el tema del tráfico , lo único que no consigo conectar el mmi con la aplicación de myaudi para introducir destinos y demás extras , alguien que lo haya hecho me ayuda ? O no se puede al noser original la instalación ? Gracias 

 Ahí si creo estar en lo cierto al decirte, que como en audi oficial no consta que tengas el "connect" , la función no está activada "online", dado que se hace a través de la web de audi, y allí, no figuras. Esto lo sé, por que lo pregunté en el conce, antes de hacer el invento y me explicaron el tema.

(si estoy equivocado, alguien me cerregirá)

hace 6 horas, Mivi36 dijo:

... y lo único es que para el tráfico online me pide una licencia válida de audi connect porque pone que está caducada se puede hacer algo con esto ....

¡Qué raro! A mi no me ha dicho nada, y no lo he escuchado de nadie que le haya ocurrido. Aunque también es cierto, que no lo he usado nada mas que el primer día de pruebas, por que luego, no recuerdo haber entrado a mirar. Probaré mañana a ver que me dice.

Yo es que las caravanas ya me las sé de memoria (en mi zona), y sé cuando debo salir o volver para evitarlas.

Hola trompos: no podía esperar ,necesitaba las luces mañana, así que he tirado por la calle de en medio y he cogido unas genéricas recomendadas en forocoches. No puedo ir por ahí con la luz fundida, que si me pillan se me cae el pelo. Me llegan mañana si la cosa cumple.

En 1/6/2017 a las 23:42, trompos dijo:

Ese fallo que comentas es lampara Fijo.

Tu coche al ser un Facelift monta las Philips D3S 4800k 35w, mi consejo es que cambies las 2 porque la otra también te durará poco y el tono y potencia de iluminación también te va a variar.

 

Una ayudita, please:

He visto esta en la "bahía"

ebay.es/itm/172333665697

(he quitado el tres w de delante por si no deja pegar enlaces)

¿crees que valen de sobra? Por el precio de dos lo veo excesivamente barato, pero tiene buenos votos. Aunque, me da, que son de 4300k, no de 6000k como dice el anuncio, y si son de 4300, no valen

Confirmado, los "facelift" de 2012 en adelante (hasta 2016 que salió el B9) llevan BiXenon D3S Philips XenStart 35w. He mirado como cambiarlas yo, y he descubierto que llevan una tapa de goma muy fácil de acceder y quitar (bueno, la derecha hay que quitar el filtro del aire), y la lámpara es fácil de agarrar con la mano par sacar. No lo he hecho, por aquello de "tomar precauciones", pero al menos sé qué modelo es y como puedo acceder a ellas.

Ahora, a buscar precios por la red, y estudiarme las normas de seguridad antes de tocarlas.

Thanks, eso imaginaba. Y lo de cambiar las dos, también lo suponía. En Lámparas normales sé que se hace, pero en Xenon pensaba que no.

Hola:

Me uno al clan de los Xenon con problemas.

Para rizar el rizo, la extensión de garantía de mi coche acabó hace poco mas de seis meses. Tiene 4 años y medio aprox. y tenía la extensión de garantía a 4 años. Y mira tú por dónde, me falla al de poco de acabar la garantía. (por cierto, 110mil km han durado)

Es un Facelift de 2012 (A4-B8) con ¿Bi-Xenon? (creo que sí) Ha empezado a parpadear la luz izquierda y da fallo en el FIS. Si muevo el mando de AUTO a MANUAL, se arregla el fallo, se quita el error del FIS y vuelve a funcionar, pero al de una hora vuelve a fallar.

Eso sí, de momento, desde ayer no ha vuelto a hacerlo.

Por lo tanto, según he leído, descarto el "Balastro" o "transfo de alta", por que al ser BiXenon no llevan balastro, sino que es la electrónica del Xenon el que controla cada lámpara. De lo cual deduzco, que con cambiar la lámpara izquierda, lo soluciono.

Aquí viene la duda: ¿qué modelo es sin tener que desarmar previamente?

He leído que pueden ser D3S (ref. N10721801), ¿puede ser cierto?

Tengo un vale de norauto por cambiar unas ruedas a otro coche de 100€ que quiero emplear en el xenon.

Sobre el AMI no te puedo ayudar, por que no he usado ese método (de hecho, no tengo USB por AMI, solo AUX). Pero si te puedo decir, que probablemente en la SD que usaste para meter el script de configuración AMI, habrá quedado una copia de seguridad del viejo fichero, en una carpeta llamada BACKUP o algo así. Si eso es cierto, solo has de copiarlo sobre el script de la carpeta principal, pisando este con el mismo nombre, y volver a ejecutarlo para que lo deje como estaba al princicpio. (antes de hacer nada, copia la SD en un PC al completo, no sea que pises o renombres lo que no es y se líe aún más)

hace 16 horas, FrA1l3 dijo:

 

Buenas!

 

Hombre puedo estar equivocado, pero te aseguro que el cacharro que llevo lo abrí antes de meterlo en el coche y no vi ni baterías ni pilas ni nada dentro. Es más, aparte de 3 placas base unidas no trae nada más. Otra cosa es que tenga capacitadores gordos y lo mantengan encendido los segundos necesarios que necesita para apagar bien.

Ahí ya no digo nada.

 

saludos!

No quiero quitarte la razón, no estoy aquí para eso, solo quiero hacerte ver que no es posible, que la única explicación lógica son las baterías, las veas o no estarán por ahí. Hay baterías del tamaño de la uña del dedo meñique, como las que usan los mandos BlueTooth de bolsillo para presentaciones ;-)

Piensa que una simple RPI, incluso la primera, necesita 650mha para encender, y que tarda 20 segundos en apagarse, y eso es algo que solo lo aguantarían unos condensadores mas grandes que la propia RPI. Y si ademas lleva pantalla TFT, el consumo llega a 1a. Los condensadores de hoy día son "simbólicos", son formato SMD y están pensados para bajo consumo, con lo cual no son capaces de almacenar energía suficiente para aguantar un GPS con una CPU decente (¿ARM?) el tiempo suficiente mientras apaga. Una prueba la tienes en un cimple móvil, si le quitas la batería cae de golpe, no se apaga poco a poco.

Pero no importa, no hablamos del tiempo que aguanta tu GPS mientras se apaga, sino de lo que habría que hacer para que una RPI si apagara sola, y el sistema necesario no merece la pena.

Rizando el rizo que se podría hacer una cosa, y es poner un botón de apagado en el puerto de expansión. Pero la pega, es que no puedes cartar el encendido del coche hasta que veas que deja de parpadear la luz de la RPI, lo que es algo muy inexacto. Son unos 20 o 30 segundos los que necesita para apagarse bien, y habría que dejar el coche en marcha mientras. Pero ya digo, que es complicar la cosa, por una posibilidad entre 100 de que falle la SD, y tengamos que volver a meter el operativo.

hace 8 horas, FrA1l3 dijo:

 

...los navegadores android (al menos el que llevo yo en el coche) va alimentado en paralelo al MMI (es independiente) y cuando sacas la llave del contacto, se apaga bien

Los navegadores independientes tienen batería propia, y detectan la desconexión del "anfitrión" con lo que saben que deben ir apagándose. En el Ibiza de mi hijo, que tiene navegador externo (garmin) pero integrado en el salpicadero (se encaja en un conector propietario de seat), al apagar o extraer el navegador, este inicia la desconexión.

La RPI no tiene batería, al cortar el encendido, la RPI cae de golpe y porrazo, sin opciones. Se puede poner una batería a la RPI, y esta a su vez al mechero del coche, pero entonces la RPI estaría toda la vida conectada, y estaríamos siempre pendientes de que la batería aguante el tiempo que el coche esté parado.

No es que sea imposible, es que es inviable. Se podría poner una batería y un pulsador en uno de los pines de expansión de la RPI y configurar ese pulsador como botón de apagado (solo serviría para apagar, no para encender). Y para encender habría que quitar y volver a poner la batería. El trabajo que lleva hacer todo eso no compensa.  Es mejor jugar con la probabilidad y que la RPI aguante los parones a lo bestia sin romperse. En las dos semanas que lo tengo no se ha roto ninguna vez.

Una cosa que se puede hacer, para no repetir los pasos, es hacer copia de seguridad de la SD con el mismo programa usado para grabar el operativo (el "Win32DiskImager"). Yo ya lo hice. Si se me rompe algo, vuelvo a grabar la copia de seguridad.

hace 7 horas, pan_con_atun dijo:

Por cierto, ¿hace falta contratar una tarjeta de datos, o sirve con los datos de nuestro teléfono? Si sirve con el Internet de nuestro teléfono: ¿puede el teléfono ir conectado por bluetooth al coche sin perder ninguna funcionalidad?

Otra duda: ¿se apaga solo al apagar el encendido y se enciende automáticamente o tenemos que estar desconectándolo?

 

Un saludo a todos y gracias por vuestros aportes.

Te comento hasta donde puedo:

Tarjeta de datos vale la que estés pagando a tu proveedor de telefonía móvil. Yo tengo con lowi un solo giga (de esos que se acumulan hasta dos) y en las dos semanas que lo llevo activado, solo me ha gastado 200 megas, y es la peor parte, por que la primera vez tiene que descargar el mapa entero de google y las imágenes a diferentes niveles de detalle y aumento. Luego, una vez cargado, solo actualiza cuando el nivel de detalle cambia (por ejemplo si vas por ciudad muy lento, las imágenes tienen mas detalle y tardan algo mas en cargar y gastan algo mas de datos). Pero en general, solo gasta la primera vez, y luego cuando cambia algo del mapa. Las noticias, tiempo, tráfico y demas no gastan nada de nada, muy poco, es solo texto.

En cuanto al internet del móvil, puede usarlo sin problema, siempre que tu móvil permita compartir una conexión vía wifi, y sepas ver la IP que maneja. Eso es cosa de cada móvil, los hay mas completos en opciones y mas "sosos" y simples. Lo del BlueTooth sin problema, va con ambos sistemas conectados, y si te llaman puedes coger la llamada como siempre, al menos, en mi móvil "Windows Phone". Eso sí, la batería del móvil se resiente en viajes largos, el móvil se calienta de mas, en mi caso.

El sistema se apaga "de golpe" al cortar encendido, por que los mecheros dejan de recibir energía, y si lo dejas conectado, al dar al contacto, vuelven a cargar el Linux y todo igual. El problema es tener que volver a compartir el WIFI del móvil cada vez que inicias, por que los móviles, al no detectar conexiones se desconectan solos (al menos, en el mio es así). Otro problema puede ser (y MUY GRAVE) es que la RPI no vuelva a encender, por que se ha apagado de mala manera, a lo bestia. Es un sistema operativo, y debe apagarse con su menú, estilo "guindous". Puede ocurrir que apagamos el coche justo cuando está grabando datos en la SD, y esta se corrompa, y no vuelva a arrancar. Pero se suele solucionar llevando la SD de la RPI a un PC y reparando la partición.

Mad-i , lo del módulo lo conocía, por eso estoy en este hilo, por que en su día no cogí el módulo SIM para no depender de un servicio de suscripción, pero como ya he agotado la garantía de 4 años del coche (cogí la extensión), ahora puedo "meterle mano" sin miedo a perderla.

Yo lo que decía, es que, teniendo el módulo que admite la SIM, tienes la opción de comprarla original a Audi o de poner la tuya propia. En ambos casos vas a pagar por el servicio, pero uno se lo pagas a Audi, y el otro a tu proveedor de telefonía.

En nuestro caso, con el invento RPI, pagamos nosotros por los datos, simplemente. (lo que no es malo, eso depende del bolsillo de cada uno)

Ahora mismo, estoy encantado con poderle dar una vida distinta al navegador 3g+, gracias a la conexión de datos. Y no gasta tanto como puede parecer, quizás el primer día sí gasta, por que descarga las imágenes de Google, pero luego, en el día a día, gasta muy poco, dado que las noticias, precios, tiempo y demas, son solo texto (y alguna imagen pequeña).

hace 11 horas, Acuatrovant dijo:

Por cierto, mi pregunta sigue sin respuesta: ¿por que podemos conectarnos a "audi connect" sin pagar el servicio? ¿es tan ilegal que nadie se arriesga a responder?

Nuevamente me respondo yo solo.

He leído por foros extranjeros, que el servicio audi es en realidad un compendio de servicios de terceros, que audi simplemente ofrece juntos en un paquete, y que lo que cuesta es la tarjeta SIM que lleva el vehículo (en los modelos anteriores a 2016 creo), y eso es lo que se paga.

Así que, a mi modo de entender, lo que hacemos NO ES ILEGAL, es ALTERNATIVO. Esto es, que en lugar de usar una tarjeta SIM entregada por audi, y pagar por ella una cuota, lo que hacemos, es usar NUESTRA propia SIM, en este caso, la del móvil que se conecta a la RPI.

Así que, mientras nadie me corrija, es perfectamnet legal lo que hacemos, simplemente, nos conectamos pagando por los datos que usamos, a nuestro proveedor de telefonía, en lugar de pagar por la tarjeta de audi. Aparte, que los servicios a los que accedemos, no sou de audi, sino generales, como lo de las gasolineras que lo coge de "www.inrix.com" o el tiempo, que sale de "www.meteogrup.com", el tráfico lo coge de "tomtom", etc....

Es lo mismo, que si hubieramos tenido el módulo SIM (que evidentemente no tenemos, y por eso estamos aquí) y nos conectaramos mediante BlueTooth haciendo "streaming" de los datos, en cuyo caso, los datos correrían a nuestra cuenta y la tarjeta original audi quedaría sin uso.

Esto no sirve en los nuevos modelos (¿B9?) por que llevan "eSIM", que va integrada en el navegador.

Todo esto, lo digo un tanto "a voleo", por que no consigo encontrar nada que responda mi pregunta, y es una suposición mia.

Quería hacer un par de puntualizaciones importantes.

Antes de nada, decir que soy un fanático de la electrónica y por ende, de los dispositivos electrónicos, como las raspberry. Eso significa, que he ido comprando todos los modelos de RPI que han salido, desde la primera "A" hasta la actual "RPI3".

Por este motivo, como tengo RPI de sobras, quería utilizar una de las primeras, la "B256" que es la que menos consume, y es ideal para tener enchufada en el cargador del mechero.

Las primeras pruebas, las hice con el último de los modelos, el RPI3, que lleva WIFI integrado y  4 USB, y así, con un solo pincho WIFI, un teclado y un ratón he podido configurar. Pero hoy me ha dado por probar uno de los "viejos" modelos, el "B" (a secas, no el "+") con solo DOS USB y 256megas de ram, pero que solo consume 650mha, y se alimenta fácil con el mechero.

El problema con el que me he encontrado, sin quererlo ni saberlo, es que, la RPI no tiene potencia suficiente para alimentar los dos WIFI.

Cuando he configurado la RPI en casa, lo he hecho con un "hub" de 4 USB alimentado externo, y no había problema, pero al quitar el hub, y dejar solo los dos WIFI (dado que solo hay dos USB), la cosa no funcionaba. Investigando, he averiguado algo que no sabía, y es que no tiene potencia suficiente para los dos WIFI, ya que cada uno consume 500mha, y la RPI solo entrega 300mha a cada USB.

Hasta que he averiguado eso, me he tirado horas de pruebas, sin saber dónde estaba el error.

Una vez sabido el fallo, investigando mas a fondo, resulta que la raspberry tiene un parámetro para entregar hasta 1a. en cada USB, activando una variable en el fichero "/boot/config.txt" que se puede editar desde un PC  con la SD insertada. Pero solo funciona a partir del modelo "B+" que es de 512megas. (parámetro "max_usb_current=1")

Así que, tras muchas pruebas, he visto que los primeros modelos de RPI no sirven (el "A256" y el "B256") y solo es válido a partir del "B512+".

Así que, si tenéis una RPI "vieja", no probéis, no os va a funcionar.

El principal problema de las RPI anteriores a la RPI2 y RPI3 (modelos "B") es que solo tienen dos USB, y si usamos los dos con los pinchos WIFI, no podemos conectar un teclado, pero en ese caso, podemos configurar mediante una sesión SSH con el programa PuTTY por ejemplo. Poniendo la IP de la RPI (que habremos averiguado antes de poner los pinchos WIFI, con un teclado, y haciendo IP ADDR para ver la IP del ETH0) podemos conectar remotamente, y controlar la RPI desde el PC.

Así lo he hecho yo, y he logrado tener una RPI B+ de 512mb "vieja", pero que consume poco, no mas de 850mha, ideal para llevar en el coche, bajo el reposabrazos central.

Por cierto, mi pregunta sigue sin respuesta: ¿por que podemos conectarnos a "audi connect" sin pagar el servicio? ¿es tan ilegal que nadie se arriesga a responder?

hace 10 horas, Mad-i dijo:

 

Muchas gracias por tu aportación y por recompilar todo, la verdad es que ando fatal de tiempo y tenía pendiente hacer un PDF para descargar, pero nada... Si te animas, será bienvenido...

 

Respecto al fallo de Audi Connect, si te funcionan los mapas es que es un problema puntual del servicio de Audi, creo yo.

 

Saludos.

Puedo "intentar" lo del PDF, lo que ocurre es que a mi, todo lo que vaya mas allá del "txt" se me escapa, hasta un simple "word" me cuesta usar. Ya investigaré.

Lo del Audi connect se solucionó ello solo al día siguiente, pero me sigue asaltando una duda: ¿cómo es posible que accedamos a un servicio de pago, de forma gratuíta? ¿no se supone que son servicios por los que se paga cuota, y nosotros entramos gratis? ¿sabes(sabéis) algo de eso?

A ver si va a resultar que por entrar de forma "rara" nos van a bloquear los navegadores, o peor aún, considerarnos "piratuelos" y mandarnos una visita a casa.

Me da un poco de miedo. Si son gratis lo entiendo, si son de pago, habrá que estar "al loro"

hace 2 horas, FrA1l3 dijo:

 

Hola!

Gracias por el aporte en primer lugar. Te he editado el post para corregir esto que indicas. Si necesitas algo más, pídelo sin problema 

 

saludos!

Thanks!

Ya que lo dices, borra este texto marcado en negrita:

Se acabó, esto es todo en la RPI. Al reiniciar ("sudo reboot" o con los menús) y hacer:
"ip addr" en una ventana de comandos, deberíamos ver las dos redes wifi (me remito al primer punto, el de comprobación de wifi).
O sino, lo mejor

Que hay al final casi, cuando ya indico el final de los pasos linux.Puede llevar a confusión, está incompleto y sobra. Se me habrá ido la pinza ahí, por que no recuerdo lo que iba a poner.

He visto varios errores en mi ayuda, pero no me deja editarlos ya. Algunos son faltas de ortografía que se pueden perdonar, pero en una sitio he puesto info equivocada:

donde dice:
tecleamos "sudo leafpad /etc/network/interfaces" o "sudo leafpad /etc/network/interfaces"
 

debería ser
tecleamos "sudo leafpad /etc/network/interfaces" o "sudo nano /etc/network/interfaces"
 

He sacado tiempo para repetir los pasos en una nueva SD y me ha funcionado a la primera.

Dejo escrito aquí el proceso. Si alguien lo quiere pulir y subir como PDF, mejor, que así se ve bastante feo.

En Linux, abrir una ventana de comandos (en raspbian, hay un icono con una consola estilo MS-DOS arriba en la barra).
Desde ahora mismo, todo lo haremos en modo consola, al estilo del viejo MS-DOS.
Trabajaremos con "sudo" por delante (minúsculas) para tener permisos de administrador. O podemos convertirnos en superusuario con el comando "su" y la calve que sea según la distribucion raspberry que usemos (en mi caso es "root", pero en otros he visto "raspberry" o "raspberrypi", eso es cuestión de buscar en la red).
Es mas incómodo usar "sudo" delante de cada comando, pero mas seguro que estar en modo "su" que podemos romper algo.
Yo he trabajado todo el tiempo con "sudo", en lugar de "su" (a gustos)

Antes que nada, decir que hay varios editores para trabajar, cada uno con su peculiaridad.
Lo mas cómodo es trabajar con uno gráfico, pero si no podemos, usaremos los de comandos, como el "nano" o el "vi".
Pero mientras podamos usaremos uno como el "leafpad" que viene en la mayoría de las rapsberry con raspbian.
Pero sea cual sea, SIEMPRE como "admin", o sea, con "sudo" delante.
Algunos editores gráficos típicos son: KDE, GPEDIT, LEAFPAD
El editor "vi" será necesario solo en caso de problemas con el "script-cortafuegos.sh" del que hablaré mas adelante.
El "nano" en caso de no tener uno gráfico (raro, siempre hay uno).
Para saber qué editor gráfico tenemos, vamos a los menús de ventanas, y buscamos "editor de textos" o algo parecido, lo ejecutamos, y vamos a "acerca de" para saber cuál es, o lo buscamos por la red. En mi caso, como ya he dicho, se llama "leafpad".

empezamos:
¿tenemos wifi autoreconocidos por nuestra rpi? podemos saltarnos este paso. (como el caso de los "Edimax EW-7811Un")

********************************************************************************************************************************
--------------------------------------
TODO ESTE EMBROLLO WIFI SE EVITA SI USAMOS PINCHOS RECONOCIDOS POR RPI A LA PRIMERA, COMO LOS "Edimax EW-7811Un".
--------------------------------------
Para saber si tenemos WIFI activo y reconocido, tecleamos "ip addr" (o "ifconfig") (en este caso no hace falta el "sudo", cuando sea necesario lo indico)
Veremos varios apartados que empiezan con un número y ":". Si tenemos adaptador wifi, veremos tres grupos, si no tenemos veremos dos.
algo parecido a esto (abreviado, para no liar):
1: lo: ....
  inet 127.0.0.1 ....
  ....
2: eth0: .....
  inet 192.....  <<<---- esta línea "solo" la vemos si está el cable de red rj45 conectado
  .....
3: wlan0: ..... <<<< esta y la siguiente son las que interesan
  inet 192..... <<<< solo la veremos si está detectado, sino, es que no lo reconoce linux
  .....
4: wlan1: .... idem al "3:", pero el segundo wifi

Si vemos un "inet 192." o algo parecido (el 192 depende de cada equipo, pero es el estándar) debajo de "wlan0" o "wlan1" vamos bien, todo funciona.
(no confundir con "inet6" que también aparece, tiene que ser SIN el "6", a pelo, "inet", que es la IPV4 de toda la vida)
Si no aparece "init 192." pero sí aparecen "wlan0" y "wlan1" , tenemos suerte, por que se reconocen los wifi, pero no están instalados.
Si no aparece "wlan0" ni "wlan1", lo tenemos "chungo", hay que instalar todo desde cero.
En caso de tener "wlan", podemos ir al siguiente paso.
Si no lo tenemos, hay que detectarlos. Aquí lo pasos varían mucho dependiendo de las distros (versiones linux), wifi usb, etc.
Lo normal es tratar de averiguar el tipo de pincho enchufado:
con "lsusb" vemos los dispositivos usb conectados. Ahí debemos ver nuestro wifi, pero aquí, no hay manual que valga, hay miles de dispositivos wifi diferentes, y cada uno se nombra de una manera. Es tener "ojo" y verlo entre la maraña de datos. Veremos algo así como "WLAN Adapter" y el modelo del chip, en mi caso un "RTL8188CUS" de "Realtek".
Si no somos capaces de averiguar el chip y modelo, yo poco puedo hacer.
Una forma de intentar verlo, es hacer "lsusb" SIN conectar el WIFI, luego, conectarlo, esperar un rato a que lo detecte, volver a dar a "lsusb" y comparar líneas para ver cuál de ellas es nueva, y ver si en esa línea pone el chip o fabricante al menos.
Sabiendo el chip que es, bajamos los drivers. Si tenemos el RJ45 conectado a la red, no es problema, sino, debemos bajarlos en PC y copiarlos por usb a la carpeta "home" y el resto, es cosa de cada uno (no puedo hacer un manual de linux, por que no acabo nunca).
En mi caso, el comando para bajar los drivers Realtek es "sudo apt-get install firmware-realtek" (fijaros en el "firmware-realtek", cada fabricante usa el suyo, eso es cuestión de tirar de "San Gugle" a ver cuál nos corresponde).
Una vez instalados, con "lsmod" podemos ver si se han instalado, deberíamos ver el chip de nuestro wifi, en mi caso vería un "rtl8188".
Si no lo ha detectado.... a buscarse la vida...

Algunos modelos comunes muy empleados y sus chips.
Broadcom BCM43142
Broadcom BCM43XX
Ralink RT28XX-RT539X
Ralink RT3290
Realtek RTL8723Be <<-- este el mio

En la página "http://elinux.org/RPi_USB_Wi-Fi_Adapters" hay una lista de pinchos wifi que funcionan (o no) en raspberry
-----------------------------------
fin de embrollo deteccion wifi
-----------------------------------
*****************************************************************************************************************************

-------------------------------------
SEGUIMOS CON PASOS SI YA TENEMOS WIFI
-------------------------------------
Vamos a editar el fichero "interfaces" que está en la ruta "/etc/network/" (como he comantado arriba, yo uso el modo gráfico, cada uno que use el que quiera, como el "nano", pero este es mas lioso, a ser todo con combinación de letras"
tecleamos "sudo leafpad /etc/network/interfaces" o "sudo nano /etc/network/interfaces"
Con el "leafpad" es mas simple, con el "nano" usaremos combinaciones tipo "control+x" para salir, "control+o" para guardar, etc.
En el "leafpad" podemos usar "copiar/pegar" muy útil para pegar el contenido de los ficheros que dejo adjuntos.
En este fichero pondremos el acceso a ambos wifi y sus claves.
Para no liar explicando, dejo el usado por mi (alterando claves y demas)

--------------------
EDITAR fichero "interfaces" (podeis hacer "copiar/pegar") (sin las líneas de asteriscos, claro)
--------------------
Ni que decir tiene, las claves del móvil y del audi y sus SSID (nombres de red) son de cada uno, os toca averiguarlo.
Y lo mismo con la IP del móvil (en mi caso 192.168.0.1), cada móvil lleva la suya.
Donde pone IPMOVIL pondremos la de nuestro teléfono, son dos sitios en las últimas líneas
para los que no lo entiendan:
en el texto DEBEMOS cambiar IPMOVIL, SSIDAUDI, SSIDMOVIL, CLAVEAUDI, y CLAVEMOVIL por NUESTROS datos
los del AUDI, hasta no completar los pasos del coche, no sabemos cuál es.
Para completar los pasos, podemos inventarnos las del Audi si no las sabemos, y luego, una vez en el Audi, poner las inventadas
(Yo por ejemplo, puse AUDIPEPINO como SSID y 12345678 como clave, y luego cuando hice lo del coche, puse las mismas.)
*************************************************************************************
            auto lo
            iface lo inet loopback
            
            # mantenemos la red cableada
            auto eth0

            # MMI
            auto wlan0
            iface wlan0 inet static
            address 192.168.1.254
            netmask 255.255.255.0
            network 192.168.1.0
            broadcast 192.168.1.255
            wpa-ssid SSIDAUDI
            wpa-psk CLAVEAUDI

            # movil
            auto wlan1
            iface wlan1 inet dhcp
            wpa-ssid SSIDMOVIL
            wpa-psk CLAVEMOVIL

            # gateway por defecto
            # redirigimos a las del telefono móvil IPMOVIL
            # y anulamos la 192.168.1.1
            post-up route add default gw IPMOVIL
            post up route del default gw 192.168.1.1
            pre-down route del default gw IPMOVIL
            pre-down route add default gw 192.168.1.1
***********************************************************************************

-----------------------------
EDITAR fichero "wpa_supplicant.conf" (podeis hacer "copiar/pegar") (sin las líneas de asteriscos, claro)
-----------------------------
Editamos el fichero de valos WPA:
"sudo leafpad  /etc/wpa_supplicant/wpa_supplicant.conf"
(lo del "country" es opcional, es para que ajuste los canales a los 13 de españa (¿o eran 11?, da igual...)
Todo esta, asumiendo que el móvil emite en WPA, si es WEP dudo que funcione, ademas, como sabéis, no se recomienda ya.
*************************************************************************
            country=SP
            ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
            update_config=1

            network={
            ssid="SSIDOMOVIL"
            psk="CLAVEMOVIL"
            proto=RSN
            key_mgmt=WPA-PSK
            pairwise=CCMP
            auth_alg=OPEN
            }

            network={
            ssid="SSIDAUDI"
            psk="CLAVEAUDI"
            proto=RSN
            key_mgmt=WPA-PSK
            pairwise=CCMP
            auth_alg=OPEN
            }
*************************************************************************

------------------------
segundo paso, redirecciones
------------------------
Hacemos este comando:
"sudo echo 1 > /proc/sys/net/ipv4/ip_forward"  (nota el guión bajo de "ip_forward")
Si no nos da error "bash .... permiso denegado", podemos ver si está activo con
"sudo cat /proc/sys/net/ipv4/ip_forward"
y deberíamos ver un "1" solo.
Si vemos un "0", no ha funcionado (por lo de "permiso denegado"), en este caso, tratar de hacerlo con:
"sudo leafpad /proc/sys/net/ipv4/ip_forward"
y cambiamos "a mano" el "0" por un "1", y debería valer. (verificamos con el comando "cat" como antes)
Si tampoco nos deja, la cosa se complica, y esto me lo salto (es un lío de explicar, copiar, quitar permisos, editar, dar permisos y volver a copiar sobreescribiendo)

-------------------------
tercer paso, editar fichero "sysctl.conf"
--------------------------
"sudo leafpad /etc/sysctl.conf" y donde pone "#net.ipv4.ip-forward = 1" quitar el "#" y guardar
(buscar entre la maraña de líneas que sale, está por la mitad mas o menos)

REINICIAMOS EN ESTE PUNTO (por ejemplo con "sudo reboot")

---------------------------
cuarto paso, fichero "fireguol"
---------------------------
Toca ejecutar el "firewall". Lo ideal es copiar el archivo que dejo adjunto que ya está preparado.
Es MUY, pero que MUY importante, que si haces tú a "mano" el fichero, por que no puedes copiar/pegar, que lo hagas sí o sí con el "vi".
Si lo vas a crear con el "vi", puedes "flipar" con el cristo que es. El comando "vi" es la mayor m**** que ha ..... (me callo).
Es muy arcáico , usa comandos que dan la risa de usar, como "x" para borrar un carácter, o "dd" para borrar un línea entera.
Hay un truco muy simple, y es crear el archivo con el "leafpad" o con "nano" (o incluso en PC) y luego ir a "vi" y quitar todos los "^M" que salen (según versiones linux, sale en color azul chillón).
Para usar el "vi", hay manuales en internet, pero a modo rápido, vamos al caracter a borrar, y pulsamos "x", y se borra.
Cuando tenemos el fichero bien escrito, guardamos con ":w" y salimos con ":q".
Pero lo ideal es tratar de no usar "vi" por que podemos perder la paciencia con él.
Sea el método que sea, debemos tener un fichero llamado "script-cortafuegos.sh" (el nombre no es importante, solo importa la extensión, que sea ".sh"
El contenido debe ser el siguiente (o parecido): (sin las líneas de asteriscos)
********************************************************
            #!/bin/bash
            ### BEGIN INIT INFO
            # Provides:          no importa
            # Required-Start:    $syslog
            # Required-Stop:     $syslog
            # Default-Start:     2 3 4 5
            # Default-Stop:      0 1 6
            # Short-Description: la que sea
            # Description:
            #
            ### END INIT INFO
            # Script para hacer permanentes las reglas del cortafuegos en cada arranque
            iptables -t nat -A POSTROUTING -o wlan1 -j MASQUERADE
********************************************************

Como podéis comprobar, es igual al citado en este hilo, pero con las líneas añadidas desde la segunda hasta la de #script.
Esto es así, por que según qué versión de linux empleemos, dará un error de "missing LSB tags"
Si seguimos viendo ese error, ahí me pierdo, sería tirar de internet para ver qué mas puede faltar.
En mi caso, y en mi distro linux (una debian) es necesaria esa cabecera.
(importante, recuerda que si haces copiar pegar de mi texto de script de PC a LINUX, luego, con el "vi" debes quitar los "^M" que salen.)
Ahora, los pasos son como se dice en este hilo.
Copiar el archivo en la ruta "/etc/init.d" (el "script-cortafuegos.sh"), o bien desde los menús de linux al estilo copiar/pegar o bien, desde la consola de comandos, si sabemos dónde lo hemos dejado.

Suponiendo que lo hemos copiado de un PC o una llave USB a la carpeta "Download" del "home" (como la de "mis documentos" del "guindous"), desde la consola haremos:
"sudo cp /home/pi/Downloads/script-cortafuegos.sh /etc/init.d/script-cortafuegos.sh"
(ojo a la "D" mayúscula de "Downloads", que el linux es sensible)
Damos permisos de ejecución:
"sudo chmod 755 /etc/init.d/script-cortafuegos.sh"
y lo ejecutamos:
"sudo update-rc.d script-cortafuegos.sh defaults"
"sudo sh /etc/init.d/script-cortafuegos.sh"

para ver que está activo:
"sudo iptables -t nat -L -n" (ojo a las mayúscula-minúsculas)
y deberíamos ver una línea "Chain MASQUERADE" por algún lado

*********************************
Se acabó, esto es todo en la RPI. Al reiniciar ("sudo reboot" o con los menús) y hacer:
"ip addr" en una ventana de comandos, deberíamos ver las dos redes wifi (me remito al primer punto, el de comprobación de wifi).

------------------------------------------
Alternativo, copiado de alguna de las 29 páginas del hilo, como algo OPCIONAL (YO NO LO HE HECHO Y FUNCIONA SIN ELLO):
No es mas que un caché para acelerar accesos y evitar descargas repetidas. Funciona sin hacerlo, pero gastas mas datos que si lo haces.
Yo no lo hice, por que ya lo tenía en el coche instalado, y no tenía un teclado a mano para escribir en la RPI.

 para no usar un DNS externo y además crear una cache DNS en la propia Raspberry, instalé la aplicación DNSMASQ de la siguiente manera, ejecutando los comandos como root o con sudo y teniendo en cuenta que debe estar conectado a internet, por ejemplo con el móvil por wlan1:

apt-get update
apt-get install dnsmasq
Editar el fichero /etc/dnsmasq.conf y poner:
[Línea 69 aproximadamente]
Descomentar #interface y poner:
interface = wlan0
[Linea 143 aproximadamente]
poner:
dhcp-range = wlan0,192.168.1.50,192.168.1.100,8h
dhcp-options = 3, 192.168.1.254
------------------------------------------------------------------

###########################################################################
                          pasos en el audi
###########################################################################
Están bien documentados en el PDF de la página 20:
http://www.audisport-iberica.com/foro/topic/326261-transformar-mmi-3g-en-3g-con-google/?do=findComment&comment=4453588
A partir de la hoja 9

solo unas notas mias, para aclarar aún mas:
El script de activación del audi, debemos copiarlo "extraído" del archivo, y en el raíz de la SD, sin la carpeta principal.
Debe quedar así cuando lo abrimos en un PC: (o sea, copiamos desde dentro de la carpeta "script")

read(dir)
screens(dir)
utils(dir)
copie_scr.sh
run.sh

Esperamos como uns tres minutos una vez iniciado el MMI. Aunque pensemos que la música suena que ya ha terminado de arrancar, no es cierto, hay servicios que aún no se han cargado (se ve sobre todo en el menu "car", que está todo en "gris" hasta que acaba de cargar)

Sacar TODAS las SD, y meter sola esta del script.

se ejecuta, salimos y esperamos como poco otros 2 minutos a que se aplique el parche, a pesar de que nos dice que ya está, en
realidad, no esta, es mejor esperar antes de reiniciar, por que no le da tiempo a terminar y hay que volver a hacer todo.

tras aplicar el script y esperar los dos minutos, sacamos la sd y veremos una carpeta BACKUP con la copia del script interno original, si queremos guardar la copia antes de aplicar el parche.

Reiniciamos el MMI con el reset ese que da pánico, el de lso tres botones diagonal que hay en la página 6:
http://www.audisport-iberica.com/foro/topic/326261-transformar-mmi-3g-en-3g-con-google/?do=findComment&comment=4310292

Si todo ha ido bien (eso espero, tras este tostón), veremos un acceso WIFI y el nuevo icono "Audi Connect" en el menú del coche.
Y en el navegadore veremos la opción "Google Earth"

Como dato curioso (y lógico), mientras conducimos se va almacenando en nuesto HD las imágenes del Earth y la próxima vez que conduzcamos, no es necesario tener encedido el invento de la RPI, por que ya quedan almacenados.
Solo si vamos por una zona nueva (o un nivel de "zoom" diferentes) necesitaremos acceso "online"

Si sabes algo de linux no es problema, si no sabes nada o no te manejas bien con él, olvídalo. La peor parte es el linux.

A grandes rasgos, en linux (raspberry) en ventana de comandos debes editar el fichero "interfaces" y añadir las líneas que modifican ambos pinchos wifi para que uno conecte al mmi y otro al móvil (meter claves, ssid, ip), modificar un par de ficheros de sistema, crear (o copiar uno creado) el script cortafuegos, y opcionalmente, instalar drivers de los pinchos wifi en caso de no ser reconocidos por linux. Se me olvida, que en tu móvil debes conocer su ip para escribirla en "interfaces"

Todo ese proceso, si no te manejas bien escribiendo en linux puede ser un infierno. Hay cosas, como lo de activar el redireccionamiento de la ip, que si no te sale a la primera, se convierte en un infierno de "copia/pega/cambia-permisos/edita/guarda/vuelve-a-cambiar-permisos/vuelve-copia/pega/reinicia, bla, bla" todo ese embrollo solo para poner "1" en una variable, como suena, para poner un simple "1", si no te manejas bien en linux, se vuelve un quebradero de cabeza.

Incluso con un tutorial, hay muchas cosas que son mas de conocer el sistema linux que de seguir unos pasos. Como el caso de crear el script cortafuegos, que el genérico de este hilo a mi no me funcionaba, y tuve que investigar por la red en busca de una solución. Probé dos o tres antes de dar con la que "a mi" me funcionaba.

O el tema de los drivers, que yo lo he realizado con una RPI3 que lleva wifi integrado, con lo que me ahorro un dispositivo a detectar, pero el segundo, me volví loco buscando drivers genéricos para él, y no sé ni cuando lo logré, solo sé que probé varios y en una de esas pruebas, lo detectó.

Podría intentar un manual genérico, con pasos mas detallados, pero implica empezar de cero, eso significa borrar todo, dejar de fábrica, y empezar otra vez, pero si me sale algo mal, me quedo sin el invento que me ha costado una mañana entera de intentos.

En el caso de linux no es difícil, me guardo la SD y creo una nueva, pero en el audi ya no hay marcha atrás, y los pasos en él no puedo reproducirlos ya.

Quizás lo intente, a ver qué consigo, no prometo nada.