How to Break an Arbitrary Tcp/Ip Connection on Linux

How to kill a single TCP connection in Linux?

Here are some options:

• Attach with gdb and call close() on the fd. You can map from addr/port to inode number via /proc/net/tcp and from inode number to FD inside the process with ls -la /proc/$pid/fd.
• Spoof a RST packet. You'll need to generate it locally and guess the SEQ number somehow.
• Maybe setup an iptables rule to generate a RST on the next packet.
• Write a kernel module.

There doesn't seem to be a well supported way to do this. It is likely that processes will crash if their FDs are unexpectedly closed anyway.

How to route TCP/IP responses through a different interface?

You could add an additional address to the lo interface on each system and use these new addresses as the TCP connection endpoints. You can then use static routes to direct which path each machine takes to get to the other machine's lo address.

For example:

Machine A:
  ip addr add 1.1.1.1/32 dev lo
  ip route add 2.2.2.2/32 dev eth0 via <eth0 default gateway>

Machine B:
  ip addr add 2.2.2.2/32 dev lo
  ip route add 1.1.1.1/32 dev gr0

Then bind to 1.1.1.1 on machine A and connect to 2.2.2.2.

TCP/IP communication from the unix server to the Pure Data

here's an outline of what you have to do:

• repackage the bytelist to small messages of the correct size for the various types.

  since all your elements are 4 byte long, you simply repackage your list (or bytestream, as TCP/IP doesn't guarantee to deliver your 16 bytes as a single list, but could also decide to break it into a list of arbitrary length) to a number of 4 atom lists.

  the most stable way, would probably be to 1st serialize the list (check the "serializer" example in the [list] help) and than reassamble that list to 4 elements.

  if you can use externals like zexy you could use [repack 4] for that.

  if you trust [netclient] to output your messages as complete lists, you could simply use a large [unpack ....] and 4 [pack]s

• interpret the raw data for each sublist

  integers is rather simple, floats are way more complicated

integers:

    |
    [unpack 0 0 0 0]
    |      |   |   |
    [<< 8] |   |   |
    |      |   |   |
    [+     ]   |   |
    |          |   |
    [<< 8]     |   |
    |          |   |
    [+         ]   |
    |              |
    [<< 8]         |
    |              |
    [+             ]
    |

floats are left as an exercise to the user :-)

Does arbitrary manipulation of TCP connection flow cause problems?

The problem is that TCP has an explicit mechanism to fix reordering problems. This may involve NACK's which force the sender to resend packets.

Your "priority" reordering of bytes in a TCP stream will at best create a lot of resending of data, so your "priority" degrades everything. But it's quite well possible that either side just gives up when the TCP stream is too disrupted.

Possible for a TCP socket to break so that it's still receiving but can no longer send?

I think it's likely a routing problem. The other comments above regarding unidirectional traffic only apply in the face of a shutdown(2) which presumably you would be aware of, since your application has to do that explicitly.

The routing could have been different in the two directions (as @RonMaupin noted). Or it could be that there was simply a large amount of congestion in one direction at some intermediate router. Either situation can result in packet drops.

In the face of dropped packets like this, the two sides will continue to retry their transmissions due to not receiving ACKs (which I think you've correctly described). The initial retransmission time is based on the approximate round-trip time calculated by each endpoint machine. Then there is an exponential backoff for subsequent retransmits -- see for example http://www.pcvr.nl/tcpip/tcp_time.htm#21_2 for explanation. The result is an eventual timeout.

Given the exponential backoff and some number of retransmits (that number is platform-specific and often configurable), it typically takes longer than 18 seconds before your local network stack declares a session dead. But it sounds like your application may have short-circuited this process with its own timeout (which seems reasonable for a game server).

I suspect you've never seen this before because in general the route is the same in both directions, and when a router is "down", it's down in both directions.

---

Related Topics