Quand on commence à toucher à la capture réseau en Rust, la première étape est simple : savoir quelles interfaces réseau sont disponibles sur la machine. Avec la crate pcap, c’est possible en quelques lignes de code.

Dans ce guide, on va voir comment :

1. Installer les dépendances nécessaires sous Linux
2. Créer un projet Rust minimal
3. Lister les interfaces réseau et leurs adresses
4. Ajouter quelques tests unitaires simples

🛠️ Pré-requis sous Linux

La crate pcap est un binding Rust de la librairie libpcap, très utilisée en C (par Wireshark, tcpdump…).
Pour que tout fonctionne, il faut installer les headers de développement :

sudo apt update
sudo apt install libpcap-dev

⚠️ Note : lister les interfaces ne demande généralement pas de sudo. Mais si tu veux plus tard capturer des paquets, il faudra soit lancer ton programme avec sudo, soit donner les droits à ton binaire avec setcap.

📦 Création du projet

cargo new pcap-list-interfaces
cd pcap-list-interfaces

Ajoute les dépendances dans ton Cargo.toml :

[dependencies]
pcap = "1"
thiserror = "1"

💻 Le code complet

Voici le contenu de src/main.rs :

use pcap::Device;
use thiserror::Error;

fn main() -> Result<(), PcapError> {
    // On récupère les interfaces réseau
    let interfaces = get_interfaces()?;

    // On affiche les noms
    print_interfaces_names(interfaces.clone());

    // On affiche les adresses IP associées
    print_interfaces_addresses(interfaces);

    Ok(())
}

#[derive(Debug, Error)]
pub enum PcapError {
    #[error("Impossible de lister les interfaces réseau")]
    DeviceListError(#[from] pcap::Error),
}

fn get_interfaces() -> Result<Vec<Device>, PcapError> {
    let devices = Device::list()?;
    Ok(devices)
}

fn print_interfaces_names(interfaces: Vec<Device>) {
    for interface in interfaces {
        println!("{}", interface.name);
    }
}

fn print_interfaces_addresses(interfaces: Vec<Device>) {
    for interface in interfaces {
        for address in interface.addresses {
            println!("{:?}", address.addr);
        }
    }
}

🧪 Ajout de tests unitaires

Même pour un petit utilitaire, écrire quelques tests aide à éviter les mauvaises surprises :

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn get_interfaces_returns_ok() {
        let res = get_interfaces();
        assert!(res.is_ok(), "expected Ok, got {:?}", res);
    }

    #[test]
    fn print_interfaces_names_does_not_panic() {
        let interfaces = get_interfaces().unwrap_or_else(|_| Vec::new());
        let outcome = std::panic::catch_unwind(|| {
            print_interfaces_names(interfaces.clone());
        });
        assert!(outcome.is_ok(), "print_interfaces_names panicked");
    }

    #[test]
    fn print_interfaces_addresses_does_not_panic() {
        let interfaces = get_interfaces().unwrap_or_else(|_| Vec::new());
        let outcome = std::panic::catch_unwind(|| {
            print_interfaces_addresses(interfaces);
        });
        assert!(outcome.is_ok(), "print_interfaces_addresses panicked");
    }
}

Ces tests garantissent que :

• get_interfaces fonctionne correctement,
• l’affichage des noms ne panique pas,
• l’affichage des adresses ne panique pas.

▶️ Lancer le programme

Exécute simplement :

cargo run

Sur une machine Linux classique, tu verras quelque chose comme :

lo
eth0
wlan0
Some(192.168.1.42)
Some(127.0.0.1)
Some(::1)

Chaque interface (lo, eth0, wlan0) est listée, suivie de ses adresses IP.
Ici, ::1 est l’adresse IPv6 de loopback.

▶️ Lancer les tests

cargo test

Tu devrais obtenir :

running 3 tests
test tests::get_interfaces_returns_ok ... ok
test tests::print_interfaces_names_does_not_panic ... ok
test tests::print_interfaces_addresses_does_not_panic ... ok

✅ Conclusion

En moins de 100 lignes de Rust, on a appris à :

• Lister les interfaces réseau d’une machine sous Linux
• Afficher leurs adresses IP
• Gérer proprement les erreurs avec thiserror
• Écrire des tests unitaires basiques

C’est une première étape avant d’aller plus loin : capturer des paquets, filtrer avec BPF, ou analyser du trafic réseau directement depuis Rust.

Par Cyprien Avico
Toulon, 2025

🧭 SBOM et CBOM : deux concepts, deux objectifs

✅ SBOM (Software Bill of Materials)

Le SBOM est devenu un standard incontournable dans la cybersécurité logicielle.
Il représente une liste exhaustive des composants logiciels d’une application : bibliothèques, frameworks, dépendances, avec leurs versions exactes.

Pourquoi c’est important ?
Parce que le SBOM permet :

• D’identifier rapidement les vulnérabilités connues (CVE),
• D’assurer la conformité réglementaire (ISO 62443, NIS2, etc.),
• De faciliter la gestion des risques liés à la supply chain logicielle.

Il existe aujourd’hui des standards formalisés pour le SBOM :

• SPDX (Software Package Data Exchange), développé par la Linux Foundation,
• CycloneDX, soutenu par OWASP.

