I'm making this a PR instead of an issue to make it easier to read.

I'm trying to implement ICMP packets. It's far from begin complete, but I'd like to see if I can at least log an ICMP echo request using the packetdump example you provide.

But it does not compile because some getters are not created.

I define a generic ICMP packet like this:

#[packet]                                                                           
pub struct Icmp {                                                                   
    #[construct_with(u8)]                                                           
    type_: IcmpType,  // get_type_() is not created (btw I'll come up with a better name, but "type" is reserved)
    #[construct_with(u8)]                                                           
    code: DestinationUnreachableCode,  // get_code_() is not created                                               
    checksum: u16be,                                                                
    rest_of_header: u32be,                                                          
    #[payload]                                                                      
    payload: Vec<u8> // Internet Header + 64 bits of Original Data Datagram         
}   

But when I call get_type_() or get_code():

~/libpnet git:icmptests ❯❯❯ sudo cargo run --example=packetdump lo                                                                                                                    
   Compiling pnet v0.0.1 (file:///home/corentih/libpnet)
examples/packetdump.rs:64:16: 64:27 error: no method named `get_type_` found for type `core::option::Option<pnet::packet::icmp::IcmpPacket<'_>>` in the current scope
examples/packetdump.rs:64     match icmp.get_type_() {
                                         ^~~~~~~~~~~
examples/packetdump.rs:68:52: 68:63 error: no method named `get_type_` found for type `core::option::Option<pnet::packet::icmp::IcmpPacket<'_>>` in the current scope
examples/packetdump.rs:68                                               icmp.get_type_())
                                                                             ^~~~~~~~~~~
note: in expansion of format_args!
<std macros>:2:25: 2:56 note: expansion site
<std macros>:1:1: 2:62 note: in expansion of print!
<std macros>:3:1: 3:54 note: expansion site
<std macros>:1:1: 3:58 note: in expansion of println!
examples/packetdump.rs:66:38: 68:64 note: expansion site
examples/packetdump.rs:74:24: 74:34 error: no method named `get_code` found for type `core::option::Option<pnet::packet::icmp::IcmpEchoRequestPacket<'_>>` in the current scope
examples/packetdump.rs:74     match echo_request.get_code() {
                                                 ^~~~~~~~~~
examples/packetdump.rs:75:109: 75:119 error: no method named `get_code` found for type `core::option::Option<pnet::packet::icmp::IcmpEchoRequestPacket<'_>>` in the current scope
examples/packetdump.rs:75         IcmpTypes::EchoRequest => println!("[{}]: ICMP echo request: code={}", interface_name, echo_request.get_code()),
                                                                                                                                      ^~~~~~~~~~
note: in expansion of format_args!
<std macros>:2:25: 2:56 note: expansion site
<std macros>:1:1: 2:62 note: in expansion of print!
<std macros>:3:1: 3:54 note: expansion site
<std macros>:1:1: 3:58 note: in expansion of println!
examples/packetdump.rs:75:35: 75:120 note: expansion site
examples/packetdump.rs:76:129: 76:139 error: no method named `get_code` found for type `core::option::Option<pnet::packet::icmp::IcmpEchoRequestPacket<'_>>` in the current scope
examples/packetdump.rs:76         _                         => println!("[{}]: Unknown ICMP echo request packet: (code={})", interface_name, echo_request.get_code())
                                                                                                                                                          ^~~~~~~~~~
note: in expansion of format_args!
<std macros>:2:25: 2:56 note: expansion site
<std macros>:1:1: 2:62 note: in expansion of print!
<std macros>:3:1: 3:54 note: expansion site
<std macros>:1:1: 3:58 note: in expansion of println!
examples/packetdump.rs:76:38: 76:140 note: expansion site
error: aborting due to 5 previous errors
Could not compile `pnet`.

Two questions:

• Do you like the approach I take for the implementation, generally speaking? The way I write code at the moment is mostly driven by the errors the compiler throws me, and I have not idea if it's good or not
• I can't figure out why the getters are not created, can you give me some pointers please?

Using Polymorphism instead of Encapsulation is the key to use multiples backeds at the same time. Lets say that you need to open an datalink to a interface using bpf and an datalink on other interface using netmap, with this trait you can :) Note1: I couldn't compile using netmap, so I didn't test using multiples backeds. Note2: try to find a better solution to default_datalink_channel implementation

https://github.com/0xd34b33f/cloudflare-ping/blob/06e359d16fff09839cc6a09b1ebdcacb9788ee91/src/ping_core.rs#L332 Segfault, when sending icmp packet. Works in debug mode or in --march=native. Doesn't work in release mode

Currently all the code is written for Windows support, but it does not work:

• On Win32 receives time out
• On Win64 the tests segfault

These issues need investigating and fixing.

This PR is to move away from legacy winapi 0.2 and related *-sys crates to winapi 0.3.x. Note, this is currently using my git branch iphlpapi as required changes have not yet been merged into upstream, yet.

This is my second PR ever, and I'm pretty green with github, merges, forks, etc.., so I do apologize for rookie mistakes in advance and welcome any and all commentary/criticism.

This is a WIP PR, I updated to winapi 0.3 naively using rust-2018 and nightly. I need to go back and support this project's minimum Rust version. winapi 0.3 supports back to rust 1.6 so there should be no issues there.

Tests are not yet passing, for me.

libpnet version: 0.21.0 rustc version: 1.26.0 os: Windows 10 Pro x64

On Windows, it appears that the following snippet always panic!(s)s:

extern crate pnet;
extern crate pnet_datalink;

fn send_tcp_packet() {
    let interfaces = pnet_datalink::interfaces();
}


fn main() {
    send_tcp_packet();
}

With the following:

C:\Users\JDB\Projects\learn-rust\syn-client>cargo run
   Compiling syn-client v0.1.0 (file:///C:/Users/JDB/Projects/learn-rust/syn-client)
    Finished dev [unoptimized + debuginfo] target(s) in 1.61 secs
     Running `target\debug\syn-client.exe`
thread 'main' panicked at 'FIXME [windows] unable to get interface list', C:\Users\JDB\.cargo\registry\src\github.com-1ecc6299db9ec823\pnet_datalink-0.21.0\src\winpcap.rs:335:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: process didn't exit successfully: `target\debug\syn-client.exe` (exit code: 101)

After some digging it appears to be related to this line of code.

List of local Network Interfaces:

Name                      InterfaceDescription                    ifIndex Status       MacAddress             LinkSpeed
----                      --------------------                    ------- ------       ----------             ---------
vEthernet (DockerNAT)     Hyper-V Virtual Ethernet Adapter #3          25 Up           00-15-5D-00-02-1A        10 Gbps
vEthernet (Default Swi... Hyper-V Virtual Ethernet Adapter             23 Up           16-15-7D-77-FF-87        10 Gbps
Bluetooth Network Con...2 Bluetooth Device (Personal Area Ne...#2      20 Disconnected 00-1A-7D-DA-71-02         3 Mbps
vEthernet (nat)           Hyper-V Virtual Ethernet Adapter #2          13 Up           00-15-5D-8A-D4-25        10 Gbps
vEthernet (ArchLinux E... Hyper-V Virtual Ethernet Adapter #4          12 Up           70-85-C2-0B-7F-DC       100 Mbps
Ethernet                  Intel(R) Ethernet Connection (2) I219-V       6 Up           70-85-C2-0B-7F-DC       100 Mbps

I would love to submit a PR, however I am not all to proficient in Rust; especially not at such a low layer. If anyone would love to guide me through it, I would be more than happy to contribute. Otherwise it would be cool if we could push a fix for it, or at least a temporary workaround.

• rename the "pcap" feature to "with-pcap" (because of dep conflict)
• pass through the with-pcap feature to pnet_datalink
• fix random build errors

I just started working on Netlink library based on libpnet/pnet_macros. The problem is that Netlink messages are encoded in little endian. It seems like this little diff works as intended.

Hi guys, How soon the new release is supposed to happen? I'm waiting for pnet::transport::IcmpTransportChannelIterator::next_with_timeout on stable. Could you also give me a stable revision with this feature, so I could use it instead of master branch?

I'd like to know the size of packets coming to/from a certain network interface, but I seem to be getting extremely low numbers. Im using the packet dump file from your example as a PoC, and all I did was add a

println!("PACKET SIZE: {}, packet.len());

on line 251, right after Ok(packet) => { ...

I assume that packet.len() gives the length in bytes of the packet, and I hope that my assumption is wrong, because otherwise I am just getting very low numbers.

I then let it run while listening to my interface (and yes I am using the right interface, I checked several times) and I went on https://twitch.tv because It sends a lot of data.

Looking at wireshark I see a consistent flow of TCP packets, most of which are 1514 bytes. On my PoC I see a long list of "PACKET SIZE: 40" and occasionally I see a packet that's slightly higher, like 295, 398, but nothing close to 1514.

This is on windows 10. I tried to do the same thing on my ubuntu device, and got similar results, most packet sizes were about 106 with an occasional spike to 500.

Am I interpreting packet.len() incorrectly? Is the example simply out of date?

Could you run the example with the line that I added and see if you get results that seem to make sense?

https://github.com/libpnet/libpnet/blob/47f48e00282aabc005c96393930cb3408139a7f5/src/datalink/winpcap.rs#L277

I can try my hand at a fix, but I'm not sure how to handle the case where the option is Nothing.

Consider the following example:

use pnet::datalink;

fn main() {
    for interface in pnet::datalink::interfaces() {
        println!("{} {:?}", interface.name, interface.mac);
    }
}

This returns "invalid" MAC addresses. These are not the correct MAC addresses for my network interfaces, and they seem to follow a strange pattern (01, 02, 03, ...):

lo0 Some(01:00:18:03:00:00)
gif0 Some(02:00:37:04:00:00)
stf0 Some(03:00:39:04:00:00)
anpi1 Some(04:00:06:05:06:00)
anpi0 Some(05:00:06:05:06:00)
en3 Some(06:00:06:03:06:00)
en4 Some(07:00:06:03:06:00)
en1 Some(08:00:06:03:06:00)
en2 Some(09:00:06:03:06:00)
bridge0 Some(0a:00:06:07:06:00)
ap1 Some(0b:00:06:03:06:00)
en0 Some(0c:00:06:03:06:00)
awdl0 Some(0d:00:06:05:06:00)
llw0 Some(0e:00:06:04:06:00)
utun0 Some(0f:00:01:05:00:00)
utun1 Some(10:00:01:05:00:00)
utun2 Some(11:00:01:05:00:00)
utun3 Some(12:00:01:05:00:00)
utun4 Some(13:00:01:05:00:00)

This happens with libpnet 0.31.0 since nightly-2022-11-23. nightly-2022-11-22 and before are good.

Maybe this is due to an upcoming change in Rust that will affect libpnet, or it's just an issue with Rust nightly, in which case feel free to close :)

Apologies if this is a Rust noob question.

I am trying to return the first reply packet from a Layer4(Ipv4(IpNextHeaderProtocols::Icmp)) transport_channel.

The end of my function is:

    let mut rx_iter = icmp_packet_iter(&mut rx);
    rx_iter.next()

And I get the following errors:

error[E0515]: cannot return reference to local variable `rx_iter`
  --> src\main.rs:29:5
   |
29 |     rx_iter.next()
   |     ^^^^^^^^^^^^^^ returns a reference to data owned by the current function

error[E0515]: cannot return value referencing local variable `rx`
  --> src\main.rs:29:5
   |
28 |     let mut rx_iter = icmp_packet_iter(&mut rx);
   |                                        ------- `rx` is borrowed here
29 |     rx_iter.next()
   |     ^^^^^^^^^^^^^^ returns a value referencing data owned by the current function

The official advice is to "consider returning an owned value instead". How should I do it?

IIUC, the goal of this code is to look up MAC address matching target_ip, by receiving ARP packet from the target host sends.

If so, catching subsequent packet won't work because the very next received packet is the ARP request just sent by the function itself. (at least on my macbook)

To make this work, IMO, lookup every packets while reply packet found.

File pnet_packet/src/udp.rs contains routines ipv4_chekcsum() and ipv4_checksum_adv(), which are supposed to calculate the correct UDP checksum to the UDP header. Also, there is a unit test function "udp_header_ipv4_test()", which is apparently meant to show the correct use of function ipv4_checksum().

However, if a user calculates UDP checksums as shown in udp_header_ipv4_test(), the result is wrong, with probability of 0.000015. Specifically, routine util::ipv4_checksum() calculates the mathematically correct TCP checksum, which is in range 0..0xFFFE, inclusive. However, RFC768 says that UDP checksum has a special rule that differs from all other checksum calculations: if "the computed checksum is zero, it is transmitted as all ones", so a zero value (whose probability is 1/65535), must be changed to 0xFFFF before storing to UDP header. The algorithm, as shown, fails to do this change.

The result of this bug is hard to reveal, because if the sender sets the checksum to zero (as mentioned, this happens with probability 1/65535), the receiver is unlikely to notice the error, because, for the receiver, zero checksum is an indication that the sender has refused to calculate the checksum, and so the receiver omits the checksum calculation and accepts the UDP packet. So the net result is that transmissions errors, which are meant to be detected with checksum, are not detected.

Also, a similar bug is in documentation of routine pnet::util::ipv4_checksum. That routine is meant for "UDP and TCP", but the user is not warned against the special case of zero checksum.

A fix should be simple:

let mut checksum = ipv4_checksum(. . .);
if checksum == 0 {
    // UDP rules require that zero is represented as follows:
    checksum = 0xFFFF;
}
udp_header.set_checksum(checksum);

And further, the routines for IPv6 appear to have the same issues.

This can be useful if the caller want to manipulate the socket differently at creating. For example setting a BPF filter on the socket before passing it in the channel:

datalink::linux::channel(interface, config, socket_fd)

Signed-off-by: Martin Andre [email protected]

A pcap from my network shows that router solicitations are sent with no options.

If I construct a RouterSolicit packet with the pnet lib however, leaving the options field empty leads to an invalid message.

This message is constructed with:

 let adv = ndp::RouterSolicit {
            icmpv6_type: Icmpv6Types::RouterSolicit,
            icmpv6_code: Icmpv6Code(0),
            checksum: 0,
            options: Vec::new(),
            reserved: 0,
            payload: Vec::new(),
};

wireshark shows it as an error