artificial latency for a network interface

to simulate a sattelite link, I need to add a latency to a network connection.

What is the easiest and best way to do that?

I wanted to do that using two tun devices.
I had hoped to have a routing like this:

<-> eth0 <-> tun0 <-> userspace, waiting queue <-> tun1 <-> eth1

I need to do it this way and not with iptables help, because it needs to work also on 2.2.x kernels.

Now I started experimenting with the tun0 interfaces and got
problems: till now I have not succeeded to get a tun0 interface up. the example code (br_select.c) in the package (as found for example on sourceforge) looks fishy and does not work too well. is it correct that only one /dev/tun file is necessary, but /dev/tun0 and tun1 are opend for reading and writing?

to simulate a sattelite link, I need to add a latency to a network connection.

What is the easiest and best way to do that?

I wanted to do that using two tun devices.
I had hoped to have a routing like this:

<-> eth0 <-> tun0 <-> userspace, waiting queue <-> tun1 <-> eth1

Quoted 10 lines · Andreas Schuldei

to simulate a sattelite link, I need to add a latency to a network connection.

What is the easiest and best way to do that?

I wanted to do that using two tun devices.
I had hoped to have a routing like this:

<-> eth0 <-> tun0 <-> userspace, waiting queue <-> tun1 <-> eth1

yes, that works very well. A userspace app sits on top of the tun/tap device and pulls out packets, delays them and reinjects them.

The problem is routing: when you send the packet back to the kernel, it sends it straight back to you. You need to rewrite the headers, which is a pain.

A simpler approach is to use policy routing - use the source and destination devices to override the IP addresses. Works well. The code is at

http://www.uow.edu.au/~andrewm/packet-delay.tar.gz

It has its own variable bandwidth management as well
as variable latency. It's for simulating narrowband, high latency connections.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

I had a similiar problem once, and wrote a module that overwrote the loopback net device. Since it's loopback, the kernel won't care about headers.

Yeah, I know: Quick & Dirty.

I made the new loopback put its packets in a queue and then deliver them after a (adjustable) delay.

If I can still find the source for this, I'll post it here.

Quoted 5 lines

I wanted to do that using two tun devices.
I had hoped to have a routing like this:

<-> eth0 <-> tun0 <-> userspace, waiting queue <-> tun1 <-> eth1

yes, that works very well. A userspace app sits on top of the tun/tap device and pulls out packets, delays them and reinjects them.

The problem is routing: when you send the packet back to the kernel, it sends it straight back to you. You need to rewrite the headers, which is a pain.