Copiar ficheros bajo MTP con Timestamp

Hoy he tenido un problema a la hora de liberar espacio del móvil de mi mujer porque al conectarlo por USB y copiar las imágenes y vídeos la fecha de modificación no se mantenía. Lo primero que he intentado ha sido usar la linea de comandos con el comando -p (preserve)

cp -p   (Operation not supported)

Mirando un poco, he averiguado que los Android (no se si los antiguos o los nuevos, en mi caso es un Samsung Galaxy S3 Mini) se montan en Ubuntu utilizando el protocolo MTP con lo que hay que copiar los ficheros usando el comando gvfs-copy Segundo intento

gvfs-copy --preserve  

Con esto se copian todos los ficheros pero no respeta la fecha de modificación, parece que se trata de un bug reconocido, no he tenido tiempo para investigar mucho, reconozco que soy un novato en sistemas operativos. Solución final, me he creado un script (típica solución de linuxeros) que copia el fichero y luego le setea la fecha de modificación. Aquí os lo dejo, hay que tener en cuenta que en mi caso el dispositivo se montó en

mtp://[usb:002,011]/

cada vez que se monta, este número cambia, tenedlo en cuenta a la hora de cambiar de directorio

1:  #!/bin/bash  
2:  cd /run/user/1000/gvfs/mtp:host=%5Busb%3A002%2C011%5D/Card/DCIM/Camera  
3:  for i in *  
4:  do  
5:      mod_date=$(stat -c "%y" "$i"|sed 's/\..*$//')  
6:      dest_file=/media/discolo/Imagenes/Backup/"$i"   
7:      gvfs-copy $i "$dest_file"   
8:      touch -d"$mod_date" "$dest_file"  
9:  done  

Espero que le sirva a alguien, Saludos.

El desafío - Implantar una plataforma SOA Open Source

Bien, pues con todo lo que he ido aprendiendo, leyendo y experimentando durante este tiempo ahora llega el momento de la verdad.
En la empresa donde estoy trabajando, desde que llegué, he intentado cambiar la metodología y la forma de trabajar. Hemos pasado del "vamos a apagar este fuego como sea para que funcione" que me encontré al "todo lo que hagamos tiene que ser reutilizable e independiente" (vamos, un componente).

Actualmente lo que tenemos es una plataforma grotesca que ha ido creciendo durante 3 o 4 años. Técnicamente tiene cosas interesantes, pero es muy dificil de evolucionar ya que el core no es opensource ni disponemos de los fuentes y todo lo que se va desarrollando se hace sobre este core con sus limitaciones y sus desventajas.

A lo que vamos es a rediseñar todo el modelo actual de la empresa, con los cambios y evoluciones que ha sufrido. Empezar a definir servicios según las necesidades que van surgiendo. Estos servicios de momento se van a servir de los datos con los que trabaja la actual plataforma. Es decir, la implementación de los DAOs van a obtener los datos con el core actual para poder migrar cuando sea posible con el mínimo impacto.

