This post is about the product we are building at Toolsquare.io

The recent/ongoing DDoS¹ in the Netherlands impacted our customers, and our own product.

Although we don’t have publicly accessible endpoints on the customers network, we dó have to use their network connection to connect our hardware with our cloud platform. As an IOT solution, this is obvious. We do not supply our own WiFi network or cellular network, in order to reduce costs.

Offline Mode

When creating an IoT productivity system, the last thing you want is to get in the way of your user’s productivity. That’s why we implemented an offline mode on our hardware that allows the user to continue to work in case there is no network connectivity. This feature can be enabled on a per-device basis.

Slow is not Offline

As a consequence of the ongoing DDoS attack, network traffic is slow. This leads to long connection times, and response (failure to connect or connection success) takes more time to come in. Some of our hardware units were failing to go into offline mode because of this, and stuck in a reboot loop. Once we figured this out, a fix was quickly deployed and our customers can continue their work in offline mode.

You’ll never test enough

We have a robust test plan with unit tests, integration tests and end to end tests that takes many things that can be simulated into account. After today’s experience we will add slow network testing for our hardware/firmware to this by building a Raspberry Pi network emulation device that can simulate slow network behaviour.

1. Distributed Denial of Service attack ↩︎