wpa sin networkmanager

Algo que no me convencía era depender de networkmanager (y de gnome por lo tanto) para poder asociarme a una red wpa, así que aquí va la papa..

ejemplo práctico:

root@casper:/# apt-get install wpasupplicant

root@casper:/# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

eth1 unassociated ESSID:"HOMELINUX"
Mode:Managed Frequency=2.462 GHz Access Point: Not-Associated
Bit Rate:0 kb/s Tx-Power=20 dBm Sensitivity=8/0
Retry limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:25 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:18 Missed beacon:0

root@casper:/# iwlist eth1 scan
eth1 Scan completed :
Cell 01 - Address: 00:0E:2E:8D:2A:2A
ESSID:"HOMELINUX"
Protocol:IEEE 802.11bg
Mode:Master
Channel:11
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
48 Mb/s; 54 Mb/s
Quality=91/100 Signal level=-37 dBm
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (1) : TKIP
Authentication Suites (1) : PSK
Extra: Last beacon: 32ms ago

editamos /etc/wpa_supplicant.conf y agregamos

ctrl_interface=/var/run/wpa_supplicant

network={
ssid="HOMELINUX"
proto=WPA RSN
key_mgmt=WPA-PSK
pairwise=TKIP CCMP
group=TKIP CCMP
psk="acavalaclaveentextoplano"
priority=5
}

y con esto ya estamos en condiciones de empezar a trabajar.

bastará con hacer:
wpa_supplicant -Bw -Dwext -ieth1 -c/etc/wpa_supplicant.conf

y revisar con iwconfig que estemos realmente asociados

root@casper:/# iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

eth1 IEEE 802.11g ESSID:"HOMELINUX"
Mode:Managed Frequency:2.462 GHz Access Point: 00:0E:2E:8D:2A:2A
Bit Rate:54 Mb/s Tx-Power=20 dBm Sensitivity=8/0
Retry limit:7 RTS thr:off Fragment thr:off
Encryption key:5493-7EE8-B928-CB64-E684-7AE5-21BF-AF6A-6B89-B569-3A7B-853F-2133-45DE-384F-9EF6 Security mode:open
Power Management:off
Link Quality=85/100 Signal level=-45 dBm Noise level=-89 dBm
Rx invalid nwid:0 Rx invalid crypt:26 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:18 Missed beacon:0

por último tomaremos ip (en este caso por dhcp) con

dhclient eth1


Listening on LPF/eth1/00:16:6f:2f:a7:7c
Sending on LPF/eth1/00:16:6f:2f:a7:7c
Sending on Socket/fallback
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPACK from 192.168.1.1
bound to 192.168.1.11 -- renewal in 391401 seconds.
root@casper:/# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:16:6F:2F:A7:7C
inet addr:192.168.1.11 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:81 errors:26 dropped:44 overruns:0 frame:0
TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:639358 (624.3 KiB) TX bytes:261481 (255.3 KiB)
Interrupt:17 Base address:0xa000 Memory:bc008000-bc008fff

Y eso es todo...

si queremos mantenerlo de forma persistente y evitar estos pasos basta con editar /etc/network/interfaces

auto eth1
iface eth1 inet dhcp
wireless-essid HOMELINUX
pre-up wpa_supplicant -Bw -Dwext -iethX -c/etc/wpa_supplicant.conf
post-down killall -q wpa_supplicant
EOF

tunneling over ssh

No es nada que no se pueda encontrar leyendo el man de ssh pero sirve para recordarlo.
Sabía que se podía hacer un tunel sobre ssh para acceder a otros puertos/servicios dentro del servidor de destino, pero nunca había probado tratar de acceder a servicios corriendo en maquinas que pertenecían a la red local detrás de ese servidor.

En escencia lo que logramos es evitar cargar reglas para el forward con iptables o similares y poder levantar servicios externamente que no estén visibles normalmente (incrementando la seguridad) a través de un medio encriptado.

bueno.. acá va la papa:

ssh -C -N -L [bindaddress:]port:host:porthost servidor

donde -C indicará que comprima, -N que no se van a ejecutar comandos en "host", -L que haga el tunel en el servidor de destino

Siendo

bindaddress: opcional para indicar a que ip se realizará el tunel (normalmente si no se especifica es 127.0.0.1)
port: el puerto local donde esuchará el servicio una vez establecido el tunel
host: la ip de la maquina destino detrás del servidor al cual estamos accediendo
porthost: es el puerto del servicio que corre en la maquina a la cual queremos acceder
servidor: la ip del servidor publico


y bueno .. eso es todo

