Notas y recetas informáticas

Categoría: Enredando

  • Cambiar el TTL de paquetes IP ya enviados por la aplicación

    Cada paquete IP tiene en su cabecera un campo llamado TTL (Time To Live) destinado a evitar que el paquete quede eternamente circulando por la red en caso de algún problema de enrutamiento. Aunque el significado de sus siglas haga referencia al tiempo de vida, en realidad el valor del campo TTL representa el número máximo de saltos que puede dicho paquete realizar entre distintas redes.

    Para que esto se cumpla, cada vez que el paquete es enrutado de una red a otra, se decrementa el valor TTL del paquete. Si al pasar de una red a otra el campo TTL alcanza el valor 0 entonces el paquete se descarta sin enviarse a la siguiente red IP.

    Cada sistema operativo da un valor por defecto de TTL distinto a los paquetes unicast (con dirección IP de destino de un equipo concreto) que suele ser suficiente para alcanzar cualquier otro equipo del mundo a través de Internet (en Linux este valor es 64). Sin embargo, para los paquetes multicast (con dirección IP de destino de un grupo, no de ningún equipo concreto) el valor por defecto es 1, de modo que los paquetes multicast, por defecto, no puedan ser reenviados a otras redes distintas de aquella en la que se originaron.

    Afortunadamente, las aplicaciones pueden indicar que desean aplicar un TTL distinto a los paquetes multicast enviados por cierto socket. Según la norma POSIX se hace de la siguiente forma:

    unsigned char ttl = 16;
setsockopt(socket, IPPROTOIP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));

    También se puede establecer el TTL de forma genérica para todos los paquetes enviados utilizando la opción IP_TTL, en lugar de IP_MULTICAST_TTL.

     

    Bueno vale, pero el título dice que los paquetes ya están enviados por la aplicación. Es decir, no controlo o no puedo modificar la aplicación, así que, ¿qué se puede hacer si no se puede modificar cierta aplicación y se necesita cambiar el TTL de los paquetes que envía?

    socat

    Una solución obvia y bastante sencilla consiste en desplegar una aplicación que reciba dichos paquetes y reenvíe su contenido estableciendo el TTL como se desee. Esto se puede hacer de forma bastante sencilla con la aplicación socat. El siguiente ejemplo muestra como utilizarla para recibir unos paquetes multicast y reenviarlos con TTL 16 a otra dirección multicast:

    socat UDP4-RECV:$ORIGINAL_DEST_PORT,bind=$ORIGINAL_DESTINATION_IP,ip-add-membership=$ORIGINAL_DESTINATION_IP:$INGRESS_INTERFACE,reuseaddr UDP4-SENDTO:$NEW_DESTINATION_IP:$NEW_DESTINATION_PORT,ip-multicast-ttl=16,bind=$EGRESS_SOURCE_IP

    Esta orden abrirá un socket UDP de escucha en el puerto $ORIGINAL_DEST_PORT, asociado al interfaz (o interfaces) que correspondan a la dirección IP multicast $ORIGINAL_DESTINATION_IP y realizando la suscripción IGMP a la dirección de grupo multicast $ORIGINAL_DESTINATION_IP por el interfaz especificado por $INGRESS_INTERFACE. Los paquetes que reciba los enviará a la dirección IP $NEW_DESTINATION_IP y al puerto $NEW_DESTINATION_PORT con TTL 16 utilizando como dirección IP de origen $EGRESS_SOURCE_IP.

    iptables

    Otra solución mucho más versátil consiste en utilizar IPTABLES para modificar los paquetes mientras atraviesan la cadena de salida OUTPUT antes de que el sistema entregue el paquete al interfaz de red.

    La modificación del TTL solo se puede realizar en la tabla mangle, por lo que el comando IPTABLES para realizar este cambio sería el siguiente:

    iptables -t mangle -A OUTPUT -d $ORIGINAL_DESTINATION_IP -j TTL --ttl-set 16

     

  • El extraño caso del bonding medio sordo

    Una técnica muy utilizada para proporcionar mayor disponibilidad y capacidad a la conexión entre dos equipos consiste en utilizar simultáneamente varios enlaces físicos entre ambos, formando un grupo de agregación de enlaces o LAG (Link Aggregation Group). LAG considero que es el término más correcto, aunque también son conocidos como port channel en el mundo de las redes o bonding en el mundo GNU/Linux. También, aunque de forma incorrecta en mi opinión, se les llama a veces trunk (de una tecnología propietaria llamada port trunking), esto a mí me resulta ambiguo, porque el uso más generalizado del término es para referrirse a un puerto de un switch por el que se permite tráfico de varias VLAN.

    El caso es que para proporcionar mayor ancho de banda a un nuevo servidor de ficheros se quiere establecer un LAG entre este y el correspondiente conmutador (bonito término castellano para un switch). Esto, en principio, es bastante sencillo, sobre todo teniendo en cuenta que el servidor corre un Red Hat Enterprise Linux 7.3 (suficientemente moderno, su núcleo es la versión 3.10 de Linux) y el switch es un Cisco que ha costado más de lo que amortizo de hipoteca en un año.

    Para establecer el LAG entre el servidor y el switch se va a utilizar el protocolo LACP (Link Aggregation Control Protocol), soportado por ambos.

    El switch se configura creando un nuevo interfaz del tipo PortChannel, que será un interfaz virtual que representa al grupo de agregación, y añadiendo los interfaces físicos a utilizar a dicho grupo.

    Aquí llamaremos al port channel port-channel1 (Po1 para los amigos) y añadiremos a su grupo los interfaces Ethernet1/1 al Ethernet1/4.

    interface Po1

interface Eth1/1 - 4
  channel-group 1

    Con esto es suficiente, ya que aunque hay varias formas de establecer el LAG, el modelo de switch utilizado usa el protocolo LACP por defecto. Como se verá más adelante, suponer que LACP era utilizado por defecto fue la causa del problema.

    En el servidor se hace de forma similar creando un ficheo de configuración para el bonding que llamaremos bond0 y cambiando la configuración de los interfaces físicos a añadir al LAG.

    /etc/sysconfig/network-scripts/ifcfg-bond0:

    TYPE=Bond
