Logo na visita ao NOC da Itália, tive a agradável surpresa que o método de acesso à rede cabeada, leia-se switches fast/giga/ethernet, tinha mudado para usar autenticação via 802.1X.
Como já tinha trabalhado anteriormente com a mesma solução durante meus tempos de D-Link, achei que ia ser fácil.
Primeiramente tentei o seguinte comando:
musashi# wpa_supplicant -i bge0 -c ~helio/IEEE8021X/wpa_supplicant.conf
ioctl[SIOCG80211, op 16]: Invalid argument Failed to initialize driver interface
Qual não foi minha surpresa... Não tinha funcionado. Tentei verificar o erro mais de perto com a opção "-dd" (extra debug):
Initializing interface (2) 'bge0'
EAPOL: SUPP_PAE entering state
DISCONNECTED EAPOL: KEY_RX
entering state NO_KEY_RECEIVE
EAPOL: SUPP_BE
entering state INITIALIZE EAP: EAP
entering state DISABLED EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
ioctl[SIOCG80211, op 16]: Invalid argument
wpa_driver_bsd_init: failed to get roaming state: Invalid argument
Failed to initialize driver interface
Failed to add interface bge0
Cancelling scan request
A mensagem ioctl[SIOCG80211, op 16] me fez pensar sobre driver. Verifiquei a versão no ports, e realmente era muito mais antiga que a versão atual. Baixei manualmente e compilei. Consegui fazer rodar, mas dessa vez utilizando o comando:
musashi# wpa_supplicant -i bge0 -D wired -c ~helio/IEEE8021X/wpa_supplicant.conf
Com a opção -D wired consegui forçar o uso da interface de rede. Só restava verificar se meu arquivo de configuração estava correto ou não.
musashi# ./wpa_supplicant -i bge0 -D wired -c /tmp/wpa.conf -dd
Initializing interface 'bge0' conf '/tmp/wpa.conf' driver 'wired'
ctrl_interface 'N/A' bridge 'N/A'
Configuration file '/tmp/wpa.conf' -> '/tmp/wpa.conf'
Reading configuration file '/tmp/wpa.conf'
ctrl_interface='/var/run/wpa_supplicant'
ctrl_interface_group='0' (DEPRECATED)
eapol_version=1
ap_scan=0
fast_reauth=1
Line: 12 - start of a new network block ssid - hexdump_ascii(len=0): key_mgmt: 0x8
eap methods - hexdump(len=16): 00 00 00 00 19 00 00 00 00 00 00 00 00 00 00 00
phase2 - hexdump_ascii(len=13): 61 75 74 68 3d 4d 53 43 48 41 50 56 32
auth=MSCHAPV2 identity - hexdump_ascii(len=4): 75 73 65 72
user password - hexdump_ascii(len=4): [REMOVED]
Priority group 0 id=0 ssid=''
Initializing interface (2) 'bge0'
EAPOL: SUPP_PAE entering state DISCONNECTED
EAPOL: KEY_RX entering state NO_KEY_RECEIVE
EAPOL: SUPP_BE entering state INITIALIZE
EAP: EAP entering state DISABLED
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
wpa_driver_wired_init: Added multicast membership with SIOCADDMULTI
Own MAC address: 00:14:c2:e7:d2:55
Setting scan request: 0 sec 100000 usec
Using existing control interface directory.
ctrl_interface_group=0
ctrl_iface bind(PF_UNIX) failed: Address already in use
ctrl_iface exists, but does not allow connections - assuming it was leftover from
forced program term ination
Successfully replaced leftover ctrl_iface socket '/var/run/wpa_supplicant/bge0'
Added interface bge0
EAPOL: External notification - portControl=Auto
Already associated with a configured network - generating associated event
Association info event State: DISCONNECTED -> ASSOCIATED
Associated to a new BSS: BSSID=01:80:c2:00:00:03
No keys have been configured - skip key clearing
Network configuration found for the current AP
EAPOL: External notification - portControl=Auto
Associated with 01:80:c2:00:00:03
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
EAPOL: External notification - portEnabled=1
EAPOL: SUPP_PAE entering state CONNECTING
EAPOL: SUPP_BE entering state IDLE
EAP: EAP entering state INITIALIZE
EAP: EAP entering state IDLE Cancelling scan request
EAPOL: startWhen --> 0
EAPOL: SUPP_PAE entering state CONNECTING
EAPOL: txStart TX EAPOL - hexdump(len=4): 01 01 00 00
EAPOL: startWhen --> 0
EAPOL: SUPP_PAE entering state CONNECTING
EAPOL: txStart TX EAPOL - hexdump(len=4): 01 01 00 00
EAPOL: idleWhile --> 0
EAP: EAP entering state FAILURE CTRL-EVENT-EAP-FAILURE EAP authentication failed
EAPOL: SUPP_PAE entering state AUTHENTICATING
EAPOL: SUPP_BE entering state FAIL
EAPOL: SUPP_PAE entering state HELD
EAPOL: SUPP_BE entering state IDLE
EAPOL: startWhen --> 0
Apesar da interface ter sido inicializada corretamente e enviando o primeiro frame, o switch respondia com a solicitação de "identity" que nunca ocorria, ficando a interface sempre em "startWhen --> 0". Busquei vários sites e não encontrei nenhuma resposta satisfatória. Aparentemente o driver de ethernet do FreeBSD não é capaz de utilizar uma chamada ioctl para detectar que um frame foi recebido pela interface.
A única solução que encontrei, não muito elegante, foi inicialiar um linux via quemu com uma interface tap0 em bridge. O wpa_supplicant do Linux funcionou corretamente e pude auntenticar na rede. O método de autenticação foi bem simples, onde segue o arquivo de configuração:
eapol_version=1
ap_scan=0
fast_reauth=1
network={
key_mgmt=IEEE8021X
eap=PEAP
identity="DOMAIN\login"
phase2="auth=MSCHAPV2"
password="password"
}
Ano novo, vida nova, sistema novo... com a chegada de 2007, resolvi encarar a atualização de meu FreeBSD, de 6.1 para 6.2 (que no momento encontra-se ainda em RC2, mas acho que pouca coisa vai mudar). E também fazer minha primeira postagem de 2007 :-)
Ao invés de iniciar pelo sistema, resolvi começar pelos aplicativos, autilizando primeiramente o ports. Pelas minhas experiências anteriores, a atualização é o único ponto fraco do FreeBSD. Comparando com Debian, com seu sistema via apt, é realmente chato, moroso, e frequentemente com falhas o sistema de atualização dos BSDs. Mesmo assim resolvi encarar o ports, já que o mesmo se encontra em FROZEN para o lançamento do release 6.2.
Antes de iniciar, busquei algumas dicas de atualização e achei a página
http://sig9.com/articles/ports-howto
com um howto sobre atualização do ports. Como não era exatamente o que eu pensava em fazer, resolvi seguir, pois aparenta ser uma solução bem simples.
Já tinha feito a atualização do ports via portsnap, usando as opções fetch e depois extract, então somente refiz o INDEX para iniciar a atualização.
Alterei a sequência de comandos para:
portupgrade -arRP && pkgdb -F && pkgdb -fu
A opção -P do portupgrade faz com que seja buscado primeiramente o pacote já compilado antes de re-compilar a partir dos fontes. Isso tornaria a atualização mais rápida, porém...
---> Fetching the package(s) for 'ctags-5.6' (devel/ctags)
---> Fetching ctags-5.6 fetch:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-6.1-release/All/ctags-5.6.tbz:
File unavailable (e.g., file not found, no access)
O sistema continua buscando packages-6.1-release, o que é correto já que ainda não foi atualizado, mas os pacotes compilados só estão disponiveis pro release 6.2... sendo assim, não consegui poupar o tempo que queria...
Até o momento a atualização dos aplicativos já consumiu 20 horas, sem vistas de acabar. Ao menos está indo de uma forma menos traumáticas que das outras vezes. Vamos ver qual vai ser o resultado final...
Nesse domingo de feriadão, fui saudado com uma alteração no horário de verão de minhas máquinas. Eu já sabia que isso iria acontecer algum dia, já que o governou alterou o início do mesmo para seguir o calendário eleitoral.
Porém eu aguardava algum arquivo de zona lançado oficialmente por alguma entidade como o CAIS. Como isso não ocorreu, criei meu próprio arquivo de zona, baseado em um modelo de 2005, chamado hverao2006.zic, e coloquei a data de início, 00:00 horas de 05 de novembro, e a data final, 00:00 horas de 25 de fevereiro de 2007:
Rule Brazil 2006 only - Nov 05 00:00 1 D Rule Brazil 2007 only - Feb 25 00:00 0 S Zone America/Sao_Paulo -3:00 Brazil BR%sT Zone Brazil/East -3:00 Brazil BR%sT
Verifiquei se meu /etc/localtime apontava como link simbólico para /usr/share/zoneinfo/Brazil/East ou /usr/share/zoneinfo/America/Sao_Paulo(ambos são corrigidos pelo arquivo acima) e simplesmente atualizei a informação de timezone:
zic hverao2006.zic
Hoje me deparei com mais um problema estranho, daqueles que vemos nos momentos mais indesejados durante as tarefas mais corriqueiras.
Copiei minha imagem de Windão do meu laptop, FreeBSD 6.1, para meu desktop de casa, Ubuntu 6.06.1 (LTS). Minha idéia é usar a imagem do Windão para levantar uma conexão VPN à empresa. Como o aplicativo só roda em Windão... nada resta além de instalar no gateway de casa e começar a debugar a conexão (acho que é só um IPsec, mas....).
Fiz a conexão remote via ssh com o parâmetro "-X". Qual foi minha surpresa quando recebi o seguinte erro:
helio@picasso tmp> qemu -hda windows.img
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 25 (X_SendEvent)
Resource id in failed request: 0x44
Serial number of failed request: 12
Current serial number in output stream: 17
Cara de "ué?!" e alguns momentos de leitura da manpage me deram a seguinte alternativa:
helio@picasso tmp> qemu -hda windows.img -std-vga
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 25 (X_SendEvent)
Resource id in failed request: 0x44
Serial number of failed request: 12
Current serial number in output stream: 17
A cara de "ué?!" passou para um rosto de "saco...". Testei a conexão com um simples "xclock" que funcionou perfeitamente. Fiquei mais perdido ainda. Não restando muita opção, busquei ajuda no google. Felizmente achei exatamente o que queria:
O grande macete foi reiniciar a conexão ssh com o parâmetro "-Y". Funcionou!!!! VPN debugging, aqui vou eu!!!!!!!!!
Novo trabalho, novos desafios. Umas das primeiras coisas que fiz foi livrar meu laptop dos grilhões que o prendiam e instalar o bom e velho FreeBSD, release 6.1. Bom sistema, tudo funcionando (ou quase tudo). Eis que resolvi recuperar alguns dados que gravei em um DVD:
musashi# ls -skh /cdrom/
ls: Backup-musashi_Win2k-2005-04-17.tar: Value too large to be stored in data type
total 227 227
Backup-musashi_Win2k-2005-04-17.toc.gz
Fora o fato bizarro de eu estar tentando acessar um backup de Windows, achei sacal o problema de não conseguir ler a mídia. Buscando na rede, descobri que existe uma limitação no driver cd9660 para ler arquivos maiores de 2GB.
Uma busca árdua no google me levou ao link:
Apliquei a alteração:
--- sys/isofs/cd9660/cd9660_node.h.org Wed Mar 16 09:09:52 2005
+++ sys/isofs/cd9660/cd9660_node.h Sun Jan 8 00:14:54 2006
@@ -69,7 +69,7 @@
ino_t i_ino; /* inode number of found directory */
long iso_extent; /* extent of file */
- long i_size;
+ u_long i_size;
long iso_start; /* actual start of data of file (may be different */
/* from iso_extent, if file has extended attributes) */
ISO_RRIP_INODE inode;
Ao invés de patch, editei o arquivo não mão, já que alteração era de long para u_long somente. Vamos ver se funciona....
