Upgrade to smoltcp version 0.9; fix the VPN locking up and spin-looping
This is a multi-patch series; the commit descriptions are pasted below:
the smoltcp upgrade commit
- We upgrade our smoltcp version from 0.8 to 0.9.1, incorporating a bunch of very useful changes.
- The smoltcp Interface no longer owns its socket set and device, which lets us only share the socket set across tasks; the device and interface can be solely owned by the main loop, reducing the amount of locking needed.
- We clean up TcpSocket and UdpSocket's new() functions, making them
just take an &OnionTunnel
for simplicity. - This also means we can move the PcapWriter out of the interface when packet capturing is not enabled, which is a lot cleaner.
- We no longer ignore smoltcp poll_delays of zero; instead, we keep track of when the interface's transmit buffer is full, and don't bother asking smoltcp for a poll delay in this case.
- If the transmit buffer is indeed full, we won't be able to send any more, but smoltcp will still try to, resulting in spin looping for no reason.
- We might still get poll_delay of zero in some cases, but it doesn't seem to lead to pathological spin-looping behaviour any more.
the locking up fix commit
- The
PollableAsyncDevice
previously tried to be clever, only attempting a write if it was notified to wake up because a new packet was just added to the TX buffer. - This is a flawed approach: if the write fails due to the device not being ready, we won't retry it until a new packet gets added!
- And if the buffer is full, we won't ever add any new packets, and we won't ever write, and the entire VPN locks up!
- Fix this oversight by just having one semaphore to wake up the async device, and indiscriminately polling both read and write halves every time.
- This is far less clever, and it might be a performance problem ages down the line, but simple is probably best...!
oh yeah, this also fixes #49 (closed) -- please close that for me, gitlab
Edited by eta