demikernel
demikernel copied to clipboard
[tcp] Handle `RST` Packets
Description
Currently, we are not handling RST
packets. For instance, in protocols::tcp::peer::Inner::send_rst()
we are not waiting for ARP replies if needed.
The description for this bug seems to be talking about sending RST packets, whereas my PR demikernel/inetstack#123 partially fixed the handling of received RST packets. The send side of this issue mentioned in the description appears to be a datalink address resolution problem (which I believe we have a related issue for). The remaining receive side issue is with the proper closing of the connection -- we now (as of demikernel/inetstack#123) recognize that we got a RST, and make the proper state transition (previously we just blithely continued on as if the RST bit wasn't set). But we don't flush the data queues and delete the control block yet.
See also Issue demikernel/demikernel#235
Hello @BrianZill any updates on this?
Hello @BrianZill any updates on this?
As I mentioned in my May 10, 2022 comment, it's not entirely clear to me exactly what problem this Issue is about. From the title, I would think it was complaining about receiving RST packets, while the description references sending RST packets. And if the only problem is with not waiting for ARP, we have other Issues (yes, multiple) around that.
@BrianZill this was extracted from the legacy ToDos in our code. I believe that this code snippet is concerned here:
https://github.com/demikernel/demikernel/blob/64238daaae23471be8d652c74bbcd0089ec9a3e2/src/rust/inetstack/protocols/tcp/peer.rs#L557-L577