eBPF network trace incomplete packets missing

c'est un probleme classique avec les probes sur le kernel. t'es sur quel hook point exactement

si c'est des paquets data faut ptete augmenter les buffers pour tes map eBPF. t'as des map full errors dans les logs kernel

on est sur tracepoints/syscalls/sys_enter_sendto et sys_exit_sendto pour l'envoi et tracepoints/syscalls/sys_enter_recvfrom pour la reception. pas de map full dans les logs

hmm syscalls c'est haut niveau. si le paquet est droppé plus bas dans la stack reseau kernel tu le verras pas. t'as essayé des kprobes sur des points plus bas niveau comme __netif_receive_skb ou tpacket_rcv

oui kprobes plus bas c'est souvent mieux pour la visibilité reseau. mais attention à l'overhead. t'as verifié les ressources cpu de ton eBPF program. il tourne trop longtemps

le program est censé etre light. on filtre pas mal. mais c'est vrai qu'on est pas sur des hooks ultra bas. on a des soucis de fragmentation tcp aussi sur cette infra

fragmentation peut etre un souci. eBPF voit les skb. si un skb est fragmenté il faudra reassembler en userspace ce qui est galere. ou il est ptete droppé avant d'atteindre ton hook

verifie ton dmesg pour voir si t'as des bpf: R0 errors ou program too large etc. un bug dans le verifier eBPF pourrait aussi faire droppper des events

et tes cgroup v2. certaines distrib ou container runtimes peuvent mettre des limites sur les resources eBPF. t'es sur des conteneurs

c'est sur des vms classiques pas de cgroup limits bizarres. on a essayé de remonter le net.core.tstamp_allow_data mais ça change rien. on a zero erreurs dans dmesg lié à bpf

ok si c'est pas les maps ou le verifier et que les syscalls sont trop haut c'est ptete un hook point manquant. les datagrammes udp sont affectés aussi ou c'est que tcp

souvent ce genre de souci c'est un kprobe mal placé. essaie de hook ip_rcv ou ip_finish_output pour le traffic ip brut avant ou apres traitement. ça te donnera une vision plus large

pense aussi à l'offload sur la carte reseau. si t'as du tso/gso/lro activé ça peut masquer des details au kernel et donc à eBPF si le hook est pas au bon endroit apres le des-offload

bingo le tso/gso c'était activé. on a desactive ça pour les interfaces qui nous interessent et on voit les paquets maintenant. l'overhead est gerable. merci pour l'aide