How to brutally interrupt remote network connections in code on Debian Stretch

Question

I am working on a Python communications class running on a Beaglebone that connects to /reconnects to remote hosts from my list of available servers.

To test the reconnecting, I have been physically unplugging my lan from my router to simulate outages. I would like to do this in code for extended testing. Essentially I want to create a method called kill_internet(timeout) that will pull the rug out and then restore connectivity at the end of timeout.

requirements:

1. Must interrupt established socket connections.
2. Disconnect must be brutal and ugly - no chance for socket to close gracefully.

Finally - I prefer that lan connections are not interrupted so I can continue to monitor testing over SSH from my PC. Not a true requirement since I can always reconnect and read logfiles later.

Service Networking stop will satisfy #1 but not sure how brutal it is. I thought about UFW ( iptables) outbound rule but that may not block established connections and same concern about #2.

I suppose I could build a hardware 2-port device to do this at hardware level but that is well - hard.

Any ideas how to proceed?

Thanks Bill

Answer 1

I stumbled across an easy hardware solution that cost me $22. Amazon sells these USB controlled relays for $10-$15 - look for UsbRelay2. With this I can easily trigger the relay(s) from code. To interrupt Ethernet violently, all I have to do is cut the power to an Ethernet hub or switch. I got a $10 5-port switch which runs off 5V from a wall wart. I cut one of the 5v power wires and ran it through the relay. Triggering the relay cuts the power to the switch. Since it is all 5V wiring is all safe and no case is needed. It took all of 3 minutes to put it together.

Answer 2

The best way to do this in your setup is to create and tear down firewall rules on your remote server to reject/deny your client in as many different ways as you can think of. For example:

1. Reject connection requests with an active refusal (easy to deal with on the client).
2. Drop a connection mid-flow with a reset packet (again, easy to deal with).
3. Suddenly stop responding at all to packets from the client's IP, mid connection. This simulates a cable-cut on a part of the network you don't own and it's the hardest one to deal with on the client because you have to consider what is a reasonable timeout.

If you're on Linux, iptables can be scripted to implement these rules.