This project is read-only.

Bridge-Wan Emulator

Feb 16, 2013 at 3:40 AM
Hi just came across this excellent project and I'd like to ask you guys a question. Given a computer with 2 NIC's (eth0, eth1) with your solution installed for WAN emulation purposes. Can I use it like a bridge ?

Let's say I have computer1 connected to eth0 and computer2 connected to eth1 and these 2 guys are sitting on the same subnet and the intention is impairing the traffic between these 2 computers as they are on the same subnet i don't need routing there.

Is this possible?

Thanks in advance!
Feb 16, 2013 at 12:19 PM

Yes, you can.

Simply use two Direct Interface I/O handlers to connect with the interfaces and connect the Direct Interface I/O handlers to each other.
Of course you can put other traffic handlers between the two Direct Interface I/O handlers.

Here is an image of the basic compilation:


With best regards,
Feb 16, 2013 at 7:11 PM
Excellent, thank you. I will be playing around with it next week, I'll let you know how it goes.
Apr 9, 2013 at 8:17 PM
Hi Emi,

Sorry it took so long to try this one, it works well as expected, thanks for this.

Right now I am using the Wan emulator Traffic Handler and works well, however I am running into an issue and not sure if there is a way to overcome it with this project.

I am trying to limit the throughput to X kbps but i don't seem to find a way to control the size of the buffer where all delayed packets are stored because of the bandwidth limitation.

When traffic is high and throughput limitation applied it looks like buffers used are very long causing high delays in traffic, since it does not look like packets are being dropped on the queue. Is there any way to shorten the buffer to XKBps or X packets so packets get dropped ?

The reason to do this is simulating a router shaping the traffic, if you try to do it with a real one you will observe the queuing are not that long and packets start getting dropped after a certain threshold.

Do you think it is possible to manage this ?
Apr 10, 2013 at 7:51 PM
Hello again,

when I designed the WAN Emulator handler, I thought that it should be possible to simulate the effect of full queues by setting the packet drop rate to an appropriate value.

If this is not sufficient for you, it should be fairly easy to achieve dropping by adding a condition to the Push(Frame f) method of the SpeedConstrainer class.

I'll implement tail dropping now and add the changes to SVN soon, it would be nice if you tell me whether it works for you.
Apr 10, 2013 at 8:18 PM
That is fantastic and it will give your project a much more realistic approach when characterizing network constraints such speed limited links.

I don't think you would be able to simulate effect of full queues setting packet loss rate, since the the loss distribution is completely different. Assuming the queue is FIFO then the latest packets are the ones that have to be dropped after queue is full then you experience some burst distribution and also the delay effect is completely different.

There are some WAN emulators out there that approach the queuing in 2 different ways and you can use this idea to implement it here

Packet Mode: Allow limit for X packets, what they do is reserve a slot of for example 1500Bytes x packet, regardless of its size, so if you want a buffer of 70 packets then you have 70x1500B buffer size.

Byte Mode: Just allows YBytes on the buffer, so packet size matters. Let's say buffer of 128KB, it handles packets until 128KB buffer is full

Hope you get the idea and this helps you to make the enhancement since it can really make a huge improvement to emulate networks.

Feel free to reach out to me if you need testing I got plenty of time now.
Apr 10, 2013 at 8:40 PM

I implemented the byte mode-approach by now, you can find the binaries for testig at
Would you kindly check if it does the expected?

I am considering a rewrite of the WAN-Emulator including techniques like random early detection for better simulation.

Thank you for your suggestions and your help!
Apr 11, 2013 at 8:04 PM
Hi Emi,

Yes it seems to work well, I cannot verify if the Maximum Buffer size it is actually exact but seems to be doing the right thing, I suggest you default the value to something between 64KB-200KB, the default number is huge, but well this is minor as you can change it.

Another thing I want to bring up at this point is the Maximum Throughput (KB/s) , I don't think this value is correct or I may be missing something, but for sure this is what I get:

For example, setting a Maximum Throughput (KB/s) of 2000 gets me a throughput of 1000 Kbits per second, so basically the half of the value you enter in Kilobits per sec, and this is pretty consistent, could you explain this ? For me it works ok because I can set according to what I want but someone else may get confused.

Thanks so much for your efforts this really helped, I can keep giving you ideas for the WAN emulator module if you're interested.
Apr 18, 2013 at 12:06 PM

Thank you for your feedback, I am going to re-design the WAN-Emulator implementation, but I will need some time for this.

Yes, it would be a great help to get some ideas and feedback.
Are you interested to participate in developing this project?
Apr 25, 2013 at 6:30 PM
Yes, I can offer guidance on WAN emulation features if needed and I can help on testing and verification too. Thanks for your efforts!
Jun 27, 2013 at 6:31 PM
Hi Emiswelt,

Just double-checking with you whether you have plans for the WAN-Emulator implementation, just let me know when you're ready if you need help to do verification of the functionalities. Thanks
Jun 30, 2013 at 11:48 PM
Hello godzero,

I got myself familiar with network errors and issues, and now, the following features are in progress:
  • Isolate all features of the WAN-Emulator in seperate TrafficHandlers (more flexibility, more stable threading model)
  • Handler which corrupts packets, based on a given probability of errors per single bit. Modes: Invert the error bit, set error bit to zero, set error bit to one, set error bit to random.
  • Handler which corrupts packets, based on a given normal distributed error count per packet, and a given normal distributed error "burst" length. Mode: same as above.
  • Handler which drops packets, based on a given probability.
  • Handler which duplicates packets, based on a given probability.
  • Handler which delays packets, based on a given normal distributed delay.
  • Handler which limits bandwidth, either based on frames per second, or bits per second, with an optional maximum queue size and RED or TAIL dropping algorithms.
  • Additional rules for the TrafficSplitter handler: Random (or probability based/weighted random) splitting, round-robin splitting.
The first few tasks are pretty much finished, but I still want to conduct some test and add UIs for the new handlers.
I'll try to complete at least some of the new features until next sunday for preview and testing.

If you have any further ideas for handlers or features, please let me know.

With best regards,
Jul 6, 2013 at 12:01 AM
Hi Emi,

Your plan looks solid. I think I can give a try to what you have and from there make further suggestions. Let me know when it is ready and I can do some testing for you as well.

Jul 7, 2013 at 11:44 PM

Thank you very much for your support and patience.

The implementation of the traffic handler classes except RED and splitting are finished. I'll probably complete the UI and start with testing during tomorrow evening - if everything works as expected, I'll upload a version for testing.

Jul 9, 2013 at 4:44 PM
Edited Jul 9, 2013 at 4:46 PM

I finished a alpha version of the new features.

I also included some very basic test compilations into the zip package.

The new Traffic Handlers are the last five items in the toolbox.

Thank you very much!