Configuración de ALSA para soporte simultáneo de varios canales

BasaBuru vuelve a la carga y nos regala el siguiente HowTo:

«Este HowTo surge como es habitual en nuestra Comunidad, algo te pica y te rascas 🙂

Estaba bastante frustrado por que tengo la costumbre de trabajar con musica y claro mientras escuchaba musica no podía oír una notificación sonora o lo que es más importante no podía oír una llamada VozIp de nuestro Asterix. Así que dándole unas vueltas, leyendo howtos [0], pues ya lo he resuelto. Usea no perderé una llamada VozIp por oír la musica que me ayuda a trabajar. Pa que lo disfruteis. Eso sí, luego, no me digáis que se os pone la cabeza como un bombo por oír tres canciones a la vez.

8D

Bueno menos rollo y al tema.
—-

Sigue leyendo Configuración de ALSA para soporte simultáneo de varios canales

Ubuntu, Eduroam y la tarjeta Intel 1390

gutsy.png En mi desesperación por hacer funcionar la tarjeta wireless de mi portátil en la red sin cables eduroam (red común de muchas facultades europeas, entre las que afortunadamente se encuentra la de Informática de San Sebastián) he pasado a usar la versión Gutsy (beta) de Ubuntu. Tras algunos sustos (Nautilus no funcionaba, Firefox tampoco, el reloj interno tampoco) y la actualización masiva de paquetes de hoy (ayer no estaban en los repositorios, qué raro…) todo ha vuelto a la normalidad. En esa normalidad se incluye el que mi tarjeta Wireless Intel 1390 no conecta con Eduroam. He probado a conectar sin problemas con otras redes que usan encriptación WEP ó encriptación WPA Personal (a saber qué protocolo de encriptación concreto es este último, pero es la opción que aparece en el Network Manager para la conexiónb wifi FON – la privada, no la pública – de mi casa). Todo ok. Pero en Eduroam es imposible, no puedo conectar con Ubuntu y esta tarjeta. Curioso, porque desde el mismo portátil, arrancando en Windows, conecto sin problemas. Curioso también el que el driver que estoy usando en Linux, es exactamente el mismo que uso en Windows, dado que uso NDISWRAPPER.

Tras varias horas de tirarme de los pelos, creo que al menos, sé dónde está el error:
$ wpa_supplicant -dd -B -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf -D ndiswrapper

WEXT: Operstate: linkmode=1, operstate=5
Own MAC address: 00:XX:XX:XX:XX:XX
Driver does not support WPA.
wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0

La tercera línea viene a indicar que el driver que estoy usando no soporta WPA. Lo cual es muuuuuuyyyyy extraño, dado que en casa, en la red privada MyPlace (señal cifrada con WPA) de la red FON de mi casa no tengo ningún problema para conectar.

Si tras la orden anterior intento usar dhclient para obtener IP del punto de acceso:

root@laptop:/home/juanan# dhclient wlan0
Internet Systems Consortium DHCP Client V3.0.5
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/wlan0/00:xx:xx:xx:xx:xx
Sending on LPF/wlan0/00:xx:xx:xx:xx:xx
Sending on Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 13
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 2
No DHCPOFFERS received.
No working leases in persistent database – sleeping.

No sé si tirar la toalla o seguir intentándolo… sólo me queda una bala, y es usar el driver nativo para la 1390 que acabo de encontrar aquí (aún sabiendo que no es un sitio oficial de drivers).

Por otro lado, tras la actualización, por fin he conseguido conectar mi Linux al proyector del aula en la que imparto clases. ¡Ya no más trasvases de .odp al sistema de Redmond! 🙂

¿Demasiada Google-Dependencia?

google_docs.png«The server encountered an error». Es el mensaje que me lleva dando varios días seguidos Google Docs. He probado a borrar las cookies, a entrar desde diferentes navegadores (incluso el del maligno), a entrar por https vs. http, … nada. De nada. Sigo con el mismo error: «The server encountered an error. Please try again later». Pues qué bien. Lo que más me duele es que estos días he estado trabajando sobre un documento online y no se me ocurrió hacer backup (Pensamiento inocente: «¿Para qué, si Google nunca falla?») ¡aaargghh! ¡Sí que falla! En fin, ¿soy el único sin acceso a Google Docs en el planeta? ¿Alguna sugerencia aparte de hacer backups de todo lo que suba a Google? (del resto ya lo hacía)

