Para configurar o netconsole você deve passar o endereço IP e o endereço MAC do host de destino. Se você não passar o MAC como parâmetro - o netconsole empacota o pacote IP para o quadro Ethernet com o endereço de broadcast como destino. Por que o netconsole não procura a rota para hospedar na tabela de roteamento?
É uma limitação do netpoll? Ou é um recurso de tolerância a falhas, se houver algo errado com a pilha de rede? Ou é feito para um trabalho mais rápido? Ou é apenas difícil de implementar?
Qual é o principal motivo?
Responder1
O Netconsole foi projetado para funcionar o mais rápido possível após uma reinicialização. Dea documentação do kernel:
O Netconsole foi projetado para ser o mais instantâneo possível, para permitir o registro até mesmo dos bugs mais críticos do kernel. Ele também funciona em contextos de IRQ e não permite interrupções durante o envio de pacotes. Devido a estas necessidades únicas, a configuração não pode ser mais automática e algumas limitações fundamentais permanecerão: apenas redes IP, pacotes UDP e dispositivos Ethernet são suportados.
Como você pode ver, o netconsole foi projetado para ser um recurso de depuração, não para uso diário. Para isso os designers queriam que fosse o mais simples e robusto possível, mesmo que a configuração seja um tanto rudimentar.
Se o recurso tivesse sido projetado para descobrir automaticamente para onde enviar o pacote, o código teria que consultar a tabela de roteamento para ver se o host de destino está na mesma sub-rede, mas o roteamento provavelmente não está configurado quando as primeiras mensagens forem enviadas. enviado. Mesmo que possamos assumir que o host de destino está na mesma sub-rede, sem o conhecimento do endereço MAC de destino, a implementação teria primeiro que fazer uma consulta ARP. Enquanto espera pela resposta, o kernel trava e a mensagem de travamento é perdida.