Linux RAS

####################################################
### howto linux RAS v0.1 / joemac@lugmen.org.ar / 2007 - 06 - 06 ###
####################################################

Creo que deben existir algo más de 30millones de tutoriales sobre como configurar un ras en linux, pero bueno... para no olvidarme acá va uno más.

CONFIG MODEM SMARTLINK USB
---------------------------
Comenzamos para este caso bajando los drivers apropiados para manejar estos modems genéricos, dependiendo de la distribución sera en mayor o menor medida dificil dejarlo en condiciones. pero basicamente tendremos que tener por lo menos los headers del kernel que estemos usando (en el caso de los precompilados) para poder generar el modulo que se insertará luego en /lib/modules/kernelver/misc/

En mi caso al instalarlo en una distribución basada en debian pude usar module-assistant que se encargó de bajar el driver-source de este modem y algunas cosillas mas para automatizar la carga de este al arranque (creación de nodos, etc)

Por alguna razón los nodos que creo para este modem se borran (solo los lsusb, los lsamr permanecen estáticos) pero como solo lo necesito para una presentación y no planeo usarlo luego podemos crearlos a mano.

mknod -m 600 /dev/slamr0 c 242 0 ; mknod -m 600 /dev/slamr1 c 242 1 ; mknod -m 600 /dev/slamr2 c 242 2 ; mknod -m 600 /dev/slamr3 c 242 3 ; echo -n
mknod -m 600 /dev/slusb0 c 243 0 ; mknod -m 600 /dev/slusb1 c 243 1 ; mknod -m 600 /dev/slusb2 c 243 2 ; mknod -m 600 /dev/slusb3 c 243 3 ; echo -n


luego de esto hay qe cargar el módulo slusb (si es que no se autocargó con udev y hotplug) y ejecutar

slmodemd /dev/slusb0 (con esto creamos el enlace simbolico a /dev/ttySL0)

CONFIG MGETTY
-------------------------
Para mi caso solo necesito agregar a /etc/mgetty/login.config

/AutoPPP/ - a_ppp /usr/sbin/pppd file /etc/ppp/options.SL0

Con lo cual le especificamos que auto levante ppp cuando reciba una conexion en el modem y que use los parámetros especificados en options.SL0

CONFIG PPP
-------------------------
Acá vamos a definir los métodos de conexion permitidos, velocidades, dns, ip, etc

Para este caso creamos el archivo /etc/ppp/options.SL0 con lo siguiente:

-detach
asyncmap 0
modem
crtscts
proxyarp
lock
require-pap
refuse-chap
ms-dns 192.168.10.2
usepeerdns
192.168.10.3:192.168.10.250
noauth

La primera ip es la que se le asignará al modem del lado del servidor al momento de establecer la conexión y la segunda es la ip que se le asignará al modem cliente que está llamando

Luego editamos /etc/ppp/pap-secrets agregando

* * "" *

Es bastante precario poner esto pero lo cierto es que por el momento para esta prueba no requería de más. (Si se desea pueden poneres usuarios y passwords específicos para determinada conexión o determinada ip)

PUESTA EN MARCHA
---------------------------

Luego de esto estamos en condiciones de aceptar conexiones entrantes y atenderlas con mgetty

Desde una terminal ejecutamos

mgetty /dev/ttySL0

(Podemos también si es nuestra intención dejar este servicio andando continuamente si agregamos a /etc/inittab
SL0:2345:respawn /sbin/mgettty /dev/ttySL0)

y probamos conectarnos desde alguna máquina remota con user y pass de alguien que esté creado en el sistema. (creando una conexión de acceso telefónico por ej)


Para habilitar el acceso a otros puntos de la red y compartir internet por ej, hacemos:

echo "1" > /proc/sys/net/ipv4/ip_forward

y listo tenemos acceso a la red local. Podriamos jugar un poco con iptables para hacer los ruteos un poco mas convenientes pero este no es el caso.


ALTERNATIVA SIN LINEA TELEFONICA (enlace punto a punto directo)
---------------------------

Una alternativa es usar programas como minicom y al momento de efectuar la llamada desde el cliente levantar el modem con un ATA y posteriormente insertar un script (que lleve /sbin/mgetty -r /dev/ttySL0), esto se hace ejecutando Alt+K pero debe haberse definido previamente en la configuración de minicom este script.
Puede ser que mgetty no atienda porque quiera trabajar sobre el mismo lockfile que minicom, podemos solucionarlo editando la configuración de minicom y estableciendo un nuevo archivo (en una ruta distinta) para el lock.
Por ej: originalmente está en /var/lock, y podríamos cambiarlo a /tmp/lock (cada programa usará un lock propio)