Ces formats sont interopérables et largement adoptés dans les pipelines DevSecOps, les audits logiciels, et la gestion de la sécurité des applications modernes.

🔒 CBOM (Cyber Bill of Materials)

Le CBOM va au-delà du logiciel.
C’est une vue globale de la chaîne d’approvisionnement numérique d’un système :

• Composants matériels (CPU, cartes réseau, disques, etc.),
• Versions de firmware et de BIOS,
• Systèmes d’exploitation installés,
• Logiciels (SBOM inclus).

Le CBOM répond à des besoins spécifiques des environnements industriels, OT, et défense :
🎯 Identifier les risques matériels et firmware qui échappent au SBOM,
🎯 Évaluer la surface d’attaque complète d’un système,
🎯 Anticiper les menaces sur la supply chain hardware.

Problème :
👉 Il n’existe pas de standard officiel (équivalent à SPDX ou CycloneDX) pour structurer un CBOM.
👉 Aucun outil ne propose une solution complète, clé en main, pour générer un CBOM, en particulier dans les réseaux isolés.

🏭 L’industrie et la défense : un besoin non couvert

Dans les environnements industriels, SCADA, militaires, et défense, on rencontre une réalité spécifique :
Des postes isolés, sans connexion Internet, souvent vieillissants, qui pilotent des automates, des réseaux industriels ou des machines-outils critiques.

Ces PC de maintenance, stations d’ingénierie, ou systèmes air-gapped présentent des risques majeurs :

• Matériel obsolète ou compromis (ex: attaques type Supermicro),
• Firmware non mis à jour,
• Systèmes d’exploitation non patchés,
• Logiciels spécifiques sans SBOM connu.

Or, il n’existe aujourd’hui aucun outil desktop, portable, et multi-plateforme permettant de :
✅ Scanner hardware + firmware + OS + logiciels sur un poste isolé,
✅ Générer un CBOM structuré (JSON, YAML, PDF),
✅ Fonctionner en 100% offline, sans serveur ni cloud.

C’est une lacune critique pour la cybersécurité des environnements isolés.

🛠️ Les outils existants : puissants, mais pas adaptés

OutilObjectifLimitesSPDX / CycloneDXStandards pour SBOMPas de support pour CBOM (matériel/firmware)Syft / GrypeGénération d’un SBOM logiciel completPas de hardware/firmware, pas adapté au desktopOsqueryInfos système via SQLPas user-friendly, pas un CBOM completGLPI / FusionInventoryInventaire matériel + logicielDépend d’un serveur, pas portableRudderGestion d’inventaire réseauTrop lourd, nécessite une infrastructure réseaufwupdmgr / lshwInformations hardware/firmwarePas d’interface unifiée, pas de CBOM structuréAnchore / TrivyAnalyse logicielle + vulnérabilitésFocalisé sur le SBOM, pas de prise en compte hardware

🚀 Vers une solution à construire : une application desktop cross-platform pour les environnements isolés

Ce qui manque aujourd’hui, c’est une application desktop, capable de tourner sur Windows, Linux, et Mac, qui soit :
✅ Autonome et portable (ex : sur clé USB),
✅ 100% offline, sans dépendances réseau,
✅ Capable de scanner une machine locale (hardware, firmware, OS, logiciel),
✅ De générer un CBOM structuré et exploitable,
✅ Avec une interface utilisateur claire, adaptée aux postes de maintenance industrielle et aux environnements défense.

Une telle solution serait un game changer pour la sécurité des systèmes isolés et critiques.

🗣️ Appel à contribution

Le besoin est là, les technologies sont là (Rust, Tauri, Osquery, Syft, etc.).
Il ne manque plus qu’un projet pour assembler ces briques et répondre à un besoin stratégique pour la sécurité des environnements isolés.

👉 Et si on lançait ce projet ensemble ?
👉 Des idées, des retours, des besoins spécifiques ?
Je suis preneur de vos retours en commentaire ou en message privé. 🚀

From Raw Performance to Modular, Buffered, Asynchronous Capture

In Episode 1, we built a blazing-fast packet sniffer in Rust using pcap, with low-latency configuration and minimal buffering.

Now in Episode 2, we go deeper:

✅ Modular design
✅ Controlled CPU usage
✅ Configurable buffering
✅ Robust asynchronous processing with no packet loss.

🧱 From Monolith to Modular: setup_capture()

We now isolate the setup logic into a reusable function:

pub fn setup_capture(device: Device, buffer_size: i32) -> Result<Capture<Active>, pcap::Error> {
    Capture::from_device(device)?
        .promisc(true)
        .immediate_mode(true)
        .buffer_size(buffer_size)
        .open()?
        .setnonblock()
}

Why?

• Cleaner code separation
• Easier testing
• Configurable for any architecture

🔄 Dynamic channel_size

Just like buffer_size, the channel capacity between the capture and processing thread is now configurable:

start_capture("veth0", buffer_size = 8_000_000, channel_size = 10_000)

This allows:

• Fine-grained control over memory usage
• Backpressure tuning
• Easier performance testing

🧵 Two Threads, One Mission

• tx.try_send(...) ensures non-blocking send
• rx.recv() runs in a dedicated processing thread
• Together, they prevent packet drops

