Eu acho que encontrei a minha resposta, é de fato adicionado pelo libcap como um pseudo-protocolo
Em um sistema Linux que estou testando agora, ele possui alguns dispositivos virtuais L2 encadeados para adicionar / manipular nossos próprios cabeçalhos de quadros, encapsulados entre o cabeçalho Eth e o cabeçalho IP.
agora é o que "tcpdump -xx -i virtual_if_1" mostra para um pacote de saída capturado
tcpdump: WARNING: xxxtype 1000 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on virtual_if_1, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
20:20:25.558423 IP 0.0.0.0.52368 > 5.5.2.2.telnet: S 3501169179:3501169179(0) win 35848 <mss 17924,sackOK,timestamp 17386889 0,nop,wscale 8>
0x0000: 0004 03e8 0006 0000 0000 1b9a 0000 0800
0x0010: 4510 003c d792 4000 4006 5c13 0000 0000
0x0020: 0505 0202 cc90 0017 d0af 9a1b 0000 0000
0x0030: a002 8c08 0735 0000 0204 4604 0402 080a
0x0040: 0109 4d89 0000 0000 0103 0308'
A partir de 0x0010 é o cabeçalho IP de L3, mas 0x0000-0x000f é falso, não é o cabeçalho que este dispositivo virtual deve preceder ao cabeçalho L3. Parece que o tcpdump adiciona automaticamente um cabeçalho imaginário Ethernet a ele? É por causa do aviso mostrado acima, o tipo não é suportado pelo lipcap?
Onde o tcpdump obtém esses dados de qualquer maneira. é de dados sk_buff- >?
Obrigado
Eu acho que encontrei a minha resposta, é de fato adicionado pelo libcap como um pseudo-protocolo