Jamil
Jamil
> This seems to support recent UX issues seen on macOS as well, which might be due to the nature of the TCP stack there. Complaints from users indicate that...
> Should we buffer more than 1 packet here per intent? Should we make that specific to UDP & ICMP and only buffer the first one for TCP? I know...
I will test this morning.
Hmm after testing I don't think this is working as expected. Testing with `ping -c 1` shows that the packet is being buffered and then flushed, but it never reaches...
I can confirm this error happens on `main` so it is not new to this PR:
It's the ol' `ERR_NETWORK_CHANGED` event unique to Chrome. Apparently this happens when chrome detects a TCP reset. I tried reducing this in Chrome to no avail. Firefox seems to work...
So after much testing, I think I've discovered the issue. We do successfully replay buffered packets into the tunnel, but the replies are not received by the application for some...
Merged main and tried to fix the conflict in tunnel/src/client.rs.
> > So after much testing, I think I've discovered the issue. We do successfully replay buffered packets into the tunnel, but the replies are not received by the application...
cc @conectado in case maybe the recent quinn bump caused it? #5872 #6314