BOOTPROTO=none
NAME=bond0
DEVICE=bond0
ONBOOT=yes
BONDING_MASTER=yes
IPADDR=192.168.10.10
GATEWAY=192.168.10.1
PREFIX=24
BONDING_OPTS="mode=4 miimon=100 lacp_rate=1"

    Aquí es necesario indicar el modo del bonding, ya que soporta varios tipos de funcionamiento, el modo 4 utilizado es el que corresponde al protocolo 802.3ad, es decir LACP. El parámetro miimon indica cada cuantos milisegundos se debe comprobar si un interfaz del bonding tiene enlace, si se detecta que no tiene enlace será extraído del LAG inmediatamente. El parámetro lacp_rate indica cada cuantos segundos se envía un paquete de control de LACP (LACPDU).

    Los interfaces miembro del LAG se configuran así:

    /etc/sysconfig/network-scripts/ifcfg-eth0

    TYPE=Ethernet
BOOTPROTO=none
NAME=eth0
DEVICE=eth0
ONBOOT=yes
MASTER=bond0
SLAVE=yes

    Una vez configurados los interfaces del servidor (habrá que reiniciar los servicios de red) y el switch se debe establecer el LAG entre ambos.

    Para ver el estado del interfaz bond0 se puede consultar el fichero /proc/net/bonding/bond0, aunque también podemos obtener suficiente información con un simple listado de los interfaces:

    #ip link
...
8: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT qlen 1000
    link/ether a0:b6:cf:d0:2d:f8 brd ff:ff:ff:ff:ff:ff
9: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT qlen 1000
    link/ether a0:b6:cf:d0:2d:f8 brd ff:ff:ff:ff:ff:ff
10: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT qlen 1000
    link/ether a0:b6:cf:d0:2d:f8 brd ff:ff:ff:ff:ff:ff
...

    Aquí se ve que hay dos interfaces eth0 y eth1 en modo SLAVE (parte de un bonding) y que hay un interfaz en modo MASTER (el bonding), todos están UP (tienen enlace) y todos tienen la misma MAC (como debe ser), ya que todos los interfaces físicos actúan «en representación» del interfaz de bonding.

    En el switch también parece estar todo bien:

    #sh int Po1
port-channel1 is up
admin state is up,
  Hardware: Port-Channel, address: a4bd.c6db.aac9 (bia a4bd.c6db.aac9)
  MTU 1500 bytes, BW 20000000 Kbit, DLY 10 usec
  reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, medium is broadcast
  Port mode is access
  full-duplex, 10 Gb/s
  Input flow-control is off, output flow-control is off
  Auto-mdix is turned off
  Switchport monitor is off
  EtherType is 0x8100
  Members in this channel: Eth1/1, Eth1/2, Eth1/3, Eth1/4
  Last clearing of "show interface" counters never
  1 interface resets
  30 seconds input rate 2328 bits/sec, 1 packets/sec
  30 seconds output rate 2520 bits/sec, 1 packets/sec
  Load-Interval #2: 5 minute (300 seconds)
    input rate 12.83 Mbps, 1.02 Kpps; output rate 139.13 Kbps, 181 pps
  RX
    2705286 unicast packets  3316 multicast packets  3932 broadcast packets
    2712534 input packets  3986560464 bytes
    0 jumbo packets  0 storm suppression packets
    0 runts  0 giants  0 CRC  0 no buffer
    0 input error  0 short frame  0 overrun   0 underrun  0 ignored
    0 watchdog  0 bad etype drop  0 bad proto drop  0 if down drop
    0 input with dribble  0 input discard
    0 Rx pause
  TX
    510610 unicast packets  29736 multicast packets  3699 broadcast packets
    544045 output packets  53042671 bytes
    0 jumbo packets
    0 output error  0 collision  0 deferred  0 late collision
    0 lost carrier  0 no carrier  0 babble  0 output discard
    0 Tx pause

    En esta información lo importante es que el port channel está UP y que el ancho de banda del mismo es 20.000.000 Kbit. El ancho de banda indica que hay dos puertos, de los cuatro que son miembros del port channel, que están conectados (se trata de puertos de 10 Gbps).

    Viendo esto todo parece estar bien, sin embargo, al hacer un ping a otro equipo que se envía por dicho interfaz resulta que no hay respuesta:

    # ping 192.168.10.20
PING 192.168.10.20 (192.168.10.10) 56(84) bytes of data.
From 192.168.10.10 icmp_seq=1 Destination Host Unreachable
From 192.168.10.10 icmp_seq=2 Destination Host Unreachable

    Habrá que investigar, para ello lo primero comprobar qué pasa por el interfaz bond0:

    # tcpdump -nn -i bond0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:59:12.717212 ARP, Request who-has 192.168.10.20 tell 192.168.10.10, length 28
11:59:13.719184 ARP, Request who-has 192.168.10.20 tell 192.168.10.10, length 28

    Y así sucesivamente, es decir, los ARP no obtienen respuesta, pero eso ¿por qué? Indaguemos un poco más y veamos el tráfico en cada interfaz:

    # tcpdump -nn -i eth0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:01:53.985192 ARP, Request who-has 192.168.10.20 tell 192.168.10.10, length 28
12:01:54.987189 ARP, Request who-has 192.168.10.20 tell 192.168.10.10, length 28

    Vale, el bond0 está utilizando el interfaz eth0 para envíar las consultas ARP y no obtiene respuesta. Veamos entonces si hay algo extraño en el eth1:

    # tcpdump -nn -i eth1
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
12:03:21.343287 ARP, Reply 192.168.10.20 is-at a0:d6:cf:d0:32:b0, length 46
12:03:22.940519 ARP, Reply 192.168.10.20 is-at a0:b6:cf:d0:32:b0, length 46

    Bueno, no es muy extraño, la política de reparto de carga entre los enlaces no es la misma en el switch que en el servidor, por lo que el servidor envía una consulta ARP por un interfaz y la recibe por el otro. A mí me parece normal.

    Entonces, ¿por qué no pasan las respuetas ARP del interfaz eth1 al bond0? Pues porque el bonding está medio sordo. Pero, ¿por qué está medio sordo el bonding?

    Comienza la investigación por el Interné: Google, a ver qué encuentras sobre esto: «Linux bonding medio sordo». Pero parece que nadie ha escrito aún sobre esto, bueno a ver en inglés: «Linux bonding half deaf». Tampoco.

    En fin, toca leer la documentación del módulo de bonding y relacionada. Así, que tras no encontrar nada muy claro y buscar de todo relacionado con el bonding y 802.3ad dí con el artículo que me dio la clave (aunque trataba de otro problema): [Linux Bonding] 802.3ad bond interface has shown RX dropped packets.

    En ese artículo hablaba de que el bonding, de manera premeditada y (en otros casos, desde luego) correcta, descartaba los paquetes recibidos por los interfaces no activos del bonding. Esto está muy bien cuando el modo del bonding es tal que unos interfaces están activos y otros no, que no es el caso del modo 4, 802.3ad o LACP.

    Lo importante es que daba la clave de como evitar eso, el parámetro all_slaves_active. Así, estableciendo ese parámetro a uno se puede hacer un apaño y permitir que los paquetes recibidos por el interfaz eth1 sean admitidos y lleguen como recibidos por el interfaz bond0.

    # echo 1 > /sys/class/net/bond0/bonding/all_slaves_active

    Pero, como he dicho, eso es solo un apaño, ya que el problema de fondo aún está ahí. ¿Y cuál es ese problema? Pues que el bond0 no considera activo el interfaz eth1, pasa de él, como se deduce de lo siguiente:

    # ethtool bond0
Settings for bond0:
        Supported ports: [ ]
        Supported link modes:   Not reported
        Supported pause frame use: No
        Supports auto-negotiation: No
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 10000Mb/s
        Duplex: Full
        Port: Other
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        Link detected: yes

    El ancho de banda del interfaz es 10.000Mbps, es decir, lo que da un interfaz. Si estuviera utilizando los dos sería 20.000Mbps, como se vió en el estado del LAG en el lado del switch.

    Por tanto el switch ha activado ambos enlaces del LAG (como se ve al recibir tráfico por los dos interfaces en el servidor), pero el servidor solo ha activado uno.

    Mirando el detalle del estado del bonding se ve lo siguiente:

    # cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: a0:b6:cf:d0:2d:f8
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 1
        Actor Key: 13
        Partner Key: 1
        Partner Mac Address: 00:00:00:00:00:00

Slave Interface: eth0
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: a0:b6:cf:d0:2d:f8
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: churned
Actor Churned Count: 0
Partner Churned Count: 1
details actor lacp pdu:
    system priority: 65535
    system mac address: a0:b6:cf:d0:2d:f8
    port key: 13
    port priority: 255
    port number: 1
    port state: 77
details partner lacp pdu:
    system priority: 65535
    system mac address: 00:00:00:00:00:00
    oper key: 1
    port priority: 255
    port number: 1
    port state: 1

Slave Interface: eth1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: a0:b6:cf:d0:2d:fa
Slave queue ID: 0
Aggregator ID: 2
Actor Churn State: churned
Partner Churn State: churned
Actor Churned Count: 1
Partner Churned Count: 1
details actor lacp pdu:
    system priority: 65535
    system mac address: a0:b6:cf:d0:2d:f8
    port key: 13
    port priority: 255
    port number: 2
    port state: 69
details partner lacp pdu:
    system priority: 65535
    system mac address: 00:00:00:00:00:00
    oper key: 1
    port priority: 255
    port number: 1
    port state: 1

    Una mente avezada no hubiera pasado por alto (al contrario de como hice yo inicialmente) la discordancia en los «Aggregator ID» de ambos interfaces miembros del bonding. Estaba empeñado en que la culpa era de la configuración del bonding pero, preguntándole a Google por qué puede haber diferentes aggregator ID, me dice un par de cosas. En StackExchange ya me confirman algo que no terminaba de interpretar correctamente en la documentación del bonding, y es que los diferentes aggregator ID están destinados a hacer grupos de interfaces separados dentro del bonding, utilizando solo uno de ellos. Esto me hace pensar que, tal vez, el switch esté haciendo algo mal.

    La confirmación de esto la tuve en esta entrada del foro de CentOS, Only 1 NIC used in the bond, ahí se apuntaba a una entrada de un blog en la que se trataba otro síntoma, la MAC 00:00:00:00:00:00 del otro extremo. En esta entrada se remarca en negrita que lo que hay que hacer es comprobar que el port channel está en modo activo (LACP). Así que fui a hacer la comprobación:

    # show port-channel database
port-channel1
    Last membership update is successful
    4 ports in total, 2 ports up
    First operational port is Ethernet1/1
    Age of the port-channel is 0d:20h:20m:41s
    Time since last bundle is 0d:20h:20m:51s
    Last bundled member is Ethernet1/4
    Ports:   Ethernet1/1    [on] [up]
             Ethernet1/2    [on] [up] *
             Ethernet1/3    [on] [down]
             Ethernet1/4    [on] [down]

     Había supuesto erróneamente que el modo por defecto era LACP, cuando en realidad era ON. En el modo on el switch simplemente añade los puertos al port channel si tienen enlace, sin más. Por tanto para el switch los dos puertos conectados al servidor formaban parte del port channel y, consecuentemente repartía el tráfico de salida entre ellos. Pero como el servidor estaba en modo LACP y no lograba negociar la agregación con este protocolo, asigna cada interfaz a un grupo de agregación distinto y utiliza solo uno de los grupos, formado por un solo interfaz.

    La solución parecía ya al alcance de las manos.

    # configure terminal
(config)# interface Eth1/1 - 4
(config-if-range)# no channel-group 1
(config-if-range)# channel-group 1 mode active
LACP process needs to be started before configuring active or passive mode

    Resulta que ni siquiera estaba activada la capacidad LACP en el switch. En NX-OS la mayoría de capacidades del switch vienen desactivadas por defecto y hay que activarlas antes de utilizarlas. Activémosla pues y repitamos:

    (config)# feature lacp
(config)# interface Eth1/1 - 4
(config-if-range)# channel-group 1 mode active
(config-if-range)# sh port-channel database
port-channel1
    Last membership update is successful
    4 ports in total, 0 ports up
    Age of the port-channel is 0d:20h:34m:57s
    Time since last bundle is 0d:00h:00m:48s
    Last bundled member is Ethernet1/1
    Time since last unbundle is 0d:00h:04m:50s
    Last unbundled member is Ethernet1/4
    Ports:   Ethernet1/1    [active ] [up]
             Ethernet1/2    [active ] [up] *
             Ethernet1/3    [active ] [down]
             Ethernet1/4    [active ] [down]
