Basta con ejecutar el siguiente comando:
/usr/bin/rdate -s ntp.escomposlinux.org > /dev/null 2>&1
Se puede poner en el /etc/rc.local, hacerse un script de arranque, ponerlo en el cron, o lo que se quiera.
domingo, 18 de febrero de 2007
Pure-FTPD como servidor FTP con usuarios virtuales en OpenBSD 3.2
Artículo publicado originalmente en la página de "El Demonio" en agosto del 2003
En este artículo trata de cómo instalar y configurar el servidor de ftp Pure-FTPD con usuarios virtuales en una OpenBSD 3.2. ¿Por qué Pure-FTPD y no otro? Pues... porque es el que conozco, el que tengo instalado y con el que me tuve que pelear, ni más ni menos.
La confección del artículo está pensada con OpenBSD 3.2 en mente, que es lo que tengo instalado, pero debería funcionar con otras versiones sin dificultad e incluso con otros sistemas operativos sin necesidad de mucha adaptación.
Para la confección del mismo he utilizado la documentación oficial disponible (ver links al final del documento) y la experiencia propia.
Compilación e instalación
Podemos encontrar el port del Pure-FTPD en /usr/ports/net/pure-ftpd. Si no está ahí, quizás tienes los ports poco (¡o nada!) actualizados, o simplemente no los tienes. De todos modos, aquí sólo se va a tratar la instalación/configuración del Pure-FTPD, así que una vez que tengas una versión actualizada o que al menos tenga el Pure-FTPD, haz:
politvs# cd /usr/ports/net/pure-ftpd
Como queremos activar el soporte para usuarios virtuales, mensajes en castellano, y otras funcionalidades, tendremos que editar el archivo Makefile con nuestro editor favorito (el vi, claro :)), comentar la línea ya existente de CONFIGURE_FLAGS+= ... (ojo, seguramente estará partida con una barra como esta "\", así que comenta las dos líneas si no quieres que te de un error...) y añade esta por ejemplo:
CONFIGURE_ARGS+= --without-inetd --without-paranoidmsg --with-puredb \
--with-language=spanish --without-banner
Explico un poco los flags utilizados:
--without-inetd => No utilizo inetd, así así que yo lo voy a desactivar
--with-paranoidmsg => Se le mostrará siempre el mismo mensaje de error (en caso de que lo haya, claro) al usuario independientemente de cuál haya sido el error que lo haya provocado. Quizás no es muy útil a la hora de depurar errores de configuración, pero sí es útil por motivos de seguridad.
--with-puredb => Habilitamos usuarios virtuales
--with-language=spanish => Lenguaje castellano en los mensajes del servidor
--without-banner => No imprime banner de saludo <= Esta opción la hay como flavor
Otros flags que alguna gente podrá encontrar interesantes:
--with-nonroot => Permite que otros usuarios que no sean root ejecuten el servidor (con algunas limitaciones)
--with-quotas, --with-ratios => Activa cuotas de uso de disco, ratios de descarga...
--with-ftpwho => Soporte para el comando pure-ftpwho (nos da información sobre usuarios conectados, qué descargan, etc). Necesita algo más de memoria, y al parecer pueden enlentecer cuando se utilizar Pure-FTPD con inetd.
Haciendo:
politvs# ./configure --help
desde el directorio en donde están descomprimidos los fuentes (alguno que cuelgue de /usr/ports/net/pure-ftpd pero eso ya depende de la versión) podrás obtener todos los flags posibles que puedes utilizar, y sino consulta la página web oficial (casi todo lo que pongo aquí está extraído de allí), en donde hay varios "readmes".
En resumen: añade la línea CONFIGURE_FLAGS+= ... en el Makefile con los flags que quieras ;)
Ahora sólo queda hacer:
politvs# make install clean clean-depends
Y si no hay problemas y después de un rato compilando, deberíamos tener ya el Pure-FTPD instalado.
Usuarios virtuales
Uno de los puntos que me gustan del Pure-FTPD es la posibilidad de trabajar con usuarios virtuales. Para ello hay que realizar algunos pasos previos. En primer lugar, añadiremos un grupo y un usuario al sistema:
politvs# groupadd -g 6000 ftpgroup
politvs# useradd -g ftpgroup -u 6000 -d /dev/null -s /etc ftpuser
Esto no es estrictamente necesario (se pueden utilizar usuarios y grupos ya existentes), pero pienso que queda más claro y es lo que recomiendan en el "readme" de usuarios virtuales de la propia página web del programa. Ojo, hay que tener cuidado de que no exista ese usuario/grupo/uid/gid, ya que podría darnos problemas.
Seguramente te extrañará que el shell utilizado sea /etc; francamente a mi también :) pero es como dice el "readme" que hay que hacerlo. Para ello, es casi seguro que tengas que añadir la línea /etc en el archivo /etc/shells ya que seguramente no la tendrás. Hay otra posibilidad, más clara pero que no he probado, que es la de añadir /sbin/nologin (creo que ese es el path) en /etc/shells y utilizar éste como shell del usuario ftpuser; supongo que funcionará igual, ya que se trata simplemente de tener una shell falsa.
Procedemos ahora a añadir el primero de nuestros usuarios virtuales. De forma rápida sería algo así:
pure-pw useradd nombre-de-usuario-virtual -u nombre-real-del-usuario -g grupo-real-del-usuario -d /ruta/del/home/virtual
Es decir: si queremos añadir un usuario virtual pepe con el grupo y usuarios de sistema creados unas líneas atrás, y que tenga como home el directorio /mnt/ftp, tendremos que hacer:
politvs# pure-pw useradd pepe -u ftpuser -g ftpgroup -d /mnt/ftp
Nos preguntará la contraseña dos veces por motivos de seguridad.
A la hora de crear usuarios tenemos muchas otras opciones, como encerrarlo en su directorio, permitir que se conecte desde una dirección ip determinada... pero esto es solo un breve tutorial así que no me meteré a fondo con esto (tampoco podría porque no he hecho pruebas en este sentido).
Para modificar datos de usuarios ya creados tenemos el comando pure-pw usermod. Por ejemplo, si quisiéramos que pepe tenga una cuota de 1000 archivos y 10Mb, tendríamos que hacer algo así:
politvs# pure-pw usermod pepe -n 1000 -N 10
Pero no lo he probado, así que inténtalo tú mismo y luego dime si funciona, da problemas, o qué pasa.
Para borrar al usuario pepe:
politvs# pure-pw userdel pepe
Ojo, el home no se borra, tendrás que hacerlo a mano si quieres.
Cambiar la contraseña sería algo como esto:
politvs# pure-pw passwd pepe
De nuevo nos la preguntará dos veces.
Si lo que queremos es ver información sobre el usuario pepe:
politvs# pure-pw show pepe
En todos estos ejemplos están dando por sentado que estamos trabajando con la base de datos de usuarios creada por defecto por el Pure-FTPD, que es /etc/pureftpd.passwd. Podemos editar la información directamente en ese archivo, puesto que es texto plano (no recomendable). Sin embargo, hay que transformar esa información en un archivo binario con el que el Pure-FTPD pueda trabajar, y eso lo hacemos así:
politvs# pure-pw mkdb
Lo cual creará el archivo /etc/pureftpd.pdb (siempre que sigamos trabajando con la los parámetros por defecto). Hablando claro, viene a ser como una compilación. Cada vez que haya un cambio en el archivo .passwd, hay que "recompilarlo" para que el Pure-FTPD pueda usarlo.
Una opción interesante cuando añadimos usuarios, o cambiamos sus datos/contraseñas, es el modificador -m, que hace que, inmediatamente después de la acción, se reconstruya el archivo binario de información:
politvs# pure-pw passwd pepe -m
politvs# pure-pw userdel pepe -m
De esta forma ya no será necesario hacer pure-pw mkdb.
Iniciar el servidor
Bueno, llegó la hora de ver si todo esto funciona, así que activemos el servidor. En mi caso lo haré tal que así:
politvs# /usr/local/sbin/pure-ftpd -4 -B -j -lpuredb:/etc/pureftpd.pdb -lunix -c 2 -C 2 -A
¡Y ya deberíamos poder conectarnos! Explicaré un poco los flags utilizados:
-4 => Activa IPv4.
-B => Inicia el servidor como demonio.
-j => Crea los homes al entrar por primera vez si no existían con anterioridad.
-lpuredb:/etc/pureftpd.pdb => Activa los usuarios virtuales y leerá la información del archivo /etc/pureftpd.pdb
-lunix => Si la validación como usuario virtual no funcionó, la intentará como usuario de sistema.
-c 2 => Permite sólo dos clientes simultáneos como máximo.
-C 2 => Permite sólo dos conexiones simultáneas por IP.
-A => Los usuarios no pueden descender más allá de su home.
-I 15 => Timeout a los 15 minutos.
También hay otras posibilidades interesantes:
-S 42 => Conecta al puerto 42 en lugar de al 21 (que es el habitual por defecto)
-f none => Desactiva logs
-E => Prohibe clientes anónimos
-w => Soporte FXP para usuarios autenticados (¡¡ojo, que FXP es un protocolo inseguro!!)
Para más información sobre estos y para saber qué otros están disponibles, échale un ojo a la página man:
politvs# man pure-ftpd
Merecen especial atención los parámetros -lpuredb:/etc/pureftpd.pdb -lunix. En ese orden, intentará primero validarse como usuario virtual y luego como usuario del sistema. Sería cuestión de probar qué pasaría si tenemos un usuario con el mismo nombre en el sistema y en el Pure-FTPD y el orden de los parámetros es el contrario. Quizás ya no se pueda añadir como usuario virtual... Si alguien lo prueba, por favor que nos cuente qué pasa.
Usuarios anónimos (probar)
En teoría (ésto no lo he probado), si existe un usuario ftp y tiene su propio home, Pure-FTPD aceptará conexiones anónimas como anonymous o como ftp los archivos compartidos deberán estar en el directorio home del usuario. No es necesario hacer chown a esos archivos, sólo a los directorios en los que se quiera que pueda escribir.
Banners
En el caso de existir un archivo .banner en el directorio home del usuario o del servidor virtual, se imprimirá cuando un usuario se conecte a modo de mensaje de bienvenida. Este archivo no debe superar los 4000 bytes o no se mostrará.
También puede haber en cada directorio un archivo .message que será mostrado cuando un cliente entre en el directorio.
Inicio de Pure-FTPD cada vez que iniciemos el ordenador
Pues sólo sería añadir algo como:
# Pure-FTPD
if [ -f /usr/local/sbin/pure-ftpd ]; then
echo -n ' Pure-FTPD'
/usr/local/sbin/pure-ftpd -4 -B -j -lpuredb:/etc/pureftpd.pdb -lunix -c 2 -C 2 -A
fi
... en nuestro /etc/rc.local. Podríamos refinarlo un poco más, pero así nos sirve.
Logs
Quizás queramos cambiar el archivo de log o la información que en él se va a mostrar. Por defecto el Pure-FTPD lo hace a través del syslog la configuración de este demonio la podemos cambiar a través del archivo /etc/syslog.conf, así editamos este archivo con nuestro editor favorito (de nuevo vi). Habrá ya una línea para ftp de este estilo:
ftp.info /var/log/xferlog
pero yo creo que es más claro loguear a otro archivo y que se incluya en este toda la información disponible, así que cambiaremos esta línea por esta otra:
ftp.* /var/log/ftp
y luego sólo nos quedará reiniciar. Esta opción queda a gusto del consumidor.
Links y agradecimientos
Página oficial de Pure-FTPD
Documentación oficial
Me gustaría aprovechar y agradecer la existencia de la página de "El Demonio" por dar cabida a este humilde documento y facilitarnos la vida con sus documentos. Eternamente agradecido.
Despedida
Y creo que eso es todo. Espero que este documento os haya servidor de algo.
Artículo publicado originalmente en la página de "El Demonio" en agosto del 2003
En este artículo trata de cómo instalar y configurar el servidor de ftp Pure-FTPD con usuarios virtuales en una OpenBSD 3.2. ¿Por qué Pure-FTPD y no otro? Pues... porque es el que conozco, el que tengo instalado y con el que me tuve que pelear, ni más ni menos.
La confección del artículo está pensada con OpenBSD 3.2 en mente, que es lo que tengo instalado, pero debería funcionar con otras versiones sin dificultad e incluso con otros sistemas operativos sin necesidad de mucha adaptación.
Para la confección del mismo he utilizado la documentación oficial disponible (ver links al final del documento) y la experiencia propia.
Compilación e instalación
Podemos encontrar el port del Pure-FTPD en /usr/ports/net/pure-ftpd. Si no está ahí, quizás tienes los ports poco (¡o nada!) actualizados, o simplemente no los tienes. De todos modos, aquí sólo se va a tratar la instalación/configuración del Pure-FTPD, así que una vez que tengas una versión actualizada o que al menos tenga el Pure-FTPD, haz:
politvs# cd /usr/ports/net/pure-ftpd
Como queremos activar el soporte para usuarios virtuales, mensajes en castellano, y otras funcionalidades, tendremos que editar el archivo Makefile con nuestro editor favorito (el vi, claro :)), comentar la línea ya existente de CONFIGURE_FLAGS+= ... (ojo, seguramente estará partida con una barra como esta "\", así que comenta las dos líneas si no quieres que te de un error...) y añade esta por ejemplo:
CONFIGURE_ARGS+= --without-inetd --without-paranoidmsg --with-puredb \
--with-language=spanish --without-banner
Explico un poco los flags utilizados:
--without-inetd => No utilizo inetd, así así que yo lo voy a desactivar
--with-paranoidmsg => Se le mostrará siempre el mismo mensaje de error (en caso de que lo haya, claro) al usuario independientemente de cuál haya sido el error que lo haya provocado. Quizás no es muy útil a la hora de depurar errores de configuración, pero sí es útil por motivos de seguridad.
--with-puredb => Habilitamos usuarios virtuales
--with-language=spanish => Lenguaje castellano en los mensajes del servidor
--without-banner => No imprime banner de saludo <= Esta opción la hay como flavor
Otros flags que alguna gente podrá encontrar interesantes:
--with-nonroot => Permite que otros usuarios que no sean root ejecuten el servidor (con algunas limitaciones)
--with-quotas, --with-ratios => Activa cuotas de uso de disco, ratios de descarga...
--with-ftpwho => Soporte para el comando pure-ftpwho (nos da información sobre usuarios conectados, qué descargan, etc). Necesita algo más de memoria, y al parecer pueden enlentecer cuando se utilizar Pure-FTPD con inetd.
Haciendo:
politvs# ./configure --help
desde el directorio en donde están descomprimidos los fuentes (alguno que cuelgue de /usr/ports/net/pure-ftpd pero eso ya depende de la versión) podrás obtener todos los flags posibles que puedes utilizar, y sino consulta la página web oficial (casi todo lo que pongo aquí está extraído de allí), en donde hay varios "readmes".
En resumen: añade la línea CONFIGURE_FLAGS+= ... en el Makefile con los flags que quieras ;)
Ahora sólo queda hacer:
politvs# make install clean clean-depends
Y si no hay problemas y después de un rato compilando, deberíamos tener ya el Pure-FTPD instalado.
Usuarios virtuales
Uno de los puntos que me gustan del Pure-FTPD es la posibilidad de trabajar con usuarios virtuales. Para ello hay que realizar algunos pasos previos. En primer lugar, añadiremos un grupo y un usuario al sistema:
politvs# groupadd -g 6000 ftpgroup
politvs# useradd -g ftpgroup -u 6000 -d /dev/null -s /etc ftpuser
Esto no es estrictamente necesario (se pueden utilizar usuarios y grupos ya existentes), pero pienso que queda más claro y es lo que recomiendan en el "readme" de usuarios virtuales de la propia página web del programa. Ojo, hay que tener cuidado de que no exista ese usuario/grupo/uid/gid, ya que podría darnos problemas.
Seguramente te extrañará que el shell utilizado sea /etc; francamente a mi también :) pero es como dice el "readme" que hay que hacerlo. Para ello, es casi seguro que tengas que añadir la línea /etc en el archivo /etc/shells ya que seguramente no la tendrás. Hay otra posibilidad, más clara pero que no he probado, que es la de añadir /sbin/nologin (creo que ese es el path) en /etc/shells y utilizar éste como shell del usuario ftpuser; supongo que funcionará igual, ya que se trata simplemente de tener una shell falsa.
Procedemos ahora a añadir el primero de nuestros usuarios virtuales. De forma rápida sería algo así:
pure-pw useradd nombre-de-usuario-virtual -u nombre-real-del-usuario -g grupo-real-del-usuario -d /ruta/del/home/virtual
Es decir: si queremos añadir un usuario virtual pepe con el grupo y usuarios de sistema creados unas líneas atrás, y que tenga como home el directorio /mnt/ftp, tendremos que hacer:
politvs# pure-pw useradd pepe -u ftpuser -g ftpgroup -d /mnt/ftp
Nos preguntará la contraseña dos veces por motivos de seguridad.
A la hora de crear usuarios tenemos muchas otras opciones, como encerrarlo en su directorio, permitir que se conecte desde una dirección ip determinada... pero esto es solo un breve tutorial así que no me meteré a fondo con esto (tampoco podría porque no he hecho pruebas en este sentido).
Para modificar datos de usuarios ya creados tenemos el comando pure-pw usermod. Por ejemplo, si quisiéramos que pepe tenga una cuota de 1000 archivos y 10Mb, tendríamos que hacer algo así:
politvs# pure-pw usermod pepe -n 1000 -N 10
Pero no lo he probado, así que inténtalo tú mismo y luego dime si funciona, da problemas, o qué pasa.
Para borrar al usuario pepe:
politvs# pure-pw userdel pepe
Ojo, el home no se borra, tendrás que hacerlo a mano si quieres.
Cambiar la contraseña sería algo como esto:
politvs# pure-pw passwd pepe
De nuevo nos la preguntará dos veces.
Si lo que queremos es ver información sobre el usuario pepe:
politvs# pure-pw show pepe
En todos estos ejemplos están dando por sentado que estamos trabajando con la base de datos de usuarios creada por defecto por el Pure-FTPD, que es /etc/pureftpd.passwd. Podemos editar la información directamente en ese archivo, puesto que es texto plano (no recomendable). Sin embargo, hay que transformar esa información en un archivo binario con el que el Pure-FTPD pueda trabajar, y eso lo hacemos así:
politvs# pure-pw mkdb
Lo cual creará el archivo /etc/pureftpd.pdb (siempre que sigamos trabajando con la los parámetros por defecto). Hablando claro, viene a ser como una compilación. Cada vez que haya un cambio en el archivo .passwd, hay que "recompilarlo" para que el Pure-FTPD pueda usarlo.
Una opción interesante cuando añadimos usuarios, o cambiamos sus datos/contraseñas, es el modificador -m, que hace que, inmediatamente después de la acción, se reconstruya el archivo binario de información:
politvs# pure-pw passwd pepe -m
politvs# pure-pw userdel pepe -m
De esta forma ya no será necesario hacer pure-pw mkdb.
Iniciar el servidor
Bueno, llegó la hora de ver si todo esto funciona, así que activemos el servidor. En mi caso lo haré tal que así:
politvs# /usr/local/sbin/pure-ftpd -4 -B -j -lpuredb:/etc/pureftpd.pdb -lunix -c 2 -C 2 -A
¡Y ya deberíamos poder conectarnos! Explicaré un poco los flags utilizados:
-4 => Activa IPv4.
-B => Inicia el servidor como demonio.
-j => Crea los homes al entrar por primera vez si no existían con anterioridad.
-lpuredb:/etc/pureftpd.pdb => Activa los usuarios virtuales y leerá la información del archivo /etc/pureftpd.pdb
-lunix => Si la validación como usuario virtual no funcionó, la intentará como usuario de sistema.
-c 2 => Permite sólo dos clientes simultáneos como máximo.
-C 2 => Permite sólo dos conexiones simultáneas por IP.
-A => Los usuarios no pueden descender más allá de su home.
-I 15 => Timeout a los 15 minutos.
También hay otras posibilidades interesantes:
-S 42 => Conecta al puerto 42 en lugar de al 21 (que es el habitual por defecto)
-f none => Desactiva logs
-E => Prohibe clientes anónimos
-w => Soporte FXP para usuarios autenticados (¡¡ojo, que FXP es un protocolo inseguro!!)
Para más información sobre estos y para saber qué otros están disponibles, échale un ojo a la página man:
politvs# man pure-ftpd
Merecen especial atención los parámetros -lpuredb:/etc/pureftpd.pdb -lunix. En ese orden, intentará primero validarse como usuario virtual y luego como usuario del sistema. Sería cuestión de probar qué pasaría si tenemos un usuario con el mismo nombre en el sistema y en el Pure-FTPD y el orden de los parámetros es el contrario. Quizás ya no se pueda añadir como usuario virtual... Si alguien lo prueba, por favor que nos cuente qué pasa.
Usuarios anónimos (probar)
En teoría (ésto no lo he probado), si existe un usuario ftp y tiene su propio home, Pure-FTPD aceptará conexiones anónimas como anonymous o como ftp los archivos compartidos deberán estar en el directorio home del usuario. No es necesario hacer chown a esos archivos, sólo a los directorios en los que se quiera que pueda escribir.
Banners
En el caso de existir un archivo .banner en el directorio home del usuario o del servidor virtual, se imprimirá cuando un usuario se conecte a modo de mensaje de bienvenida. Este archivo no debe superar los 4000 bytes o no se mostrará.
También puede haber en cada directorio un archivo .message que será mostrado cuando un cliente entre en el directorio.
Inicio de Pure-FTPD cada vez que iniciemos el ordenador
Pues sólo sería añadir algo como:
# Pure-FTPD
if [ -f /usr/local/sbin/pure-ftpd ]; then
echo -n ' Pure-FTPD'
/usr/local/sbin/pure-ftpd -4 -B -j -lpuredb:/etc/pureftpd.pdb -lunix -c 2 -C 2 -A
fi
... en nuestro /etc/rc.local. Podríamos refinarlo un poco más, pero así nos sirve.
Logs
Quizás queramos cambiar el archivo de log o la información que en él se va a mostrar. Por defecto el Pure-FTPD lo hace a través del syslog la configuración de este demonio la podemos cambiar a través del archivo /etc/syslog.conf, así editamos este archivo con nuestro editor favorito (de nuevo vi). Habrá ya una línea para ftp de este estilo:
ftp.info /var/log/xferlog
pero yo creo que es más claro loguear a otro archivo y que se incluya en este toda la información disponible, así que cambiaremos esta línea por esta otra:
ftp.* /var/log/ftp
y luego sólo nos quedará reiniciar. Esta opción queda a gusto del consumidor.
Links y agradecimientos
Página oficial de Pure-FTPD
Documentación oficial
Me gustaría aprovechar y agradecer la existencia de la página de "El Demonio" por dar cabida a este humilde documento y facilitarnos la vida con sus documentos. Eternamente agradecido.
Despedida
Y creo que eso es todo. Espero que este documento os haya servidor de algo.
viernes, 16 de febrero de 2007
Sacándole el jugo a madwifi-ng
Traducción (mala) del siguiente artículo: http://pof.eslack.org/blog/2006/06/30/traient-li-el-suc-a-madwifi-ng/
Virtual Access Points
Los VAP son la característica más interesantes de madwifi-ng. Con una sola interfaz física se pueden crear puntos de acceso virtuales con combinaciones diferentes, pero todos usarán siempre el mismo canal. Se pueden crear diferentes VAPs trabajando en modo punto de acceso y un solo VAP trabajando en modo cliente, todo eso por interfaz física. Si el VAP que trabaja en modo cliente es el primero que vamos a crear no se podrán crear más VAPs sobre esa interfaz.
Para crear los VAPs se utiliza el comando wlanconfig, que se puede encontrar en el paquete madwifi-ng-tools. A modo resumido, la sintaxis es la siguiente:
wlanconfig ath create wlandev wifi0 wlanmode [bssid|-bssid] [nosbeacon]
Con wlanmode ap se crean VAPs en modo Master (punto de acceso), y con wlanmode sta en modo cliente (station). Existen otros modos (monitor, wds...) pero no entraré en tanto detalle; para más información, ver la página man o la documentación de madwifi-ng.
Con la opción -bssid se fuerza a que el VAP utilice la direccion MAC de la EEPROM del dispositivo físico, y con la opción bssid se genera una MAC automáticamente.
Cuando se tengan VAPs en modo Master (AP) y en modo cliente (STA) sobre un mismo dispositivo físico, se ha de utilizar el flag nosbeacon cuando se crea el cliente; este flag deshabilita el uso de los beacon timers por hardware para trabajar en modo cliente.
Repetidor utilizando VAPs
A continuación explicaré como hacer un repetidor utilizando VAPs, lo cual puede ser bastante útil.
Suponiendo que tengamos un punto de acceso con el SSID "prova" y que queramos extender el área de cobertura, vamos a crear dos VAPs. El primero, en modo AP, servirá para dar cobertura a los clientes en el área que queremos extender, mientras que el segundo VAP, en modo cliente, servirá para asociarse al AP inicial que queremos a extender.
Como tendremos un AP y un cliente sobre el mismo dispositivo físico, habrá que crear primero el AP y después el cliente, y utilizar nosbeacon cuando creemos el cliente, pero cuando levantemos las interfaces el VAP cliente se ha de subir primero permitiendo que se asociar al AP "prova", ya que este VAP será el que seleccionará el canal del AP existente.
# wlanconfig ath create wlandev wifi0 wlanmode ap
ath0
# wlanconfig ath create wlandev wifi0 wlanmode sta nosbeacon
ath1
# iwconfig ath0 essid "prova"
# iwconfig ath1 essid "prova"
# iwpriv ath0 wds 1
# iwpriv ath1 wds 1
# ifconfig ath1 up
(Esperar a que se asocie al AP)
# ifconfig ath0 up
# ifconfig eth0 up
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif ath0
# brctl addif ath1
# brctl setfd br0 1
# ifconfig br0 up
Nota: en este ejemplo nuestro AP no podrá recibir tráfico IP puesto que no le hemos asociado una dirección IP el bridge. Si queremos que pueda recibir tráfico se le puede asignar una dirección IP, pero el AP "prova" ha de soportar WDS y saber gestionar tramas de cuatro direcciones MAC.
Seleccionar el modo de operación
iwpriv ath0 mode
Los diferentes modos de operación son:
Si sólo vamos a trabajar con el modo 802.11g, sin permitir que los clientes 802.11b se puedan conectar (deshabilita las velocidades inferiores a 6Mbps) se puede hacer con el siguiente comando:
iwpriv ath0 pureg 1
Esconder el SSID
A veces nos interesa que el SSID no se anuncie utilizando beacon frames, para lo cual se puede utilizar el siguiente comando:
iwpriv ath0 hide_ssid 1
Cambiar los tiempos entre beacons
Por defecto el SSID de la red s anuncia cada 100ms, pero se puede cambiar con el siguiente comando:
iwpriv ath0 bintval
Habilitar el soporte de 802.11h
802.11h se utiliza para evitar problemas de interferencias con otros dispositivos que utilicen la misma frecuencia, particularmente radares y equipos médicos que trabajan a 5GHz
Para reducir las interferencias se utilizan dos técnicas:
Para habilitar el soporte de 802.11h se utilizará el siguiente comando:
iwpriv ath0 doth 1
Si queremos generar un reassociation request se utilizará el siguiente comando:
iwpriv ath0 doth_reassoc 1
Cuando se utilice 802.11h la potencia de emisión puede variar entre un mínimo predefinido por el usuario y el máximo permitido por el regulatory domain. Para definir este límite se utiliza el siguiente comando:
iwpriv ath0 doth_pwrtgt
La potencia se ha de especificar en escalones de 0.5 dBm. Por ejemplo, si queremos que la potencia de emisión al canal actual pueda variar entre 13 dBm y el máximo permitido por el regulatory domain especificaríamos el valor 26 como potencia del comando anterior.
ACLs basadas en direcciones MAC
Madwifi-ng permite gestionar ACLs basadas en MAC desde el propio driver, para lo se utilizarán los siguientes comandos:
Primero hemos de seleccionar de qué manera queremos hacer las gestión de ACLs:
iwpriv ath0 maccmd
En donde mode puede ser:
Para añadir o borrar direcciones MAC a la lista de ACLs se utilizan los comandos add_mac y del_mac, de la siguiente manera:
iwpriv ath0 add_mac 00:01:02:03:04:05
iwpriv ath0 del_mac 00:01:02:03:04:05
Wireless Multimedia Extensions
Wireless Multimedia Extensions (WME) o Wi-Fi Multimedia (WMM) son una porción de las especificaciones del estándar 802.11e que proporcionan capacidades básicas de QoS a las redes 802.11 a nivel MAC (capa 2), priorizando el tráfico en base a cuatro categorías o clases de acceso (AC), aunque no proporcionen la capacidad de garantizar throughput.
Por defecto WMM va habilitado en madwifi-ng, pero se puede habilitar o deshabilitar con el siguiente comando:
Habilitar: iwpriv ath0 wmm 1
Deshabilitar: iwpriv ath0 wmm 0
Los ACs que define el estándar de WMM son los siguientes:
Los parámetros que vienen a continuación tienen la siguiente sintaxis:
Modificar los valores máximos y mínimos de la contention window: parámetros cwmin y cwmax
iwpriv ath0 cwmin <#AC>
iwpriv ath0 cwmax <#AC>
Modificar el Arbitration Inter Frame Spacing (AIFS): parámetro aifs
iwpriv ath0 aifs <#AC>
Modificar el tamaño del Transmit Opportunity (TxOp): parámetro txoplimit
iwpriv ath0 txoplimit <#AC>
Modificar el flag Admission Control Mandatory (ACM): parámetro acm
iwpriv ath0 acm <#AC> <0|1>
Si el último parámetro es 0 no es necesario el control de admisión, mientras que si es 1 es obligatorio.
Modificar la política de NoACK (ACM): parámetro noackpolicy
iwpriv ath0 noackpolicy <#AC> 0 <0|1>
El segundo parámetro ha de ser siempre 0, ya que la política de NoACK sólo se aplica al set de parámetros del AP y no al del cliente.
Si el último parámetro es un 0, la política que se aplica es la de asumir que un cliente está activo si devuelve un ACK después de enviarle una trama de poll, y desasociarlo/desautentificarlo si no contesta. Si dicho parámetro es un 1 no se aplica dicha política.
Otras historias
Como veis el tema es bastante extenso y si tuviera que documentar todas las opciones posibles no daría acabado nunca, pero se puede seguir la magnífica guía de usuario del wiki de madwifi u otros ejemplos de documentación.
Virtual Access Points
Los VAP son la característica más interesantes de madwifi-ng. Con una sola interfaz física se pueden crear puntos de acceso virtuales con combinaciones diferentes, pero todos usarán siempre el mismo canal. Se pueden crear diferentes VAPs trabajando en modo punto de acceso y un solo VAP trabajando en modo cliente, todo eso por interfaz física. Si el VAP que trabaja en modo cliente es el primero que vamos a crear no se podrán crear más VAPs sobre esa interfaz.
Para crear los VAPs se utiliza el comando wlanconfig, que se puede encontrar en el paquete madwifi-ng-tools. A modo resumido, la sintaxis es la siguiente:
wlanconfig ath create wlandev wifi0 wlanmode
Con wlanmode ap se crean VAPs en modo Master (punto de acceso), y con wlanmode sta en modo cliente (station). Existen otros modos (monitor, wds...) pero no entraré en tanto detalle; para más información, ver la página man o la documentación de madwifi-ng.
Con la opción -bssid se fuerza a que el VAP utilice la direccion MAC de la EEPROM del dispositivo físico, y con la opción bssid se genera una MAC automáticamente.
Cuando se tengan VAPs en modo Master (AP) y en modo cliente (STA) sobre un mismo dispositivo físico, se ha de utilizar el flag nosbeacon cuando se crea el cliente; este flag deshabilita el uso de los beacon timers por hardware para trabajar en modo cliente.
Repetidor utilizando VAPs
A continuación explicaré como hacer un repetidor utilizando VAPs, lo cual puede ser bastante útil.
Suponiendo que tengamos un punto de acceso con el SSID "prova" y que queramos extender el área de cobertura, vamos a crear dos VAPs. El primero, en modo AP, servirá para dar cobertura a los clientes en el área que queremos extender, mientras que el segundo VAP, en modo cliente, servirá para asociarse al AP inicial que queremos a extender.
Como tendremos un AP y un cliente sobre el mismo dispositivo físico, habrá que crear primero el AP y después el cliente, y utilizar nosbeacon cuando creemos el cliente, pero cuando levantemos las interfaces el VAP cliente se ha de subir primero permitiendo que se asociar al AP "prova", ya que este VAP será el que seleccionará el canal del AP existente.
# wlanconfig ath create wlandev wifi0 wlanmode ap
ath0
# wlanconfig ath create wlandev wifi0 wlanmode sta nosbeacon
ath1
# iwconfig ath0 essid "prova"
# iwconfig ath1 essid "prova"
# iwpriv ath0 wds 1
# iwpriv ath1 wds 1
# ifconfig ath1 up
(Esperar a que se asocie al AP)
# ifconfig ath0 up
# ifconfig eth0 up
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif ath0
# brctl addif ath1
# brctl setfd br0 1
# ifconfig br0 up
Nota: en este ejemplo nuestro AP no podrá recibir tráfico IP puesto que no le hemos asociado una dirección IP el bridge. Si queremos que pueda recibir tráfico se le puede asignar una dirección IP, pero el AP "prova" ha de soportar WDS y saber gestionar tramas de cuatro direcciones MAC.
Seleccionar el modo de operación
iwpriv ath0 mode
Los diferentes modos de operación son:
- Mode :: Number :: Description
- auto :: 0 :: modo de operación automático
- 11a :: 1 :: 802.11a (5GHz) - 54Mbps
- 11b :: 2 :: 802.11b (2.4GHz) - 11Mbps
- 11g :: 3 :: 802.11b/g (2.4GHz) - 54Mbps - compatible con 802.11b
- fh :: 4 : 802.11 frequency hopping mode
- 11adt/111at :: 5 :: 802.11a (5GHz) - dynamic turbo mode
- 11gdt/11gt :: 6 :: 802.11g (2.4GHz) - dynamic turbo mode (108Mbps)
- 11ast :: 7 :: 802.11a (5GHz) - static turbo mode
Si sólo vamos a trabajar con el modo 802.11g, sin permitir que los clientes 802.11b se puedan conectar (deshabilita las velocidades inferiores a 6Mbps) se puede hacer con el siguiente comando:
iwpriv ath0 pureg 1
Esconder el SSID
A veces nos interesa que el SSID no se anuncie utilizando beacon frames, para lo cual se puede utilizar el siguiente comando:
iwpriv ath0 hide_ssid 1
Cambiar los tiempos entre beacons
Por defecto el SSID de la red s anuncia cada 100ms, pero se puede cambiar con el siguiente comando:
iwpriv ath0 bintval
Habilitar el soporte de 802.11h
802.11h se utiliza para evitar problemas de interferencias con otros dispositivos que utilicen la misma frecuencia, particularmente radares y equipos médicos que trabajan a 5GHz
Para reducir las interferencias se utilizan dos técnicas:
- Dynamic Frequency Selection (DFS): el chip wifi detecta la presencia de otros dispositivos y si solapan el canal en el que está trabajando actualmente el AP, cambia de canal automáticamente.
- Transmit Power Protocol (TCP): el chip wifi reduce la potencia de emisión a un nivel que minimiza el riesgo de interferencias desde y hacia otros dispositivos.
Para habilitar el soporte de 802.11h se utilizará el siguiente comando:
iwpriv ath0 doth 1
Si queremos generar un reassociation request se utilizará el siguiente comando:
iwpriv ath0 doth_reassoc 1
Cuando se utilice 802.11h la potencia de emisión puede variar entre un mínimo predefinido por el usuario y el máximo permitido por el regulatory domain. Para definir este límite se utiliza el siguiente comando:
iwpriv ath0 doth_pwrtgt
La potencia se ha de especificar en escalones de 0.5 dBm. Por ejemplo, si queremos que la potencia de emisión al canal actual pueda variar entre 13 dBm y el máximo permitido por el regulatory domain especificaríamos el valor 26 como potencia del comando anterior.
ACLs basadas en direcciones MAC
Madwifi-ng permite gestionar ACLs basadas en MAC desde el propio driver, para lo se utilizarán los siguientes comandos:
Primero hemos de seleccionar de qué manera queremos hacer las gestión de ACLs:
iwpriv ath0 maccmd
En donde mode puede ser:
- Argumento: Accción
- 0: Deshabilita el control de ACLs
- 1: Sólo permite acceder a las MACs incluidas en la lista de ACLs
- 2: Sólo deniega el acceso a las MACs incluidas en la lista de ACLs
- 3: Borra la base de datos de ACLs
- 4: Elimina la política de ACLs
Para añadir o borrar direcciones MAC a la lista de ACLs se utilizan los comandos add_mac y del_mac, de la siguiente manera:
iwpriv ath0 add_mac 00:01:02:03:04:05
iwpriv ath0 del_mac 00:01:02:03:04:05
Wireless Multimedia Extensions
Wireless Multimedia Extensions (WME) o Wi-Fi Multimedia (WMM) son una porción de las especificaciones del estándar 802.11e que proporcionan capacidades básicas de QoS a las redes 802.11 a nivel MAC (capa 2), priorizando el tráfico en base a cuatro categorías o clases de acceso (AC), aunque no proporcionen la capacidad de garantizar throughput.
Por defecto WMM va habilitado en madwifi-ng, pero se puede habilitar o deshabilitar con el siguiente comando:
Habilitar: iwpriv ath0 wmm 1
Deshabilitar: iwpriv ath0 wmm 0
Los ACs que define el estándar de WMM son los siguientes:
- #AC: Descripción
- 0: BE - Best Effort
- 1: BK - Background
- 2: VI - Video
- 3: VO - Voice
Los parámetros que vienen a continuación tienen la siguiente sintaxis:
- #AC especifica el nombre de AC (de la tabla anterior) al que vamos a modificarle el parámetro.
- X: Puede tener dos valores: 0 o 1. El valor 0 indica que modificaremos los valores por el set de parámetres del AP, mientras que el valor 1 indica que lo haremos por el set de parámetros de cliente.
- Y: El valor que vamos a modificar en las unidades tal como es describen al estándar de WMM.
Modificar los valores máximos y mínimos de la contention window: parámetros cwmin y cwmax
iwpriv ath0 cwmin <#AC>
iwpriv ath0 cwmax <#AC>
Modificar el Arbitration Inter Frame Spacing (AIFS): parámetro aifs
iwpriv ath0 aifs <#AC>
Modificar el tamaño del Transmit Opportunity (TxOp): parámetro txoplimit
iwpriv ath0 txoplimit <#AC>
Modificar el flag Admission Control Mandatory (ACM): parámetro acm
iwpriv ath0 acm <#AC>
Si el último parámetro es 0 no es necesario el control de admisión, mientras que si es 1 es obligatorio.
Modificar la política de NoACK (ACM): parámetro noackpolicy
iwpriv ath0 noackpolicy <#AC> 0 <0|1>
El segundo parámetro ha de ser siempre 0, ya que la política de NoACK sólo se aplica al set de parámetros del AP y no al del cliente.
Si el último parámetro es un 0, la política que se aplica es la de asumir que un cliente está activo si devuelve un ACK después de enviarle una trama de poll, y desasociarlo/desautentificarlo si no contesta. Si dicho parámetro es un 1 no se aplica dicha política.
Otras historias
Como veis el tema es bastante extenso y si tuviera que documentar todas las opciones posibles no daría acabado nunca, pero se puede seguir la magnífica guía de usuario del wiki de madwifi u otros ejemplos de documentación.
lunes, 12 de febrero de 2007
Crear paquete amule en ArchLinux
1. Crear un directorio cualquiera en el que vayamos a trabajar y situarnos en él
2. Bajar el pkgbuild de http://gift.altervista.org/amule-cvs/amule-cvs/PKGBUILD
3. Asegurarse de que tenemos las dependencias (perl, crypto++, wxgtk...)
4. Hacer makepkg y rezar para que todo salga bien. Él solo se descargará los fuentes, compilará, aplicará los --enable o --disable...
lysandra# cd /usr/tmp
lysandra# mkdir amule
lysandra# wget -c http://gift.altervista.org/amule-cvs/amule-cvs/PKGBUILD
lysandra# makepkg
Esta versión especial del aMule hay que llamarla con el parámetro --even-if-lfroen-complains-this-will-stay (al menos el binario amule), lo cual al parecer se puede evitar ejecutando el este script.
Los fuentes los descargarán de la página http://www.hirnriss.net/, en donde diariamente se va dejando, listo para descargar, un tar.bz2 con los fuentes descargados por CVS correspondientes a un día determinado.
Más información sobre ABS aquí.
2. Bajar el pkgbuild de http://gift.altervista.org/amule-cvs/amule-cvs/PKGBUILD
3. Asegurarse de que tenemos las dependencias (perl, crypto++, wxgtk...)
4. Hacer makepkg y rezar para que todo salga bien. Él solo se descargará los fuentes, compilará, aplicará los --enable o --disable...
lysandra# cd /usr/tmp
lysandra# mkdir amule
lysandra# wget -c http://gift.altervista.org/amule-cvs/amule-cvs/PKGBUILD
lysandra# makepkg
Esta versión especial del aMule hay que llamarla con el parámetro --even-if-lfroen-complains-this-will-stay (al menos el binario amule), lo cual al parecer se puede evitar ejecutando el este script.
Los fuentes los descargarán de la página http://www.hirnriss.net/, en donde diariamente se va dejando, listo para descargar, un tar.bz2 con los fuentes descargados por CVS correspondientes a un día determinado.
Más información sobre ABS aquí.
domingo, 11 de febrero de 2007
amuled, amulecmd y amulegui
Pequeño resumen para andar por casa de esta entrada del blog de http://orion220.blogcindario.com.
En primer lugar hay que tener instalado en aMule (con Pacman, pkgsrc o el que coincida). En caso de que sea con los ports de los BSDs quizás sea necesario modificar el Makefile para añadir alguna opción de compilación extra puesto que quizás por defecto no se compile con el demonio del amuled.
Una vez instalado se ejecuta con el comando amuled:
lysandra# amuled
Si se ejecuta con el parámetro -f se iniciará en background, dejando la consola libre para introducir comandos.
Sin embargo con esto solo no se consigue nada, puesto que hay que comunicarse con el demonio del alguna forma, activando el acceso remoto, el amuleweb, etc. Más info en el link de orion220 o sino jugar un poco con las opciones de "Controles remotos" en las opciones del aMule.
Luego para administrar remotamente el amule simplemente llega con abrir el amulegui, que es la interfaz gráfica del amule pero para control remoto, o bien con cualquier navegador web, abriendo una página a la ip del ordenador donde esté el amule, al puerto 4711 (por ejemplo: http://192.168.1.35:4711). En este último caso habrá que iniciar antes el amuleweb.
Para ArchLinux me he hecho un pequeño script para poder arrancarlo como servicio, bien desde el arranque con el rc.conf o bien desde la consola. No funciona del todo bien pero ahí va como referencia:
#!/bin/bash
USER=politvs
. /etc/rc.conf
. /etc/rc.d/functions
PID=`pidof -o %PPID /usr/bin/amuled`
case "$1" in
start)
stat_busy "Starting amuled Daemon"
[ -z "$PID" ] && su "$USER" -c /usr/bin/amuled -f
if [ $? -gt 0 ]; then
stat_fail
else
PID=`pidof -o %PPID /usr/sbin/amuled`
echo $PID >/var/run/amuled.pid
add_daemon amuled
stat_done
fi
;;
stop)
stat_busy "Stopping amuled Daemon"
[ ! -z "$PID" ] &&amp; kill $PID &>/dev/null
if [ $? -gt 0 ]; then
stat_fail
else
rm_daemon amuled
stat_done
fi
;;
restart)
$0 stop
$0 start
;;
*)
echo "usage: $0 {start|stop|restart}"
esac
exit 0
En primer lugar hay que tener instalado en aMule (con Pacman, pkgsrc o el que coincida). En caso de que sea con los ports de los BSDs quizás sea necesario modificar el Makefile para añadir alguna opción de compilación extra puesto que quizás por defecto no se compile con el demonio del amuled.
Una vez instalado se ejecuta con el comando amuled:
lysandra# amuled
Si se ejecuta con el parámetro -f se iniciará en background, dejando la consola libre para introducir comandos.
Sin embargo con esto solo no se consigue nada, puesto que hay que comunicarse con el demonio del alguna forma, activando el acceso remoto, el amuleweb, etc. Más info en el link de orion220 o sino jugar un poco con las opciones de "Controles remotos" en las opciones del aMule.
Luego para administrar remotamente el amule simplemente llega con abrir el amulegui, que es la interfaz gráfica del amule pero para control remoto, o bien con cualquier navegador web, abriendo una página a la ip del ordenador donde esté el amule, al puerto 4711 (por ejemplo: http://192.168.1.35:4711). En este último caso habrá que iniciar antes el amuleweb.
Para ArchLinux me he hecho un pequeño script para poder arrancarlo como servicio, bien desde el arranque con el rc.conf o bien desde la consola. No funciona del todo bien pero ahí va como referencia:
#!/bin/bash
USER=politvs
. /etc/rc.conf
. /etc/rc.d/functions
PID=`pidof -o %PPID /usr/bin/amuled`
case "$1" in
start)
stat_busy "Starting amuled Daemon"
[ -z "$PID" ] && su "$USER" -c /usr/bin/amuled -f
if [ $? -gt 0 ]; then
stat_fail
else
PID=`pidof -o %PPID /usr/sbin/amuled`
echo $PID >/var/run/amuled.pid
add_daemon amuled
stat_done
fi
;;
stop)
stat_busy "Stopping amuled Daemon"
[ ! -z "$PID" ] &&amp; kill $PID &>/dev/null
if [ $? -gt 0 ]; then
stat_fail
else
rm_daemon amuled
stat_done
fi
;;
restart)
$0 stop
$0 start
;;
*)
echo "usage: $0 {start|stop|restart}"
esac
exit 0
Suscribirse a:
Entradas (Atom)