Articles tagged #networking
Crafting ICMP-bearing IPv4 packets with the help of bitvec
So. Serializing IPv4 packets. Easy? Well, not exactly.
IPv4 was annoying to parse, because we had 3-bit integers, and 13-bit integers, and who knows what else. Serializing it is going to be exactly the same.
Right now, we don’t have a way to serialize that.
Let’s take the version and ihl fields, both of which are supposed
to take 4 bits, together making a byte. We could serialize them like this:
Crafting ARP packets to find a remote host's MAC address
Alright. ALRIGHT. I know, we’re all excited, but let’s think about what we’re doing again.
So we’ve managed to look at real network traffic and parse it completely. We’ve also taken some ICMP packets, parsed them, and then serialized them right back and we got the exact same result.
So I know what you’re thinking - let’s just move our way down the stack again - stuff that ICMP packet in an IP packet, then in an Ethernet frame, and then serialize the whole thing.
Parsing and serializing ICMP packets with cookie-factory.
In the last part, we’ve finally parsed some IPv4 packets. We even found a way to filter only IPv4 packets that contain ICMP packets.
There’s one thing we haven’t done though, and that’s verify their checksum. Folks could be sending us invalid IPv4 packets and we’d be parsing them like a fool!
This series is getting quite long, so let’s jump right into it.
Parsing IPv4 packets, including numbers smaller than bytes
Hello and welcome to Part 11 of this series, wherein we finally use some of the code I prototyped way back when I was planning this series.
Where are we standing?
Let’s review the progress we’ve made in the first 10 parts: first, we’ve started thinking about what it takes for computers to communicate. Then, we’ve followed a rough outline of the various standards and protocols that have emerged since the 1970s.
Consuming Ethernet frames with the nom crate
Now that we’ve found the best way to find the “default network interface”… what can we do with that interface?
Well, listen for network traffic of course!
use rawsock::open_best_library;
use std::time::Instant;
fn main() -> Result<(), Error> {
let lib = open_best_library()?;
let iface_name = format!(r#"\Device\NPF_{}"#, netinfo::default_nic_guid()?);
let iface = lib.open_interface(&iface_name)?;
println!("Listening for packets...");
// doing some low-cost logging over here
let start = Instant::now();
iface.loop_infinite_dyn(&mut |packet| {
println!(
"{:?} | received {} bytes",
start.elapsed(),
packet.len()
);
})?;
Ok(())
}
Binding C APIs with variable-length structs and UTF-16
Okay, I lied.
I’m deciding - right this instant - that using wmic is cheating too. Oh, it was fair game when we were learning about Windows, but we’re past that now.
We know there’s IPv4 routing tables, and we know network interfaces have indices (yes, they do change when you disable/enable one, so ill-timed configuration changes may make our program blow up).
Finding the default network interface through WMI
Let’s set aside our sup project for a while.
Don’t get me wrong - it’s a perfectly fine project, and, were we simply rewriting “ping” for Windows in Rust, we could (almost) stop there.
We’re currently using the operating system’s facility to speak ICMP, which is great for a bunch of reasons: we can be sure that whatever flaws there are in the implementation, all “native” Windows programs suffer from it as well.
The builder pattern, and a macro that keeps FFI code DRY
Our ping API is simple, but it’s also very limited:
pub fn ping(dest: ipv4::Addr) -> Result<(), String>
// called as:
ping(ipv4::Addr([8, 8, 8, 8])).unwrap();
It doesn’t allow specifying the TTL (time to live) of packets, it doesn’t allow specifying the timeout, it doesn’t let one specify the data to send along, and it doesn’t give us any kind of information on the reply.
Go back to the homepage.