🕳️ Adaptive Backoff Strategy

To avoid wasting CPU cycles when no packets are available:

let mut backoff = 1; // microseconds
...
thread::sleep(Duration::from_micros(backoff));
backoff = (backoff * 2).min(10_000); // exponential backoff

💡 The backoff resets to 1 µs after a successful packet.

🧠 Channel Monitoring (Backpressure)

We measure channel fill rate to avoid overflow:

let fill = rx.len();
if fill >= 0.9 * channel_size as f32 {
    println!(
        "[BACKPRESSURE] Channel is {}% full",
        (fill * 100.0 / channel_size as f32).round()
    );
}

Use this data to tune channel_size, buffer_size, or CPU affinity.

🧪 Real-world Load Test

Using the following setup:

• immediate_mode = true
• buffer_size = 8 MB
• channel_size = 10_000

We pushed the sniffer to process over 1 million packets with:

✅ Zero drops
✅ Stable CPU usage
✅ Low-latency processing

🧭 Mental Map of the Architecture

🖼️ Screenshots: With and Without Backpressure

🧩 Example 1: CPU usage without backoff during low activity
🧩 Example 2: CPU usage with backoff enabled

🖼️ Screenshots: With and Without Backpressure

🧩 Example 1: CPU usage without backoff during low activity

🧩 Example 2: CPU usage with backoff enabled

🚫 Goodbye Packet Drops

Thanks to:

• immediate_mode
• setnonblock
• bounded() channel with enough size
• dedicated processing thread

We hit zero packet loss, even with Gigabit-level input traffic.

🔮 Coming Up Next

In Episode 3 we’ll explore: 📈 Real-time telemetry (Prometheus + Grafana?)

🎯 Goal

Create a minimal yet production-grade network sniffer in Rust that never misses a packet, even under heavy load.

We’ll build on the pcap crate and leverage best practices for memory control, error handling, and performance tuning at the system level.

📦 Dependencies

Add this to your Cargo.toml:

[dependencies]
pcap = "1"
thiserror = "1"
log = "0.4"
env_logger = "0.10"

⚙️ Project Setup

We will:

List available interfaces

Open the target interface in:

• promiscuous mode (see all packets)
• immediate mode (no kernel buffering)
• non-blocking mode (responsive loop)

Process packets in an infinite loop

• Handle all known error cases explicitly
• Track and display dropped packets and receive/processing delta

🧱 Custom Error Management

error.rs:

use thiserror::Error;
use pcap::Error as PcapError;

#[derive(Error, Debug)]
pub enum CaptureError {
    #[error("Network interface not found: {0}")]
    InterfaceNotFound(String),

