What does the reason code in the WiFi disconnection log mean? I checked them one by one according to the table. 5 and 34 completely solved the case of two disconnections.

Last month, I cured the cell phone at home that was suddenly disconnected. The process is written here The article about WiFi intermittent Here, I looked through the log and saw that deauth and Zhonglian appeared in pairs, which was considered a real hammer. At the end of the article I said something: The string of numbers following deauth in the log is the real clue. Recently, the room layout at home was changed, and another mobile phone started to malfunction again. This time I was not satisfied with "seeing the dropped call record", so I checked the string of numbers one by one - only after checking did I realize that the same line of deauth could lead to a huge difference in the direction of the pot.

First put out that line of log. OpenWrt logread | grep -i deauth , what comes out looks like this:

Mon Nov 2 21:41:18 2025 daemon.info hostapd: wlan0: STA a4:c6:xx:xx:xx:xx IEEE 802.11: disassociated
Mon Nov 2 21:41:18 2025 daemon.info hostapd: wlan0: STA a4:c6:xx:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (reason 4)

The string after STA is the MAC address of the wireless network card of the mobile phone, the one in brackets reason 4 That's today's protagonist. It is the "disconnection reason code" defined in the 802.11 standard. Who initiated the disconnection and why it was disconnected are all encoded in this number. The numbers are different if the router kicks the phone, if the phone runs on its own, and if no one makes any mistakes and just follows the process. Knowing this code, you don't have to guess at vague descriptions like "your phone keeps getting disconnected."

Make a rule first: This number refers to "who initiated the breakup", not necessarily "whose fault"」

Correct this concept before looking up the table, otherwise it is easy to wrongly accuse people. The reason code in the deauth line of the log says: Which party initiated this disconnection and for what reason? , it records the process, not the trial. The router kicks off a silent device according to the rules, and the log writes reason 4. This does not mean that the router is broken. ； If the mobile phone feels that the signal is poor and automatically switches off, writing reason 3 or 34 does not mean that there is something wrong with the mobile phone. I suffered this loss from the beginning: When I saw reason 4 filling the screen, I thought the router was bullying the phone and almost ordered a new machine.

By analogy, this string of numbers is like the "initiating party" column on a divorce agreement. Who filed the divorce and what reason is written down. But where the blame lies for the breakdown of the relationship depends on the reason itself. So the correct usage is two steps: First look at who initiated the digital positioning, and then look at the reasons to determine where to fix it. Below, I will go over the most common codes at home in the order that I actually encountered them.

reason 4: The device is silent when kicked, 90% of the time it is in power saving mode

The official name of reason 4 is "Inactivity Timeout". The associated device will regularly send a small data packet to report that it is safe, which is called keep-alive in the jargon. Mobile phones especially send it frequently. After waiting for a long time and not receiving a single packet, the router determined that the device was lost and cleared it from the association table. Pay attention to a detail: When clearing it out, the phone will probably still show that it is connected to WiFi with a full grid of icons. It doesn't even know it has been removed from the list, and only realizes that it has to reconnect again when it wants to send data.

Reason 4 appears most frequently in my home when my old mobile phone is in power-saving mode and placed beside the bed to charge. After locking the screen, the system reduces the wireless network card's power consumption to extremely low, and the packets reporting safety can be delayed as long as possible, and the router will be kicked off if it cannot wait. If you count a string of reason 4 in your log and the time points are concentrated in the middle of the night, don't touch the router yet, and try turning off the WiFi power-saving switch of that phone. It costs nothing. netsh wlan show interfaces You can also get a rough idea on your laptop, I'm Interpret the netsh output article Wrote in. The principle of this is the same as that of the "default gateway is unavailable" network card power saving trick. The article about network card power saving There are detailed accounts.

reason 3 and 15: A pair of twins, one carries a mobile phone and the other carries a router

The names of these two codes are the same, both are called "Leave after negotiation between both parties", the difference lies in the initiator. The mobile phone proactively sends a deauth message saying I’m leaving, and the router records reason 3. ； The router actively sends deauth to let the other party go, and the mobile phone records reason 15. The boundary between 15 and 3 is the first clue to determine whether "the device is gone" or "the router is catching up".

reason 3 The most common trigger on mobile phones is roaming: The mobile phone feels that the signal of the current router is not good enough, or it finds a more suitable node, so it goes offline first and then comes online again. When it comes to families with Mesh networking, the proportion of 3 in the log is naturally high, which is a normal metabolism, so don’t worry if the amount is small. But if the mobile phone clings to a node that is almost out of signal, that is roaming stickiness, which is another matter. I am The article does not switch when roaming How to treat it if it has been removed. What you really need to be wary of is reason 15 that gets together.: That means the router is kicking people in batches. This will happen if the password is changed, new access control is enabled, or the restart process is performed. The night I changed my password, the whole screen was filled with 15 in the log. I came back to each device the next day and it was quiet.