(config-if-range)# copy running-config startup-config
[########################################] 100%
Copy complete, now saving to disk (please wait)...

    Ahora.

    Comprobemos el otro lado:

    # cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: a0:b6:cf:d0:2d:f8
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 2
        Actor Key: 13
        Partner Key: 110
        Partner Mac Address: 00:01:02:03:aa:fc

Slave Interface: p4p1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 2
Permanent HW addr: a0:b6:cf:d0:2d:f8
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 1
Partner Churned Count: 2
details actor lacp pdu:
    system priority: 65535
    system mac address: a0:b6:cf:d0:2d:f8
    port key: 13
    port priority: 255
    port number: 1
    port state: 61
details partner lacp pdu:
    system priority: 32768
    system mac address: 00:01:02:03:aa:fc
    oper key: 110
    port priority: 32768
    port number: 389
    port state: 61

Slave Interface: p4p2
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 2
Permanent HW addr: a0:b6:cf:d0:2d:fa
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 2
Partner Churned Count: 2
details actor lacp pdu:
    system priority: 65535
    system mac address: a0:b6:cf:d0:2d:f8
    port key: 13
    port priority: 255
    port number: 2
    port state: 61
details partner lacp pdu:
    system priority: 32768
    system mac address: 00:01:02:03:aa:fc
    oper key: 110
    port priority: 32768
    port number: 385
    port state: 61
# ethtool bond0
Settings for bond0:
        Supported ports: [ ]
        Supported link modes:   Not reported
        Supported pause frame use: No
        Supports auto-negotiation: No
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 20000Mb/s
        Duplex: Full
        Port: Other
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        Link detected: yes

    Todo listo, ambos interfaces en el mismo grupo de agregación, el ancho de banda de ambos interfaces agregado al bonding y la MAC del switch detectada.

    ¡El bonding ya no está medio sordo!

    Ya se puede desactivar el apaño del all_slaves_active, el LAG está ya funcionando correctamente (aunque esta configuración no era persistente).

    # echo 0 > /sys/class/net/bond0/bonding/all_slaves_active

    Otras referencias:

    Para entender el significado de los estados de los interfaces del bonding (port state) ver las definiciones AD_STATE_… en el código del fichero bond_3ad.c.

    El estado mostrado en /proc/net/bonding/bond0 es la representación en decimal del resultado de unir (OR) los valores que corresponden al estado del puerto según las definiciones encontradas en dicho código fuente. Es decir, cuando se estableció correctamente el LAG, el estado del bonding era 61 = 0x3d = 0x20+ 0x10 + 0x08 + 0x04 + 0x01 = DISTRIBUTING + COLLECTING + SYNCHRONIZATION + AGGREGATION + LACP_ACTIVITY.

    Antes, cuando el bonding estaba medio sordo, un interfaz del bonding estabe en estado 77 = 0x4d = 0x40 + 0x08 + 0x04 + 0x01 = DEFAULTED + SYNCHRONIZATION + AGGREGATION + LACP_ACTIVITY. El otro puerto estaba en estado 69 = 0x45 = 0x40 + 0x04 + 0x01 = DEFAULTED + AGGREGATION + LACP_ACTIVITY.

  • Conexión de interfaces de red entre distintos espacios de nombres con iproute2

    Llevaba ya algún tiempo con ganas de practicar con el comando ip y el otro día surgió la ocasión ideal al necesitar que dos aplicaciones (no preparadas para ello) recibieran un mismo flujo de información multicast en el mismo equipo.

    El problema surgió cuando se instaló en un equipo una aplicación que leía el mismo flujo multicast que otra ya instalada previamente, solo la primera en arrancar recibía el flujo, independientemente de cual fuera. Este comportamiento es consecuencia de que ambas aplicaciones abren el socket de recepción del tráfico multicast en modo exclusivo (no es que lo hagan explícitamente, es que es el modo por defecto). Si ambas aplicaciones hubieran establecido la opción SO_REUSEADDR en el socket de escucha antes de hacer bind(), ambas podrían recibir el mismo flujo, pero no era este el caso.

    La solución obvia es modificar las aplicaciones, así no presentarán este problema en futuros despliegues. Pero también hay otra solución más rápida y que puede utilizarse incluso con aplicaciones que no puedan modificarse por no disponer de su código fuente; hacer uso de los espacios de nombres (namespace) ofrecidos por el núcleo de Linux.

    Un espacio de nombres (namespace), o más concretamente, un espacio de nombres de red (network namespace) es un entorno particular dentro de una misma instancia del sistema operativo que tiene su propio conjunto de interfaces de red y tablas de enrutamiento, separado del de otros espacios de nombres de la misma instancia del sistema operativo.

    Por tanto, si creamos un espacio de nombres particular para una de las aplicaciones, mientras dejamos la otra en el espacio de nombres global del sistema operativo, ambas podrán abrir el socket de escritura sobre el mismo puerto sin cambiar su forma de hacerlo. Para ello se necesita crear un interfaz en el espacio de nombres adicional que reciba el flujo multicast al igual que lo hace el interfaz físico (o no) en el que escucha la otra aplicación en el espacio de nombres global.

    La idea estaba clara, ahora quedaba ponerla en práctica con las piezas que pone a disposición el conjunto de herramientas iproute2. No describiré el par de cabezazos que pegué por ir a pecho descubierto sin antes haber leído con cierto detalle la documentación del comando ip y, sobre todo, el funcionamiento de los distintos tipos de interfaces virtuales que se pueden crear.

    Una vez correctamente (no completamente) documentado, decidí aplicar la siguiente configuración con un interfaz de tipo bridge, que es una especie de switch (conmutador ya me parece demasiado aunque sea correcto), al que asociaría el interfaz donde se recibe el flujo multicast y uno de los extremos de un par de interfaces ligados entre sí a modo de tubería creados a partir de un dispositivo tipo veth. El otro extremo de esa tubería se coloca en el espacio de nombres particular para la otra aplicación y listo. A continuación una imagen que vale más que este párrafo:

    Una vez soltado todo el rollo puedo pasar ya a la chicha que son los comandos a ejecutar para realizar ese despliegue.

    En primer lugar se crea el espacio de nombres adicional:

    #ip netns add ns0

    Se crea la tubería que conectará los dos espacios de nombres:

    #ip link add type veth

    Esta orden crea automáticamente dos interfaces llamados veth0 y veth1 (en el caso de que sean los primeros). También se pueden crear dichos interfaces con los nombres que uno desee de la siguiente forma:

    #ip link add vethA type veth peer name vethB

    Se crea el puente y se conectan a él el interfaz que recibe el flujo y un extremo de la tubería:

    #ip link add dev br0 type bridge
#ip link set eth0 master br0
#ip link set veth0 master br0

    Se mueve el otro extremo de la tubería al espacio de nombres adicional y se le asigna una dirección IP y una puerta de enlace en la misma subred que el interfaz eth0:

    #ip link set veth1 netns ns0

    Una vez situado veth1 en el espacio de nombres ns0, todas las operaciones a realizar sobre él deben realizarse desde dicho espacio de nombres, de hecho, habrá ya desaparecido de la lista de interfaces que se puede consultar ejecutando ip link.

    Para facilitar las cosas se puede lanzar un intérprete de comandos en el espacio de nombres y todas las órdenes se ejecutarán en dicho espacio de nombres, pero para que quede más claro aquí pondré las órdenes a ejecutar desde el espacio de nombres global:

    #ip netns exec ns0 ip address add 192.168.1.11/24 dev veth1
#ip netns exec ns0 ip route add default vial 192.168.1.1 dev veth1
#ip netns exec ns0 ip link set veth1 up

    Y listo, aunque puede que se me haya olvidado levantar los interfaces br0 y veth0, por lo que añado estas dos líneas que, en cualquier caso, no hacen daño:

    #ip link set br0 up
#ip link set veth0 up

    Ahora.

    Algunas referencias:

    http://man7.org/linux/man-pages/man7/socket.7.html

    http://rg3.name/201504241907.html

    http://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/

    http://www.policyrouting.org/iproute2.doc.html

    El diagrama lo hice en 5 minutos con https://www.draw.io/

     

  • Configuración automática de un interfaz de red manteniendo NetworkManager

    En Debian Squeeze por defecto, según el contenido de /etc/NetworkManager/NetworkManager.conf, los interfaces que se definan en /etc/network/interfaces no son administrados por NetworkManager. Por tanto, si el contenido de /etc/NetworkManager/NetworkManager.conf es el siguiente

    [main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

     

    basta con proporcionar la configuración deseada en /etc/network/interfaces

    auto lo wlan0
iface lo inet loopback
    iface wlan0 inet dhcp
        wireless-essid ...

     

    Si el interfaz a configurar es inalámbrico ver Configuración manual de interfaz inalámbrico…

    El contenido de este post procede directamente del artículo sobre NetworkManager en Squeeze de la magnífica documentación de Debian.

     

  • Ubuntu Oneiric «Waiting for network configuration…»

    Al actualizar a Ubuntu Oneiric el sistema se quedaba en el arranque esperando durante un minuto con el siguiente mensaje:

    Waiting for network configuration...

    Y después un minuto más:

    Waiting up to 60 seconds for network configuration...

    Tras esto mostraba el mensaje:

    Booting system without full network configuration.

    Por lo visto es muy común este problema, aunque con dos variantes con causas y consecuencias completamente distintas. Una, que al parecer provocaba que tras la espera se detuviera el arranque, estaba originada por la ausencia de los enlaces simbólicos a /run y /run/lock dentro de /var. Este problema debe tener su origen en la existencia previa de directorios con los nombres de dichos enlaces dentro de /var. Pero en mi caso los enlaces existían, y el problema era otro, pues después de la larga espera el sistema continuaba arrancando normalmente.

    La solución la encontré gracias a la quinta entrada del hilo [SOLVED] waiting for network configuration de Ubuntu Foums, en la que se aludía a la configuración automática de interfaces de red no existentes durante el inicio en el fichero de configuración /etc/network/interfaces.

    Así era, en dicho fichero, tenía especificado para su configuración automática el interfaz usb0, utilizado para la conexión IP por USB con mi móvil. En las versiones anteriores no suponía un problema, cuando conectaba el móvil, se aplicaba la correspondiente configuración y listo, pero ahora, espera durante dos minutos a que todos los interfaces configurados como automáticos estén presentes.

    La solución es bien sencilla, eliminar el interfaz usb0, o aquel que no exista durante el inicio del sistema, de la línea auto de /etc/network/interfaces.

  • Configuración de un servidor DNS distinto al proporcionado por DHCP en Ubuntu

    Para modificar la configuración ofrecida por DHCP se pueden utilizar en el fichero dhclient.conf las sentencias supersede, prepend y append.

    La sentencia supersede ignora el valor proporcionado por DHCP para la opción indicada, usando el valor que se indique.

    La sentencia prepend añade la opción indicada y después los valores proporcionados por DHCP.

    Y la sentencia append obtiene en primer lugar los valores de DHCP y añade a continuación los indicados en la sentencia.

    Así, para especificar el servidor DNS local como principal y luego añadir los servidores proporcionados por DHCP se utilizaría la siguiente sentencia en /etc/dhcp/dhcp.conf:

    prepend domain-name-servers 127.0.0.1;

    Para hacer efectiva la nueva configuración:

    sudo ifdown wlan0
sudo ifup wlan0

    Referencias:

  • Configuración manual de interfaz inalámbrico para conectar a puntos de acceso con cifrado WPA-PSK y WEP

    Estas instrucciones se han elaborado para Ubuntu 10.10, aunque serán, en su mayoría, válidas  para otras distribuciones GNU/Linux, particularmente si utilizan el sistema de inicio upstart.

    Con estos pasos se podrá prescindir de NetworkManager, haciendo que el servicio network de Ubuntu/Debian sea el que conecte a los puntos de acceso inalámbricos configurados, utilizando tanto cifrado WPA-PSK como WEP y con configuración IP automática mediante DHCP.

    Para poder realizar la conexión se necesitarán los paquetes ifupdown y wpasupplicant, por lo que lo primero será instalarlos.

    Una vez instalados se debe desactivar NetworkManager. Lo mejor es desinstalar el paquete network-manager, pero si sólo se quiere desactivar se pueden mover los ficheros encargados de configurar su inicio a otro directorio y parar su ejecución.

    sudo mv /etc/init/network-manager.conf disabled-init/
sudo stop network-manager

    Con NetworkManager desactivado es turno para configurar el interfaz inalámbrico y las características de conexión de cada punto de acceso en los ficheros /etc/network/interfaces y /etc/wpa_supplicant/wpa_supplicant.conf respectivamente.

    Las instrucciones para la configuración del fichero /etc/network/interfaces y la conexión al punto de acceso WPA-PSK se obtuvieron del artículo Linux_Wireless_Networking, y la configuración de la conexión al punto de acceso con cifrado WEP se completo utilizando la ayuda del fichero /usr/share/doc/wireless-tools/README.Debian y del manual de wpa_supplicant.conf, ya que se hizo sin acceso a Internet.

    Configuración de /etc/network/interfaces

    La configuración del interfaz, suponiendo que sea eth1 el interfaz inalámbrico,  se hará añadiendo lo siguiente al fichero /etc/network/interfaces (para configuración DHCP):

    auto eth1
iface eth1 inet dhcp
 wireless-essid WiFi_01
 pre-up wpa_supplicant -B -Dwext -ieth1 -c/etc/wpa_supplicant/wpa_supplicant.conf
 post-down killall -q wpa_supplicant

    Esta configuración hace que cuando se active el interfaz eth1 se lance wpa_supplicant en modo demonio (-B), utilizando el driver wext (-Dwext), gestionando el interfaz eth1 (-ieth1) con la configuración indicada en /etc/wpa_supplicant/wpa_supplicant.conf.

    Hay que hacer notar que en la parada se están matando todas las instancias de wpa_supplicant, por lo que si tenemos más de un interfaz inalámbrico, al detener uno de ellos se desconectarán los demás.

    Configuración de los puntos de acceso

    Una vez configurado el inicio del interfaz se configura su conexión a los puntos de acceso conocidos. Para ello, dado que en este caso se utilizan cifrados WPA-PSK o WEP, hay que proporcionar las correspondientes contraseñas de los puntos de acceso. En el caso de WPA-PSK la contraseña se puede proporcionar tanto en texto claro como cifrado. Si se quiere proporcionar como texto cifrado se debe utilizar el comando wpa_passphrase, proporcionando el ESSID del punto de acceso y la contraseña:

    wpa_passphrase <ESSID> <contraseña de acceso>

    El resultado será similar al siguiente:

    network={
 ssid="<ESSID>"
 #psk="<contraseña de acceso>"
 psk=<contraseña cifrada>
}

    Ahora, se utilizará la contraseña cifrada proporcionada para incluirla en el fichero /etc/wpa_supplicant/wpa_supplicant.conf,  junto con algunas opciones más, de modo que el contenido del fichero sea el siguiente:

    # The below line not be changed otherwise we refuse to work
ctrl_interface=/var/run/wpa_supplicant

# Ensure that only root can read the WPA configuration
ctrl_interface_group=root

# Let wpa_supplicant take care of scanning and AP selection
ap_scan=1

network={
 ssid="<ESSID>"
 key_mgmt=WPA-PSK
 psk=<contraseña cifrada>
}

    Para el punto de acceso con cifrado WEP hay que tener cuidado al proporcionar las contraseñas, no ya porque no se pueden proporcionar cifradas (que también debe tenerse en cuenta), sino porque según si las claves se proporcionan en formato ASCII o hexadecimal deberán ponerse entre comillas dobles o no. Es decir, si se va a proporcionar la clave en formato ASCII (13 caracteres para WEP104 o 5 para WEP40) la clave debe escribirse entre comillas, y si se proporciona en formato hexadecimal se hará sin comillas (26 dígitos hexadecimales para WEP104 o 10 para WEP40):

    network={
    ssid=»<ESSID>»
    scan_ssid=1
    key_mgmt=NONE
    wep_key0=»1234567890zxy»
    wep_tx_keyidx=0
    priority=4
    }

    La propiedad scan_ssid a 1 indica que se realice una búsqueda activa de un punto de acceso con el ESSID indicado, para los casos en los que el punto de acceso no difunde esta información.

    La propiedad priority indica la preferencia por uno u otro punto de acceso en el caso de que varios estén al alcance simultáneamente, de lo contrario se ignora.

    Con esto es suficiente, ahora, desactivando y activando de nuevo el interfaz debería conectar con el punto de acceso configurado que se encuentre al alcance.

    sudo ifdown eth1
sudo ifup eth1

    Recuerdo que es fundamental tener NetworkManager desactivado, para comprobarlo:

    ps -elf | grep NetworkManager

  • Crear interfaces virtuales para VirtualBox

    Este procedimiento surge de la necesidad de crear interfaces virtuales para su uso por distintas máquinas virtuales de VirtualBox ejecutadas sobre un equipo anfitrión Kubuntu, pero es válido para cualquier otra situación en la que se necesiten crear interfaces virtuales en una máquina interconectados entre sí virtualmente.  En otras distribuciones debe bastar con sustituir los comandos de obtención de paquetes y poco más.

    El procedimiento consiste en crear un interfaz bridge que sirva de conexión entre los interfaces virtuales y entre éstos y el resto de interfaces de la máquina. Para crear este tipo de interfaz se necesita instalar el paquete bridge-utils:

    # apt-get install bridge-utils

    También hará falta el paquete uml-utilities (no relacionado con diagramas UML, sino con User-Mode Linux):

    # apt-get install uml-utilities

    Puesto que en este caso se desea que estos interfaces estén disponibles siempre que se inicie la máquina se ha elaborado un conjunto de scripts que puedan configurarse para su ejecución al inicio del sistema y que capturan parte de la configuración de un fichero para facilitar la modificación del conjunto de interfaces virtuales deseados.

    Hay un script principal pensado para aceptar los parámetros start y stop de modo que pueda configurarse como un servicio más y arranque automáticamente en los niveles de ejecución deseados y se detenga al salir de los mismos. Este será /etc/init.d/netbridges.

    Dicho script utilizará a su vez otros cuatro destinados cada uno de ellos a una de las funciones para crear y eliminar los interfaces virtuales y habilitar y deshabilitar el encaminamiento de paquetes desde el interfaz bridge y sus interfaces con el resto de interfaces de la máquina para permitir a estos interfaces virtuales la comunicación con el exterior de la máquina anfitrión. Estos estarán situados en /usr/local/sbin y se llamarán addtap, deltap, nattap y unnattap respectivamente. Tanto addtap como deltap accederán al fichero /etc/local/network-bridges.conf para preparar la lista de interfaces virtuales a crear/eliminar, que estará formada por $NUMBER_OF_VM interfaces virtuales numerados desde $NB y por los interfaces separados por espacios indicados en $NAMED_TAPS.

    /etc/local/network-bridges.conf

    NUMBER_OF_VM=2
NB=1
NAMED_TAPS="tap_win"

    Cada interfaz, a su vez, puede incluir comandos específicos de configuración en un fichero con el nombre tap<numero>.conf o <nombre>.conf situado en /etc/local/netbridges.d/:

    /etc/local/netbridges.d/tap1.conf

    ifconfig tap1 hw ether 00:ff:10:01:01:10

    Los scripts son:

    /etc/init.d/netbridges

    #!/bin/sh -e                                         
### BEGIN INIT INFO                                  
# Provides:          netbridges                      
# Required-Start:    $network                        
# Required-Stop:     ifupdown $local_fs              
# Default-Start:     2                               
# Default-Stop:                                      
# Short-Description: Raise bridge network interfaces.
### END INIT INFO                                    

PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"

[ -x /sbin/ifup ] || exit 0

. /lib/lsb/init-functions

case "$1" in
start)      
 log_action_begin_msg "Configuring network bridge interfaces"

 if [ "$VERBOSE" != no ]; then
 if addtap; then          
 log_action_end_msg $?
 else                     
 log_action_end_msg $?
 fi                       
 else                         
 if addtap >/dev/null 2>&1; then
 log_action_end_msg $?      
 else                           
 log_action_end_msg $?      
 fi                             
 fi                                 

 unnattap
 nattap  
 ;;      

stop)
 log_action_begin_msg "Removing NAT with network bridge interfaces"

 unnattap

 log_action_begin_msg "Removing network bridge interfaces"

 if deltap >/dev/null 2>&1; then
 log_action_end_msg $?
 else
 log_action_end_msg $?
 fi
 ;;

force-reload|restart)
 if $0 stop; then
 log_action_end_msg $?
 else
 log_action_end_msg $?
 fi

 if $0 start; then
 log_action_end_msg $?
 else
 log_action_end_msg $?
 fi

 ;;

*)
 echo "Usage: /etc/init.d/netbridges {start|stop|restart|force-reload}"
 exit 1
 ;;
esac

exit 0

    /usr/local/sbin/addtap

    #!/bin/sh                                          
# set PATH for the case we are called via sudo or su root

PATH=/sbin:/usr/sbin:/bin:/usr/bin
USER=usuario_virtualbox                          

NUMBER_OF_VM=2
NB=1          

$LOCAL_ERRORS=0

if [ -f /etc/local/network-bridges.conf ];
then                                      
 . /etc/local/network-bridges.conf       
fi                                        

# create the bridge
brctl addbr br0    

# create the taps and insert them into the bridge

while [ $NB -le $NUMBER_OF_VM ];
do
 tunctl -t tap$NB -u $USER
 `cat /etc/local/netbridges.d/tap$NB.conf`
 ip link set up dev tap$NB
 brctl addif br0 tap$NB
 if ifconfig tap$NB; then
 echo Tun interface created: tap$NB
 else
 LOCAL_ERRORS=`expr $LOCAL_ERRORS + 1`
 fi
 NB=`expr $NB + 1`
 done

