¿Se puede mirar desde mi raspberry si hay conflictos de IP con otro dispositivo?

[chema]

hola
me conecto en remoto a mi raspberry y veo que de vez en cuando 'se va' el wifi de la raspberry y me quedo sin conexión. Esto me pasa desde que tengo instalada una cámara ip que cada vez que se conecta provoca que se vaya el wifi de mi raspberry (aparentemente). La cámara también se conecta vía wifi al router.

[lmarmisa]

Si la cámara IP y la RPI utilizan clientes DHCP para negociar automáticamente con el router sus direcciones IP en la LAN, no debería haber ningún conflicto.

Puede ser que tu problema tenga una causa diferente. Si la cámara IP es de alta definición, es posible que las prestaciones de la red inalámbrica se degraden radicalmente porque se ocupa toda la velocidad real disponible de la wifi en intentar transmitir el vídeo HD. Las prestaciones de la wifi pueden ser malísimas en esas circunstancias, incluso usando estándares de wifi modernos como 802.11 n.

Personalmente he padecido un problema de este estilo con los canales de TV HD que ofrece mi proveedor de Internet. Mi router principal está lejos del salón y la señal de wifi flaquea allí un poco por la distancia. Así que añadí un segundo punto de acceso wIfi + switch en el salón que se conecta por cable ethernet con el router principal. Como el deco estaba también en el salón, los canales de TV sintonizados con el deco (que usan multicast) se enviaban también a la wifi y el resultado era realmente penoso con 802.11 n. Un canal HD de 8-12 Mbps tumbaba la wifi del salón. Si se dejaba de sintonizar el canal HD con el deco, la wifi del salón volvía a funcionar perfectamente. Afortunadamente el AP permite añadir filtros de modo que los canales multicast de TV no se envien a la wifi y la degeneración de prestaciones cesó al activar dichos filtros.

Intenta conectar la cámara IP mediante Ethernet. Si, en este caso, la wifi funciona correctamente, el problema es que la wifi no es capaz de transmitir el video de la cámara con la calidad HD seleccionada. Si realmente te ves obligado a conectar mediante wifi la cámara IP, tal vez debas seleccionar una calidad de imagen menor para que la wifi no se degenere. Te recomiendo que hagas ese tipo de pruebas.

[chema]

Puede ser que tu problema tenga una causa diferente. Si la cámara IP es de alta definición, es posible que las prestaciones de la red inalámbrica se degraden radicalmente porque se ocupa toda la velocidad real disponible de la wifi en intentar transmitir el vídeo HD. Las prestaciones de la wifi pueden ser malísimas en esas circunstancias, incluso usando estándares de wifi modernos como 802.11 n.

Hola,
sí, mi cámara es HD quizás ese sea el problema de fondo, pero al principio estaba conectada vía cable ethernet y el wifi de la raspberry fallaba igualmente. Lo curioso es que los problemas con el wifi de la raspberry comenzaron al día siguiente de instalar la cámara; puede ser coincidencia pero no sé ya qué pensar... en otros foros me han hablado de la tarjeta SD que puede estar empezando a fallar (tengo la raspberry 24/7) ¿puede influir la calidad de la SD en la gestión del wifi?

gracias.

[lmarmisa]

Hola,
sí, mi cámara es HD quizás ese sea el problema de fondo, pero al principio estaba conectada vía cable ethernet y el wifi de la raspberry fallaba igualmente. Lo curioso es que los problemas con el wifi de la raspberry comenzaron al día siguiente de instalar la cámara; puede ser coincidencia pero no sé ya qué pensar... en otros foros me han hablado de la tarjeta SD que puede estar empezando a fallar (tengo la raspberry 24/7) ¿puede influir la calidad de la SD en la gestión del wifi?

gracias.

Pufff. Veo muchas incertidumbres en tu planteamiento. Tendrás que intentar acotar el problema para llegar a un diagnóstico, paso previo a la solución del problema.

El único hecho probado que ocurre es que hay desconexiones de la wifi en la RPi: ."de vez en cuando 'se va' el wifi de la raspberry y me quedo sin conexión". No indicas si esa desconexión es permanente o se recupera de algún modo pasado un tiempo.