reason 5 and 34: These two disconnected my house twice and completely solved the case.

Now to the point. The two solved cases mentioned in the title are these two codes.

reason 34, official name "lack of acknowledgment frame"」 . In wireless transmission, each data packet sent by the mobile phone requires the router to send back a small ACK confirmation frame. The mobile phone only considers the packet to be delivered after receiving it. The router failed to respond to several ACKs it should have responded to. The mobile phone determined that the link was unreliable and sent a deauth message on its own. Under what circumstances will the router fail to respond with ACK? Most of the time, the signal on the other end of the phone is actually so bad that the router can no longer hear what it is saying - pay attention to the direction. 34 is because the mobile phone thinks this road is bad and runs on its own, but the root cause is often two-way signal attenuation. . I later took the location of the faulty phone at home and read it. It was stable around -78dBm, with repeated jumps near the critical line. No wonder 34 appeared every now and then. How to read this reading, and what level is below it to be considered sick? -The 65dBm article There is a complete gear list inside. After moving the router location, -78 changed to -66, and 34 basically disappeared.

reason 5, the official name is "AP Overload」 . The router feels that it is too busy and actively kicks off some devices to reduce the load. I specifically called my friend who owns an Internet cafe to verify this code. I saw it when he had dozens of machines in his shop. ； It is generally out of reach for household use. but there is an exception: When there is an old device at home that competes for bandwidth, the processing pressure on the router will be concentrated and amplified. Let’s take a look first. The article about old equipment slowing down the entire network For troubleshooting, don’t rush to suspect the router itself. By the way, if 5 occasionally appears sporadically mixed in other codes, it can be ignored. If it appears in clusters, it is really overloaded.

A table collects the common codes, and you can start after picking the numbers.

Collect the codes that I have checked and those that actually appear in the logs at home into a list. The extremely popular codes that I have never encountered are not listed. Listing them is also bluffing.:

Just one sentence to explain the usage clearly: First, count which code appears the most, and then click the "Who initiated" column to decide whether to repair the device or the router. . The full screen 4 is used to save battery power on the mobile phone, the full screen 3 is used for roaming during the group time, the 15 is used to look back and think about what has been changed, and the 34 is just reading the signal honestly.

There is a stupid method for number distribution, which is more reliable than focusing on a single line

Just looking at one line of deauth means little. The truth about disconnection is hidden in the distribution. What I do is to capture the logs of a night and count the frequency. One line of OpenWrt command is enough.:

logread | grep -o "reason [0-9]*" | sort | uniq -c | sort -rn

What came out was a frequency table. For example, on my night, 4 appeared 23 times, 34 appeared 9 times, and 3 appeared 2 times. The two codes 4 and 34 together accounted for 90%. The combination of power saving and signal criticality was in perfect agreement with the subsequent actual measurement of -78dBm, and the conclusion that dropped calls were immediately reduced after power saving was turned off. The advantage of the frequency table compared to scanning the logs with the naked eye is that occasional procedural disconnections (like 1, 2, 7) will be naturally diluted, and the real culprit code will surface on its own.

Don’t forget to check the timestamp after counting the frequency. 4 episodes are concentrated in the middle of the night, 34 episodes are in the evening rush hour when the signal is crowded, and 15 episodes are after a specific moment - the time pattern intersects with the code, and the blame basically cannot escape. This method of "obtaining evidence first and then taking action" is what I'm talking about. Three-stage ping to locate packet loss The same idea is written in: Don't restart or change your phone when you see it's disconnected. Build up the chain of evidence first.

The original router cannot see the code, what should I do?

Not everyone uses OpenWrt. Most of the log pages of the original firmware only provide "device offline/online" and do not provide codes. There is no way to do this. The degree of tailoring varies from company to company. There are two ways to make do. One is to look at behavioral profiling: It goes off after locking the screen and returns immediately when the screen is turned on = high probability 4 (power saving) ； If it falls in a certain room, it will be stable if it is moved back to the living room = high probability 34 (signal) ； The whole family lost it at the same time = it’s not a matter of deauth level at all, check out the modem and broadband. The second is to install a tool on your laptop that can read wireless logs for one night. There are also disconnection records in WLAN-AutoSource of Windows Event Viewer. Although the granularity is coarse, the time stamp is enough for cross-validation.

There is another misunderstanding that is easy to avoid. Let me finish by mentioning it.: If the timestamp of deauth in the log suddenly clears and changes, it means that the phone is not disconnected, but the router has restarted itself. The event level is one level higher than the disconnection. Press first. Five-step troubleshooting for home network disconnection The order starts from the power supply. Look at the table first before reading the code, and count the distribution before taking action. After completing these two steps, most of the confusing accounts of "old mobile phones and WiFi" can be solved clearly.