for TAP_NAME in $NAMED_TAPS; do
 tunctl -t $TAP_NAME -u $USER
 `cat /etc/local/netbridges.d/$TAP_NAME.conf`
 ip link set up dev $TAP_NAME
 brctl addif br0 $TAP_NAME
 if ifconfig $TAP_NAME; then
 echo Tun interface created: $TAP_NAME
 else
 LOCAL_ERRORS=`expr $LOCAL_ERRORS + 1`
 fi
done

# set the IP address and routing
ip link set up dev br0
ip addr add 10.1.1.1/24 dev br0
ip route add 10.1.1.0/24 dev br0 2> /dev/null

echo $LOCAL_ERRORS

    /usr/local/sbin/deltap

    #!/bin/sh
# set PATH for the case we are called via sudo or su root

PATH=/sbin:/usr/sbin:/bin:/usr/bin
USER=usuario_virtualbox

NUMBER_OF_VM=2
NB=1

if [ -f /etc/local/network-bridges.conf ];
then
 . /etc/local/network-bridges.conf
fi

# remove the taps and extract them from the bridge

while [ $NB -le $NUMBER_OF_VM ];
do
 sudo brctl delif br0 tap$NB
 tunctl -d tap$NB
 NB=`expr $NB + 1`
 echo Tun interface deleted: tap$NB
