Sobre redes y rpi

[Segata Sanshiro]

Hola famiguitos. Estoy intentando configurar el móvil para usarlo como mando para el XBMC de la raspberry pi, pero de momento no hay manera. Creo que el problema es por cómo tengo configurada la red, y seguramente se solucionaría comprando un adaptador wifi, pero a ver si puedo arreglarlo con lo que tengo ahora y me ahorro esos eurillos (y posibles problemas de consumo).

A mi "router wifi" (llamémoslo "router principal") está conectado por cable de red mi PC principal. Están en la subred 192.168.1.0/24

Por otro lado, tengo un antiguo router Comtrend con un firmware alternativo. Por un lado se conecta a la red inalámbrica de mi router principal, y por otro a la subred 192.168.2.0/24. En esa subred están, conectados por cable de red, el mencionado router Comtrend y la raspberry pi. Es decir, uso el Comtrend como si fuera un "pincho wifi", solo que se conecta a la raspberry por ethernet en lugar de USB.

El caso es que desde mi móvil, conectado por wifi a la subred 192.168.1.0/24 de mi router principal, no puedo acceder a ninguna dirección de la otra subred, en la que se encuentra, entre otras cosas, el servidor web de la rpi que permite controlar el XBMC de manera remota. ¿Hay alguna manera de poder acceder desde mi móvil a la raspberry, o voy pensando en comprarme un mando a distancia USB o pincho wifi tradicional?

[JoJo_ReloadeD]

Intenta poner el router comtrend transparente, si no puedes, tienes que hacer nat en el puerto 80 (el default para el raspbmc) hacia la ip 192.168.2.x que tenga la pi. Luego desde el movil le dices que el raspbmc esta en la ip 192.168.1.x que sea el router comtrend.

[eToiAqui]

Es decir, tienes el comtrend de punto de acceso inalámbrico, pero generas una subred entera...

¿No tiene la opción de usar la misma subred? Es decir, un "wireless bridge", le pones una ip llamada 192.168.1.20 al comtrend y 1.21 a la rpi y se puede acceder a todo desde la subred principal.

Algún problema con el cortafuegos de ese router hace que no sea transparente... a mí con alguno me ha pasado, y si el contenido es fiable, lo he acabado arreglando así.

[Dullyboy]

Yo me acabo de enterar el otro día de que es HDMI-CEC buscando precisamente la forma de manejar el XBMC de la raspberry. Si tienes esa misma cándida inocencia en el tema como yo es la mejor solución si se puede usar (y sino puedes ignorar este mensaje :D).

[Segata Sanshiro]

Estoy intentando configurar la NAT, tengo un portátil conectado al router Comtrend.

Al router Comtrend puedo acceder por el cable de red, escribiendo 192.168.2.1, como por wifi a través del otro router, escribiendo 192.168.1.250. Antes no podía acceder por wifi, para ello tuve que añadir una entrada en la pestaña del firewall, sección "Zones - > Forwardings" (la de abajo, antes estaba todo a reject y la puse a accept)

35421

Ahora ya podía acceder al router tanto por cable como por wifi. Además, podía acceder al control remoto de XBMC vía web por cable, mediante la dirección 192.168.2.218:8080 (puse ese puerto aposta para no liarme). Luego me puse a configurar la NAT para redirigir el tráfico de 192.168.1.250:8080 a la otra dirección que acabo de poner, pero no funciona. Añadí esta entrada en "Redirections":

35424

Por si acaso, también añadí una entrada en la sección rules, pero no tuvo efecto:

35427

Cuando intento entrar mediante 192.168.1.250:8080 se queda un rato esperando y al final me dice que no se pudo entrar en la página. ¿Alguna idea de qué más puede estar fallando? Muchas gracias a los dos. (Dullyboy: gracias por la idea pero no tengo HDMI).

[Trenz]

