dnspeep
dnspeep copied to clipboard
feat: support Windows
- capture packets from an interface
- conditional compilation
- fix overflow in get_time function
There's one thing needs to pay attention to(in Cargo.toml). Since we only enable pcap's capture-stream feature on unix, we need to update the publish.yml
file to pass down the --features
arguments for cargo build
.
I have not set up the CI for Windows build yet !!!
Thanks so much for your work on this!
4 questions I have:
- Why does this add an
interface
flag? Is it because theany
interface doesn't exist on Windows? - Why does it say to not use the
port
flag on Windows? (does WinPcap not support using another port?) - Do you know why
capture-stream
doesn't work on Windows? From some very brief Googling it looks like Tokio has some sort of Windows support, but I don't know a lot about this. - Does the "
" feature work on Windows? More specifically -- if you start dnspeep
and then send a packet that doesn't get a DNS response (like withdig @127.0.0.1 example.com
), do you see that packet printed out with<no response>
?. My guess is that it won't because it's not using pcap's stream feature and so tokio's event loop will be blocked.
- Yes. You can see this example comment from pcap, which points out
any
is not support on Windows. Moreover, in some scenarios we may only care the packets from the specific interface. Withinterface
flag, we can do this. - I think I can do dome adjustments to combine
interface
withport
working together(DONE with 4307ca2). -
capture-stream
feature will enablePacketStream
that has the dependency chainPacketStream -> SelectableFd -> RawFd
whileRawFd
akastd::os::unix::io::RawFd
isn't enabled on Windows. You can explorer it in stream.rs - Yes. It does print out with
<no response>
, See the figure below.
![snipaste_20210406_001218](https://user-images.githubusercontent.com/19922814/113596501-fe2e1780-966c-11eb-9a2d-bad3bb226371.png)
Resolve #15
abandoned?