El comando iwconfig puede ser una buena herramienta para hacer un primer diagnóstico de la calidad de la conexión wifi de tu RPi. Aquí tienes un ejemplo con una señal buena wifi recibida en la RPi desde el router (Link Quality 69/70; Signal level -41 dBm; Bit Rate 150 Mb/s):

Code: Select all

pi@rpi:~ $ iwconfig wlan0 
wlan0     IEEE 802.11  ESSID:"MI_WIFI"  
          Mode:Managed  Frequency:2.452 GHz  Access Point: 4F:53:0C:BA:7A:07   
          Bit Rate=150 Mb/s   Tx-Power=31 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=69/70  Signal level=-41 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:558  Invalid misc:0   Missed beacon:0

pi@rpi:~ $ 

Te recomiendo apagar la cámara IP, abrir un terminal, teclear el comando y copiar el resultado aquí, para evaluar qué señal de wifi llega a la RPi.

Puedes repetir cuantas veces quieras el comando fácilmente: simplemente tecleas flecha para arriba, verás que se recupera el comando y enter.

Una vez que domines este comando, sería muy conveniente ver si la cámara IP influye o no en los cortes de la wifi.

¿Ha sucedido alguna vez con la cámara apagada?. ¿Cuánto tarda en producirse un corte: segundos, minutos, horas, días?. ¿Se recupera el corte por si solo?.

Dices que te conectas "en remoto" a la RPi. Entiendo que la conexión la haces mediante ssh/putty o vnc y que no tienes conectado a la RPi pantalla ni teclado ni ratón (headless). Eso limita los comandos que podemos ver en la RPi en los momentos de la desconexión.

Otra ayuda la puede proporcionar el router. ¿Tiene algún menú que muestre los dispositivos conectados a la LAN en cada momento?. ¿Desaparece de la lista del router la RPi cuando está "desconectada"?.

Y una cosa más muy importante: confirma si usas una configuración de red automática (DHCP) para la RPi y la cámara.

De momento lo dejo ahí a la espera de que me des más información.

[chema]

El único hecho probado que ocurre es que hay desconexiones de la wifi en la RPi: ."de vez en cuando 'se va' el wifi de la raspberry y me quedo sin conexión". No indicas si esa desconexión es permanente o se recupera de algún modo pasado un tiempo.

la desconexión no es permanente. Vuelve por sí misma al cabo de un tiempo que pueden ser varios minutos o varias horas.

El comando iwconfig puede ser una buena herramienta para hacer un primer diagnóstico de la calidad de la conexión wifi de tu RPi. Te recomiendo apagar la cámara IP, abrir un terminal, teclear el comando y copiar el resultado aquí, para evaluar qué señal de wifi llega a la RPi.

wlan0 IEEE 802.11 ESSID:" XXXX"
Mode:Managed Frequency:2.412 GHz Access Point: XX:XX:XX
Bit Rate=65 Mb/s Tx-Power=31 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=70/70 Signal level=-19 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

¿Ha sucedido alguna vez con la cámara apagada?. ¿Cuánto tarda en producirse un corte: segundos, minutos, horas, días?. ¿Se recupera el corte por si solo?.

Siempre ha sucedido con la cámara activa. La tengo preparada para que se encienda y recoja una imagen si detecta algún movimiento.

Dices que te conectas "en remoto" a la RPi. Entiendo que la conexión la haces mediante ssh/putty o vnc y que no tienes conectado a la RPi pantalla ni teclado ni ratón (headless). Eso limita los comandos que podemos ver en la RPi en los momentos de la desconexión.

Correcto

Otra ayuda la puede proporcionar el router. ¿Tiene algún menú que muestre los dispositivos conectados a la LAN en cada momento?. ¿Desaparece de la lista del router la RPi cuando está "desconectada"?.

Sí, tiene un menú donde muestra todos los nodos de la red, pero no desaparece del router la Raspberry cuando se queda sin wifi

Y una cosa más muy importante: confirma si usas una configuración de red automática (DHCP) para la RPi y la cámara.

Por supuesto, uso DHCP y no tengo ninguna IP configurada como estática.

