Archivo de la categoría: Temas HW

Truco: Android, mala conexión inhabilitada.

Igual en algún momento alguno os encontráis con el mismo problema con el que me he encontrado yo hoy cuando de repente y tras mucho tiempo de funcionar sin problemas, vuestro móvil decide no conectarse a vuestra WiFi.

La única señal es ver en los ajustes de red, en las redes WiFi, que vuestro móvil intenta conectarse continuamente a vuestra red habitual sin éxito, hasta que finalmente os da un mensaje:

mala conexión inhabilitada

De momento la única solución pasa por cambiar la configuración por defecto, por DCHP, por configurar la IP de forma manual.

Poner una IP fija dentro del rango de las configuradas en vuestro router, los mismos servidores DNS configurados en vuestro router, y como puerta de enlace la IP del propio router.

Tras ello probar a conectar y volveréis a disfrutar de vuestra conexión WiFi habitual.

No he encontrado explicación oficial, aunque en los foros de HTCMania un usuario daba una solución definitiva (aunque yo no la he probado aún):

La solución es:

1. “Olvidar” la wifi en cuestión en el móvil
2. Desactivar la wifi
3. borrar todos los ficheros de la carpeta /data/misc/dhcp (yo lo hice con Root Explorer, supongo que es necesario ser root)
4. reiniciar, volver a activar la wifi, volver a poner el password de tu wifi, etc

A mí me pasaba y esto lo solucionó definitivamente.

Actualizaré cuando la haya podido probar y validar.

Actualizado:

Efectivamente con esto funciona, aunque hay que ser un poco más precisos con las instrucciones.

Los ficheros a borrar están en /data/misc/dhcp, y son:

  • dhcpcd-wlan0.lease
  • dhcpcd-wlan.pid

Para eliminarlos, siendo root en vuestro móvil, lo mejor es bajarse una aplicación de terminal (por ejemplo esta) , abrir una sesión y hacer:

$ su

Con esto nos pedirá otorgar permisos de superusuario (root), permitirlo para ser root.

#cd /data/misc/dhcp
#rm dhcpcd-wlan*

Ahora volvemos a la configuración de la WiFi, borramos nuestra red, volvemos a configurarla y debe funcionar de nuevo sin problemas.

Actualización – 26 de enero de 2014

Sois muchos los que dejáis comentarios mencionando que no encontráis los ficheros a eliminar en la ruta especificada.

Ante esto, dado que a mí no me ha sucedido y no puedo investigarlo, solo os puedo decir que os aseguréis de:

  • Acceder al directorio como usuario root (no olvidéis tener permisos de root y hacer el ‘su’ en la ventana de terminal).
  • Acceder a la ruta en la partición adecuada, muchos móviles traen la memoria principal particionada con dos particiones.
  • Si con el terminal no veis los archivos, descargar una aplicación como Root Explorer o Root Browser (la segunda es gratuita) para intentar acceder al directorio como root.
  • Probar a configurar una IP estática.
  • Si la IP estática no funciona, probar a cambiar el nombre y el canal de vuestra red en el router (según el modelo de router podéis encontrar información sobre cómo hacerlo buscando en Google) para que el teléfono la reconozca como una red distinta.

Para cualquier otro problema no os vamos a poder ayudar, dado que estas cosas requieren de probarlas en persona para poder discernir qué es lo que está ocurriendo y cómo solucionarlo.

Un saludo.

Sony y el acierto de su estrategia en Android

Hace algo más de un mes, el pasado 12 de diciembre de 2012, una noticia me llamó la atención sobre Sony y Android:

Sony apoya a la comunidad y soluciona problemas de compatibilidad de CyanogenMod

hoy mismo hemos sabido que Sony ha salido al paso para solventar un problema de compatibilidad con el audio de los Sony Xperia en CyanogenMod. Como lo oís, Sony se ha preocupado de corregir un problema en el código fuente de CyanogenMod. Para hacer esto sin tener que liberar el código fuente de los componentes el desarrollador de Sony, Oskar Anderö, examinó el código público de CyanogenMod y corrigió los errores decompatibilidad con el chip de audio de forma que ahora CyanogenMod cuenta con soporte total para el audio de los Xperia.

Hasta ahora, hacer root o flashear una ROM distinta a la que tu smartphone traía de fábrica, era sinónimo de posibles problemas, pérdidas de garantía o quedar expuesto a perder una (muchas veces) lenta ROM original en pro de una ROM que no termina de ir bien.

Sin embargo, esta noticia del pasado diciembre ofrecía un giro total a la política que la totalidad de fabricantes llevaban a rajatabla, al pasar de solo dar soporte con sus ROMs oficiales a ayudar, por primera vez, a la comunidad para mejorar la compatibilidad con sus dispositivo.

A esto hay que añadir que si dispones de un Xperia (yo tengo un Neo V), el hacer root puede ser mucho más sencillo de lo que hasta ahora era gracias a que la propia Sony te ofrece el método y código de desbloqueo del bootloader de tu Xperia en su propia página web:

Página de Unlocking de Sony

Página de Unlocking de Sony

Es decir, basta con aceptar sus condiciones, hacer una comprobación para verificar que el bootloader puede ser desbloqueado y seguir el proceso que ellos mismos te indican, te envía tu clave de desbloqueo y una vez recibida puedes llevar a cabo el proceso.

Pero, ¿cuáles son las ventajas para Sony con esta estrategia?

Por una parte consiguen mejorar su imagen, dentro de la comunidad de desarrolladores de ROMs y de los que no tenemos problema en lanzarnos a probar distintas ROM para nuestros dispositivos, lo que le repercutirá en mejorar sus ventas y ganar puestos entre las preferencias de muchos posibles clientes.

No olvidemos que uno de los grandes problemas de Android es la enorme fragmentación del sistema, que provoca que aún a día de hoy sigamos viendo terminales lanzados con versiones 2.3.6 del sistema, aunque ICS (4.0) lleva con nosotros más de un año y Jelly Bean (4.1) ha demostrado ser una versión muy pulida y apetecible.

Gráfico fragmentación Android

Fragmentación en Android, tremendo el porcentaje de Gingerbread a estas alturas

Las quejas entre usuarios de Android por la falta de rigor a la hora de que los fabricantes dediquen esfuerzo y tiempo en traer las últimas versiones de Android a terminales recientes, son muy numerosas y suelen conllevar que muchos usuario renieguen de un determinado fabricante o incluso opten por lanzarse a comprar un Nexus de Google (cuando hay disponibilidad).

De ahí el acierto en la estrategia de Sony, por un lado consigue aprovechar el propio esfuerzo de la Comunidad en adaptar las últimas versiones de Android a sus terminales, lo que le puede ahorrar mucho esfuerzo y dinero si lo hicieran todo ellos mismos.

Por otra parte consigue contentar a muchos usuarios que se sienten más respaldados por el fabricante y que ven cómo tienen más opciones a la hora de decidir que ROM instalar, disfrutando así de versiones de Android que de otra forma no podrían instalar.

 

Por mi parte ya he desbloqueado el bootloader, así que ahora solo me queda decidir qué ROM terminaré probando.

Usar un D-Link DSL-524T como switch.

Hoy vamos a ver cómo podemos reutilizar un viejo modem-router para añadir conectividad en casa y dar acceso a internet a algunos dispositivos que por su sitio en la casa es más complicado conectar.

En casa tengo un router WiFi de ONO, un Netgear CG3100D con el que estoy muy contento desde  que me lo instalaron para quitar mi primero cable modem, dando conectividad al PC de sobremesa y los dispositivos con WiFi que tengo por casa.

Netgear CG3100D

Netgear CG3100D usado por ONO

El caso es que en el salón tengo un LCD Samsung LE37B651, que por defecto trae puerto Ethernet para conectarlo a internet e incluso aprovechar su funcionalidad DLNA+, y al que en su día se podía comprar un stick USB para darle funcionalidad WiFi, pero a un precio abusivo de 60€.

Junto al LCD tengo un O!Play HDP-R1, una de las mejores compras que he hecho, con el que reproduzco películas, aunque siempre con el handicap de tener que copiar las películas a un disco duro para poder reproducirlas.

Así que pensando en darle acceso a internet, y al PC de sobremesa donde tengo muchas películas, hace uno meses compré un kit PLC (TP-LINK) para conectar el O!Play o el LCD, o para llevar conexión a cualquier habitación a dispositivos sin WiFi.

Kit PLC

Kit PLC

Pero para no tener que andar desenganchando y volviendo a enganchar el cable del O!Play al LCD y viceversa, vamos a reutilizar un ‘viejo’ modem-router D-Link DSL-524T de Ya.com que me dio un amigo, para poder dar conexión a ambos dispositivos.

Modem ADSL+2 D-Link DSL-524T

Modem ADSL+2 D-Link DSL-524T

Para ello tenemos dos formas de hacerlo, una es con una configuración manual de la red para todos los dispositivos, teniendo para ello que introducir la IP/Máscara de Red/Puerta de enlace en cada dispositivo que conectemos. La segunda es manteniendo la características de DCHP del modem-router, de forma que cualquier nuevo dispositivo conectado tenga su configuración de forma automática.

Por ser la más cómoda, vamos a centrarnos en la segunda forma.

Lo primero es conectar el PC por cable al modem, para poder acceder a la consola web y configurar el mismo.

Por defecto, la IP del módem es 192.168.1.1, el usuario y password: admin/admin.

Una vez que accedamos nos encontramos con esta pantalla:

Home de la configuración

Pantalla Inicial de la consola

Lo primero que haremos será pulsar sobre la opción LAN, accediendo a la siguiente pantalla:

Configuracion LAN

Configuración LAN del módem