    #[error("Error listing network interfaces: {0}")]
    DeviceListError(#[from] PcapError),

    #[error("Failed to initialize capture: {0}")]
    CaptureInitError(#[from] PcapError),
}

🚀 Main Code

use error::CaptureError;
use pcap::{Capture, Device};
use std::{thread, time::Duration};
use log::{info, warn, error};

mod error;

fn main() -> Result<(), CaptureError> {
    env_logger::init();
    start_capture("enxfeaa81e86d1e")?;
    Ok(())
}

pub fn start_capture(interface_name: &str) -> Result<(), CaptureError> {
    info!("Starting packet capture on '{}'", interface_name);

    let iface = Device::list()
        .map_err(CaptureError::DeviceListError)?
        .into_iter()
        .find(|d| d.name == interface_name)
        .ok_or_else(|| CaptureError::InterfaceNotFound(interface_name.to_string()))?;

    info!("Interface found: {}", iface.name);

    let mut cap = Capture::from_device(iface)?
        .promisc(true)
        .immediate_mode(true)
        .open()?
        .setnonblock()?;

    let mut count = 0;
    let mut last_stats = None;

    loop {
        match cap.stats() {
            Ok(stats) => {
                let current = (stats.received, stats.dropped, stats.if_dropped);
                if last_stats != Some(current) {
                    last_stats = Some(current);
                    let (received, dropped, if_dropped) = current;
                    info!("Stats => received: {}, dropped: {}, kernel drop: {}", received, dropped, if_dropped);
                    info!("Delta recv - processed: {}", received.saturating_sub(count));
                }
            }
            Err(e) => warn!("Unable to retrieve stats: {:?}", e),
        }

        match cap.next_packet() {
            Ok(packet) => {
                info!(
                    "PACKET len = {}, ts = {}.{}",
                    packet.data.len(),
                    packet.header.ts.tv_sec,
                    packet.header.ts.tv_usec
                );
                count += 1;
            }
            Err(pcap::Error::PcapError(e)) if e.contains("Packets are not available") => {
                thread::sleep(Duration::from_micros(500));
            }
            Err(pcap::Error::TimeoutExpired) => {
                thread::sleep(Duration::from_micros(500));
            }
            Err(pcap::Error::PcapError(e)) if e.contains("Interrupted") => {
                warn!("Capture interrupted cleanly");
                break;
            }
            Err(pcap::Error::PcapError(e)) if e.contains("Operation not permitted") => {
                error!("Missing privileges. Try:\nsudo setcap cap_net_raw,cap_net_admin=eip ./your_binary");
                break;
            }
            Err(e) => {
                error!("Unknown error: {:?}", e);
                break;
            }
        }
    }

    info!("Capture completed. Total packets: {}", count);
    Ok(())
}

🔐 Required Capabilities (Linux)

To capture packets without root:

sudo setcap cap_net_raw,cap_net_admin=eip ./your_binary

📊 Process Overview

🧩 Going Further

• 🧵 Use a dedicated thread to offload packet parsing
• 🧠 Implement a ring buffer to reduce allocations
• 📡 Expose stats via a local HTTP or Unix socket API
• 🔍 Add protocol parsing (e.g. etherparse, dns-parser)
• 🧪 Benchmark critical code with criterion

✅ Conclusion

With Rust and pcap, you can build a low-level, high-performance, and secure network sniffer that rivals tools written in C — with far fewer risks.

This foundation is ideal for:

• IDS sensors,
• industrial protocol analyzers (Modbus, Profinet),
• telemetry collection agents,
• or integration into a Tauri or CLI-based security tool.

Voici une explication complète sur les différentes versions de Windows XP, notamment les notions de SP1, SP2, SP3, x86, x64, 32-bit et 64-bit :

🧠 1. Windows XP : la base

Windows XP est un système d’exploitation de Microsoft sorti en 2001. Il a connu plusieurs Service Packs (SP) qui sont des mises à jour majeures cumulant sécurité, stabilité et nouvelles fonctionnalités.

🛠️ 2. Les Service Packs (SP)

• SP0 (ou RTM) : version de lancement d’origine (2001).
• SP1 (2002) : ajoute le support de l’USB 2.0 et corrige plusieurs bugs.
• SP2 (2004) : grande mise à jour axée sur la sécurité (pare-feu, sécurité IE, Windows Security Center…).
• SP3 (2008) : dernière mise à jour officielle majeure (stabilité, compatibilité, mais pas d’IE7/8 ni Media Player 11 inclus de base).

📌 À noter : XP x64 n’a jamais eu de SP3, seulement SP1 et SP2.

🧮 3. x86 vs x64 : 32-bit vs 64-bit

🖥️ x86 (32-bit)

• Version la plus courante.
• Limite de 4 Go de RAM maximum (souvent seulement 3.2 Go utilisables).
• Compatible avec la majorité des logiciels XP.
• Plus stable à l’époque, meilleure compatibilité.

🖥️ x64 (64-bit)

• Permet d’utiliser plus de 4 Go de RAM (jusqu’à 128 Go théorique).
• Meilleures performances sur matériel 64-bit.
• Moins de compatibilité avec anciens drivers et logiciels.
• Basée sur Windows Server 2003 x64, donc un peu différente de XP 32 bits.

⚠️ Beaucoup de logiciels XP n’avaient pas de version 64-bit, et les pilotes étaient plus rares à l’époque. Pour cette raison, XP 32 bits (x86) est resté la norme.

🌍 4. Licences : Retail vs VL

• Retail : version boîte, vendue au grand public (activable avec clés individuelles).
• VL (Volume License) : pour entreprises, écoles… Permet l’utilisation d’une même clé sur plusieurs machines, sans activation Internet.

🌐 5. Langues disponibles

Les ISO sont disponibles en :

• EN = Anglais
• DE = Allemand
• RU = Russe
• TR = Turc

🔐 6. Clés de licence fournies

Le document contient des clés génériques pour installation/test. Elles sont Volume License ou Retail selon les ISO. Ces clés ne sont pas valides pour l’activation en ligne aujourd’hui (serveurs d’activation fermés).

🧪 7. Vérification des ISO

Chaque fichier ISO est accompagné de :

• MD5 : somme de contrôle
• SHA1 : autre méthode d’empreinte numérique

Ces valeurs permettent de vérifier l’intégrité des fichiers téléchargés.

🧾 8. Versions spécifiques

Quelques éditions spéciales :

• Windows XP Home : version familiale, plus limitée.
• Windows XP Professional : plus complète, pour pro et entreprises.
• Windows XP Tablet PC Edition 2005 : pour ordinateurs avec écran tactile/stylet.
• Windows Fundamentals for Legacy PCs : version allégée pour vieux PC.

🧩 9. SP4 non-officiel

• Il existe un “Service Pack 4 Unofficial”, regroupant toutes les mises à jour post-SP3 (jusqu’en 2019).
• Utilisé par les passionnés pour prolonger la durée de vie de XP de manière sécurisée.

🔧 SP4 Unofficial en détail :

• Fichier : WindowsXP-USP4-v3.1b-x86-ENU.exe
• Langue : Anglais uniquement
• Taille : ~992 Mo
• Auteur : “Harkaz” (forum MSFN)
• Intègre : IE8, Media Player 11, RDP 8.0, KB sécurité jusqu’en 2019, .NET 3.5/4.0 en option
• Fonctionne offline, installable sur XP SP3
• Prise en charge de POSReady 2009 (XP pour distributeurs de billets)

🖥️ Scénarios d’usage en 2025

• Déploiement de VM XP sécurisées pour tests rétrocompatibles
• Maintenance de logiciels embarqués ou industriels encore utilisés
• Création d’une base propre et à jour pour le développement rétro
• Utilisation dans un réseau isolé, avec snapshot régulier

📌 Astuce : On peut créer un ISO personnalisé avec SP4 intégré grâce à nLite ou RVM Integrator.

⚠️ Limitations : non supporté officiellement, uniquement en anglais, ne corrige pas les failles matérielles modernes (ex : Spectre/Meltdown)

📂 10. Fichiers MUI

• Les MUI (Multilingual User Interface Packs) permettent de changer la langue de l’interface sans réinstaller.

📅 En résumé :

Version Architecture SP Disponible Notes XP Pro SP0 x86 Non (version de base) 2001 XP Pro SP1 x86 / x64 Oui Ajoute USB 2.0, sécurité XP Pro SP2 x86 / x64 Oui Très axée sécurité XP Pro SP3 x86 seulement Oui Dernier SP officiel, le plus complet XP Pro x64 x64 seulement SP1 & SP2 uniquement Basée sur Windows Server 2003 XP Home x86 Jusqu’à SP3 Pour particuliers XP Tablet PC x86 SP2 (2005) Pour PC à stylet XP FLP x86 SP2 Allégé pour vieux PC XP SP4 Unofficial x86 Non officiel Mises à jour post-SP3 jusqu’en 2019

Introduction

Windows XP est mort… mais pas enterré.

En 2025, alors que Windows 11 est le standard imposé par Microsoft, et que la majorité des logiciels migrent vers le cloud, une réalité subsiste dans l’ombre des infrastructures modernes : certaines machines tournent encore sous Windows XP. Et ce, non par nostalgie, mais par nécessité.

Dans l’industrie, la défense, la santé ou les systèmes embarqués, XP reste un pilier, souvent parce que les coûts de migration sont prohibitifs, ou que des logiciels critiques n’ont jamais été portés sur des systèmes plus récents. Cet article s’adresse à ceux qui doivent encore faire vivre XP en 2025, en particulier pour des besoins de développement logiciel ou de maintenance de parcs informatiques vieillissants.

1. Pourquoi Windows XP est encore utilisé aujourd’hui

• Dépendance à des logiciels anciens : logiciels industriels, médicaux ou militaires non migrés.
• Compatibilité matérielle : drivers spécifiques, ports série (RS232), interfaces PCI/E.
• Stabilité connue : XP est un environnement stable, documenté, connu par les techniciens.
• Coûts de remplacement élevés : remplacer le parc entier est souvent hors budget.

2. Les risques de continuer sous XP

• Plus de mises à jour de sécurité.
• Incompatibilité avec le matériel récent.
• Pas de prise en charge du HTTPS moderne ou des outils cloud.
• Risques en cas de connexion Internet (ransomwares, malware…)

→ XP ne doit pas être utilisé comme poste de travail connecté au web. Il doit être considéré comme un “outil isolé”.

3. Environnements techniques pour XP en 2025

A. Virtualisation

• XP tourne très bien sous VirtualBox, VMware ou QEMU.
• Idéal pour le développement ou les tests de compatibilité.
• Possibilité d’import/export d’image VM.

B. Réinstallation native (hardware d’origine)

• Requiert du matériel compatible : CPU avant 2010, 2 Go RAM, chipset Intel ou nVidia.
• Disques IDE/SATA, pas de NVMe.
• ISO disponibles sur Archive.org (versions MSDN de confiance).

C. Alternatives

• ReactOS : système libre compatible XP (encore instable).
• Wine : faire tourner des programmes XP sur Linux, selon les cas.

4. Développement logiciel pour Windows XP

• Environnement classique : Visual Studio 6.0, 2005, ou 2008.
• .NET Framework 2.0 ou 3.5.
• Compilation avec /SUBSYSTEM:WINDOWS,5.1 pour compatibilité XP.
• Tests via VM XP, émulation de matériel si nécessaire.

Utiliser XP permet de vérifier la compatibilité descendante de logiciels modernes dans des contextes critiques.

5. Où trouver des ISO fiables

• Archive.org propose les versions officielles MSDN en anglais, allemand, russe et turc.
• Toujours vérifier les MD5/SHA1 pour s’assurer de l’intégrité.
• Privilégier les versions :
• SP2 : meilleure stabilité.
• SP3 : le plus complet.
• x64 : uniquement si besoin > 4 Go RAM et drivers compatibles.

6. Bonnes pratiques de sécurité

• Toujours isoler XP du réseau Internet.
• Utiliser des snapshots, des sauvegardes et des images figées.
• Lire seule sur le disque si besoin.
• Désactiver les partages inutiles.

Conclusion

Windows XP n’est plus une solution moderne, mais reste un outil valable pour des cas très spécifiques. Il permet de maintenir en vie des infrastructures critiques, de valider la compatibilité de certains logiciels ou encore de comprendre les anciens environnements logiciels.

En 2025, utiliser XP est un choix technique, à faire en connaissance de cause, avec rigueur et sécurité. Ce n’est pas un retour en arrière, mais un pont vers le passé pour ceux qui doivent encore le traverser.

When developing in Rust, you often encounter situations where a module and a function have the same name. This can lead to redundant and verbose imports, such as:

use commandes::get_interfaces::get_interfaces;

This kind of repetition makes your code harder to read and maintain. Fortunately, there’s an elegant solution to flatten these hierarchies while preserving Rust’s modular structure. Here’s how I solved this issue.

The Problem

Let’s consider a concrete example. You have a module structure like this:

src/
├── commandes/
│   ├── get_interfaces.rs
│   └── mod.rs
└── main.rs

Contents of get_interfaces.rs:

pub fn get_interfaces() {
    println!("Fetching interfaces...");
}

Contents of mod.rs:

pub mod get_interfaces;

When importing this function in main.rs, you end up writing:

use commandes::get_interfaces::get_interfaces;

fn main() {
    get_interfaces();
}

While this works, repeating get_interfaces twice feels unnecessarily verbose. Here's how you can avoid this redundancy.

The Solution: Use pub use to Re-export

Rust allows you to re-export items from a module using pub use. This enables you to expose functions directly at a higher level, reducing the need to repeat their full path.

Here’s how to update your mod.rs file to re-export the get_interfaces function:

Updated mod.rs:

pub mod get_interfaces;

// Re-export the function
pub use get_interfaces::get_interfaces;

Now, in main.rs, you can write:

use commandes::get_interfaces;

fn main() {
    get_interfaces();
}

This change makes the code more readable and intuitive while preserving the original modular structure.

Why Re-export?

1. Improved readability:
   Avoid unnecessary duplication in your import paths.
2. Ease of access:
   Consumers of your module can directly access its key functions without diving into the full submodule hierarchy.
3. Preserved modularity:
   Your code structure remains well-organized without manually flattening all your modules.

Extending This Approach

If you’re working with multiple modules and want to expose their key functions, you can apply this strategy across your project.

Example with Multiple Modules:

mod.rs:

pub mod get_interfaces;
pub mod set_interfaces;

// Re-export for simpler access
pub use get_interfaces::get_interfaces;
pub use set_interfaces::set_interfaces;

In this case, main.rs can use the functions as follows:

use commandes::{get_interfaces, set_interfaces};

fn main() {
    get_interfaces();
    set_interfaces();
}

When Not to Use This Approach

• If you want to keep an explicit hierarchy for clarity in a complex project or for public API design.
• If multiple modules contain functions with the same name. Re-exporting them can lead to conflicts.

Conclusion

Re-exporting with pub use is a simple yet powerful technique to make your Rust imports cleaner and more intuitive. It shows that despite its strictness, Rust allows elegant solutions for managing modularity and reducing code complexity.

Want to learn more tricks to simplify your Rust code? Follow me for more practical tutorials!

In this article, I’ll walk you through the journey of developing a profinet_parser crate in Rust, covering the implementation of TryFrom for parsing, enhanced error handling using thiserror, and the performance optimizations achieved by using references instead of copying data. Additionally, I’ll explain Rust’s lifetime annotations and their significance in building efficient and safe code.

Introduction to ProfinetPacket

Profinet is an industry-standard protocol widely used in industrial automation for communication between controllers and devices. Parsing Profinet packets accurately and efficiently is critical for applications that need to analyze or manage network traffic. The goal of this crate was to implement a Rust structure that can parse a Profinet packet from a byte slice and return a structured representation of it.

Initial Implementation Using TryFrom

Here’s how the TryFrom implementation was constructed:

impl<'a> TryFrom<&'a [u8]> for ProfinetPacket {
    type Error = ProfinetPacketError;

    fn try_from(data: &'a [u8]) -> Result<Self, Self::Error> {
        validate_packet_length(data)?;
        let frame_id = validate_frame_id(data)?;
        validate_dcp_block(data)?;

        let service_id = data[2];
        let service_type = data[3];
        let xid = u32::from_be_bytes([data[4], data[5], data[6], data[7]]);
        let response_delay = u16::from_be_bytes([data[8], data[9]]);
        let dcp_data_length = u16::from_be_bytes([data[10], data[11]]);

        let option = data[12];
        let suboption = data[13];
        let dcp_block_length = u16::from_be_bytes([data[14], data[15]]);

        let name_of_station = extract_name_of_station(data)?;

        Ok(ProfinetPacket {
            frame_id,
            service_id,
            service_type,
            xid,
            response_delay,
            dcp_data_length,
            option,
            suboption,
            dcp_block_length,
            name_of_station,
        })
    }
}

Adding Error Handling with thiserror

Robust error handling is essential for understanding what went wrong when parsing fails. We used the thiserror crate to create custom, user-friendly errors:

use thiserror::Error;

#[derive(Error, Debug, PartialEq, Eq, Clone, Copy)]
pub enum ProfinetPacketError {
    #[error("Packet too short: {0} bytes")]
    PacketTooShort(usize),
    #[error("Unknown Frame ID: {0:#04x}")]
    UnknownFrameId(u16),
    #[error("Invalid DCP block length: {0}")]
    InvalidDcpBlockLength(usize),
    #[error("Invalid name of station: not valid UTF-8")]
    InvalidNameOfStation,
}

Those errors are propagated when validations fail.

These descriptive error types provided clear feedback during parsing failures, improving the overall debugging experience.

Benchmarking for Performance Optimization

To measure the performance of the try_from implementation and optimize it, we used the criterion crate. Our initial benchmarks showed that copying data into a new array could be costly. By switching to referencing slices directly, we aimed to minimize unnecessary copies and improve parsing speed.

Benchmark Results

We ran benchmarks using Criterion and compared the performance of the initial implementation with one that used references instead of copying. Here’s an example of a benchmark:

use criterion::{black_box, criterion_group, criterion_main, Criterion};
use profinet_parser::ProfinetPacket;

pub fn benchmark_packet_conversion(c: &mut Criterion) {
    let data = black_box(vec![
        0xFE, 0xFE, 0x01, 0x02, 0x00, 0x00, 0x00, 0x01,
        0x00, 0x10, 0x00, 0x0C, 0x02, 0x03, 0x00, 0x04,
        b'T', b'E', b'S', b'T'
    ]);

    c.bench_function("profinet_packet_conversion", |b| {
        b.iter(|| ProfinetPacket::try_from(&data[..]))
    });
}

criterion_group!(benches, benchmark_packet_conversion);
criterion_main!(benches);

Here is an exemple of a modification

we change the fn extract_name_of_station so it returns a &’a str and not a String:

fn extract_name_of_station<'a>(data: &'a [u8]) -> Result<&'a str, ProfinetPacketError> {
    let block = &data[12..];
    let dcp_block_length = u16::from_be_bytes([block[2], block[3]]) as usize;

