Tests hang forever after interface idle for some time

[torsteingrindvik]

I have only done this on a single computer yet so I'm not sure if it's reproducible on other networks/PCs/OSes, etc.

On Ubuntu 19.10.
Commit is e150911

Reproducable by:

cargo test; echo "WAITING 10 min"; sleep 600; cargo test; echo Success!

The last line will never be echoed, as the second test will hang forever.
First test finishes instantly.

[vorner]

I'm not sure if it's the time. When I run the tests repeatedly, they lock up sometimes. I suspect there's some race condition or maybe it doesn't perform well if packets are lost on the interface 🤷.

Anyway, this crate really is not at the very top of my priority list, it might take some time before I get to this. So if you could have a look at what might be happening (maybe strace would help), it would be great.

[torsteingrindvik]

Ok (sorry for late reply)! Same for me, might take a while until I need the functionality from this crate.
But unless fixed I'll be happy to take a look when I get around to it.

[torsteingrindvik]

Quick update. Tried this again, but with Wireshark (I don't recall if I had Wireshark running when I reported this).
I saw that when the test hangs there is an ICMP Destination unreacable (Host administratively prohibited).
And using dmesg --follow showed that my firewall was actively blocking those (but only sometimes?!).

I haven't been able to have the tests fail after allowing all traffic in the tun10 interface.

Could it be the same issue for you?
If yes then there might not be an issue.

Although I'm pretty sure I've seen tests fail without locking up... will poke it some more.

[vorner]

I didn't find the time to look at it more since then, but I'm pretty confident nothing manipulates my firewall and the ports should be the same each time.

[torsteingrindvik]

I have using the TAP parts of this over the weekend and captured >1 000 000 packets without problems.
Feel free to close this if you want.

[vorner]

I'll keep this open for now. If my gut feeling is right, it's a problem in the test, not in the actual library code.