En esta pantalla cambiaremos la IP por defecto (192.168.1.1), dado que el router Netgear usa la misma y tendríamos un conflicto. Manteniendo la misma máscara de red para ambos (255.255.255.0), cambiamos la IP por una dentro de un rango libre en el servicio DCHP del Netgear (así evitamos que se la pueda asignar a otro dispositivo y ocasionar conflictos).

Una vez hecho esto, tras pulsar en Apply se cambia la IP en la barra del navegador y nos vuelve a pedir el usuario y password de acceso.

Accedemos de nuevo y esta vez nos vamos a la opción de  DCHP y seleccionar la opción ‘No DCHP’, de esta forma cuando conectemos un nuevo dispositivo a este modem, el que realmente estará asignando nuevas IPs será el Netgear

Una vez llegados aquí, y antes de colocar el modem en su lugar final y conectar los dispositivos, vamos a probar que funciona.

Conectamos a uno de los puertos el conector PLC, cuyo gemelo está conectado al Netgear en la otra habitación.

Conectamos el PC (lo desconectamos y volvemos a conectar) a otro de los puertos, y teniendo configurada la red para que pida automáticamente la conexión, deberíamos tener conexión a la primera sin problemas y abriendo un navegador para acceder a cualquier web comprobaremos que ya todo funciona correctamente.

De esta forma, podemos reutilizar cualquiera de nuestros viejos modem-router ADSL como switch y ampliar nuestra red con un mínimo de inversión en tiempo y quizás algún cable de red extra que podamos necesitar (más el kit PLC en mi caso).

Truco: Solucionar error rtorrent en Raspberry Pi

Estos días atrás estuve trasteando, al fin, con mi Raspberry Pi.

El puente y el post que Javier Pastor publicó en su blog, Incognitosis, me animó a dedicar un rato a montar el Raspberry Pi con un cliente Torrent, además de un MySQL para usarlo como pequeño (muy pequeño) servidor casero.

Pero tras ponerlo en funcionamiento, aprovechando un viejo disco por USB de 2.5″ que tenía por casa, terminé encontrándome con un problema al cabo de un tiempo, que provocaba que el cliente de Torrent (rtorrent) terminase fallando.

rtorrent: page allocation failure: order:3, mode:0x20

Con el problema añadido de dejar el fichero de sesiones bloqueado y no permitiendo que el script de reinicio pudiese volver a arrancarlo.

Tras investigar un poco, encontré un foro donde un usuario indicaba que el problema parecía estar en la activación (en el fichero de configuración .rtorrent.rc) del uso de DHT.

Así que ayer procedí a cambiarlo y hoy he podido comprobar, tras más de 24h encendido, que de momento el problema no se ha vuelto a reproducir.

Por cierto, acaban de anunciar que el modelo B de Raspberry Pi ha sufrido una ampliación de RAM de los 256MB a los 512MB, manteniendo el precio de 35$, lo que lo hace aún más apetecible.

Actualización: pues el error se ha reproducido, es menos habitual pero aún hay fallos. Toca seguir investigando.

 

Edito: 06 noviembre 2012

Tras investigar un poco por los foros de Raspberry, el error apunta a un problema en el kernel de linux que estamos usando o un problema con los drivers USB, que provocaría un error ante condiciones de carga de CPU y uso intensivo del disco duro:

Kernel paging error during heavy network and disk load

 

I have an external, self powered 300gb NTFS drive mounted using ntfs-3g to /mnt/sda1. I am also running rtorrent in a background screen session using the recommended init.d startup script. rtorrent is configured to use ~/rtorrent/watch and ~/rtorrent/session as it’s watch and session directories (which are located on the sd card), and /mnt/sda1/rtorrent/downloads as the primary download directory.

After 30 mins or so of downloading a single torrent at ~1MB/s,
the Raspi crashes and I get the message:

Unable to handle kernel paging request at virtual address 8e78b8a2
pgd =cb9e4000
*pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT
Entering kdb (current0xca4ec520, pid 1313 Oops: (null) due to oops @ 0xc024d3d4

Incluso algún usuario apuntaba al modo ‘Turbo’ habilitado en la última versión, que haría que se usara más CPU para mejorar el tráfico de red:

setting to stabilize the official image

Please add “smsc95xx.turbo_mode=N” to /boot/cmdline.txt in the official image, it prevents the rpi from crashing under load.
Also prevents the log from filling with this:

CODE: SELECT ALL

smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped

by El_Presidente » Thu Aug 16, 2012 5:13 pm
OK – so I’ve done my own Googling and find that the turbo mode is meant to make the Ethernet more efficient but at the cost of using more Kernel memory. Putting this together with comments from around the Pi forum, it looks like the turbo mode grabs too much resource when heavily using the network, leading to kevent drops and page allocation issues. Others believe that because the Ethernet is effectively a port off the USB 3-port hub built into the Pi, it is flooding the whole USB subsystem, thus being a contributor to overall crap USB experience as well as kernel panic/crash.

Lo cierto es que con unas opciones u otras los errores se siguen produciendo, aunque al menos en esta última ocasión parece que con modo turbo anulado ha sido más estable y ha aguantado más tiempo en ejecución.