Open hunhoffe opened 10 months ago
Check packet dumps of both sides, you'll hopefully see one side is transmitting packets that never get to the other side. Could be something wrong with the phy impl or something in the link. If you see only big packets getting dropped it could be a MTU issue, it's common for it to give trouble if you're tunneling/VPNing.
Hi,
In our system we're seeing a similar issue where the TCP connection gets stuck when we send a lot of small packets.
It seems like a packet is somehow lost and smoltcp
tries to re-transmit repeatedly.
The interesting part is that whenever smoltcp
logs a re-transmit nothing is detected on the wire when looking with wireshark
on the computer to which this TCP socket is connected, this is the only measurable effect we've been able to capture as of yet.
We're trying to create a reproducible test so we can make a proper bug report, but the end effect is that smoltcp
seems to get stuck as here, until tokio
's TCP stream hits timeout which then causes the sockets to be recreated and and the problem is alleviated until the next time it happens.
If it's this issue we are hitting or a separate one I'll let our investigation into the issue show.
Hello,
This is probably a user error but I'm unsure how, and I've been unable to replicate it in more minimal example/unit tests. I'm seeing that a TCP connection gets stuck in a state where one endpoint is reporting retransmission. Data stops flowing.
For example, in one endpoint, the smoltcp debug output from the entire connection looks something like this:
The other endpoint reports something like this. It is stuck in a poll loop waiting to receive some data:
I've confirmed both endpoints are polling the interface regularly. I've confirmed that the clock I'm using - while it may return the same value - it never goes backwards. I am a bit concerned that it might be a timing error (I'm using the rawtime library to get the current time), but I'm not sure what other clock requirement I need to check for other than monotonicity. I am also using a custom device, which could perhaps be the issue.
I'm using smoltcp v0.8.0. I did go through some previous issues/PRs to see if someone else has reported something similar, and I saw some things about retransmissions but I think those issues were merged before the v0.8.0 release, if I am reading the release dates correctly. So I'm not sure if I should invest time in upgrading to a newer release.
Any insight would be appreciated for how to get to the root of this issue!