Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows support #10

Open
SonnyX opened this issue Mar 28, 2019 · 6 comments
Open

Windows support #10

SonnyX opened this issue Mar 28, 2019 · 6 comments

Comments

@SonnyX
Copy link

SonnyX commented Mar 28, 2019

Currently tokio-ping can't be compiled for windows since it makes use of

use std::os::unix::io::{AsRawFd, RawFd};

Windows-specific behavior should be implemented.

@orf
Copy link

orf commented Dec 16, 2019

It might be possible to use https://github.com/TyPR124/winping?

@JRAndreassen
Copy link

Hi...

I had the same issue, and I have been trying to get it to work...

I've got it compiled and running...
It sends the packets correctly, the responses come back to the machine (checked Wireshark)
But, there responses are not coming delivered to the poller...

Any idea of where to look...
During the registration :
Pinger::new():
Self::with_handle(&Handle::default()).map_err(From::from)
-------------------------------^^^^^^
Handle::default() returns None...
Not sure if that is a problem...
I'd really like to get this to work (using Tokio)...
First with the versions originally in the Cargo...
Then bring it up to current.
So, any assistance would be greatly appreciated.
Thanks
JR

@usbalbin
Copy link

I just opened #15 which changes to new tokio and futures. This removes the need for Handle::default(), not sure if this affects your problem in any way. Thought I'd mention it...

@JRAndreassen
Copy link

Hi ...

It might... After all the wall-intersections over the last few day's...
It's like a fresh mountain breeze :)...
It looked like the registration with Handle is the issue. It all works except for the notification of incoming packets...
I'll try it and get back to you..

@usbalbin
Copy link

If I am not mistaken I believe at one point I had a problem where I accedentally dropped the pinger before the future resolved. This caused some similar problem where the response from the host was never handled and the future thus resolved into a timeout.

Again not sure if this is relevevant in your case (and if I am even remembering correctly)

@JRAndreassen
Copy link

JRAndreassen commented Jan 28, 2020

Hello again...
I made the changes on top of your changes...
The changes are limited to the mio.rs files now...
(https://github.com/JRAndreassen/tokio-ping/blob/usalbin_withwindows_changes/src/socket/mio.rs)
Still the same...

I've tried "15" different ways...
I've tried with tokio::net::UdpSocket, mio::net::socket, etc...
Still the same... It sends but I never get the reply
101 46632.863647 172.16.1.2 8.8.8.8 ICMP 66 Echo (ping) request id=0x4c60, seq=2/512, ttl=128 (reply in 102)
102 46632.882358 8.8.8.8 172.16.1.2 ICMP 66 Echo (ping) reply id=0x4c60, seq=2/512, ttl=52 (request in 101)
If I bind the socket, it does not send.
no bind, it sends but no response.
I'm at a loss and short on time at this point...
Perhaps someone can shed some light on this..
Or do we have to get assistance from the "Pros from Dover" (@alexcrichton / @carllerche / )

Anyone that has some insight into why it does not work ... I would welcome some guidance
https://github.com/JRAndreassen/tokio-ping/tree/usalbin_withwindows_changes
Thanks
JR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants