Estou interessado na interface de baixo nível com pacotes de rede. Pelo que eu li, ferramentas como tcpdump e libpcap usam o dispositivo de filtro de pacotes BPF / dev / bpf * para ler pacotes de rede de camada de link (no Mac OS X e FreeBSD).
Mas de onde vêm os dados de / dev / bpf *? Se começarmos de baixo para cima, os dados são primeiro lidos pela placa de rede de hardware (de ondas de rádio para wifi). Em seguida, o driver da placa de rede lê esses pacotes e os fornece ao kernel. Por exemplo, no meu computador, a placa de rede é o Aeroporto Brcm_4331, cujo driver está listado no IOReg como "com.apple.driver.AirPort.Brcm4331". Mas quando você olha para ele da camada de soquete ou usando ifconfig, a interface de rede é chamada de "en0". Este é também o nome da interface que você fornece quando usa a API de captura de pacotes bpf.
Então, o que está no intervalo entre o driver real da placa Airport Brcm_4331 e a interface genérica "en0"?
Meu palpite é que o próprio driver da NIC fornece uma interface genérica para ler pacotes brutos. Por isso, lê os pacotes do hardware (camada física, wifi) e, em seguida, fornece algumas funções padrão para ler pacotes de maneira independente do dispositivo para a camada de dados (ethernet). Isso seria o que é chamado de interface "en0". Em seguida, o bpf lê a partir da interface "en0" e grava seus dados no arquivo / dev / bpf para fornecer uma interface semelhante a um arquivo Unix.
Isso está correto? E se sim, então é possível escrever código que interaja diretamente com o driver, sem usar a API do bpf? Estou muito confuso neste nível porque é difícil encontrar documentação sobre essas coisas. Geralmente, apenas as APIs de alto nível do Unix (sockets raw, libpcap e bpf) são discutidas, sem explicar como elas interagem com os drivers reais.
Tags network-interface osx