31–40 of 42 posts
In the same direction, I once wanted to test an embedded device on crap wifi. So I just ordered the cheapest AP I could find. Except the damn device worked perfectly. Slow but rock solid. One of our testers at $CURRENT_JOB also has trouble simulating a crap network, because our network is good.
maybe look into jammers?
In the same direction, I once wanted to test an embedded device on crap wifi. So I just ordered the cheapest AP I could find. Except the damn device worked perfectly. Slow but rock solid. One of our testers at $CURRENT_JOB also has trouble simulating a crap network, because our network is good.
https://highscalability.com/how-facebook-makes-mobile-work-a...
In the same direction, I once wanted to test an embedded device on crap wifi. So I just ordered the cheapest AP I could find. Except the damn device worked perfectly. Slow but rock solid. One of our testers at $CURRENT_JOB also has trouble simulating a crap network, because our network is good.
You can simulate bad wifi with the throttling option on the network tab of your browser's developer tools
Oh? How does that help for native applications?
> You can always also simulate bad WiFi by walking away from your access point until you have bad wifi
That's unfortunately very inconvenient when you work on an embeddeded device prototype that consists of several boards interconnected by hair thin wires :)
Maybe I should make some friends across the street to the point they give me access to their APs...
In the same direction, I once wanted to test an embedded device on crap wifi. So I just ordered the cheapest AP I could find. Except the damn device worked perfectly. Slow but rock solid. One of our testers at $CURRENT_JOB also has trouble simulating a crap network, because our network is good.
I remember Facebook while developing it's mobile app in the early days of smartphones did similar tests. https://highscalability.com/how-facebook-makes-mobile-work-a...
In the same direction, I once wanted to test an embedded device on crap wifi. So I just ordered the cheapest AP I could find. Except the damn device worked perfectly. Slow but rock solid. One of our testers at $CURRENT_JOB also has trouble simulating a crap network, because our network is good.
If you're testing hardware or vm's that don't support it or don't have root, you can stick your linux box transparently in the middle by bridging two interfaces, and apply your traffic mangling there. Testing wifi? Use a decent WiFi AP connected to one of these bridges and mangle your traffic once it hits the wire/after it stops being RF.
At a previous job I had a linux box set up with multiple bridges (each set with a different "testing profile" on different vlans) and trunked to a physical switch. Made it very easy for people in the office to attach physical devices through known bad network links by either using pairs of physical switchports or just dumping VMs/SSIDs into the right VLAN so they could test different things (simultaneously) without needing to reconfigure the actual mangling.
Worth noting that tc applies to egress traffic, so if you want a uniformly bad line it needs applying to both sides - but it does mean you can simulate unidirectional link problems too.
In the same direction, I once wanted to test an embedded device on crap wifi. So I just ordered the cheapest AP I could find. Except the damn device worked perfectly. Slow but rock solid. One of our testers at $CURRENT_JOB also has trouble simulating a crap network, because our network is good.
Why not just loosely wrap the antenna or entire box in foil or move it to the basement/garage/roof? If you're going for realism, bad wifi is a radio signal problem.
Meanwhile HTTP keeps working just fine and is decentralized. Just "add your own crypto" on top, which is the ONLY thing a sane person would do. 3... 2... 1... banned?