Archivo de la etiqueta: Trucos

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.

Truco: Spring 3.1 y error con persistence-unit de test.

Estaba recordando Spring, siguiendo un tutorial de Francisco Grimaldo, cuando me he encontrado con un curioso error.

Tras implementar un Unit Test para la recuperación de datos de la base de datos, la ejecución ha empezado a darme el siguiente error:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘entityManagerFactory’ defined in class path resource [test-context.xml]: Invocation of init method failed; nested exception is java.lang.IllegalStateException: Conflicting persistence unit definitions for name ‘springappPU’: file:/H:/Users/Manuel/Documents/workspace-sts-3.1.0.RELEASE/webMeet/target/classes, file:/H:/Users/Manuel/Documents/workspace-sts-3.1.0.RELEASE/webMeet/target/test-classes
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1486)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:524)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:461)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1117)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:922)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:83)

Tras comprobar si había metido la pata en alguno de los pasos y darle muchas vueltas, sin encontrar dónde estaba el error, he terminado encontrando una solución en (como no) Stackoverflow.

La solución, por si os sirve a alguno de ayuda, pasa por renombrar la persistence-unit usada por los Unit Test de nombre:

test/resources/META-INF/persistence.xml

<persistence-unit name="springappPUtest" transaction-type="RESOURCE_LOCAL">
	</persistence-unit>

test/resources/test-context.xml

<property name="persistenceUnitName" value="springappPUtest"></property>

Y luego unificar en el mismo persistence.xml ambos ficheros.

main/resources/META-INF/persistence.xml

	<persistence-unit name="springappPU" transaction-type="RESOURCE_LOCAL">
	</persistence-unit>

	<persistence-unit name="springappPUtest" transaction-type="RESOURCE_LOCAL">
	</persistence-unit>

No es la solución más óptima, pero al menos permite que el Unit Test se ejecute.

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.

Truco: Proxy on / Proxy off

Los que solemos llevarnos el portátil del trabajo a casa tenemos un problema común, habilitar y des-habilitar el proxy de la empresa en el portátil.

Si usais IE, Chrome o si en Firefox le ponemos que use la configuración del proxy del sistema, el tema pasa por entrar en las opciones de IE, ya sea desde el propio IE o desde las opciones que Chrome que invocan el mismo dialogo de IE.

Harto de este rollo cada vez que voy y vengo, me puse a buscar una forma de hacerlo por línea de comando. Lógicamente este valor debe estar en el registro, así que lo primero era buscarlo, por medio de la utilidad REG que trae windows:

reg query HKCU /v proxy

Salieron unos cuantos resultados, pero el mas probable era este:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet Settings
ProxyEnable REG_DWORD 0x1

Una vez comprobado que este era el valor correcto, ya solo era cuestión de hacer un par de scripts (si teneis curiosidad por los parametros, usad REG /?):

proxy_on.bat
reg add  "HKCUSoftwareMicrosoftWindowsCurrentVersionInternet Settings" /v ProxyEnable /t REG_DWORD /d 1 /f


proxy_off.bat
reg add  "HKCUSoftwareMicrosoftWindowsCurrentVersionInternet Settings" /v ProxyEnable /t REG_DWORD /d 0 /f

Listo. (ya solo me falta que en el arranque de windows un script mire mi IP y des-habilite el proxy si no es la de la empresa, pero eso ya será otro día).