fix(examples): resoudre le LINKTYPE par paquet dans scan_pcaps - #78
Conversation
Un pcapng peut decrire plusieurs interfaces, chacune avec son LINKTYPE, et chaque paquet designe la sienne par interface_id. scan_pcaps appelait get_datalink() une seule fois par fichier puis bouclait sur while let Ok(packet) : le LINKTYPE de la premiere interface etait applique a tout le fichier, et la lecture sortait au premier changement d'encapsulation. Silencieusement — le fichier affichait zero trame. La lecture passe de libpcap a pcap-file, deja dependance principale de la crate, qui donne acces aux blocs de description d'interface. packet_parser prend deja le LinkType en parametre : c'etait bien l'iteration qui etait en cause, pas la crate. Trois fichiers du corpus etaient concernes, pas seulement celui de l'issue : The-Ultimate-PCAP.pcapng 0 -> 51328 capwap-only.pcapng 0 -> 2 capwap-association-valid.pcapng 0 -> 2 Les trois comptes correspondent exactement a tshark. Une comparaison avant/apres sur tout le corpus confirme qu'aucun autre fichier ne change. Une erreur de lecture est desormais distinguee d'une fin de fichier et signalee, fichier par fichier puis en recapitulatif final : un total de corpus bati sur des lectures amputees ne se presente plus comme complet. Le chemin pcap classique utilise next_raw_packet : next_packet rejette orig_len > snap_len comme invalide, ce qui est plus strict que libpcap et que la realite d'une trame tronquee a la capture. Cette validation faisait tomber une capture de 3584 trames a 4 — regression detectee par la comparaison de corpus, avant commit. Les erreurs L2 portent enfin leur LINKTYPE, ce qui repond au point 3 de l'issue : les 10667 echecs de The-Ultimate-PCAP viennent tous du LINKTYPE 274, IEEE 802.3br mPackets, seule des quatre encapsulations du fichier a n'avoir pas de decodeur. Closes #74 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e46e0708b7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if let [link_type] = linktypes[..] { | ||
| outcome.frames += 1; | ||
| on_packet(link_type, &spb.data); |
There was a problem hiding this comment.
In a valid pcapng section with multiple Interface Description Blocks, a Simple Packet Block is associated with the first interface (interface 0); it does not require the section to contain exactly one interface. Matching only [link_type] silently drops every SPB in such a capture, undercounts frames, shifts --focus frame numbers, and still reports the file as completely read.
Useful? React with 👍 / 👎.
| Block::EnhancedPacket(epb) => { | ||
| if let Some(&link_type) = linktypes.get(epb.interface_id as usize) { | ||
| outcome.frames += 1; | ||
| on_packet(link_type, &epb.data); | ||
| } |
There was a problem hiding this comment.
When an Enhanced Packet Block references an out-of-range interface_id, this branch silently skips it, leaves truncated_by unset, and excludes it from the frame count; the analogous Packet Block branch behaves the same way. Thus a malformed or partially generated pcapng is presented as a complete scan even though packet blocks were discarded, defeating the new incomplete-read reporting; record an error or otherwise mark the outcome incomplete instead.
Useful? React with 👍 / 👎.
La PR de sync (#77) a ete mergee avant celle du correctif (#78), si bien que la roadmap designait encore #74 comme priorite et comme bloquant de #56 et #70, alors qu'il etait clos dans la foulee. #74 est clos : scan_pcaps resout le LINKTYPE par paquet, et trois captures sortent de l'invisibilite (The-Ultimate-PCAP.pcapng 0 -> 51328, capwap-only.pcapng et capwap-association-valid.pcapng 0 -> 2). Le corpus n'est rendu qu'aux quatre cinquiemes : les 10667 trames en LINKTYPE 274 restent indecodees, soit 21 % de The-Ultimate-PCAP.pcapng. #79 devient donc le prealable restant a #56 — ces trames portent 2403 ICMPv6, 818 VRRP, 777 GLBP, 678 IS-IS et 599 NTP, dont plusieurs sans autre source de trames reelles dans le depot. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Ferme #74.
scan_pcapssurThe-Ultimate-PCAP.pcapngremonte desormais51 328 trames, exactement le compte de tshark.
Cause
Un pcapng peut decrire plusieurs interfaces, chacune avec son LINKTYPE, et
chaque paquet designe la sienne par
interface_id.scan_pcapsappelaitget_datalink()une seule fois par fichier, puis bouclait surwhile let Ok(packet). Le LINKTYPE de la premiere interface etait doncapplique a tout le fichier, et la lecture sortait au premier changement
d'encapsulation — silencieusement, en affichant zero trame.
La lecture passe de libpcap a
pcap-file, deja dependance principale de lacrate, qui donne acces aux blocs de description d'interface. Aucune dependance
nouvelle.
packet_parser::parseprend deja leLinkTypeen parametre :c'etait bien l'iteration qui etait en cause, pas la crate.
La panne touchait trois fichiers, pas un
The-Ultimate-PCAP.pcapngcapwap-only.pcapngcapwap-association-valid.pcapngUne comparaison avant/apres sur l'integralite de
pcaps_exemple/confirmequ'aucun autre fichier ne change de compte.
Point 3 de l'issue : le LINKTYPE 274
Les erreurs de couche liaison portent desormais leur LINKTYPE, ce qui rend le
trou diagnosticable au lieu de le laisser anonyme. Sur
The-Ultimate-PCAP,les 10 667 echecs viennent tous du LINKTYPE 274 — IEEE 802.3br
mPackets (confirme par
capinfos), seule des quatre encapsulations dufichier a n'avoir pas de decodeur :
Cablier un decodeur 802.3br debloquerait ces 10 667 trames, mais le format
mPacket implique la preemption — une trame preemptible peut etre fragmentee
sur plusieurs mPackets. C'est un chantier a part entiere, pas une ligne de
plus dans
decoder_for; hors perimetre de cette PR.Une regression introduite, puis rattrapee avant commit
La comparaison de corpus a montre que le gros
.capCAPWAP tombait de 3 584 a4 trames :
next_packetdepcap-filerejetteorig_len > snap_lencommeinvalide, ce qui est plus strict que libpcap et que la realite d'une trame
tronquee a la capture. Le chemin pcap classique utilise donc
next_raw_packet, qui n'applique pas cette validation — on ne lit de toutefacon que
data. Apres correction, le diff de corpus est du gain pur.Fin de fichier vs erreur de lecture
Une lecture interrompue par une erreur est desormais distinguee d'une fin de
fichier et signalee, fichier par fichier puis en recapitulatif final. Un total
de corpus bati sur des lectures amputees ne se presente plus comme complet.
Deux fichiers MQTT remontent ainsi « lecture incomplete ». Ce n'est pas une
regression : l'ancienne version donnait exactement les memes comptes, sans le
dire.
mqtt_packets_Windows.capest un fichier Sniffer (Windows) 2.00x, queni libpcap ni
pcap-filene lisent ;mqtt_packets_RedHat61_tcpdump.pcapestune variante que les deux lecteurs arretent a la premiere trame.
Verification
cargo test: 1 065 tests verts.cargo clippy --all-targets --all-features: aucun warning.Closes #74
🤖 Generated with Claude Code