Re: artificial latency for a network interface
> > 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. Right. And you don't even need tun1. Just write them back to tun0. >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. True. Max Maksim Krasnyanskiy Senior Kernel Engineer Qualcomm Incorporated [EMAIL PROTECTED] http://bluez.sf.net http://vtun.sf.net - 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/
Re: artificial latency for a network interface
On Thu, Jun 28, 2001 at 11:29:38PM -0500, Burkhard Daniel wrote: > 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. > And for something with a lot more options, try http://www.antd.nist.gov/nistnet. Works great, lets you drop packets, have variable latency, simulate congestion, almost everything you need to simulate networks. Even has a nice GUI to tune it all ;) - 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/
Re: artificial latency for a network interface
On Thu, Jun 28, 2001 at 11:29:38PM -0500, Burkhard Daniel wrote: 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. And for something with a lot more options, try http://www.antd.nist.gov/nistnet. Works great, lets you drop packets, have variable latency, simulate congestion, almost everything you need to simulate networks. Even has a nice GUI to tune it all ;) - 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/
Re: artificial latency for a network interface
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. Right. And you don't even need tun1. Just write them back to tun0. 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. True. Max Maksim Krasnyanskiy Senior Kernel Engineer Qualcomm Incorporated [EMAIL PROTECTED] http://bluez.sf.net http://vtun.sf.net - 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/
Re: artificial latency for a network interface
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. Burk. On Fri, 29 Jun 2001, Andrew Morton wrote: > Andreas Schuldei wrote: > > > > 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/ > - 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/
Re: artificial latency for a network interface
Andreas Schuldei wrote: > > 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/
artificial latency for a network interface
I once solved this problem using the QoS qdisc facilites: http://edge.mcs.drexel.edu/GICL/people/udmcwher/dnt/DNT.html It works on 2.2 kernels as well. -david Andreas Schuldei writes: > 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? --[=] David T. McWherter[EMAIL PROTECTED] My religion consists of a humble admiration of the illimitable superior spirit who reveals himself in the slight details we are able to perceive with our frail and feeble mind. -- Albert Einstein - 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/
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? I also did not manage to point any routes at tun0 or tun1. thoes interfaces do not show up in the /proc/net/dev either. only the module is loaded. I seem to miss something. who has used those devices before and got them working and could help me debug this? - 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/
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? I also did not manage to point any routes at tun0 or tun1. thoes interfaces do not show up in the /proc/net/dev either. only the module is loaded. I seem to miss something. who has used those devices before and got them working and could help me debug this? - 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/
artificial latency for a network interface
I once solved this problem using the QoS qdisc facilites: http://edge.mcs.drexel.edu/GICL/people/udmcwher/dnt/DNT.html It works on 2.2 kernels as well. -david Andreas Schuldei writes: 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? --[=] David T. McWherter[EMAIL PROTECTED] My religion consists of a humble admiration of the illimitable superior spirit who reveals himself in the slight details we are able to perceive with our frail and feeble mind. -- Albert Einstein - 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/
Re: artificial latency for a network interface
Andreas Schuldei wrote: 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/
Re: artificial latency for a network interface
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. Burk. On Fri, 29 Jun 2001, Andrew Morton wrote: Andreas Schuldei wrote: 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/ - 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/