    if block.len() < (4 + dcp_block_length) {
        return Err(ProfinetPacketError::InvalidDcpBlockLength(block.len()));
    }

    std::str::from_utf8(&block[4..4 + dcp_block_length])
        .map_err(|_| ProfinetPacketError::InvalidNameOfStation)
}

Results:

• Before optimization: Parsing time was around 25 ns.
• After optimization: Parsing time dropped significantly to around 13.7 ns, showing a 45% performance improvement.

This result confirms that avoiding data copying and using references instead can lead to substantial performance gains.

Understanding Lifetimes:

In Rust, lifetimes are crucial for ensuring that references are valid and safe throughout the program. In our `ProfinetPacket` implementation, lifetimes were used to tie the lifetime of the parsed packet to the byte slice it references. This avoided unnecessary allocations and allowed the `ProfinetPacket` struct to point directly to parts of the input slice:

By leveraging lifetimes, we ensured that the parsed data only lived as long as the input slice, thus maintaining safety and efficiency.

impl<'a> TryFrom<&'a [u8]> for ProfinetPacket<'a> {
    // Implementation that leverages lifetimes for zero-copy parsing.
}

Conclusion

Creating a profinet_parser crate in Rust taught us valuable lessons about efficient parsing, error handling, and optimization. Implementing TryFrom allowed us to convert byte slices into structured packets seamlessly, while thiserror improved error clarity. Most importantly, performance benchmarks showed that using references instead of copying can have a substantial impact on parsing speed.

If you’re working on parsing network protocols or performance-critical applications, considering these techniques can help build robust and efficient solutions in Rust.

Introduction

Rust’s ecosystem has grown to include several powerful crates for network programming, including pnet, a crate used for packet-level access to network interfaces. This article will explore what happens "under the hood" when pnet captures packets from a network interface. We will delve into the concept of raw sockets, system calls, and how Rust interacts with these low-level details using libc.

What Are Raw Sockets?

A raw socket is a special kind of network socket that allows applications to access packets directly at the network layer (OSI Layer 3). Unlike standard sockets, which handle protocol-specific parsing (TCP, UDP, etc.), raw sockets allow you to capture and inspect packets in their raw form — including headers and payloads. This capability is essential for network monitoring, intrusion detection systems, and packet manipulation tools.

How pnet Uses Raw Sockets for Packet Capture

When you use pnet to capture packets, it sets up a raw socket and binds it to a specific network interface. This allows it to receive all packets traversing the interface without filtering based on a particular protocol. Here’s a breakdown of what happens step-by-step:

1. Creating a Raw Socket The first step is to create a raw socket using the socket system call. In Rust, this is done using the libc library to directly access OS-level functionality. Here's a code snippet that demonstrates this:

use libc::{socket, AF_PACKET, SOCK_RAW, ETH_P_ALL};

