demikernel icon indicating copy to clipboard operation
demikernel copied to clipboard

[tcp] Handle `RST` Packets

Open ppenna opened this issue 3 years ago • 1 comments

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.

ppenna avatar Jan 26 '22 13:01 ppenna

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

BrianZill avatar May 10 '22 22:05 BrianZill

Hello @BrianZill any updates on this?

ppenna avatar Dec 19 '22 18:12 ppenna

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 avatar Jan 18 '23 20:01 BrianZill

@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

ppenna avatar Jan 19 '23 10:01 ppenna