A ver, si no me equivoco, el router Comtrend tiene su interfaz LAN con la dirección 192.168.1.250, y el interfaz WAN, que es al que está conectado la RPI, con la dirección 192.168.2.1. En el Comtrend, en principio, no habría que tocar nada más. Es como si estuviera conectado a Internet, solo que Internet es la RPI. Todo el tráfico que le llegue por la LAN dirigido a la red 192.168.2.0/24 ya sabe que tiene que enviarlo al puerto WAN, y lo normal es que haga NAT automáticamente. El problema es el siguiente (no digo que no pueda haber otros): desde un equipo de la red 192.168.1 quieres conectarte a otro de la red 192.168.2 (la RPI, el único que hay). Los paquetes dirigidos a dicha red llegan al router principal, el router de la red 192.168.1, y éste no sabe a dónde enviarlos, porque no sabe cuál es la ruta a la red 192.168.2. En ese caso tendría que enviarlos por su ruta por defecto, que es la de su WAN (por donde probablemente accedas a Internet), y no lo va a hacer porque son direcciones privadas. En cualquier caso, no sería la ruta correcta. Lo que hay que hacer es configurar una ruta estática en el router principal para decirle que la pasarela (el gateway) a través de la cual se llega a la red 192.68.2 es el equipo 192.168.1.250, el router Comtrend.

Otra solución es lo que estabas haciendo: redirigir un puerto del router Comtrend. Lo normal es redirigir puertos del interfaz WAN a la LAN, pero en este caso sería al revés, por eso no sé si va a funcionar. Por lo que se ve en la captura que has puesto, entinedo que tendrías que marcar como "source zone" la LAN, no la WAN.

[Segata Sanshiro]

Gracias por el comentario Trenz. El Comtrend tiene la interfaz WAN con la IP 192.168.1.250 y la LAN como 192.168.2.1, no al revés. En la subred 192.168.1.0/24 están mi router principal (que es el que tiene conexión física con Internet), mi PC (que no tiene vela en este entierro), mi móvil (el mando) y la interfaz wifi del Comtrend. En la subred 192.168.2.0/24 está el interfaz LAN del Comtrend y la rpi.

Lo suyo sería que el Comtrend sacara por su interfaz ethernet aquéllos paquetes TCP y UDP que le lleguen por la interfaz wifi (a la cual accedo sin problemas desde la subred .1) con el puerto 8080, pero por alguna razón o eso no ocurre, o no se están enrutando bien los paquetes en sentido contrario, lo cual me extrañaría.

[Trenz]

Ok. Entonces, si no me equivoco, estás asociando la interfaz WAN al módulo wifi del router. Eso es algo que puedes hacer gracias al firmware especial que lleva, porque se sale fuera de lo que sería una configuración normal. Estás haciendo algo así (http://wiki.openwrt.org/doc/howto/clientmode#masqueraded):

http://wiki.openwrt.org/_media/doc/howto/802.11-routed-masq.png

En ese caso, tal como dice ahí, los equipos conectados a la LAN del router no serían visibles desde la red wifi. Pero supongo que con la redirección de puertos debería funcionar. No sé qué fallará en tu caso.

Puede que sea menos problemático si en lugar de la redirección de puertos añades una ruta a la subred 2 en el router principal: es el modo "routed" que menciona ahí. Es como lo que comentaba en el post anterior, aunque yo estaba pensando en un escenario distinto, en el que puede que no fuese muy correcto hacerlo.

[Segata Sanshiro]

He añadido la ruta que comentas al router principal:

35430

Gracias a eso ahora puedo acceder desde el móvil al router Comtrend escribiendo 192.168.2.1.

Como se ve en la siguiente imagen, en teoría el router conoce las rutas a la raspberry, al router principal, y a mi móvil, que son los tres dispositivos que aparecen en la tabla ARP:

35431

Aun así sigo sin poder acceder a la raspberry por el móvil, aunque ahora sé algo más: si desde el móvil pongo 192.168.2.218:8080, la luz de red de la rpi parpadea, y luego vuelve a hacerlo unas 2 ó 3 veces, como reenviando la respuesta, pero al navegador de mi móvil no llega nada y la cosa acaba en timeout. Si accedo a algún otro puerto al azar (como :1), la raspberry cierra la conexión enseguida y aparece el aviso en el navegador de inmediato. ¿Alguna idea más?

[Trenz]

Me temo que no :( Se me hace un poco raro que fallen las conexiones con la RPI y la vez puedas conectarte con el router a través de su dirección de la red 2. También, lo lógico sería que las conexiones a otros puertos de la RPI fallasen del mismo modo que al puerto de servicio, con un time out, si es que se están perdiendo las respuestas.

Las conexiones a la red 2 deberían ir a través del router principal, y dado que es una ruta dentro de la misma subred (eso es lo atípico), supongo que para que funcionase, el router principal debería enmascararlas. Sería interesante que en un ordenador de la red 1 probaras a añadir la ruta a la red 2 y conectarte a la RPI. Eso debería funcionar y sería lo correcto, en lugar de tener que añadirla en el router principal. Claro, el problema es que probablemente en el móvil no tengas opción para añadir rutas, más allá de poner la pasarela por defecto. Otra posibilidad sería que el router principal comunicara esa ruta mediante DHCP a los equipos de la red 1 (no creo). También, en un equipo de la red uno (y sin añadir en él la ruta a la red 2) se puede utilizar un sniffer como Wireshark y tratar de ver cuál es la diferencia entre lo que ocurre cuando tratas de conectarte a la RPI o al router Comtrend. Pero bueno, igual es liarse demasiado, y no garantiza que se vaya a descubrir cuál el problema.

Otra posibilidad, la que te habían mencionado otros foreros, es que mires a ver si el router y el firmware que lleva tiene algún modo tipo wireless bridge que te permita poner la RPI en la red 1.

[eToiAqui]

¿Qué comtrend es y con qué firm lo tienes?

[Segata Sanshiro]

Gracias de nuevo trenz. Realmente es extraño, el problema se escapa a mis conocimientos de largo xD Tanto lo de crear la ruta en el router principal como lo de tocar la NAT del otro router tendría lógica que hubiera funcionado, pero nop!

Tengo un Comtrend 536+ (el que daba jazztel) con OpenWRT backfire (que es la versión más moderna que funciona bien en este router).

[Trenz]

Por lo que pone aquí (http://wiki.openwrt.org/doc/howto/clientmode#bridged.and.routed.client.modes), el modo "bridged client" sólo está disponible por defecto para la versión brcm-2.4 del firmware, mientras que la de tu Comtrend es la bcm63xx. Puede que se pueda activar o instalar algún parche, pero no tengo ni idea sobre el tema (tampoco he mirado mucho).

La información que dan sobre la configuración de los distintos modos cliente es muy escueta. Y son instrucciones para hacerlo a través de la línea de comandos, que no sé si la correspondencia con la configuración a través del interfaz gráfico es clara.

En el modo "routed client", además de añadir la ruta en el router principal, hay que cambiar la configuración del secundario para deshabilitar el NAT (masquerading). No sé si te fijaste en ello (http://wiki.openwrt.org/doc/recipes/routedclient#step.1change.the.firewall.configurati on). Haciendo la configuración a través del interfaz gráfico, supongo que llega con desmarcar la casilla Masquerading que se ve en la primera imagen que pusiste en uno de los post anteriores. De hecho, creo que lo mejor sería deshabilitar el firewall completamente. Puede hacerse por línea de comandos (info (http://wiki.openwrt.org/doc/uci/firewall#firewall.management)): "/etc/init.d/firewall stop". No sé si en el interfaz gráfico hay alguna opción para ello. En fin, no se me ocurre nada más.

[Segata Sanshiro]

Ya lo tenía desactivado, y aún así nada :( En fin, muchas gracias a todos, aunque creo que va tocando comprar pincho wifi xD

[Trenz]

El modo routed client es muy simple. Lo único necesario es que estén bien configurados los interfaces y activado el reenvío, todo lo demás sobra. Así que si está fallando el Comtrend, que es lo que parece, no tengo ni idea de dónde puede estar el fallo. En fin, esperemos que tengas más suerte con el pincho wifi.