Immediate mode appears not to work when capturing using streams in multithreading on Windows

[trumansdo]

Hi, I’m a beginner with pcap. I was experimenting with the stream example in the examples directory and noticed something unusual.

I used a small image file (around 1.5KB) for testing, but no packets were captured. However, when I switched to a larger image file (around 1.3MB), packets were successfully captured.

Is this expected behavior? Does the asynchronous stream approach have limitations when capturing small amounts of network data? Or am I missing something in my setup?

[Stargateur]

what example exactly ? This just look like buffering.

[trumansdo]

I referred to the examples/streamlisten_mt.rs file.。This is the information I obtained using curl.

[Wojtek242]

Can you explain in more detail what you are doing?

• What command are you using to execute the example?
• How are you using the image file?
• Did you modify the example in any way?
• What is your OS?

[trumansdo]

OS: win11 22631.4460
rust version: 1.82.0
pcap and pnet is latest version.

I just used the curl command as shown in the image to initiate a simple network request.I have no use for the image in the response, as I am solely focused on the content of the network packets in a single request.
this code:

use futures::StreamExt;
use pcap::{Active, Capture, Device, Error, PacketCodec, PacketStream};
use std::error;

pub struct SimpleDumpCodec;

#[derive(Debug, PartialEq, Eq)]
pub struct PacketOwned {
    pub header: pcap::PacketHeader,
    pub data: Box<[u8]>,
}

impl PacketCodec for SimpleDumpCodec {
    type Item = PacketOwned;

    fn decode(&mut self, pkt: pcap::Packet) -> Self::Item {
        println!("SimplePacketCodec decode");
        PacketOwned {
            header: *pkt.header,
            data: pkt.data.into(),
        }
    }
}

async fn start_new_stream(device: Device) -> PacketStream<Active, SimpleDumpCodec> {
    match new_stream(device) {
        Ok(stream) => stream,
        Err(e) => {
            println!("{:?}", e);
            std::process::exit(1);
        }
    }
}

fn new_stream(device: Device) -> Result<PacketStream<Active, SimpleDumpCodec>, Error> {
    // get the default Device
    println!("Using device {}", device.name);

    let cap = Capture::from_device(device)?
        .immediate_mode(true)
        .open()?
        .setnonblock()?;
    cap.stream(SimpleDumpCodec {})
}

#[tokio::main(flavor = "multi_thread", worker_threads = 10)]
async fn main() -> Result<(), Box<dyn error::Error>> {
    let inter_name = "XXXXXXXXXX-D6FE-49C9-8993-XXXXXXXXXXX";

    let device = Device::list()?
        .into_iter()
        .find(|d| d.name.contains(inter_name))
        .unwrap();
    let stream = start_new_stream(device).await;

    let fut = stream.for_each(move |s| {
        println!("{:?}", s);
        futures::future::ready(())
    });
    fut.await;
    Ok(())
}

[Wojtek242]

Hi @trumansdo I just tried your code on my laptop on a test image of about 1.2 kB and the packet capture worked for me. Your example code is fine.

However, I use linux and set_immediate_mode is done differently on Linux and on Windows. And based on your description of the issue this could be the problem. Could you start the example and try downloading the small image multiple times, say 20 times? Does this cause the packet capture to work?

If that will work then it would show that the problem is with set_immediate_mode

[Wojtek242]

Also, do you have the same problem when running single threaded?

[trumansdo]

I experimented with different combinations of promisc and immediate_mode, and found that the println output indeed appears after multiple calls. Additionally, this issue does not occur under single-threaded conditions. Approximately every fifth network request, then println produces output.

[Wojtek242]

That sounds like a bug. Multithreaded with immediate mode set to true should work just like the single threaded version. It also sounds like a Windows-specific issue.

Unfortunately, I don't use Windows so we have to wait until a Windows contributor picks up this issue.

[trumansdo]

Alright, we’ll just have to wait patiently for this bug to be fixed then.