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!”.

Advertisements

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.