[lmarmisa]

Los resultados del comando iwconfig parecen absolutamente correctos. Entiendo que la RPi debe estar situada a muy poquita distancia del router, ya que el nivel de la señal recibida es muy fuerte (-19 dBm). Eso descarta el típico caso de cobertura crítica de la señal wifi situada en el límite de la detección. La cobertura wifi es, por tanto, excelente.

Dada la corta distancia entre RPi y router, te haré la siguiente pregunta: ¿puedes conectar con cable ethernet la RPi a algún puerto vacante del router aunque sea de modo temporal?. No hay ningún problema al conectar a la vez la RPi mediante ethernet y wifi. No tienes que cambiar nada de la configuración. Simplemente dispondrás de dos direcciones IP locales y el tráfico por defecto se encaminará por ethernet ya que en el enrutamiento se le asigna una métrica más baja. Los comandos ifconfig e ip route pueden serte de utilidad para ver los detalles de este escenario de conexión doble de la RPi:

Code: Select all

pi@rpi:~ $ ifconfig 
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.37.58  netmask 255.255.255.0  broadcast 192.168.37.255
        inet6 fe80::a96:4f2e:4e5c:c5c1  prefixlen 64  scopeid 0x20<link>
        ether b8:27:ef:3a:de:1b  txqueuelen 1000  (Ethernet)
        RX packets 4098279  bytes 3098868541 (2.8 GiB)
        RX errors 0  dropped 573  overruns 0  frame 0
        TX packets 2961496  bytes 1647736264 (1.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 324  bytes 75452 (73.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 324  bytes 75452 (73.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.37.57  netmask 255.255.255.0  broadcast 192.168.37.255
        inet6 fe80::2104:cfde:fff6:79ce  prefixlen 64  scopeid 0x20<link>
        ether b8:27:e0:9f:8b:4e  txqueuelen 1000  (Ethernet)
        RX packets 187528  bytes 12031757 (11.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 42304  bytes 6236172 (5.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@rpi:~ $ ip route
default via 192.168.37.1 dev eth0 src 192.168.37.58 metric 202 
default via 192.168.37.1 dev wlan0 src 192.168.37.57 metric 500 
192.168.37.0/24 dev eth0 proto kernel scope link src 192.168.37.58 metric 202 
192.168.37.0/24 dev wlan0 proto kernel scope link src 192.168.37.57 metric 500 
pi@rpi:~ $ 

En el ejemplo que te acompaño puedes ver que la métrica asociada a eth0 es 202 frente a 500 de la correspondiente a wlan0. Eso implica que el tráfico por defecto se tramitará por ethernet. Cuando tengas puesto el cable ethernet, usa la IP de eth0 para conectarte a la RPi desde putty/ssh o vnc.

Si puedes conectar el cable ethernet, lo más probable es que sigas teniendo acceso a la RPi cuando se produzcan los cortes de la wifi. Así tendrías más facilidad para obtener información de la RPI en esas situaciones raras y diagnosticar mejor el problema.

No obstante, es posible preparar un shell script que se ejecute en la RPi en background y que vaya haciendo un log de comandos de interés del tipo iwconfig/ifconfig que permita analizar con posterioridad qué ha pasado con la wifi durante los cortes desde el punto de vista de la RPi. Puedo intentar preparar un script de este estilo aunque ahora no tengo tiempo de hacerlo.

Siempre ha sucedido con la cámara activa. La tengo preparada para que se encienda y recoja una imagen si detecta algún movimiento.

Este dato es interesante. Parece que la cámara de seguridad sólo debería enviar información cuando se ha detectado un movimiento y, en el resto del tiempo, no enviar nada. ¿Has detectado alguna relación causa efecto entre la detección de movimientos y los cortes de la wifi?. Y una pregunta un poco más técnica: ¿sabes si la cámara utiliza protocolos del tipo rtp que puede hacer uso a bajo nivel de mecanismos de multicast en la LAN?.

https://en.wikipedia.org/wiki/Real-time ... t_Protocol

[chema]

Dada la corta distancia entre RPi y router, te haré la siguiente pregunta: ¿puedes conectar con cable ethernet la RPi a algún puerto vacante del router aunque sea de modo temporal?.
Si puedes conectar el cable ethernet, lo más probable es que sigas teniendo acceso a la RPi cuando se produzcan los cortes de la wifi. Así tendrías más facilidad para obtener información de la RPI en esas situaciones raras y diagnosticar mejor el problema.

Bueno pues tras conectar por ethernet y estar unas cuantas horas funcionando de forma normal, de repente se ha vuelto a desconectar justo cuando iniciaba un escaneo con clamav (cosa que tb me pasaba con la wifi cuando trataba de escanear y por ello abrí en su día este otro hilo https://www.raspberrypi.org/forums/view ... 6&t=260686) tras recuperarse de esta nueva 'caída' tras varias horas offlinne, volvió a funcionar con normalidad hasta que volvió a perder la conexión con el router (seguía por ethernet); no sé, me está empezando a resultar todo muy raro.

Este dato es interesante. Parece que la cámara de seguridad sólo debería enviar información cuando se ha detectado un movimiento y, en el resto del tiempo, no enviar nada. ¿Has detectado alguna relación causa efecto entre la detección de movimientos y los cortes de la wifi?.

No sabría contestar, la mayoría de los avisos no los cotejo con la pérdida de señal de la Raspberry porque es casi imposible. Está situada en un lugar donde hay bastante actividad.

Y una pregunta un poco más técnica: ¿sabes si la cámara utiliza protocolos del tipo rtp que puede hacer uso a bajo nivel de mecanismos de multicast en la LAN?.

Ni idea, lo que sé es que la cámara genera una red wifi propia, al menos, lo veo cuando hago un barrido de SSID. Nunca me he conectado a esa red (no sé si es posible tampoco) y no sé para qué la genera porque en teoría su cometido es conectarse directamente al router vía wifi como un nodo más de la red.

[lmarmisa]

Bueno pues tras conectar por ethernet y estar unas cuantas horas funcionando de forma normal, de repente se ha vuelto a desconectar justo cuando iniciaba un escaneo con clamav (cosa que tb me pasaba con la wifi cuando trataba de escanear y por ello abrí en su día este otro hilo https://www.raspberrypi.org/forums/view ... 6&t=260686) tras recuperarse de esta nueva 'caída' tras varias horas offlinne, volvió a funcionar con normalidad hasta que volvió a perder la conexión con el router (seguía por ethernet); no sé, me está empezando a resultar todo muy raro.

Eso no cuadra. Todo es demasiado raro e inconexo.

Cortes de red que se recuperan ellos solos tras horas( ) y que afectan indistintamente a wifi y a ethernet ( ) en un sistema Linux.

Un antivirus que busca infecciones que afectan sólo a código de Windows para PC (CPUs de arquitectura Intel) extrañamente cuelga un ordenador RPi que ejecuta un sistema operativo absolutamente diferente a Windows como es Raspbian que además corre código de una CPU ARM. Para entendernos, Intel y ARM son como el agua y el aceite. ¿Para qué necesitas clamav en una RPi?. ¿Crees que Raspbian es inseguro a nivel de usuario doméstico y necesita un antivirus o incluso paquetes extra de seguridad?. ¿No será alguno de esos paquetes extra el origen de tus tribulaciones?.

Demasiado raro.

En cualquier caso, no veo que tenga sentido buscar el origen de esos problemas en una cámara IP externa.

[chema]

Bueno pues tras conectar por ethernet y estar unas cuantas horas funcionando de forma normal, de repente se ha vuelto a desconectar justo cuando iniciaba un escaneo con clamav (cosa que tb me pasaba con la wifi cuando trataba de escanear y por ello abrí en su día este otro hilo https://www.raspberrypi.org/forums/view ... 6&t=260686) tras recuperarse de esta nueva 'caída' tras varias horas offlinne, volvió a funcionar con normalidad hasta que volvió a perder la conexión con el router (seguía por ethernet); no sé, me está empezando a resultar todo muy raro.

Eso no cuadra. Todo es demasiado raro e inconexo.

Cortes de red que se recuperan ellos solos tras horas( ) y que afectan indistintamente a wifi y a ethernet ( ) en un sistema Linux.

Un antivirus que busca infecciones que afectan sólo a código de Windows para PC (CPUs de arquitectura Intel) extrañamente cuelga un ordenador RPi que ejecuta un sistema operativo absolutamente diferente a Windows como es Raspbian que además corre código de una CPU ARM. Para entendernos, Intel y ARM son como el agua y el aceite. ¿Para qué necesitas clamav en una RPi?. ¿Crees que Raspbian es inseguro a nivel de usuario doméstico y necesita un antivirus o incluso paquetes extra de seguridad?. ¿No será alguno de esos paquetes extra el origen de tus tribulaciones?.

Demasiado raro.

En cualquier caso, no veo que tenga sentido buscar el origen de esos problemas en una cámara IP externa.

Hola
según lo que expones ¿debo entender que GNU/Linux es invulnerable a ataques o virus? ¿debo eliminar medidas de seguridad de mi RPi como antivirus, anti rootkits...etc.. teniendo en cuenta que mi RPi sale a internet continuamente? quizás te he entendido mal, disculpa si es así. ¿qué medidas de seguridad serían convenientes?

Y respecto al tema de la desconexión no creo que se deba a ningún 'paquete' instalado y extraño. Habitualmente todo lo que instalo lo descargo de repos 'oficiales' es decir, SW no sospechoso (teóricamente ) me falta probar otra cosa: crear una imagen de mi SD y copiarla a otra SD nueva. No tiene por qué estar afectada en cuanto a ciclos lectura/escritura (sólo 6 meses con ella de uso ininterrumpido y por lo que sé mucha gente lleva hasta años con la misma SD sin problema) pero por probar...

[lmarmisa]

Hola
según lo que expones ¿debo entender que GNU/Linux es invulnerable a ataques o virus? ¿debo eliminar medidas de seguridad de mi RPi como antivirus, anti rootkits...etc.. teniendo en cuenta que mi RPi sale a internet continuamente? quizás te he entendido mal, disculpa si es así. ¿qué medidas de seguridad serían convenientes?

Y respecto al tema de la desconexión no creo que se deba a ningún 'paquete' instalado y extraño. Habitualmente todo lo que instalo lo descargo de repos 'oficiales' es decir, SW no sospechoso (teóricamente ) me falta probar otra cosa: crear una imagen de mi SD y copiarla a otra SD nueva. No tiene por qué estar afectada en cuanto a ciclos lectura/escritura (sólo 6 meses con ella de uso ininterrumpido y por lo que sé mucha gente lleva hasta años con la misma SD sin problema) pero por probar...

Linux es un sistema de muy alta seguridad si está bien administrado y mantenido. La propia arquitectura del sistema desde sus orígenes de Unix está concebida con criterios de seguridad: kernel, usuarios separados, privilegios en relación a cuentas, ficheros y carpetas, firmas de seguridad de paquetes, repositorios oficiales, etc. Eso no quiere decir que sea invulnerable ni mucho menos. Yo he visto en este foro hace años un caso en el que el usuario abrió gentilmente la puerta de su sistema a los malos instalando él en persona un script que era puro malware, creyendo que Linux era invulnerable. ¿Un banco es invulnerable si el director le da a los ladrones los códigos de las alarmas y las llaves de la caja fuerte?. Pues eso.

Yo he tenido corriendo apache durante años expuesto a Internet en un par de sistemas RPi y nunca he tenido el más mínimo problema. No obstante, me limitaba a servir páginas html y php. Los códigos de php los diseñé yo y no había forma de que ni siquiera se alterara un fichero de mi sistema desde Internet. ¿Qué pasaría si el php fuera de terceros?. ¿Puedo confiar en él?. Esa es una buena pregunta. Podrás garantizar que el usuario de apache o equivalente no tenga acceso a funciones de superusuario, definir un usuario limitado en la base de datos y temas así, al objeto de conseguir que una posible infección quede confinada en los recursos asignados al servidor web y no infecten el resto de usuarios del sistema. Pero, si el propio código de terceros incluye malware, el malware estará funcionando tranquilamente si tu abriste la puerta de tu sistema a los malos y lo instalaste en tu Linux.

Está claro que para garantizar seguridad debes configurar bien el servicio, usar paquetes instalados desde los repositorios oficiales y mantener actualizado el sistema con todos los parches disponibles. Si se usa software adicional de terceros, como el ejemplo de php que te indicaba, debe existir confianza absoluta en que no contenga malware.

¿Es necesario clamav?. Personalmente dudo de que sea de utilidad en tu caso. Yo lo he usado en PCs para limpiar virus de Windows arrancando con Linux desde un disco externo. Y funcionó muy bien. La base de datos de virus que usa clamav está muy orientada al mundo Windows,/PC/Intel. ¿Otros paquetes extra?. El miedo es libre.

No obstante, un sistema perfectamente seguro también puede ser atacado para dejarlo fuera de servicio temporalmente (ataque DoS). En ese caso los malos no intentan infectar el sistema y ponerlo a trabajar a su servicio sino boicotearlo. Evidentemente una instalación doméstica y un servidor web de bajas prestaciones son totalmente vulnerables a estos ataques y no hay remedio casero para zafarse de ellos, pero tampoco sería muy normal un ataque de este tipo a una pequeña página web.

Dado que tu problema no es de fácil solución, dudo mucho que pueda darte una pista genial para solucionarlo. Pero un tema a considerar es el nivel de tráfico de tu servicio web. ¿Puedes tener un tráfico muy alto en determinados momentos que pueda dar lugar a consecuencias similares a un ataque DoS?. Algunos routers de proveedores ISP son muy limitados en RAM y pueden quedarse sin recursos en escenarios de múltiples conexiones (p.e. P2P). No creo que sea el caso, pero por comentarlo no pasa nada.

En cuanto a tarjetas SD que se degradan también he sufrido ese problema. Pero el síntoma que he detectado es que la partición del sistema, ante los problemas en las escrituras, pasa a montarse en modo read-only.

NOTA: no estoy seguro de lo del montaje en modo read-only en caso de la RPi ante errores de la tarjeta. He echado un vistazo al fichero /etc/fstab y no me cuadra. Por defecto no define la opción errors=remount-ro en la línea de montaje de la partición root. Es posible que ése no fuera el comportamiento en el caso de la RPi.

[chema]

Gracias @Imarmisa por el tiempo que te has tomado para responder, se agradecen tus esfuerzos por tratar de comprender el problema, siento no ser de más ayuda o facilitar más información pero recién estoy empezando en este mundillo de las RPi y GNU/Linux y aún sigo aprendiendo.

Si obtengo algún resultado positivo lo pondré por aquí. De momento todo sigue igual. He desinstalado todo aquello que había instalado más o menos en el intervalo temporal que coincide con las pérdidas de red (y de instalación de la ip cam) pero de momento la cosa no ha mejorado, vamos que sigue exactamente igual.

Estoy por instalarlo todo desde cero y comenzar con una instalación limpia aunque ya te digo que no he metido ningún software sospechoso ni instalado ningún script, programa, etc de terceros o mio propio que pueda ser considerado como poco fiable. En fin, sigo en la lucha

saludos.

[chema]

hola

bueno pues tras iniciar una instalación limpia y desconectar estos días la cámara IP puedo confirmar que:
1. mientras la cámara está offline la RPi funciona sin ningún problema
2. cuando la cámara está online la RPi comienza a tener problemas de conectividad e incluso llega a quedarse fuera de línea tanto por wifi como por ethernet.
3. No hay conflictos de IP en modo DHCP

saludos.

[lmarmisa]

hola

bueno pues tras iniciar una instalación limpia y desconectar estos días la cámara IP puedo confirmar que:
1. mientras la cámara está offline la RPi funciona sin ningún problema
2. cuando la cámara está online la RPi comienza a tener problemas de conectividad e incluso llega a quedarse fuera de línea tanto por wifi como por ethernet.
3. No hay conflictos de IP en modo DHCP

saludos.

Parece que has encontrado una relación causa-efecto pobada con respecto a tu problema y eso es un paso importante.

No obstante, tienes otro hilo reciente en el foro en que sigues insistiendo en que clamav también provoca desconexiones a tu RPi, al que te contesté que clamscan es un programa que no interacciona con la red y que sólo hace lecturas de disco y, a lo sumo, algún borrado de ficheros. O sea, que tiene pocas probabilidades de ser culpable de dejar desconectada de la red tu RPi.

¿Podría ser que la RPi funcionara adecuadamente y que haya algo en su entorno que te impide conectarte a ella durante algunos periodos?. Yo lo considero como una opción probable.

Dado que tu sistema es headless, no tienes posibilidad de acceder a él durante los cortes. No obstante, hay formas de lanzar comandos que ayuden al diagnóstico que corran en modo batch y que vuelquen sus resultados a un fichero y podamos verlos con posterioridad.

Lo primero un par de trucos:

1) Te recomiendo colocar tus scripts y programas en un directorio de nombre bin creado desde el home de tu usuario de la RPi.

Code: Select all

cd
mkdir bin
. .profile

El directorio bin se añadirá automáticamente al PATH cada vez que inicies una shell y podrás llamar a tus programas y scritps desde cualquier directorio de tu usuario. Digamos que es como una extensión de los comandos/scripts de Raspbian con los tuyos propios.

2) Para lanzar un comando/script de larga duración en modo batch, desconectarte y más adelante volver a conectarte al mismo, puedes usar el programa screen.

Code: Select all

sudo apt-get install screen

Para arrancar un comando/script en este modo simplemente anteponle screen:

Code: Select all

screen myscript mis_parametros_aqui

Verás que muestra sus salidas de modo normal. Eso significa que estás unido (attached) al comando. Para desconectarte del comando y que siga funcionando a su aire teclea Ctrl-a Ctrl-d (el comando pasa a un estado separado del comando dettached).

Puedes ahora si lo deseas desconectarte de la RPi.

Más adelante podrías ver qué comandos están corriendo en modo batch que se hayan lanzado con screen:

Code: Select all

screen -ls

La respuesta te muestra si hay algún programa corriendo y si está dettached o attached a algún terminal. Si un comando está en modo attached, no se puede conectar a un segundo terminal. Sólo los dettached son susceptibles de reconexión.

Si sólo hay un comando corriendo, la reconexión es muy sencilla:

Code: Select all

screen -r

Si son varios los programas que corren bajo screen, hay que indicar el id apropiado tras la opción -r.

Puedes conectarte (screen -r) y desconectarte (Ctrl-a Ctrl-d) al script las veces de desees. Si el comando termina dejarás de verlo en la lista de screen -ls.

Para abortar un script de duración infinita corriendo bajo screen, conéctaté a él con el terminal (screen -r) y después teclea ctl-c.

Hasta aquí los preparativos.

Ahora te recomiendo un script para que lo dejes lanzado en la RPi y puedas ver qué se ve ahí dentro durante esos periodos en que no la ves conectada.

Edita un fichero de nombre prueba01.sh que deberá estar situado en el directorio bin:

Code: Select all

nano bin/prueba01.sh

Y ponle un contenido como éste:

Code: Select all

#!/bin/bash

while true; do
	echo
	date
	echo
	iwconfig wlan0
	ifconfig eth0
	ifconfig wlan0
	ping -c2 1.1.1.1
	echo
	sleep 20
done

Lo siguiente es darle permiso de ejecución al script:

Code: Select all

chmod +x bin/prueba01.sh

Te recomiendo lanzar tu script de este modo:

Code: Select all

screen prueba01.sh | tee > prueba01.txt

Con la redirección de la salida al comando tee, verás la salida normal de los comandos del script y a la vez esas salidas se guardarán también en el fichero prueba01.txt. Cuando compruebas que funcionan todos los comandos del script correctamente, desconéctate de screen con ctrl-a ctrl-d.

Si se produce una desconexión de la RPi de la red, encontrarás información de utilidad en el fichero prueba01.txt cuando consigas reconectarte. Como se ha incluído un comando date en el script, verás en el ficgero de salidas la hora del comienzo de cada bucle.

Espero que este procedimiento te ayude a avanzar en la resolución de tus problemas.