// Create a raw socket
let sock_fd = unsafe { socket(AF_PACKET, SOCK_RAW, (ETH_P_ALL as u16).to_be() as i32) };
if sock_fd < 0 {
    panic!("Failed to create raw socket: {}", std::io::Error::last_os_error());
}

• AF_PACKET: Specifies that the socket is for packet-level access, typically used on Linux.
• SOCK_RAW: Indicates that the socket should operate in raw mode, giving access to all network layer packets.
• ETH_P_ALL: Tells the socket to capture all Ethernet packets, regardless of protocol.

2. Binding the Socket to a Network Interface Once the socket is created, it must be bound to a specific network interface (e.g., eth0) to listen for incoming packets. This is done with the setsockopt system call:

use libc::{setsockopt, SOL_SOCKET, SO_BINDTODEVICE};

// Convert the interface name (like "eth0") to a CString
let interface_name = CString::new("eth0").unwrap();

// Bind the socket to the network interface
let result = unsafe {
    setsockopt(
        sock_fd,
        SOL_SOCKET,
        SO_BINDTODEVICE,
        interface_name.as_ptr() as *const libc::c_void,
        libc::IFNAMSIZ as libc::socklen_t,
    )
};
if result < 0 {
    panic!("Failed to bind socket to interface: {}", std::io::Error::last_os_error());
}

