Como rastrear os passos da minha rede

2

Pergunta (versão concisa):

Onde nos meus arquivos de log eu encontraria informações sobre as etapas de rede executadas entre a hora em que saí da tela de login e a hora em que pousei confortavelmente na tela da minha área de trabalho?

$ uname -a
Linux schmo 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux

Pergunta (versão mais longa com mais de uma cláusula):

Quem, ou que daemon, ou quais scripts são responsáveis por configurar minhas configurações de rede no login? Descobri que várias tentativas de modificar /etc/network/interfaces são ignoradas ou terminam em uma configuração que não funciona, mas que a versão de loopback original de duas linhas funciona bem. Eu quero saber onde a ação está realmente acontecendo.

Quais scripts .conf e bash devo incluir em instruções echo-dump ou quais variáveis de ambiente devo conhecer e definir se o nível atual de feedback nos arquivos de log disponíveis atualmente não é de uma resolução alta o suficiente para capturar as alterações de rede que estão sendo executadas durante o login?

Motivação (pelo menos um deles):

Como eu diria ao meu computador para estabelecer uma ponte sem fio após meu adaptador de rede sem fio estar em funcionamento, o que parece ocorrer somente após fazer login , às vezes completando depois que eu já clicou no Firefox, mas antes de eu lembrar de procurar pelo ícone de status do wifi, argh.

O que eu fiz até agora:

  • SUCCESSALMENTE incluiu uma VM executando o servidor i686 preciso em meu desktop i686 preciso usando o KVM

  • SUCESSAMENTE atualizado, atualizado e adicionado aos pacotes na VM por meio da configuração de ponte sugerida em link , e seguindo o curso do link , enquanto o ssh ' d da minha área de trabalho. Isto implica que a bridge estava funcionando , mesmo que apenas por uma sessão. Meu palpite é que entre o tempo que eu configurei meu arquivo /etc/network/interfaces e o tempo que eu não tinha mais acesso à Internet através da minha VM, as alterações que eu (ou KVM ou alguém) fez nos meus arquivos de configuração se propagaram apenas parcialmente pelo meu sistema (s) da inicialização ao boot e reiniciar para reiniciar, o que quer que isso signifique.

  • Tentou ressuscitar o acesso à VM ao adicionar% wlan0 a /etc/network/interfaces em vários formulários, incluindo a instalação de wpa_supplicant .

  • RECEBEU UM ERRO de wpa_supplicant , que acredito ter sido capaz de rastrear o fato de que os serviços wpa já estão misteriosamente em execução toda vez que eu reinicio a rede. Isso me levou à descoberta de que ...

  • AVAHI NÃO PERMANECERÁ MORTO devido a ser respawned pelo processo # 1; avahi , em seguida, executa outras coisas e pode ser responsável pelo comportamento normalmente satisfatório, mas agora vexatório, da minha conexão sem fio que fica ativa toda vez que eu fizer login (ou não, se eu tentar modificar /etc/network/interfaces ). / p>

Mais detalhes estão disponíveis; apenas me diga o que você gostaria. Eu estou jogando um jogo de chutes-e-escadas com os montes de conhecimento que aprendi ao tentar o que eu tenho até agora, e os vastos abismos da ignorância sobre termos básicos e SOP que me impedem de colocar as coisas em ordem.

Eu olhei para esta página help.ubuntu.com . Observe a parte sobre ponte sem fio. Eu tenho minhas razões para ignorar esta advertência no momento.

    
por Louis Carole 13.10.2012 / 01:36

1 resposta

1

Quanto à pergunta curta (e note o cmd # 's que eu adicionei, começando de 0):

0) dmesg | grep wlan0

fornecerá registros de data e hora para eventos do sistema (desde a sua inicialização mais recente) referentes ao seu roteador sem fio. Note que os dispositivos de algumas pessoas podem ser chamados de 'eth0' ou outra variante além de 'wlan0', dependendo do kernel, gerenciamento de dispositivos e outras configurações além do alcance do entrevistado.

Em seguida, siga a cadeia grep . Em caso de dúvida, procure em todos os lugares possíveis. Everywhere I poderia pensar em /etc e /var/log :

  • /etc contém arquivos de configuração e scripts que definem praticamente todo o comportamento de seus serviços, sem exagero.
  • /var/log é a localização padrão para esses serviços despejarem suas saídas para o registro, seja de uma forma facilmente identificável para os olhos humanos ou não.

