1

Is it possible to test an TCP stack using TUN / TAP interfaces ? I'm thinking of a mechanism like this:

  +--------------------------------+
  |   TCP Client / Server          |
  |  socket(AF_INET, SOCK_STREAM)  |
  | e.g. HTTP Server / Client      |
  +----------+---------------------+
             |
             |  +---------------------+
             |  |  TUN Device         |
             |  | ( kernel does TCP ) |
             |  +---------------------+
             |                       
  +------------+----------------------+
  | Linux Kernel + Forwarding Magic   |
  +-----------------------------------+
            |
            | +---------------------+
            | |TAP Device           |
            | |Raw ethernet frames  |
            | +---------------------+
            |
 +----------+----------------------+
 |  Raw  Socket API                |
 | socket(AF_PACKET, SOCK_RAW)     |
 | User mode TCP Stack over raw API|
 | a HTTP client/server over it    |
 +---------------------------------+

The top box, is (say) a standard unmodified HTTP server, listening on a IP address, which has been routed to the TUN device. The bottom box is a custom TCP/IP stack, which works on the raw ethernet frames.

Questions:

  1. Is it possible to connect two TAP/TUN devices back to back like this ?
  2. Is 'bridge' needed here ? How else they talk back-to-back ?
  3. And finally : Is there a better way to do this ?

Thanx in advance.

PS: I'm going to run all of them on same machine. The 'Box' are more like process or set or processes here.

vrdhn
  • 4,024
  • 3
  • 31
  • 39
  • It turns out that I don't actually need to create two devices. This is the set of command that can demonstrate getting the raw packets: # socat STDOUT TUN:10.0.0.1/24,up ; # ping 10.0.0.2 – vrdhn Apr 25 '13 at 18:59

1 Answers1

1

I'm not sure if this is a reasonable design. It depends on what you are trying to achieve, exactly.

You can certainly send the traffic into a TUN device on the top box... but then you have to have some kind of process that runs on that box to collect the traffic coming through the TUN device. That process could be your actual custom TCP/IP stack, or it could be something that tunnels the packets to your bottom box. I assume you'd want it to be a tunnel since you want to run your custom TCP/IP stack on a different machine (the bottom box). In that case you might even find it advantageous for the tunnel software in question on the top box to be something that already exists, like OpenVPN.

However, my guess is that your needs are more likely to be served by running a standard TCP/IP stack with no tunnels on the top box, and having the bottom box act as a router that routes packets between a real ethernet interface (where the packets arrive from the top box) and a TUN device. And at the userspace end of the TUN device sits your custom TCP/IP stack.

In neither case would you need to use any raw sockets or indeed any sockets at all. Either way, your custom TCP/IP stacks receives frames out of the TUN device (possible tunnelled from tophost, possibly directly on bottomhost) and injects the frames it originates back into the same TUN device.

Celada
  • 21,627
  • 4
  • 64
  • 78