EOF

Wi-Fi en mi laptop

Estos son los pasos que tuve que hacer para configurar la tarjeta de red inalambrica de mi laptop en Ubuntu.
Después de haber leído mucha info que hay dando vuelta por internet sin obtener los resultados que quería y llegando a pensar que mi tarjeta de red wi-fi ya no servia para nada, no me quedo otra que profundizar en el tema y ver que rayos era el problema.
El problema principal que tuve fue el de encontrar el driver adecuado para mi chipset más alla de que en muchas guías y howtos dicen bajate este driver que es el que funciona.
Probé muuuuchos drivers que encontré, pero para saber cual es que funciona hay que buscar el ID del dispositivo PCI, se puede ver con
$ lspci | grep BCM
05:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
y el primer número de la línea nos sirve como identificador para buscar el ID usando lspci -n 05:02.0
entonces en este caso el ID es 14e4:4318, los primeros 4 digitos son el ID del fabricante y los otros son el ID del dispositivo. Estos últimos 4 son los números que tenemos que buscar en los archivos .ini que acompañan al driver que descargamos. Por ejemplo, tengo 10 directorios, cada uno con un driver que encontré en internet y que supuestamente era el que funcionaba. Si hago un cat *.ini | grep 4318 en cada directorio, puedo ver solo 2 tienen una línea que menciona al identificador de mi tarjeta wi-fi. Y estos son los drivers que funcionaron en mi laptop.
Una vez que tenemos identificado el driver que funciona, tenemos que instalar el firmware para que el módulo de nuestro kernel lo utilize al ser cargado.
Esto lo podemos hacer con el paquete bcm43xx-fwcutter que se encuentra en los repositorios de Ubuntu.
Para instalar el firmware solo tenemos que hacer
$ sudo bcm43xx-fwcutter -w /lib/firmware/ driver.sys
Con esto debería estar instalado y solo faltaría hacer un
$ sudo rmmod bcm43xx
$ sudo modprobe bcm43xx
Para recargar el módulo y que comienze a funcionar.

-- Actualización 17.05.2007 --
Después de probar el módulo bcm43xx que viene con el kernel, creo que es mejor usar ndiswrapper; ya que proporciona mejor desempeño que el bcm43xx, que por ejemplo solo se conecta a 11M y con ndiswrapper llego a 54M.
Lo que hace ndiswrapper es usar directamente el driver para Windows de la tarjeta Wi-Fi.

Instalando una TDM400P sobre Etch

Introducción
Para que Asterisk pueda hacer uso de la red telefónica conmutada (PSTN) es necesario contar con una interfaz, la misma la proveen los módulos de hardware FXS o FXO, que permiten la interconexión directamente a teléfonos o a las líneas telefónicas. En mi caso tengo una TDM400P que tiene integrados dos módulos FXO y dos módulos FXS. Todo esto lo haremos funcionar sobre un Debian GNU/Linux Etch con kernel 2.6.17.

Instalación
Una vez que la placa esta instalada en el slot correspondiente del motherboard, hay que hacer que nuestro sistema operativo pueda usarla. Para esto tenemos que instalar el controlador adecuado para esta placa. Podriamos usar la versión empaquetada que se encuentra en los repositorios oficiales de Debian, pero como queremos instalar la última versión, los descargamos desde http://ftp.digium.com/pub/zaptel/zaptel-1.4-current.tar.gz
Hay que tener instaladas los paquetes de desarrollo como linux-headers build-essential, entre otros. Una vez descargado hacemos

tar zxvf zaptel-1.4-current.tar.gz
make linux26
sudo make install

Con esto ya tendriamos los módulos para el kernel listos.
Para probarlos podemos hacer

sudo modprobe zaptel
sudo modprobe wctdm

si todo salió bien no deberían haber mensaje de error. Y podemos comprobar con dmesg que aparecen estas líneas.

Module 0: Installed -- AUTO FXS/DPO
Module 1: Installed -- AUTO FXS/DPO
Module 2: Installed -- AUTO FXO (FCC mode)
Module 3: Installed -- AUTO FXO (FCC mode)
Found a Wildcard TDM: Wildcard TDM400P REV I (4 modules)
Registered tone zone 0 (United States / North America)

Con esto solo restaría toquetear un poco el archivo de configuración /etc/zapata.conf, agregandole estas

fxsks=1-2
fxoks=3-4

Eso es todo! con esto ya podremos hacer uso de los canales Zap en nuestro Asterisk.