Nota lateral: estoy pensando que tengo demasiada Google dependencia. Gmail, Calendar, Notebook, Code Hosting, Docs, Video… Creo que voy a patrocinar un proyecto fin de carrera para crear una aplicación de Google-backups para Linux ¿Voluntarios? 🙂

Soporte SOCKS con SSH. O cómo navegar de forma ‘más segura’

socks.pngssh cada vez me sorprende más. Las posibilidades que ofrece son inmensas, es com una navaja suiza de las comunicaciones. Al principio sólo lo usas para conexiones seguras. Luego le vas sacando punta con el uso de claves públicas, más tarde te enteras de la posibilidad de port forwarding, luego de la posibilidad de montar por ssh en local un directorio remoto, y ahora del soporte de port forwarding dinámico, es decir, del soporte SOCKS, que la Wikipedia define como: » protocolo de Internet que permite a las aplicaciones Cliente-servidor usar de manera transparente los servicios de un firewall de red. SOCKS es una abreviación de ‘SOCKetS'».

¿Y traducido al castellano? 🙂 Veámoslo con un caso práctico. En la facultad, tienes una conexión a Internet buena, pero no te fías de posibles intrusos, sniffers y demás. Y quieres actualizar tu blog a través de una conexión http (lo ideal sería https, pero…) sin que tu password vaya a caer al saco de los passwords capturados. Te gustaría enviar la información web cifrada SIEMPRE, independientemente de si usas http o https (al menos, te gustaría enviarla cifrada hasta un punto seguro, a partir del cual, te fías más y desde el que no te «molesta» tanto que vaya sin cifrar). Además, has leído que, si dispones de acceso ssh a algún servidor, puedes usarlo como trampolín (la información viajará cifrada hasta ese servidor y a partir de ahí, se usará como puente hacia la web que quieras acceder. La respuesta será recogida por el servidor ssh y éste nos la devolverá cifrada).

Bien, éste es el procedimiento: vamos a configurar un servidor SOCKS con ssh. Para ello:


$ ssh -l usuario -f -N -D 1082 servidor.com sleep 7200 <--- tenemos acceso ssh a servidor.com Ahora, en Firefox, abrimos Editar/Preferencias/Avanzado/Red/Configuración/ Seleccionamos Configuración manual del Proxy y en la casilla "Servidor SOCKS" ponemos: localhost En la casilla puerto, ponemos: 1082 (el mismo que hayamos elegido en el comando ssh anterior, no tiene por qué ser 1081) Pulsamos Aceptar y Cerrar. Ya puedes navegar de forma "algo más segura" 🙂 (¡y usando la IP del servidor SSH !) Esto último puede tener muchos e interesantes usos... Nota: -f es para hacer fork del proceso. -N es para evitar que se ejecuten comandos en la sesión ssh abierta. sleep 7200 es un comando cualquiera que no hace nada (para poder usar -f hay que dar un comando inicial a ejecutar. A partir de ahí el proceso se quedará residente en segundo plano.)

Convertir de hexadecimal a decimal con dc

dc es una calculadora de notación polaca inversa para la línea de comandos. Si tienes un número en hexadecimal que quieres convertir a decimal de forma rápida, es una buena herramienta, dado que está disponible en casi cualquier sistema Linux por defecto. El procedimiento es sencillo:

Lanzamos dc:

$ dc

Tecleamos ahora:

16i

con lo que indicamos que vamos a teclear un número en hexa. Lo tecleamos (o pegamos) teniendo en cuenta que las letras del número deben de ir en mayúsculas:

009F77085BF7BE73E0DEC1353AE973E5CCACDB84458FD21331BB73907C77578019

y ahora le pedimos que convierta con el comando p:
p

72128055418864388239811665381831147739297500507689951365215045997288224161817

Para salir, pulsamos q.

Nota: si tienes curiosidad por saber qué estoy haciendo con un número en hexa tan grande, la respuesta es: factorizarlo.