• SOL_SOCKET and SO_BINDTODEVICE are options used to configure the socket at the system level.
• The network interface name is passed as a CString, a null-terminated string format expected by many C libraries.

3. Receiving Packets in a Loop With the socket bound to the interface, it is ready to capture packets. The recv system call reads packets from the socket, which are then processed:

use libc::recv;

// Buffer to store received packets
let mut buffer = [0u8; 65536];

loop {
    // Receive packets from the socket
    let packet_size = unsafe { recv(sock_fd, buffer.as_mut_ptr() as *mut libc::c_void, buffer.len(), 0) };
    if packet_size < 0 {
        panic!("Error receiving packet: {}", std::io::Error::last_os_error());
    }

    // Convert the buffer to a packet
    let packet: Vec<u8> = buffer[..packet_size as usize].to_vec();

    // Print the packet in hexadecimal format
    println!("Received packet: {:02X?}", packet);
}

• recv: Reads data from the socket into a buffer. In the example, 65536 bytes are allocated to handle even large packets.
• The packet data is then converted to a Vec<u8> for easier manipulation.

What is pnet Handling for You?

The pnet crate abstracts many of these low-level details, providing a higher-level API while still granting fine-grained control over network packets. Here's what pnet does behind the scenes:

1. Socket Creation and Binding: pnet manages socket creation and binding, supporting multiple platforms (Linux, Windows, macOS) with appropriate system calls for each OS.
2. Packet Parsing: pnet provides pre-built structures to parse common network protocols like IPv4, IPv6, TCP, UDP, and ARP. This parsing is handled automatically, saving developers from manually dissecting each packet's binary structure.
3. Error Handling: Errors during packet capture, such as socket creation failures or permission issues, are handled with meaningful Rust error types instead of raw error codes.
4. Filter Application: pnet allows users to apply packet filters (e.g., using Berkeley Packet Filter syntax) to limit the type of traffic captured.

Why Use Raw Sockets with Rust?

While crates like pnet make packet capture accessible, using raw sockets directly provides full control over how packets are captured and processed. This approach is beneficial for:

• Performance Optimization: Fine-tuning the capture loop to handle high-throughput environments.
• Advanced Filtering: Implementing custom filters beyond the capabilities of pre-built filters.
• Protocol Development: Crafting new or niche protocols that require specific handling not covered by high-level libraries.

Conclusion

Packet capture in Rust using raw sockets reveals the power and flexibility of the language for network programming. While pnet offers a great abstraction for common use cases, understanding what happens underneath allows developers to make more informed decisions when building network tools. Rust’s safety features combined with low-level access give you the best of both worlds for secure and performant network programming.

Introduction

Network analysis is crucial for monitoring, security, and diagnosing network infrastructure. Rust, with its performance and memory safety, is becoming an increasingly popular choice for developers building network tools. In this article, we will explore how to use Rust crates pcap and pnet to read PCAP files, capture live network traffic, and briefly discuss using PF_RING for high-performance packet capture.

Reading PCAP Files with the pcap crate

The pcap crate allows you to read network capture files, commonly known as PCAP (Packet Capture), which contain traces of network traffic. This step is essential for analyzing network incidents or debugging.

A simple example to read packets from a file:

use pcap::Capture;

   fn main() {
       let mut cap = Capture::from_file("example.pcap").unwrap();
       while let Ok(packet) = cap.next() {
           println!("Packet : {:?}", packet);
       }
   }

Using pnet for Fine-Grained Packet Capture and Analysis

The pnet crate allows working at a lower level with network packets in Rust. Unlike pcap, it offers a more detailed API to manipulate packet headers, protocols, and access the network card through system libraries.

Pnet embeddes raw sockets form the os informations to the user of the crate:

   use pnet::datalink::{self, Channel::Ethernet};

   fn main() {
       let interfaces = datalink::interfaces();
       let interface = interfaces.into_iter()
           .find(|iface| iface.is_up() && !iface.is_loopback())
           .expect("No suitable interface found.");

       let (_, mut rx) = match datalink::channel(&interface, Default::default()) {
           Ok(Ethernet(tx, rx)) => (tx, rx),
           Ok(_) => panic!("Unhandled channel type."),
           Err(e) => panic!("An error occurred: {}", e),
       };

       loop {
           match rx.next() {
               Ok(packet) => println!("Packet : {:?}", packet),
               Err(e) => eprintln!("An error occurred while reading: {}", e),
           }
       }
   }

Accessing Network Cards with pnet and libc

To capture and filter packets efficiently, `pnet` can directly interact with system libraries. On Windows, this is done via `Npcap` (a fork of `WinPcap`), and on Linux through raw sockets and the Berkeley Packet Filter (BPF). `libc` is often used to access these system-level features.

Pnet uses system calls to access network drivers through libraries like libc.

High-performance capture with PF_RING:

For environments requiring high performance, `PF_RING` can be used for optimized capture with direct access to the network card.

Conclusion

Rust offers a variety of powerful tools for network analysis and capture. The pcap and pnet crates provide features suited for different levels of abstraction. For detailed analysis and performance needs, pnet and PF_RING are particularly interesting.