done

for TAP_NAME in $NAMED_TAPS; do
 sudo brctl delif br0 $TAP_NAME
 tunctl -d $TAP_NAME
 echo Tun interface deleted: $TAP_NAME
done

# remove the bridge
ip link set down dev br0
brctl delbr br0

    /usr/local/sbin/nattap

    #!/bin/bash

INTIF="br0"
EXTIF="wlan0"
echo 1 > /proc/sys/net/ipv4/ip_forward

# clear existing iptable rules, set a default policy
iptables -P INPUT ACCEPT
iptables -F INPUT
iptables -P OUTPUT ACCEPT
iptables -F OUTPUT
#iptables -P FORWARD DROP
iptables -P FORWARD ACCEPT
iptables -F FORWARD
iptables -t nat -F

# set forwarding and nat rules
iptables -A FORWARD -i $EXTIF -o $INTIF -j ACCEPT
iptables -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE

# enable forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 0 > /proc/sys/net/ipv4/ip_dynaddr

    /usr/local/sbin/unnattap

    # remove NAT rule
iptables -t nat -F
# disable forwarding
echo 0 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_dynaddr

    Bueno, pues eso es todo, los scripts podrían estar un poco mejor hechos, sobre todo con más información tomada del fichero de configuración, pero como base sirven.

  • Instalación de módem HSDPA K3520 de Huawei en Linux

    Los pasos descritos corresponden a la instalación para Kubuntu 64 bits. Aunque exceptuando la descarga de los paquetes debería ser similar en el resto de distribuciones y plataformas.

    El primer paso es descargar los paquetes desde http://forge.betavine.net allí, con toda probabilidad, aparecerá como proyecto más descargado el Vodafone Mobile Connect Card driver. En el caso de Ubuntu AMD64 hay que descargar los paquetes ozerocdoff, usb-modeswitch y vodafone-mobile-connect.

    Estos paquetes habrá que instalarlos en el orden que se han nombrado, pero antes hay que satisfacer las dependencias que tienen de otros paquetes.

    En la instalación de la que surge este artículo se encontraron problemas con la versión de los paquetes ya instalados, pues en la máquina donde se instaló se había intentado instalar trac y las versiones de python no eran las del repositorio. Así que hubo que reinstalar las versiones oficiales para poder descargar el resto de paquetes necesarios sin problemas.

    $ sudo aptitude --purge install python-gnomecanvas

    Ahora se puede continuar con la instalación de ozerocdoff.

    $ sudo dpkg -i ozerocdoff_0.4_amd64.deb

    Se continua con las dependencias del paquete vodafone-mobile-connect.

    $ sudo apt-get install python-crypto python-gnome2 python-sqlite python-twisted python-tz
$ sudo apt-get install python-gnome2-extras

    En el equipo donde se realizó la instalación no se pudo instalar python-gnome2-extras y también se necesitó forzar la actualización de algunos paquetes a la versión oficial para poder instalarlo.

    $ sudo aptitude --purge install python-gnome2-extras libgdl-1-0 libgtkspell0 python-gnome2-desktop

    Y se termina con la instalación de usb-modeswitch y vodafone-mobile-connect.

    $ sudo dpkg -i usb-modeswitch_0.9.7_amd64.deb
$ sudo dpkg -i vodafone-mobile-connect_2.10.01-1_all.deb

    Ahora debería estar todo preparado para conectar el módem  y ejecutar la aplicación de conexión.

    $ vodafone-mobile-connect-card-driver-for-linux

    La aplicación de conexión requiere introducir los datos de conexión que para Vodafone España son los siguientes:

    Usuario: vodafone
    Contraseña: vodafone
    Modo de autenticación: Predefinido
    Host APN: ac.vodafone.es
    Usar DNS estáticos
    DNS primario: 212.73.32.3
    DNS secundario: 212.73.32.67

    Referencias:

    http://usrweblog.wordpress.com/2008/09/22/instalar-modem-3g-huawei-k3520-en-kubuntu/
    http://www.grupobonatel.com/modem-usb-vodafone-en-linux-mobile-connect/#more-537

  • ¿Conseguí? funcionar el driver rt2500

    En primer lugar uso Kubuntu 8.04 Hardy Heron. Tengo una Conceptronic C54Ri basada en el chip RT2500. Un lspci me la identifica así:

    01:0a.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)

    La instalación del driver para RT2500 desde los paquetes oficiales de Ubuntu y el uso de module-assistant no me funcionaba, así que busqué una descripción específica de pasos para la instalación. Es decir, hacer la instalación a mano.

    El primer buen documento que encontré fue este de la documentación de Ubuntu ofrecida por la comunidad. En él se indican unos pasos válidos para instalar el driver pero debía estar algo desfasado ya que no pude instalar RaConfig2500 tal como se indicaba. En la descarga del estado actual de rt2500 no se proporcionaba el código de RaConfig dentro del directorio Utilitys y lo intenté también con la beta v1.1.0-b4 pero aunque sí estaba el código fuente no logré compilarlo.

    Después instalé RutilT 0.16 en lugar de RaConfig2500 y conseguí ver las redes inalámbricas de mi entorno y hasta conectar con la mía, pero… la conexión duraba unos segundos se perdía y volvía. Así de forma continua.

    Cuando ya estaba pensando en utilizar ndiswrapper dí con este otro documento donde además de valorar, acertadamente en mi opinión, los efectos de las dificultades que sufrimos los usuarios de WiFi con Linux, se describe lo que fue la solución para el autor y que también espero que sea la mia.

    El autor realizó todo el proceso como superusuario y aunque, en teoría, algunos pasos no lo requieren, yo voy a imitarle.

    sudo su

    Después instalo el driver descomprimiendo la última actualización del código en desarrollo desde la página de descargas de rt2x00.serialmonkey.com y ejecutando make y make install. Hasta aquí bien.

    A continuación el autor indica que RaConfig ha sido despreciado (deprecated) en favor de RutilT y que la última y anteriores versiones se pueden obtener desde la página de RutilT. La instalación es también simple:

    ./configure.sh; make; make install

    Ahora un reinicio y continuo escribiendo.

    Bueno, ahora un reinicio del servicio de red y levantamos el interfaz inalámbrico por si no está por defecto así indicado:

    /etc/init.d/networking restart

    ifup ra0

    o si el interfaz se llama wlan0:

    ifup wlan0

    Ahora ejecutamos rutilt:

    sudo rutilt

    Vamos a «Site survey» para ver las redes al alcance, seleccionamos la nuestra y añadimos un perfil para ella pulsando en «Add Profile». Para crear el nuevo perfil indicamos un nombre e introducimos la contraseña en el campo «Key».

    Ahora vamos al apartado «Profiles», seleccionamos nuestro perfil y pulsamos en «Aplicar». Tras lo cual deberemos poder conectar. Para ver información sobre la conexión podemos ir al apartado «Link Status».

    Podemos comprobar si ha guardado el perfil viendo el contenido del directorio ~/.config/rutilt/, si no se ha guardado el perfil puede ser necesario matar la ventana de rutilt:

    sudo killall -q rutilt

    Si tras iniciar sesión no arranca automáticamente rutilt podemos lanzarlo desde la línea de comandos así:

    rutilt ra0 -d -p <<Nombre del perfil>>

    Aquí terminan los pasos indicados en el artículo «Ubuntu and WPA«. En principio a mí también me funcionaron. Pero…

    Pero al reiniciar la conexión se iba a los 5 segundos, volvía al rato y de nuevo se perdía tras 5 segundos. De nuevo pensando en ndiswrapper, una tarjeta nueva, un punto de acceso inalámbrico como enlace y conectarme a él por cable, …

    Ya a la desesperada cerré rutilt, desinstalé todos los paquetes (excepto los fuentes) relativos a rt2500 y reinstalé el driver mediante module-assistant:

    sudo module-assistant install rt2500

    Y ahora está funcionando, en apariencia, perfectamente. Emitiré un juicio cuando lo haya probado descargando algún torrent. De momento no me atrevo ni a reiniciar para comprobar si lo coge en el inicio del sistema.