Lo primero que pretendo implantar será, como he dicho, unos servicios imprescindibles que permitan obtener ciertos datos que mostrar en un portal web de acceso a terceros, con lo que la interacción con los clientes se incrementa y dejamos de tener el cutre-portal-web para poder ofrecer contenidos dinámicos. Para esto utilizaremos Liferay, el contenedor de Portlets, y para diseñar los servicios Web voy a probar Apache Tuscany (http://tuscany.apache.org/).

Ya iré contando qué tal va evolucionando y qué otras soluciones OpenSource voy añadiendo, aunque en mi mente ya están jBPM para los procesos de negocio, Apache Synapse como ESB ligero y EsperTech para los eventos. Aunque también incorporaré otras en su versión Community como pueden ser Alfresco para la gestión documental y Liferay que ya he comentado.

Acceso JMX remoto con JConsole a Tomcat

JConsole permite monitorizar en tiempo real el estado de la JVM que necesitemos y ejecutar operaciones JMX remotamente, incluso forzar GCs (Garbage Collections). Podemos acceder a nuestros procesos locales que estén ejecutando la JDK o procesos remotos que tengan habilitado el acceso remoto por JMX.

En mi caso he necesitado monitorizar un applet local y un Tomcat 6 situado en otra máquina.

JConsole es un programa que está situado en el bin de la JDK, basta con ejecutarlo para que aparezca un menú donde se elige el proceso local que está corriendo o el remoto.

Para conectarnos por JMX remotamente habrá que habilitar el servicio en la máquina virtual remota. Esto se hace incluyendo los siguientes atributos en el inicio de la JVM:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=%my.jmx.port%
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

Esta es la forma fácil e insegura, ya que estoy deshabilitando la autenticación, pero para habilitarla a partir de ficheros de configuración sería algo así:

-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=jmxremote.password
-Dcom.sun.management.jmxremote.access.file=jmxremote.access

Fichero de acceso:

# The "monitorRole" role has password "QED".
# The "controlRole" role has password "R&D".
monitorRole QED
controlRole R&D

Fichero de passwords:

monitorRole tomcat
controlRole tomcat

Donde lo he probado ha sido en Windows XP, con la versión de Tomcat 6.0.20, instalada como servicio, por lo que he tenido que ejecutar tomcat6w.exe para editar, desde la pestaña Java las propiedades Java y añadir las que he comentado al principio.

Si queremos habilitar una conexión segura por SSL habría que configurar el keystore y el password, pero como no lo he probado dejo únicamente una referéncia:
http://download.oracle.com/javase/1.5.0/docs/guide/management/agent.html#remote

Aquí está la documentación para hacerlo en Tomcat 6
http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html#Enabling_JMX_Remote

Saludos!

Mostrar los puertos escuchando relacionados con los procesos

Hoy me ha hecho falta saber qué proceso me estaba escuchando en el mismo puerto que me hacía falta y buscando he encontrado el cómo, por si a alguien le hace falta.

sudo netstat --tcp --udp --listening --program

rromero@madrid:~$ sudo netstat --tcp --udp --listening --program
Conexiones activas de Internet (solo servidores)
Proto Recib Enviad Dirección local Dirección remota Estado PID/Program name
tcp 0 0 localhost:64022 *:* ESCUCHAR 1445/novacomd
tcp 0 0 localhost:12311 *:* ESCUCHAR 1445/novacomd
tcp 0 0 localhost:ipp *:* ESCUCHAR 1173/cupsd
tcp 0 0 localhost:6968 *:* ESCUCHAR 1445/novacomd
tcp 0 0 localhost:6969 *:* ESCUCHAR 1445/novacomd
tcp 0 0 localhost:6970 *:* ESCUCHAR 1445/novacomd
tcp 0 0 localhost:6971 *:* ESCUCHAR 1445/novacomd
rromero@madrid:~$ ps -fea | grep novacomd
root 1445 1 5 16:59 ? 00:09:39 /opt/Palm/novacom/novacomd

Info extraída de aquí:
http://www.go2linux.org/which_service_or_program_is_listening_on_port

Singletons en Java

Tras realizar un diseño de un servicio, me puse a definir las clases necesarias, con su esqueleto básico con lo que varias requerían ser Singletons, por lo que utilicé la implementación típica sacada de los libros de ingeniería de software.

public class DefaultSingleton {
private static DefaultSingleton instance = null;

private DefaultSingleton(){}

public synchronized DefaultSingleton getInstance() {
if(instance == null) {
instance = new DefaultSingleton();
}
return instance;
}

En teoría esto permite la inicialización única para accesos concurrentes ya que el getInstance() es sincronizado, pero cualquier objeto que necesite obtener la instancia deberá pasar por la sincronización, lo que puede no ser necesario y si no me equivoco también dará problemas de concurrencia.

Para intentar evitar esta situación, se ha confiado durante mucho tiempo en el doble chequeo de la sincronización (Double-Checked Locking), pero sin entrar en más detalle, decir que se ha demostrado que genera diversos errores en entornos altamente concurrentes, sin entrar en más detalles pongo un enlace.
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

A partir de aquí surgen dos alternativas, la inicialización impaciente (eager) o la perezosa (lazy). Los dos ejemplos anteriores son Lazy. La principal diferencia entre una y otra es cuándo se crea la instancia, si al iniciar la aplicación o al hacer el getInstance(). La elección de cada una dependerá de cada caso concreto, ya que si tienes pocos Singleton y requieren poco procesamiento, o simplemente te da igual lo que tarde en iniciarse la aplicación, optarás por la primera, si son muchos los Singleton que necesitas inicializar, algunos contienen un procesamiento complejo y/o lento, o simplemente prefieres que se vayan creando las instancias conforme vayan haciendo falta, por temas de recursos o lo que sea, tal vez prefieras la segunda opción. En mi caso me he decantado por la inicialización bajo demanda.

Ejemplo de inicialización impaciente.

public class EagerSingleton {
private static EagerSingleton instance = new EagerSingleton();

private EagerSingleton(){}

public EagerSingleton getInstance() {
return instance;
}

Se puede observar como evitamos el synchronized ya que es la JVM quien se encarga de inicializar la instancia. Al centralizar la inicialización en un único punto (la JVM) previenes cualquier inicialización concurrente.

Ejemplo de inicialización perezosa (o bajo demanda).

public class LazySingleton {
private static class InstanceHolder {
public static LazySingleton instance = new LazySingleton ();
}

private LazySingleton (){}

public LazySingleton getInstance() {
return InstanceHolder.instance;
}

Aquí no se instanciará la variable instance hasta que algún objeto haga el getInstance() de tal forma que igual que en el caso anterior, será la JVM quien creará la instancia cuando deba ser ejecutado.

Espero que este resumen rápido sirva para tener claro cómo utilizar un Singleton en Java.

Aquí dejo un par de fuentes
http://embarcaderos.net/2009/06/23/the-singleton-pattern-in-java-multi-threaded-applications/
http://www.rockstarprogrammer.org/post/2006/oct/19/java-singletons-without-locks/

Creando un archetype en Maven 2 / 3

Para empezar, un archetype de maven es una plantilla que sirve para generar proyectos muy fácilmente y empezar a trabajar rápidamente. En estas plantillas se debe generar todo lo necesario para que el proyecto funcione, por lo que incluirá tanto el pom.xml, las clases main y de test y todos los resources que hagan falta según el tipo de proyecto (persistence.xml, logback.xml, etc.).

Si bien hay muchos archetypes por internet yo soy de usar la configuración que más me gusta y siempre acabo personalizando mucho mis proyectos por lo que me he acabado haciendo uno propio con las dependencias que suelo usar en un proyecto sencillo. Esto incluye lo siguiente:

- SLF4J
- Logback
- HSQLDB como in-memory database
- Hibernate como implementación de JPA
- Spring como inyector de dependencias
- Junit 4

Para generar el tutorial he utilizado lo siguiente:
- Apache Maven: 3.0
- Java version: 1.6.0_22
- Git version: 1.7.1

Como he dicho antes hay muchos archetypes, incluso hay uno para generar archetypes (maven-archetype-archetype). El caso es que si tenemos muy claro lo que vamos a hacer e incluso ya tenemos nuestro proyecto base creado lo más sencillo es crearse un archetype a partir de este proyecto. Primero vamos a hacerlo y luego explicamos la diferencia principal con crearlo desde cero.

El proyecto base

La estructura del proyecto es la siguiente.

.
├── pom.xml
└── src
├── main
│   ├── java
│   │   └── es
│   │   └── discolo
│   │   ├── app
│   │   │   └── App.java //Símplemente hace un log Hello World
│   │   ├── dao
│   │   │   ├── FooEntityDao.java //Interfaz Dao
│   │   │   └── impl
│   │   │   └── FooEntityDaoImpl.java //Implementación de JPA para ese interfaz
│   │   └── model
│   │   └── FooEntity.java //Entity para probar la integración con JPA
│   └── resources
│   ├── applicationContext.xml //Configuración de Spring
│   ├── logback.xml //Configuración de Logback
│   └── META-INF
│   └── persistence.xml //Configuración del persistence unit asociado a HSQLDB
└── test
├── java
│   └── es
│   └── discolo
│   └── test
│   ├── AbstractTest.java //Clase abstracta que configura el contexto de tests de Spring
│   └── PersistenceTest.java //Prueba la persistencia y las inyecciones de dependencias
└── resources
├── logback-test.xml //Configuración de test de Logback
└── testContext.xml //Configuración de Spring utilizada por AbstractTest

Generando el archetype a partir del proyecto

Es tan sencillo como escribir:

discolo@granada:~/workspace/jpa-spring-archetype$ mvn archetype:create-from-project
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building jpa-spring 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] >>> maven-archetype-plugin:2.0-alpha-5:create-from-project (default-cli) @ jpa-spring >>>
[INFO]
[INFO] <<< maven-archetype-plugin:2.0-alpha-5:create-from-project (default-cli) @ jpa-spring <<< [INFO] [INFO] --- maven-archetype-plugin:2.0-alpha-5:create-from-project (default-cli) @ jpa-spring --- [INFO] Setting default groupId: es.discolo [INFO] Setting default artifactId: jpa-spring [INFO] Setting default version: 1.0-SNAPSHOT [INFO] Setting default package: es.discolo [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building jpa-spring-archetype 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ jpa-spring-archetype --- [WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent! [INFO] Copying 13 resources [INFO] [INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ jpa-spring-archetype --- [WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent! [INFO] Copying 2 resources [INFO] [INFO] --- maven-archetype-plugin:2.0-alpha-5:jar (default-jar) @ jpa-spring-archetype --- [INFO] [INFO] --- maven-archetype-plugin:2.0-alpha-5:add-archetype-metadata (default-add-archetype-metadata) @ jpa-spring-archetype --- [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2.360s [INFO] Finished at: Sun Oct 24 12:35:00 CEST 2010 [INFO] Final Memory: 6M/66M [INFO] ------------------------------------------------------------------------ [INFO] Archetype created in target/generated-sources/archetype [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 6.555s [INFO] Finished at: Sun Oct 24 12:35:00 CEST 2010 [INFO] Final Memory: 7M/65M [INFO] ------------------------------------------------------------------------

Bien, con esto ya tenemos en target nuestro archetype generado. Vamos a ver lo que ha hecho maven dentro de target/generated-sources/archetype. Tenemos un pom.xml que corresponde al archetype, un src y un target. En el source está la configuración del archetype que incluye el proyecto modificado para adaptarse a la configuración y la estructura de la que partió al generarse. En el target tenemos el archetype listo para instalar.

Echamos un vistazo rápido al src:

src/
├── main
│   └── resources
│   ├── archetype-resources
│   │   ├── pom.xml
│   │   └── src
│   │   ├── main
│   │   │   ├── java
│   │   │   │   ├── app
│   │   │   │   │   └── App.java
│   │   │   │   ├── dao
│   │   │   │   │   ├── FooEntityDao.java
│   │   │   │   │   └── impl
│   │   │   │   │   └── FooEntityDaoImpl.java
│   │   │   │   └── model
│   │   │   │   └── FooEntity.java
│   │   │   └── resources
│   │   │   ├── applicationContext.xml
│   │   │   ├── logback.xml
│   │   │   └── META-INF
│   │   │   └── persistence.xml
│   │   └── test
│   │   ├── java
│   │   │   └── test
│   │   │   ├── AbstractTest.java
│   │   │   └── PersistenceTest.java
│   │   └── resources
│   │   ├── logback-test.xml
│   │   └── testContext.xml
│   └── META-INF
│   └── maven
│   └── archetype-metadata.xml
└── test
└── resources
└── projects
└── basic
├── archetype.properties
└── goal.txt

Vemos que ha incluido nuestro proyecto dentro de src/main/resources/archetype-resources y que en src/main/resources/META-INF/maven existe un fichero archetype-metadata.xml, este es el que dice qué ficheros incluir y cuales no. Aunque parezca que ha respetado nuestro proyecto tal cual, no es así puesto que hace falta personalizarlo para que realmente sea una plantilla. Esto se puede ver por ejemplo en el fichero pom.xml

...
${groupId}

${artifactId}

${version}
...

Se ve como se han parametrizado los atributos que dependerán de quien genere un proyecto a partir de este archetype. Otro ejemplo en la clase de AbstractTest que empieza así:

#set( $symbol_pound = '#' )
#set( $symbol_dollar = '$' )
#set( $symbol_escape = '\' )
package ${package}.test;

Estas cosas son las que hacen más sencillo generar el archetype a partir de un proyecto.

Instalando el archetype

Para poder usar el archetype deberá estar instalado en nuestro repositorio con lo que ejecutamos un mvn install desde target/generated-sources/archetype:

discolo@granada:~/workspace/jpa-spring-archetype/target/generated-sources/archetype$ mvn install
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building jpa-spring-archetype 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ jpa-spring-archetype ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 13 resources
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ jpa-spring-archetype ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 2 resources
[INFO]
[INFO] --- maven-archetype-plugin:2.0-alpha-5:jar (default-jar) @ jpa-spring-archetype ---
[INFO]
[INFO] --- maven-archetype-plugin:2.0-alpha-5:add-archetype-metadata (default-add-archetype-metadata) @ jpa-spring-archetype ---
[INFO]
[INFO] --- maven-archetype-plugin:2.0-alpha-5:integration-test (default-integration-test) @ jpa-spring-archetype ---
/home/discolo/workspace/defaultJPA_bkp/target/generated-sources/archetype/target/test-classes/projects/basic/archetype.properties
[INFO]
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ jpa-spring-archetype ---
[INFO] Installing /home/discolo/workspace/defaultJPA_bkp/target/generated-sources/archetype/target/jpa-spring-archetype-1.0-SNAPSHOT.jar to /home/discolo/.m2/repository/es/discolo/jpa-spring-archetype/1.0-SNAPSHOT/jpa-spring-archetype-1.0-SNAPSHOT.jar
[INFO] Installing /home/discolo/workspace/defaultJPA_bkp/target/generated-sources/archetype/pom.xml to /home/rromero/.m2/repository/es/discolo/jpa-spring-archetype/1.0-SNAPSHOT/jpa-spring-archetype-1.0-SNAPSHOT.pom
[INFO]
[INFO] --- maven-archetype-plugin:2.0-alpha-5:update-local-catalog (default-update-local-catalog) @ jpa-spring-archetype ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.429s
[INFO] Finished at: Sun Oct 24 12:47:36 CEST 2010
[INFO] Final Memory: 6M/66M
[INFO] ------------------------------------------------------------------------

Usando el archetype

Finalmente vamos a generar un proyecto a partir del archetype. Si escribimos mvn archetype:generate nos aparecerán tanto los locales como los remotos, aunque podemos filtrar y mostrar únicamente los locales incluyendo el parámetro -DarchetypeCatalog=local

Nos vamos a una carpeta nueva:

mkdir /tmp/workspace
cd /tmp/workspace
mvn archetype:generate -DarchetypeCatalog=local
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] >>> maven-archetype-plugin:2.0-alpha-5:generate (default-cli) @ standalone-pom >>>
[INFO]
[INFO] <<< maven-archetype-plugin:2.0-alpha-5:generate (default-cli) @ standalone-pom <<< [INFO] [INFO] --- maven-archetype-plugin:2.0-alpha-5:generate (default-cli) @ standalone-pom --- [INFO] Generating project in Interactive mode [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0) Choose archetype: 1: local -> jpa-spring-archetype (Archetype - jpa-spring-archetype)
Choose a number: : 1
Downloading: http://repository.jboss.com/maven2/es/discolo/archetype/jpa-spring-archetype/1.1-SNAPSHOT/maven-metadata.xml
Downloading: http://snapshots.jboss.org/maven2/es/discolo/archetype/jpa-spring-archetype/1.1-SNAPSHOT/maven-metadata.xml
Define value for property 'groupId': : com.mycorp
Define value for property 'artifactId': : prueba-archetype
Define value for property 'version': 1.0-SNAPSHOT: :
Define value for property 'package': com.mycorp: :
Confirm properties configuration:
groupId: com.mycorp
artifactId: prueba-archetype
version: 1.0-SNAPSHOT
package: com.mycorp
Y: : y
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 46.169s
[INFO] Finished at: Sun Oct 24 12:54:19 CEST 2010
[INFO] Final Memory: 7M/66M
[INFO] ------------------------------------------------------------------------

Perfecto! Con esto ya tenemos nuestro proyecto listo para echar a andar. Vamos a pasar los tests por si algo no ha ido bien.

...
Results :

Tests run: 3, Failures: 0, Errors: 0, Skipped: 0

12:57:13.824 [Thread-1] INFO o.hibernate.impl.SessionFactoryImpl - closing
12:57:13.824 [Thread-1] INFO o.h.c.DriverManagerConnectionProvider - cleaning up connection pool: jdbc:hsqldb:mem:test
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

Pues esto es todo, espero que os ahorre algo de tiempo a la hora de empezar vuestros proyectos. El código fuente en un repositorio de git, en codaset, por si queréis consultarlo o mejorarlo.

http://codaset.com/discolo/jpa-hibernate-archetype

Saludos,
Discolo.

VIA VT6566 en Ubuntu

Esta vez tocaba lidiar con la wifi de mi HTPC que no conseguía conectarse. La placa base es la Zotac ITX 9300 WiFi.
El WiFi que trae es el VIA VT 6566 que hasta hace poco tenías que compilarlo e instalarlo manualmente en Linux, pero aún así no conseguía conectarme, me detectaba la red pero no conseguía acceder, me pedía una y otra vez la clave.

Bien, estamos hablando de Ubuntu 9.10 con los drivers instalados manualmente. Hoy he probado con la beta2 de Ubuntu 10.04 en su LiveCD y me he dado cuenta que los drivers vienen ya instalados, pero sigo con el mismo problema de no poder conectarme.

La red WiFi está protegida con WPA y el router es un DLink DIR655 Firmware 1.32NA. En los logs del Router veía el siguiente mensaje cuando veía que no podía conectar:

Received Deauthentication

Para más detalles tenía configurada la seguridad de la siguiente forma:

Security Mode: WPA-Personal
WPA Mode: Auto (WPA or WPA2)
Cipher Type: AES and TKIP

Estaba de esa forma porque viene por defecto así, además así aumentas la compatibilidad porque utilizas WPA2 con los dispositivos más modernos y WPA con los legacy.

Claro, si le quitaba el cifrado me podía conectar, pero para probar vale, no lo voy a dejar así.

Finalmente vi que cambiando el modo a WPA2 Only y el tipo de cifrado a AES podía conectarme correctamente (menos mal).

Saludos,
Discolo