<div dir="ltr">  Hmm, I've had so little experience with tuntap interfaces I didn't think of them. That sounds like the way to go to get things working on OSX, though at a much larger amount of effort (both the learning curve on my part, and re-implementing the degradation behaviors I get for free from the kernel). Thanks for suggesting it; once I get things to where it's usable on Linux in all the ways I want, some research and a rewrite may be in order to get it fully portable.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 5, 2015 at 8:11 PM, Michael Santos <span dir="ltr"><<a href="mailto:michael.santos@gmail.com" target="_blank">michael.santos@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jan 05, 2015 at 09:16:42AM -0500, Christopher Phillips wrote:<br>
> For OSX ipfw was deprecated in Lion and removed in Yosemite. I've done a<br>
> bit of looking at the replacement, pf, and it looks like dropping packets<br>
> based on percentage is doable, as is bandwidth throttling (something I'd<br>
> like to add, in general), but I don't see any way to induce a delay, beyond<br>
> an implicit one based on tos prioritization. If someone knows how and can<br>
> point me in the right direction I'd appreciate it.<br>
<br>
</span>The portable way is to use a tuntap device. Then you can arbitrarily<br>
drop packets, throttle bandwidth, introduce latency, whatever, from your<br>
code. Sort of like quickcheck for networks :)<br>
<div class="HOEnZb"><div class="h5"><br>
> On Mon, Jan 5, 2015 at 6:52 AM, Sergej Jurečko <<a href="mailto:sergej.jurecko@gmail.com">sergej.jurecko@gmail.com</a>><br>
> wrote:<br>
><br>
> > This looks like a great tool and something that could easily be added to<br>
> > unit tests.<br>
> > Anyone with ipfw skills to add bsd/osx support?<br>
> ><br>
> > Sergej<br>
> > On Jan 5, 2015 1:41 AM, "Christopher Phillips" <<a href="mailto:lostcolony@gmail.com">lostcolony@gmail.com</a>><br>
> > wrote:<br>
> ><br>
> >> <a href="https://github.com/lostcolony/damocles" target="_blank">https://github.com/lostcolony/damocles</a><br>
> >><br>
> >> I asked a while back on this mailing list if anyone had any useful<br>
> >> libraries or similar for testing distribution scenarios. I only got back a<br>
> >> few responses (maybe co-op riak_test? Maybe make use of the underlying<br>
> >> Linux traffic control and network emulation apps?), and my own searches,<br>
> >> while finding a few libraries, didn't find anything I could easily co-op<br>
> >> for my purposes.<br>
> >><br>
> >> To that end, I went ahead and spent part of my break on this, and it just<br>
> >> got sufficiently feature complete to throw out there. I haven't had a<br>
> >> chance to really start using it heavily, and I've only been testing it on<br>
> >> my dev box, but a basic run through of the functionality as I typed up the<br>
> >> readme worked (so any issues being pointed out would be appreciated).<br>
> >> Essentially, it allows you to create and manipulate local interfaces on a<br>
> >> Linux machine to emulate packet delay and loss (using the underlying<br>
> >> traffic control and network emulation mechanisms), with a number of<br>
> >> convenience methods to (hopefully) easily describe fairly intricate<br>
> >> distribution scenarios.<br>
> >><br>
> >> Things like "create these 5 interfaces, (now from my test code, launch a<br>
> >> copy of my app on each one, or even a different app on one of them, to see<br>
> >> what happens when that resource is flaky); now make it so 1 and 2 can't<br>
> >> talk to 3 and 4, and vice versa, but everyone can still talk to 5, but<br>
> >> replies have a 50% chance of being dropped from 5 when responding to 1 and<br>
> >> 2, and there's a 300ms delay between 3 and 4; (now, let's run more of our<br>
> >> test code to assert that trying to write to any node still succeeds); okay,<br>
> >> now let's restore the network back to normal (and have our test code make<br>
> >> sure the write was retained)", or whatever, can be set up in a<br>
> >> straightforward, automated manner as part of a common test run, and not be<br>
> >> reliant on certain VMs being up, nor the tests being run on a specific<br>
> >> network. The tradeoff, obviously, being that you can't really load test<br>
> >> things with it. Still, it fits my basic needs, and I figured it might be of<br>
> >> use to others.<br>
> >><br>
> >> I'll be adding some simple examples when I next get free time (I ran out<br>
> >> of it from the holiday break without getting to them; dunno when I will),<br>
> >> and will try and get to any bugs or simple suggestions in a timely manner,<br>
> >> but hopefully it's fairly straightforward and useful as is.<br>
> >><br>
> >> _______________________________________________<br>
> >> erlang-questions mailing list<br>
> >> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> >> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
> >><br>
> >><br>
<br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
</div></div></blockquote></div><br></div>