NOTA: Recursivamente grep 'ing / não pode prejudicar nos sistemas atuais com memória, tempo de CPU e espaço em disco de sobra. Familiarize-se com bio breaks coordenados e ctrl-C, pode demorar um pouco. Também procure redirecionar a saída para um arquivo, para que você possa lê-lo mais tarde. NÃO sudo grep a menos que você realmente saiba o que está por baixo dos diretórios do sistema grep nega você. Esses diretórios do sistema tornam-se rapidamente redundantes, recursivos, excessivamente verbosos, não textuais e miríades.

Recebi informações abundantes dos seguintes representantes:

1) grep "wlan0" -R /var/log 2>/dev/null

Este grep vai cuspir todas as linhas que eu tenho de dmesg mais algumas coisas dmesg não mostra - como nomes de processos de chamada para cada timestamp ou id de processo, linhas de anterior botas, os nomes dos arquivos que eu nem conhecia como /var/log/udev ...

Um aparte: udev faz frickin 'tudo!

Esse grep -R vai precisar de alguma desconstrução, no entanto. Para relacioná-lo imediatamente à instrução grep inicial, pegue qualquer timestamp de dmesg (os números entre colchetes) e tente

2) grep "\[ 8529.265562\]" -A 10 /var/log/syslog 2>/dev/null

onde você substitui meu registro de data e hora por qualquer data que esteja interessado. OBSERVAÇÃO: Para ser o mais hostil possível, o pessoal do shell-e-regex exige que você adicione essas barras invertidas os colchetes, ou seja, \[ e \] , simplesmente não copiam e colam. Por quê? Barreiras à entrada, é por isso. Leia as expressões grep e regular .

O grep -A acima deve fornecer a linha de dmesg que você esperava (que também foi registrada em / var / log / syslog com o restante) e suas 10 entradas subsequentes:

$ grep "\[11766.363095\]" /var/log/syslog -A 10 2>/dev/null
Oct 19 08:57:40 mitzvah kernel: [11766.363095] wlan0: authenticate with 12:34:56:78:9a:bc (try 1)
Oct 19 08:57:40 mitzvah kernel: [11766.365183] wlan0: authenticated
Oct 19 08:57:40 mitzvah NetworkManager[1261]: <info> (wlan0): supplicant interface state: authenticating -> associating
Oct 19 08:57:41 mitzvah kernel: [11766.638899] wlan0: associate with 12:34:56:78:9a:bc (try 1)
Oct 19 08:57:41 mitzvah kernel: [11766.641406] wlan0: RX AssocResp from 12:34:56:78:9a:bc (capab=0x411 status=0 aid=2)
Oct 19 08:57:41 mitzvah kernel: [11766.641411] wlan0: associated
Oct 19 08:57:41 mitzvah wpa_supplicant[1866]: Associated with 12:34:56:78:9a:bc
Oct 19 08:57:41 mitzvah kernel: [11766.646978] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Oct 19 08:57:41 mitzvah NetworkManager[1261]: <info> (wlan0): supplicant interface state: associating -> associated
Oct 19 08:57:42 mitzvah NetworkManager[1261]: <info> (wlan0): supplicant interface state: associated -> 4-way handshake
Oct 19 08:57:42 mitzvah wpa_supplicant[1866]: WPA: Key negotiation completed with 12:34:56:78:9a:bc [PTK=CCMP GTK=CCMP]

Ei, olhe! Há wpa_supplicant, na linha 6. O ID do processo era 1866 na época. E há outro processo que parece um gerenciador de rede, chamado NetworkManager. Esse é o culpado que eu estava procurando, que continua acenando com sua varinha mágica na configuração da minha rede.

Este não é o fim, é claro. Eu pesquisei no NetworkManager; Eu estou grep 'os diretórios log e / etc no wpa_client armados com um pouco mais de informação. Quando minha rede não funcionava bem e eu não conseguia descobrir como o NetworkManager sabia o que fazia nas minhas costas, encontrei solice no seguinte comando:

3) grep wlan0 -R /etc
...
/etc/udev/rules.d/70-persistent-net.rules:SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="12:34:56:78:9a:bc", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
...

Esse arquivo /etc/udev/rules.d/70-persistent-net.rules contém informações sobre meus dispositivos menos permanentes ao longo de uma sessão para outra, eu acho. Isto seria como vários serviços são capazes de parecer que eles sabem o que é que você está conectando e desconectando de tempos em tempos; eles sabem, já que alguém está gravando isso.

Tudo isso, apenas para informações. Minha principal motivação é insatisfeita: eu ainda tenho que tirar meu wlan0 da inicialização. Aqui está a esperança.

Linux - Because I like banging my head against walls.
    
por Louis Carole 19.10.2012 / 17:39