4 ms·
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 pe
by nottorp 7mo ago
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.
- Groxx 7mo agoSome proxies, iptables extensions, and OS-provided tools exist - there's almost certainly a combo that would work for them. What platform? Unless it's for a custom physical device, then uh. idk. Probably something, proxying through another computer that is hosting a separate wifi network? But likely a lot harder.
- nottorp 7mo agoI think he figured it out eventually, used some software tool. But I heard the complaining first.
- deleted 7mo ago[deleted]
- gnopgnip 7mo agoYou can simulate bad wifi with the throttling option on the network tab of your browser's developer tools
- dieulot 7mo agoThat’s an unreliable way of simulating an unreliable network, as overviewed in https://calendar.perfplanet.com/2016/testing-with-realistic-networking-conditions/#browser_level_traffic_shaping https://calendar.perfplanet.com/2016/testing-with-realistic-...
- patmorgan23 7mo agoSlow networks != Bad networks. Bad networks could be slow, or drop random packets, or corrupt packets, or have jitter, etc
- SOLAR_FIELDS 7mo agoYou can always also simulate bad WiFi by walking away from your access point until you have bad wifi
- nottorp 7mo ago> 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...
- a_t48 7mo agoI'm building a product that helps out Docker usage in poorly networked environments (ie, robotics deployments). I've just been moving the Jetson around the house.
- callistocodes 7mo agoPutting a StarLink dish so it has a tree branch in the way is a good way to get packet loss.
- makr17 7mo agoComing up on 20 years ago I was building a system that was going to be deployed at various locations throughout a very large country. All locations had internet access; but the throughput, latency, and quality (e.g. packet drops) were all over the map. For testing we ended up building a small linux box to proxy for the test environment in the office. We could throttle the throughput to any arbitrary level, introduce latency, and introduce packet drops. It's amazing how poorly a frontend will work when you throttle the network to 128kbps, and introduce a small percentage of dropped packets. But once you get the system to work (for some definition of "work") under those conditions you feel pretty good about deploying it.
- NooneAtAll3 7mo agomaybe look into jammers?
- bigfatkitten 7mo agoNot an option if you want to act lawfully.
- NooneAtAll3 7mo agoit is lawful if it's your devices only
- bigfatkitten 7mo agoIt’s not your radiofrequency spectrum.
- sublinear 7mo agoWhy 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.
- contraposit 7mo agoI 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-at-scale-for-all-phones-on-al/ https://highscalability.com/how-facebook-makes-mobile-work-a...
- tdg5 7mo agoI miss https://highscalabilty.com https://highscalabilty.com ;( The “Stuff The Internet Says On Scalability” posts were always worth a read.
- BuildTheRobots 7mo agoThe linux kernel traffic control (tc) can do network emulation with qdisc to simulate bad network connections. Add latency, jitter, bandwidth limits, and settable levels of traffic loss to your network interface. 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.