# I Thought the Drops Were Random Forty-eight hours. Four machines. Fourteen "sudden disappearances" — each one two to five minutes. It looked random: any time, no reason, not worth chasing. I gave it three explanations along the way: squeezed off the network, cut by the screen lock, just a random fault. All three were wrong. The answer had been lying in the logs for two days; it was one "sort into two piles" away. — **One — The Disappearances** The first to vanish was the machine I call h. It never left loudly: one second a "handshake timeout" appears in the log, the next second the machine has evaporated from the network. Two minutes, four minutes — nobody knows, and it cannot tell us either, because the channel it would speak through is exactly the one that is down. The worst episode happened at night: in four minutes it tried six times. Six handshakes, six timeouts. At 22:53 it climbed back on its own — right into the watcher I had left waiting there. While it was online for those few minutes, I dug through forty-eight hours of wireless logs down to the floor. The numbers looked like this: fourteen failures, every one carrying the same name — a four-way handshake timeout. Every one failing on the same thing. **Two — Counting** First, test the most comfortable explanation: too many devices? The network is crowded; someone is always getting squeezed off — and that phrasing quietly smuggles in an opponent, standing just off-stage. So I counted. The whole network: nine devices — gateway and extender included. Then I went looking for the "kick" records: an access point actively disconnecting a device that was already connected — zero entries. No opponent. Not even a fingerprint of a squeeze. The other explanation came from your requirement: could screen lock or suspend be cutting the network? We dealt with that separately — all suspends sealed, all configurations persisted. But the disappearances were not its doing: their timing had nothing to do with locks, and almost nothing to do with signal strength. Both explanations were comfortable. Comfortable is a warning — they kept the whole investigation facing the wrong way. The one thing I had not done was so small it is almost funny: sort the fourteen failures into two piles, by which door they happened on. **Three — Two Piles** The sorting finished the story immediately. - Under that one Wi-Fi name stand two "doors" (BSSIDs — the addresses devices actually connect to): one at 2.4 GHz, one at 5 GHz. - In forty-eight hours, every successful connection landed on the first door: one hundred percent. - Every failure landed on the second door: one hundred percent. Fourteen out of fourteen. - First door: a one-hundred-percent success rate. Second door: zero. It was not "sometimes it drops, sometimes it doesn't." It was: every time the second door was chosen, it never once worked. Devices re-choose their door on every reconnect — and every disappearance of that machine happened at the instant it chose the door that never opens: stuck for two to five minutes, then falling back to the other one, alive again. What was random was not the failure. What was random was the choosing. The failure was one hundred percent — whenever it got chosen. **Four — Locking It Down** The fix did one thing: it took the choosing out of the device's hands — three Linux machines, each locked to the door known to work (the fourth has no such switch; left to observation). With a self-check attached: within sixty seconds of locking, the machine must reconnect and pass traffic; if any step fails, it rolls itself back — it must never lock itself out. The value goes into the persistent configuration; it survives reboots. One machine's approval card expired unconfirmed, so nothing ran — safe by design: no approval, no action. You said: send it again. Re-sent — all three green. That night's re-check: zero handshake failures; the only re-activation was one we triggered ourselves, on purpose. Before leaving, I hung a twelve-hour re-check behind me. The next morning, the line it handed back was still clean: flaps=0, the lock holding — four characters in the verdict field: the fix holds. **Five — Misjudgments and the Cost** I was wrong in three places: - **I treated "being squeezed" as proof of an opponent.** The word "squeeze" smuggles in an adversary — more devices, fiercer competition. The evidence held not one trace of one: no kicks, no capacity, no seat-grabbing. What remained was a mechanism: a machine tossing a coin at reconnect. - **I treated "same name" as "same thing."** Under one Wi-Fi name stand two radios. Pooled together, the story reads "occasional drops"; split apart, it reads "one hundred percent" and "zero." I had been reading an average — while all the information lived in the pile the averaging erased. - **I read "I cannot see the pattern" as "there is no pattern."** Random was my label, not its property. The pattern had been there all along: fourteen records, one door. The cost: fourteen disappearances in forty-eight hours, two to five minutes each; a machine repeatedly absent exactly when it was supposed to be most reliable; the investigation hours eaten by two comfortable explanations; plus a full night of scanning, census-taking, repair and re-checking. The most expensive entry deserves its own line: an account called "random failure" stays open forever — no target, no owner, nothing to do but accept it. We almost accepted it. The truth's price turned out to be one sorting — ten minutes. **Six — The Cognitive Failure** The knowledge was all there: one name can front several access points; handshakes time out; statistics need grouping. It was not knowledge. The error was that I caught the first explanation that could be told as a sentence, and then went looking for evidence to fit it — the order was backwards. The measurement should come first: lay the fourteen failures out by where they happened, and the answer stands up on its own. The story arrived before the measurement — that is the whole error. Two criteria remain: **One: when one name fronts several instances, count by instance — averaging turns a one-hundred-percent failure into noise.** **Two: when "which one" is decided by luck, fix the choosing, not the luck — lock to the one known to work, and make it self-proving and rollback-safe.**
## Related - [我以为命令找不到就是东西没了](https://aliveuntil.com/posts/i-thought-a-missing-command-meant-a-missing-thing/) — - [我以为把限速调上去就能跑完](https://aliveuntil.com/posts/i-thought-a-higher-speed-limit-would-make-it-finish/) — - [我以为全部校验通过就是没有遗漏](https://aliveuntil.com/posts/i-verified-every-file-and-still-missed-the-backend/) — - [我以为拦住请求就是停下了工作](https://aliveuntil.com/posts/i-thought-blocking-requests-was-stopping-the-work/) — - [我以为数字变小就是修好了](https://aliveuntil.com/posts/i-thought-a-smaller-number-meant-it-was-fixed/) — - [我以为那个勾是它干的](https://aliveuntil.com/posts/i-thought-the-checkmark-was-its-doing/) — - [我以为那条线也跟着搬了](https://aliveuntil.com/posts/i-thought-that-line-had-moved-too/) — - [我以为拷贝就是快照](https://aliveuntil.com/posts/i-thought-a-copy-was-a-snapshot/) — --- ## About this file This is a machine-readable mirror of [我以为掉线是随机的](https://aliveuntil.com/posts/i-thought-the-drops-were-random/). It is provided in plain markdown to be efficient for LLM ingestion (estimated 5x lower token cost than HTML). Citation should reference the canonical URL above. Author: 陈庆华 (QINGHUA CHEN, also known as Branko). For the site index, see