Alice/O2 DSL and SSL

So, recently I wrote about how I had trouble connecting to google.com over HTTPS using my home DSL connection. I have narrowed the problem down and I must say that ppp is inocent.

I have tried to use the crappy router in router mode and even the fancy Fritz!Box7390 from my old VDSL connection both in modem and router mode and the problem persists. I have tried the original phone cable (you never know, right?) and any other thing imaginable: still fails to connect to google. But it's not alone! Trying amazon.com also fails from time to time! It still doesn't happen from my neighbor's connection or from my own connection for other servers (I tried, among others, facebook.com, deutsche-bank.de, visa.com, paypal.com, dkb.de).

 * About to connect() to amazon.de port 443 (#0)
*   Trying 178.236.6.38...
* connected
* Connected to amazon.de (178.236.6.38) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2): * error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error
* Closing connection #0
curl: (35) error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error

 * About to connect() to amazon.com port 443 (#0)
*   Trying 72.21.211.176...
* connected
* Connected to amazon.com (72.21.211.176) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error
* Closing connection #0
curl: (35) error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error

 * About to connecd() to amazon.com port 443 (#0)
*   Trying 72.21.211.176...
* connected
* Connected to amazon.com (72.21.211.176) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certifhcates.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-MD5
* Server certificate:
*        subject: C=US; ST=Washington; L=Seattle; O=Amazon.com Inc.; CN=www.amazon.com
*        start date: 2010-07-15 00:00:00 GMT
*        expire date: 2013-07-14 23:59:59 GMT
*        common name: www.amazon.com (does not match 'amazon.com')
*        issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)09; CN=VeriSign Class 3 Secure Server CA - G2
*        SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.26.0
> Host: amazon.com
> Accept: */*
>
* SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
* Closing connection #0


 * About to connect() to google.de port 443 (#0)
*   Trying 173.194.69.94...
* connected
* Connected to google.de (173.194.69.94) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* Unknown SSL protocol error in connection to google.de:443
* Closing connection #0
c5rl: (35) Unknown SSL protocol error in connection to google.de:443

 * About to connect() to google.de port 443 (#0)
*   Trying 173.194.69.94...
* connected
* Connected to google.de (173.194.69.94) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error
* Closing connection #0
curl: (35) error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error

 * About to connect() to google.com port 443 (#0)
*   Trying 173.194.69.113...
* connected
* Connected to google.com (173.194.69.113) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Sebver finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac
* Closing connection #0
curl: (35) error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record lac

So here is my new theory about who's the bad guy:
- Google, Amazon: nope, work for the rest of the world.
- PPP: no, tried without it and still fails.
- Crappy router: nope, also happens with fancy router.
- Alice ADSL: the only difference between my connection and the neighbor's connection is the access router to Alice's network. That MUST be it!

From my connection:
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 52 byte packets
 1  alice.box (192.168.1.1)  2.437 ms  2.381 ms  17.397 ms
 2  lo1.br12.muc.de.hansenet.net (213.191.64.41)  26.054 ms gi2-0-0.pr02.muc.de.hansenet.net (213.191.88.88)  22.261 ms  26.177 ms
 3  inxs.google.com (194.59.190.61)  30.079 ms  30.047 ms  28.297 ms
 4  66.249.94.88 (66.249.94.88)  51.782 ms  34.389 ms  31.082 ms
 5  216.239.48.125 (216.239.48.125)  29.833 ms 216.239.48.117 (216.239.48.117)  32.006 ms 216.239.48.125 (216.239.48.125)  29.545 ms
 6  209*85.254.116 (209.85.254.116)  53.968 ms  30.843 ms 209.85.254.112 (209.85.254.112)  32.079 ms
 7  * * *
 8  google-public-dns-a.google.com (8.8.8.8)  32.152 ms  32.125 ms  30.507 ms

 PING 213.191.88.88 (213.191.88.88) 56(124) bytes of data.
64 bytes from 213.191.88.88: icmp_req=2 ttl=253 time=27.9 ms
NOP
RR:     192.168.1.4
        213.191.88.74
        213.191.88.88
        213.191.88.88
        213.191.64.41
        192.168.1.4


From neighbor's connection:
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 52 byte packets
 1  172.24.128.1 (172.24.128.1)  2.520 ms  2.459 ms  2.429 ms
 2  172.24.0.1 (172.24.0.1)  2.428 ms  2.453 ms  2.414 ms
 3  192.168.1.1 (192.168.1.1)  5.133 ms  5.205 ms  4.880 ms
 4  lo1.br02.muc.de.hansenet.net (213.191.89.9)  28.328 ms  28.179 ms  28.098 ms
 5  gi2-0-0.pr02.muc.de.hansenet.net (213.191.88.88)  27.318 ms  27.837 ms  26.953 ms
 6  inxs.google.com (194.59.190.61)  136.017 ms  39.291 ms  39.645 ms
 7  66.249.94.86 (66.249.94.86)  38.188 ms  39.087 ms  38.489 ms
 8  216.239.48.125 (216.239.48.125   43.581 ms  42.874 ms 216.239.48.117 (216.239.48.117)  46.876 ms
 9  209.85.254.116 (209.85.254.116)  44.041 ms  45.064 ms  44.261 ms
10  * * *
11  google-public-dns-a.google.com (8.8.8.8)  42.816 ms  46.818 ms  46.312 ms

PING 213.191.88.88 (213.191.88.88) 56(124) bytes of data.
64 bytes from 213.191.88.88: icmp_req=1 ttl=251 time=36.1 ms
NOP
RR:     172.24.128.2
        172.24.0.4
        192.168.1.254
        85.181.69.47
        213.191.88.70
        213.191.88.88
        213.191.88.88
        213.191.89.9
        192.168.1.1


The whole thing about 213.191.64.41 disappearing from the 2nd traceroute hop after the first packet is quite weird, BTW. With an ICMP traceroute it does not happen:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 52 byte packets
 1  alice.box (192.168.1.1)  3.759 ms  2.364 ms  2.359 ms
 2  lo1.br12.muc.de.hansenet.net (213.191.64.41)  27.701 ms  157.436 ms  27.542 ms
 3  gi2-0-0.pr02.muc.de.hansenet.net (213.191.88.88)  23.166 ms  23.293 ms  22.792 ms
 4  inxs.google.com (194.59.190.61)  30.130 ms  29.518 ms  29.570 ms
 5  66.249.94.86 (66.249.94.86)  44.804 ms  38.765 ms  30.947 ms
 6  216.239.48.117 (216.239.48.117)  32.570 ms  31.293 ms  30.783 ms
 7  209.85.254.118 (209.85.254.118)  31.931 ms  31.347 ms  31.427 ms
 8  * * *
 9  google-public-dns-a.google.com (8.8.8.8)  32.889 ms  31.240 ms  32.917 ms

All this drives me to the conclusion that:
- 213.191.64.41is buggy as hell and Alice should be ashamed of having it there.
- 213.191.64.41is doing some really creepy targeted SSL tampering / man-in-the-middle / hijacking / manipulation and Alice should be seriously ashamed of having it.

Any ideas about the problem? How to solve it other that with a VPN past 213.191.64.41?

Crazy Google - PPPd - SSL BAD MAC error

UPDATE: follow up

Hi all. Long time no see. Just didn't have much to say lately. But now I do. So hi :)

A lot has actually changed lately, both at personal and professional level, but the relevant part is: I have a new ISP.  I moved and the awesome 50/10Mbit 1&1.de VDSL was no longer available, so now I have a much crappier 16/1Mbit ADSL by O2/Alice (after several months of borrowing the neighbor's WiFi). Also, instead of the fantasboulous FritzBox7390 I got a crappy Alice IAD 4412, or something whatever the thing it's called. It's 2.4Ghz only and 150 Mbit. And on top of that O2/Alice is soooo worried for some reason that I would sell the router on ebay to buy a yacht, that I have to return the damn thing at the end of the 24 month contract.

Of course the first thing I did was to disable everything internet related on the router, enable PPPoE passthrough and set up PPPoE on my linux box to act as a Torrent / Router / Firewall / Apache / Misc server. Since I had the same setup with 1&1 everything went pretty smoothly and all was fine. The End.

No, of course not. Everything did go smoothly, until I tried to use GMail. I got a nice SSL error page with the following message:

Secure Connection Failed
An error occurred during a connection to accounts.google.com.
SSL peer reports incorrect Message Authentication Code.

(Error code: ssl_error_bad_mac_alert)

I tried to google it, but since I use google with https by default, it happened for www.google.com too! After a F5 it would work again.

I thought it might be an iptables problem but the usual clamp-tcpmss-to-pmtu did no good. Trying to debug I wrote the following crude script:

C=0 E=0; while [ $E = 0 ]; do curl 'https://www.google.com' --no-sessionid -v -1; E=$?; C=$((C+1)); echo $C; done

I ran it in multiple configurations of destination servers, hosts and connections. Since I still have access to the borrowed neighbor's wifi I also ran it there. It's worth mentioning that the neighbor uses the same ISP and a traceroute shows that the second router down the road is already the same, so basically what's different is the ppp method (me - pppd through crappy router, he - crappy router directly).

Result: it fails ONLY when:

• I use my connection (pppd though router), doesn't matter if it's a NATed machine or the server itself. Ran over 11k times from other connections, no problem.
• I connect to google servers (accounts.google.com, www.google.com). Ran over 2k connections to other https servers from same connection: no problem.

So who is to blame?

• Google: no, it works fine from my work maciine and the neighbor's WiFi.
• pppd: no, it worked before with 1&1.
• Alice ADSL: no, the neighbor has Alice as well.
• Crappy router: no, it works fine when connecting to facebook, yahoo, deutsche bank, etc.
• Combination of all of the above: well, it works sometimes.

Solution? Sadly, I have none. I have a packet capture that shows exactly when the problem happens most often:

• Client Hello
• Server Hello
• Server Certificate, Server Key Exchange, Server Hello Done
• Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message (encrypted MAC of handshake).
• Server issues SSL Alert: Bad Record MAC.

Googling did not help either. Some suggest changing the clock would help, but same client fails only on a specific connection. Anyway, I synced all clocks of all involved machines: no joy. Clearing the cache: curl doesn't even have cache. Anyway, it didn't help. The closest online discussion of the problem is this thread. On other threads, some people hint that the problem is dependent on the particular connection, but nobody offers a decent solution.

I know it's a long shot, but: does anybody out there have an idea on how to fix this? Even a hint towards a method to further debug it would be greately appreciated. Problems for a good debug method:

• MAC is over random numbers: any comparison with different server/connection handshakes is useless.
• Since it is connection dependent client side errors are rather impossible.
• The sent MAC is encrypted, it's hard to analyze with wireshark.

The last ideas I have is to capture the ppp packets and compare if contents change over wlan0 contents (unlikely, since only google complains (only google checks?? unlikely...)), or try a different router/set the router in gateway mode instead of pppoe modem...

As said before, any idea will be appreciated!

PPPoE with German 1&1 (1und1)

Boring alert: I'm leaving this here just in case it's useful for someone. If you don't {live in Germany, have a 1und1 connection, want to use the Fritz!Box as a modem} you probably don't want to read this

Germany has very nice network coverage (at least compared to Spain). At home, I have a VDSL2 connection, 50Mbps downstream, 10Mbps upstream with 1&1. It includes some online movie rental, online storage, VoIP landline flatrate and a very fancy router to manage it all (FritzBox!Fon 7390), with Phone<->VoIP converter, dual radio WiFi, and lots of other stuff (even console access to the linux underneath, but you need to dial some stuff on a phone to get there, and I have no phone...)

The problem is that the bandwidth is a bit too much for this thing to handle. It manages very well web browsing, ftp upload and downloads and all sorts of usual navigation, but it chokes on BitTorrent usage. Even with just 400 connections it freezes after a few hours, requiring a reboot.

Solution? The web interface allows to use it just as a modem, with a very handy option just in the menu! I have the "advanced options" (Einstellungen>Ansicht>Expertenansicht) active, maybe it's not possible without it. Kudos to Fritz, the firmware might have some bugs / stability problems but their attitude is great. They give the user complete control over the hardware and it looks like they really care about the customer (when I reported another bug I got to talk with a technician after just one email exchange with some operator).

Problem? Of course there is one! It wouldn't be funny without it! After following the super-easy PPPoE guide it wouldn't work. Looking at /var/log/errors.log it said something about an authentication error, and the PAP protocol error was "profile not sufficient". Weird, huh? After some googling it turns out that the credentials 1&1 gives you to connect are not complete. They are in the form 1und1/USERNAME@online.de but the real PPPoE username is ONELETTER1und1/(SOMESTUFF)USERNAME@online.de.

How to find out the first letter and the stuff inside the parens? Maybe you could call 1&1 but if your german is not that... well, german, you can find it out with a packet capture. Yes, a packet capture, of the original PPPoE handshake. No, I'm no kidding. No, you don't need and specialized DSL-sniffing gizmo. Just go to http://ROUTER_IP/html/capture.html, force a reconnect from the main webpage and you just captured the handshake on the DSL interface.

Really really nice job, Fritz, I am impressed. Arguably "lucky for us", the PAP authentication is in clear text, so just get the full username, and put it in the peer file, in the pap-secrets, and you are good to go! The linux box will have a public IP so don't forget a firewall and turning everything you don't need off.

Connect to the internet from Linux through a Windows Mobile phone

*Post en inglés por si le es útil a alguien ;)
_______________________________

Maybe with *buntu it's stupid easy, but as far as my experience goes, they probably tried to make it easy but it fails catastrophically in 50% of the cases. This is how to connect you linux box to the internet using the "Share connection" funcion of many phones, directly from the command line, so it should work in any linux distro, even in *buntu! Of course, some commands must be run as root, so be warned that if you type "rm -rf /" by mistake, I accept no responsability for your (incredibly dumb) actions.

Via USB: plug the phone to the computer, select "USB" as the PC connection in the application, press conect on the phone screen and type "dhcpcd eth1" in the console. If the browser gets stuck in a "Waiting for [domain]" step, try "ifconfig eth1 mtu 1394" and the reload the website again.
Good to go? Then I'm glad.
Something failed? Try: modprobing rdnis_host, using dhclient instead of dhcpcd or trying a different interface. To find out which one is the correct one just do a "ifconfig -a" before and after pressing connect on the phone screen. Or try with different MTU values, of course for the USB network interface.
If it still doesn't work, something definitely sucks: you with linux, me as a teacher or life. I'm sorry either way.

Via Bluetooth: ok, pay attention because this one is not as straightforward as the USB one. Of course you need BT working in your computer, so if you don't, go read some howto, install bluez utils and keep reading.
- First select "Bluetooth PAN" as the PC connection on the phone screen and press connect.
Now, if you haven't used bluetooth between you linux box and your phone before, you have to introduce them to each other. If you have, it'll be enough to do the pand and dhcp steps.
- Ok, let's start with the phone. In the application's menu, go to BT config and under "Mode" make sure your phone is "discoverable" by other devices.
- Now with the computer. First, activate the BT device, either by a physical switch or any other specific method your hardware manufacturer happened to use.
- After your BT light is on and shining, find your phone by typing "hcitool scan". Among all kind of crap, including "hello kitty" depending on your location, you should see your phone. And its MAC address. So remember it. Or copy it to paste it in the next step if you are not a geek.
- Next step: connect to the phone. Type "pand -c MAC_ADDRESS". If it's the first time, your phone will ask you if you really want him to talk to this stranger. Now pay attention: on your computer, open a new console and run "bluez-simple-agent" and on your phone answer yes. You will be prompted a code on both. Enter the same code in both. Press enter/ok on both. You can close the new console on the computer now and on the phone, the messages that will pop up.
- Ok, so the computer and the phone are connected now, or at least they should be. Confirm it by looking for "Connected" on the phone and doing a "hcitool con" on the PC. You should also have a new network device, bnep0 on the linux box.
- Last step, similar as with the USB process: "dhcpcd bnep0", or your dhcp client of choice for that matter. You shouln't need to modify the MTU here.

If you have some problem you can leave a comment and we'll figure out what's sucking in that moment :)

Wireshark sin root

Todo el mundo recomienda ejecutar wireshark sin privilegios de root, lo cual es lógico. Según la propia web, son un millón de líneas de código analizando datos potencialmente maliciosos. Suena lógico, pero por desgracia para capturar tráfico hacen falta privilegios de root.

Así que para usar wireshark hay dos opciones:

• Arrancar un tcpdump o dumpcap como root, guardar el resultado en un archivo y ejecutar wireshark como un usuario sin privilegios. Bastante incómodo pero efectivo.
• Permitir a un usuario capturar tráfico. O más general aún, a un grupo de usuarios. Así, cualquiera en ese grupo puede arrancar wireshark y ponerse a capturar tráfico sin más molestias. Normalmentee esto se haría ajustando los permisos del dispositivo en cuestión, como el caso de /dev/sdX para los discos duros, pero las interfaces de red por desgracia no parecen tener estaa opción (hoy en día, en algún sitio leí de dispositivos /dev/tcp, pero me lo puedo estar inventando). La solución es la siguiente:

# which dumpcap
/usr/bin/dumpcap

# chmod 750 /usr/bin/dumpcap

# chmod +s /usr/bin/dumpcap


# chgrp GRUPO_CAPTURA /usr/bin/dumpcap

Y cualquier usuario del GRUPO_CAPTURA (por ejemplo, wheel) puede inicar wireshark normalmente y empezar a analizar tráfico en vivo.

Gestión IP en Linux

A falta de algún detalle de control de tráfico y algunos destinos de iptables creía que sabía bastante de administración de redes IP en Linux, pero una vez más se cumple eso de que cuanto más aprendes, más te das cuenta de que no sabes nada. Por una duda tonta sobre enrutamiento que me asaltó, me puse a buscar en google y llegué a este manual sobre IP en Linux.

Si bien es cierto que no es perfecto, hay temas que están vacíos (solo contienen enlaces a otras aginas) y en algunas entradas están marcadas como FIXME con preguntas del autor, en general vale la pena leerselo. Yo he descubierto cosas que desconocía, como formas de manipuación de ARP o que el kernel tiene múltiples tablas de rutas.

En caso de tener un puñado de horas libres, lo recomiendo sin duda, así como los enlaces que tiene (bridging, arp-proxy, etc).

(In)seguridad wireless III

¡Al fin! Tras mucho esfuerzo y sufrimiento al fin los vecinos no van a poder conectarse a mi wifi. Bueno, esto no es del todo cierto: si que van a poder conectarse, pero no van a poder usarla.

Ultimamente han llegado a mi casa multitud de chismes con capacidad wifi. A la semana de tener la PSP se le unió la Wii y hace una semana la flamante PS3. Y todos ellos con soporte WPA, así que ya tocaba hacer algo. Tras decidirme a cambiar al fin el cifrado WEP por WPA me puse manos a la obra. Hasta ahora tenía un portátil NEC PIVM 1.8GHz con 256Mb RAM haciendo de router/server con debian stable, usando cifrado WEP y un script iptables bastante molesto para posibles intrusos. Para los PC's que no tuvieran soporte de WPA (el PC de "la familia" con una tarjeta belkin 11b, p.ej.) tenía una fonera que podía poner en modo WEP con forwarding deshabilitado y OpenVPN al server, de modo que hiciera falta conectarse a la VPN para salir al exterior. No me hacía gracia usar la fonera con su firmware original para mover tráfico, pero no había otra opción de coste 0.
La tarjeta PCMCIA de 25 euros que me compre en su día llevaba ya un tiempo funcionando en modo Master + WEP gracias a los drivers prism54 y el hostapd anunciaba (y aún anuncia) que también daba soporte a este chispet para modo Master + WPA. Bien, apt-get install hostapd, leer docuemtancion, editar configuración, probar y... ¡buen intento, sigue probando!

hostapd -dd hostapd.conf
Configuration file: hostapd.conf
Opening raw packet socket for ifindex 5
ioctl(SIOCGIFINDEX): No such device
prism54 driver initialization failed.

No se encuentra dispositivo. Tras cambiar el archivo .conf durante 5 minutos lo doy por imposible y busco en internet. Al igual que en un mensaje en algún foro, lo ejecuto con strace y efectivamente, hostapd levanta la interfaz eth2 (bien) y luego intenta controlar la eth2ap (¡mal!). Por ahi sugerían recompilar el hostapd con un hack del driver prism54: quitar a pelo ese "ap" del string del nombre de la interfaz. Bueno, se puede intentar. Como los experimentos, mejor con gaseosa, quito la tarjeta del router/server debian stable y la pongo en el portatil gentoo. Copio el ebuild a un overlay local, lo edito para bajar el código del disco duro, modifico el propio código (%sap ->%s), digest del ebuild y pa'lante. Y... nada. Arranca el rpograma, saca todos sus mensajitos, pero ni pone la tarjeta en modo Master, ni WPA, ni nada de nada. Indagando más por la red, resulta que el soporte de prism54 para hostapd es por así decirlo "histórico" ya que la realidad es que "un día funcionó con una versión del driver" segun cuenta el propio creador del hostapd en este email. La cosa para prism54 dejó de funcionar allá por 2005, en el mail de 2006 dijo de avisar en la web que ya no funcionaba y a noviembre de 2007 sigue apareciendo que lo soporta para que algún pardillo pierda la tarde intentándolo. Dado que no me apetecía bucear en las versiones del 2004 del prism54 para recompilar un modulo para el kernel de 2007 y el posible fin del mundo que podría ocasionar dicha combinación, deseché esa vía.

Dado el estado de las cosas, me he decidido por otra configuración. Para los PC's, prism54 en Master + WEP (menos da una piedra) con OpenVPN y política DROP para FORWARD con origen wifi. A traves el tun0, salida a internet, así cualquiera se puede meter en la wifi pero ni podrá usarla ni escuchar nada puesto que todo irá en tuneles cifrados. Y para las consolas, fonera + WPA, así de paso se separa el tráfico de unos y otros para (en el futuro) implementar QoS con tc.

La instaltación de la OpenVPN la he hecho siguiendo el HOWTO oficial, usando certificados. Tanto para windows con OpenVPN GUI como para linux con NetworkManager el sistema funcona bastante bien.
Al hacer un 'ping server-f -s 15000' con la wifi da unas tasas de 1,1Mb/s tanto de subida como de bajada. Al hacerlo con la VPN, el trafico observado en la interfaz wifi es de apenas 350kb/s. Extrañado, cree en el server un archivo de 100MB con 'dd if=/dev/zero of=/var/www/zero' y lo bajé a traves de la VPN. Resultado: 350kb/s en la wifi, 3Mb/s de velocidad efectiva. Razón: comp-lzo haciendo su trabajo. En efecto, al intentar bajar un 'openssl rand 100000000 > /var/www/rand' las tasas en wifi eran de 2,4Mb/s y en el tunel 2,02Mb/s (todo esto con la wifi a 54Mbps teóricos). Eso sí, durante la descarga de datos, el proceso de VPN llega a consumir un 15% de CPU, asi que habrá que pensar en cambiar el cifrado blowfish por defecto por alguno más ligero...

Algún día postaré todos los ficheros de configuración y scripts de iptables, pero a día de hoy creo que ya he hecho bastante.

Eso sí, aunque ya tenga una wifi segura, no pienso ponerle antivirus al PequeSuave Ventanas XP, ¿que sería de esta vida sin riesgo?