I am trying to see if data is retained in memory if there is a network disconnect from a system shut down on Machine 3. All machines are running RHEL 7. My setup is as follows:

Machine 1 > Machine 2 > Machine 3

I want to disconnect Machine 3 and check to see if that information that was sent from Machine 1 is being retained on Machine 2, even if its for a few seconds. Note that Machine 2 is basically just doing routing, no actual processing of information. The information is being sent via netcat over TCP or UDP.

What is the best way to see this information. I assumed doing an strace on the process pid, but I wasn't able to glean anything useful. Looking at another thread, I saw someone mention doing a /proc/[pid]/maps and dumping memory in gdb, but that seemed a bit too arduous to rifle through all the data I had seen.

Is there a better way to do what I am looking for? Thanks!

  • 2
    How is the data transferred? Do you have TCP connections going from M1 to M2 and from M2 to M3, or just one connection from M1 to M3 with machine 2 in between as a router? How do you disconnect Machine 3? Kill the process there, shut the OS down, or just pull the network plug?
    – ilkkachu
    Jan 5, 2021 at 15:02
  • Thanks for the follow up. It's a TCP connection from M1 to M2, and TCP connection from M2 to M3. M3 is shut down via just typical OS shut down. I'd like to add that M2 is basically just doing routing, no actual processing of information. Info can be sent via UDP as well. Jan 5, 2021 at 15:05
  • ah yes, you did mention netcat there.
    – ilkkachu
    Jan 5, 2021 at 16:07
  • edit question to make clear. in preference to amendments in comments. Jan 5, 2021 at 16:27

1 Answer 1


I would expect this to depend on what M2 is doing and how M3 gets shut down. Also, if you're considering this from a security perspective, how much it matters depends on how you define your threat model and required security level.

If M2 takes active part in the communication on the TCP level, that is, if there's a TCP connection between M1 and M2, and another between M2 and M3, then the OS on M2 will need to store any data sent until M3 acknowledges reception (or until various timers run out, closing the connection with an error). This would not need to happen if it was a UDP connection, or if M2 acted only as an IP router. For both IP and UDP, packets/datagrams are sent, and then forgotten, and it's the responsibility of upper level protocols to deal with that.

In addition, the way M3 is shut down matters a bit. If it only stops answering, because it lost power or the network cable was disconnected, then M2 can't know it's gone, and (with TCP) will try to resend. But if it's actively shut down, the OS on M3 may try to make sure all active network connections are closed in an orderly fashion. In that case M2 would receive a message telling the connection is closed, and could drop any unsent data.

The network buffers would reside within the OS, so they wouldn't be visible from dumping the process memory, but the process might end up doing some buffering too. Similar arguments would be likely to apply there, if the process exits when detecting an error on the connection to M3.

All of the above applies to the data that needs to be kept for further use. In addition, it's quite possible that some data stays in the memory of M2, in buffers that are no longer used, but haven't actually been overwritten. It might be an interesting exercise to actually do that experiment with some easy-to-identify data, and then dump the memory of the whole OS to find remnant copies of it.

Depending on your threat model, you may also want to consider the case where the program on M2 or the OS itself is compromised and sends copies of the communication to an unknown party.

  • Alright so I think I understand how it works in theory, but mouse on keyboard, and regardless of what the setup is, how would I check to see if any data is resident on M2? Jan 5, 2021 at 18:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .