Advanced premise and division of labour with the v1 article: this article covers advanced differentiation only, not basic troubleshooting
This article covers advanced differentiation, not basic troubleshooting. The v1 article, listed in the repository articles file as id 85 with the slug laptop-wifi-not-working-fix-hk and a Chinese title about a laptop that cannot connect to Wi-Fi or keeps disconnecting, already covers the basic layers: moving from symptoms through software to hardware, driver handling, hardware switches and related settings, basic wireless card and antenna checks, router versus laptop comparison tests, responsibility differentiation, temporary internet arrangements, danger signals, when to seek repair, and pricing references. If your laptop has not been through that basic check, read v1 first rather than jumping straight into the advanced judgements here. This article assumes one premise: the basic check has already been done, the problem is still present, and the symptoms concentrate in four advanced scenarios. The first scenario is only 5GHz dropping, or only 2.4GHz running slowly, with the two bands behaving completely differently. The second is full signal bars but no internet access, where the bar count and real internet capability have come apart. The third is disconnection only under load, normal when idle, but dropping when a large file transfers, a video meeting starts, or many people use the network at once. The fourth is disconnection only after waking, normal after a full restart, but failing after sleep or hibernation wake.
The division of labour must be stated clearly so readers do not mix the two articles together. V1 answers which layer has failed. This article answers which advanced variable inside that layer matters most. For example, v1 covers driver handling, so this article will not repeat basic driver reinstallation teaching; it will mention it in one sentence only where necessary and point back to v1, and then concentrate on the order of driver rollback versus BIOS or embedded controller updates, the compatibility gap between old drivers and new router standards, and how timing can separate a driver problem from an antenna problem. V1 covers hardware switches and related settings, so this article will not repeat switch teaching; it will cover why two different power management settings cause confusion, how brand power software can override Windows settings, and the advanced signs of antenna cable damage after a screen or hinge repair. V1 covers router versus laptop comparison, and this article pushes that comparison to a stricter form: change only one variable at a time, equalise the distance variable, separate the bands, separate the load state, and separate the wake state, and only judge when the full set is complete.
Source levels are stated up front and used throughout. Official documentation means support documents or explanatory pages from vendors or platforms. Official forums means question and answer communities operated officially, such as Microsoft Q&A and Intel Community, where a forum reply is not the same as a formal support document. Third-party guides means explanatory or comparison articles from technology media or parties other than the vendor, not original standard documents. Forum experience means user forum posts and personal experience sharing, usable only as a reference for the phenomenon, not as a conclusion. Any fact that is unconfirmed or disputed is marked as unconfirmed or explained as a disagreement in the text, never written as a conclusion, and never packaged as an official statement. The unconfirmed items table at the end collects the full lists from first group and second group, labelled separately by group, with the reason for each uncertainty explained. For a diagnostic check or a quotation, see the pricing page, or book the diagnostic service; only a diagnostic check can confirm a diagnosis, and the differentiation directions in this article are not a diagnosis.
Overview of the four advanced scenarios: identify the symptom first, then choose the chapter, rather than checking everything from the start
The most common error in advanced troubleshooting is checking everything from the start without identifying the symptom, changing several settings a little at a time, and ending up unable to say which change mattered. The correct starting point is to place the symptom in one of the four scenarios, or to recognise that it spans several scenarios at once, and then follow the corresponding chapter. The four scenarios are not mutually exclusive categories. One laptop can fit two at once, for example waking only to disconnect and also only losing 5GHz, or disconnecting only under load and also showing full bars but no internet. When symptoms span several scenarios, record the conditions for each scenario separately, rather than writing them as a single problem. The recording method is simple: each time a failure occurs, write down which band was in use, how far the laptop was from the router, how wide the screen was opened, whether it had just woken from sleep, whether a large transfer or video meeting had just started, and whether other devices failed at the same time. After a few records, the pattern emerges on its own, and that is far more reliable than judging from a single impression.
Each scenario has one most important observation question. For only 5GHz dropping or only 2.4GHz running slowly, the question is whether the band itself or the whole wireless path has failed. For full bars but no internet, the question is what the bar count actually reflects, versus which middle layer between the device and the internet has failed. For disconnection only under load, the question is which already marginal path the load pushed beyond its usable range. For disconnection only after waking, the question is whether the wake path or the router itself has failed. Each chapter in this article first explains the phenomenon and the mechanism, then explains the comparison test, and finally explains how to narrow the cause, without jumping to a conclusion at the start. Every comparison test shares one principle: change only one variable at a time, test immediately after the change, record immediately after the test, and never change several settings at once, because otherwise attribution becomes impossible.
| Advanced scenario | Most important observation question | Most likely misreading | Corresponding chapter |
|---|---|---|---|
| Only 5GHz drops, or only 2.4GHz is slow | Whether the other band is completely normal at the same moment, and whether time and location show a pattern | Treating band characteristics, DFS checks, and channel congestion all as router damage | Band, DFS, and channel width chapter |
| Full bars but no internet | Beyond the bar count, whether the device has a valid address, and whether the gateway and name resolution respond | Assuming full bars must mean the internet is normal, and ignoring the middle layers | Signal bars and middle layers chapter |
| Disconnection only under load | Whether it never appears when idle, or also appears occasionally when idle | Blaming every load disconnection on overheating or router overload | Load chapter, with possible kept in front of every direction |
| Disconnection only after waking | Whether a full restart is completely normal, or whether startup also disconnects | Treating a wake path problem as a router problem, or a router problem as a power setting problem | Power management and wake path chapter |
Only 5GHz drops, or only 2.4GHz is slow: band characteristics, interference, DFS checks, channel width, and roaming steering
The physical characteristics of 2.4GHz and 5GHz alone can explain many phenomena that look like faults. TP-Link official documentation states that 2.4GHz penetrates better and covers further, while 5GHz attenuates faster and passes through walls less well, so only 2.4GHz remaining at a distance or behind a wall does not by itself prove a fault. This characteristic also explains why the same laptop performs normally beside the router but only keeps 2.4GHz in a bedroom or study behind a wall. Before judging, move closer to the router and test again. If 5GHz returns when close, distance and wall penetration become the first suspicion, not immediate wireless card or router damage. Conversely, if 5GHz cannot be found even beside the router, only then should support, settings, and channel questions be pursued further.
Channel congestion is another band difference. TP-Link official documentation states that 2.4GHz has only three truly non-overlapping channels, namely channels one, six, and eleven, while 5GHz has roughly two dozen non-overlapping channels, although the exact number differs by region, as recorded in the unconfirmed items master table (first group) at the end, so this article will not present a single universal number. In dense residential surroundings, 2.4GHz easily becomes congested because of neighbouring networks and non-Wi-Fi interference sources. TP-Link official documentation names microwave ovens and older cordless telephones among the non-Wi-Fi interference sources for 2.4GHz, while the main sharing counterpart for 5GHz is radar and military bands, so the interference pattern is completely different and cannot be judged by the same method. When only 2.4GHz is slow, congestion and interference should be suspected first, rather than assuming the laptop itself has become slow. When only 5GHz drops, channel and DFS related mechanisms should be suspected first, rather than assuming the whole router has died.
The DFS mechanism is the most valuable part of 5GHz advanced differentiation. ASUS official guidance states that DFS is a legal requirement for part of the 5GHz bands, that a router must perform a Channel Availability Check before using a radar-shared band, during which the 5GHz signal is unavailable, and that the check can take from one to ten minutes depending on the country or region, while 2.4GHz remains available during that period. This mechanism directly explains a very typical phenomenon: after a router restart, 2.4GHz appears immediately, 5GHz appears only after a delay, or 5GHz disappears intermittently while 2.4GHz stays online. During normal operation, if radar is detected, the router must stop transmitting on that channel and move to another available channel, during which already connected clients briefly disconnect and then reconnect. A second-hand guide suggests that a wide-channel network may fall back to a narrower channel after a radar event, but that point was not verified word for word against the ASUS original text, as recorded in the unconfirmed items master table (first group), so this article will not present it as a conclusion.
Channel width also affects stability. Third-party guides state that 2.4GHz channel width is generally narrower, and a wider setting on that band is more likely to cause problems, while 5GHz can use several widths from narrow to very wide, where a wider channel offers greater speed potential but occupies more spectrum and is affected by DFS over a wider area. A very wide channel is formed by bonding several narrower channels, and in the United States 5GHz example it often spans intervals that touch the DFS range, so intermittent disconnection that starts when a wide channel is enabled and stability that returns when the wide channel is disabled is a differentiation clue worth recording, but it does not prove that every case is caused by radar. Forum experience includes similar cases where stability returned after disabling a wide channel, but forum experience is only a phenomenon reference, not a causal conclusion. The practical differentiation advice is to test separately: separate the network names for 2.4GHz and 5GHz, or fix one band at a time, and record the time and location when only one band fails while the other stays normal. If 5GHz only appears some time after a router restart, suspect the channel availability check process. If 5GHz disappears intermittently while 2.4GHz stays online, check the router log for radar or channel change records.
Roaming and band selection authority is another common misunderstanding. The Zyxel official forum states that the final decision for roaming or band selection lies mainly with the client device, not with the access point, and access point settings can only influence the client decision by changing the signal environment and the available options. TP-Link official guidance also states that band steering is designed to steer dual-band clients preferentially toward 5GHz, using a maximum connection threshold for 5GHz and a client count difference threshold between the two bands as the conditions for continued steering, and steering is no longer forced once a threshold is reached. Taken together, these two points explain why the same laptop sometimes stays on 5GHz and sometimes falls back to 2.4GHz, which is not necessarily router failure, but may be a client choice based on signal and load. When differentiating, fix the band and test again, so steering and roaming variables are removed before judging whether the band itself has a problem.
Full bars but no internet: a signal bar is not speed, and even less proof of internet access
Full bars but no internet is the advanced scenario most likely to mislead, because the bar count gives a false impression of connection. Third-party guides state that a signal bar only reflects a rough indication of signal strength with the access point, not speed, and even less proof of internet connectivity. Windows signal bars and percentage or signal strength values are expressions at different levels of precision, and full bars do not mean bandwidth is sufficient, or that name resolution and gateway behaviour are normal. It must also be stated that there is no unified standard for converting bars to percentages. One third-party guide suggests each bar represents a certain percentage, but that conversion appears only in a single third-party guide, with no Windows official definition found, as recorded in the unconfirmed items master table (first group), so this article will not present it as a Windows official definition. In practice, treat the bar count only as a preliminary reference, and use middle layer checks for real differentiation.
Middle layer differentiation can be divided into three layers, and this article only summarises them briefly, because the basic steps appear in v1 and this section only provides the advanced bridging logic. The first layer is the device address. A device connected to router Wi-Fi does not mean the router already has outward internet access. If the device obtains an address beginning with 169.254, that means it failed to obtain a valid address from router dynamic address allocation, and TP-Link official documentation uses this as a first check. That signal points to the address allocation path between the device and the router, rather than directly to the internet provider. The second layer is the gateway. Check whether the device has a default gateway, usually the router local network address, and try to confirm whether the gateway responds. No gateway response points to the path between the device and the router, while a gateway response with no outward response points to the router outward network or provider side. The third layer is name resolution. Being able to reach a public internet address directly but not open a domain website points to a name resolution problem, while failing to reach even a public internet address points beyond the gateway or to the router outward side, requiring further layering.
For temporary comparison, several sources mention temporarily using a public name resolution service to distinguish whether the original name resolution server or the whole connection has failed, but this article must remind readers to restore the original setting afterwards, and to note the original value first. That comparison is only a differentiation tool, not a long-term setting recommendation, and even less an instruction to adopt one particular public service permanently. The advanced significance of full bars but no internet is that it forces troubleshooting to move from the signal layer to the middle layers: a normal signal layer does not mean the address, gateway, and name resolution layers are all normal, and a failure in any one of those three layers can present on the surface as full bars but no internet. After differentiation, run the mobile hotspot comparison again to see whether the problem follows the device or follows the network, and that comparison is explained in detail in the next chapter.
Separating the router side from the laptop side: the mobile hotspot comparison, changing only one variable at a time
Separating the router side from the laptop side follows a simple core logic: change only one variable at a time, change the connection without changing the device, and see whether the problem follows the device. Third-party guides state that if the same laptop becomes clearly faster after switching to a mobile hotspot or another Wi-Fi network, the original home Wi-Fi connection path deserves deeper checking, while if it remains slow, the device itself, its software, or the service in use becomes more likely. Another third-party guide adds that if a problem device can go online on a hotspot but not on home Wi-Fi, that points to a setting or compatibility issue with the home network, rather than proving the device is fault-free or the router is already damaged. Success elsewhere only shows that the device and the internet can work together under those conditions. That distinction matters greatly, because many misjudgements come from reading one hotspot success directly as the device being fault-free or the router being dead, and both readings go too far.
Changing the device on the same network is the comparison from the other side. A Microsoft official forum case states that on the same home Wi-Fi, if other devices are normal while only one laptop fails, the problem is more likely concentrated in that laptop, while if several devices fail at the same time, the router or network side becomes more likely. A wired comparison extends the same logic: if the device has a wired network port, and a wired direct connection to the router works normally while wireless does not, that points strongly to the wireless path, including band, security mode mismatch, driver, or interference, rather than the whole connection being dead. Wired normal with wireless abnormal does not mean the router has died, and it does not mean the laptop has died; it only narrows the range from the whole connection to the wireless path, after which band, setting, and device variables still need separation.
The mobile hotspot comparison has one very important limitation that must be stated, or the comparison result will mislead. In a Microsoft Q&A case, the responder noted that normal hotspot behaviour with poor router Wi-Fi may reflect signal difference caused by router position or distance, rather than router damage. A mobile hotspot is usually very close to the laptop, so the signal distance factor itself is already different. If the hotspot test places the phone beside the laptop, while the home Wi-Fi test places the laptop in a room behind a wall, the distance variables in the two tests are fundamentally different, and the comparison becomes meaningless. A methodological suggestion drawn from that limitation, marked in this article as a testing method suggestion rather than vendor original text, is to equalise the distance variable with the original router as far as possible when comparing, for example by moving the laptop close to the router and testing home Wi-Fi again, or by recording the distance during the hotspot test, so that closeness being faster is not misread as the router being faulty.
Testing bands separately follows the same logic. On the same router, the same laptop should test 2.4GHz and 5GHz one at a time, and if the router allows separate network names or fixed bands, that can separate a band problem from a whole router or whole laptop problem. If only 5GHz cannot be found, both whether the laptop supports 5GHz and whether the router is using a DFS channel should be suspected at the same time. Forum experience suggests manually fixing router 5GHz to a non-DFS channel as a comparison, but that method was not verified item by item against official documentation, as recorded in the unconfirmed items master table (first group), and should not be written as a universal solution. One common explanation for a single device having no 5GHz is that the wireless specification of some devices only supports 2.4GHz, or their driver or firmware does not support the DFS channel in use at that moment, and that possibility cannot be excluded before checking the specification.
| Comparison combination | Device | Network | Reading direction |
|---|---|---|---|
| Same device, different network | Same laptop | Home Wi-Fi switched to a mobile hotspot | Hotspot normal with home abnormal points to the home network path for deeper checking; both poor points to the device, software, or service path |
| Same network, different device | Several devices in turn | Same home Wi-Fi | Only one device failing points to that laptop; several devices failing at the same time points to the router or network side |
| Wired comparison | Same laptop | Wired direct connection to the router versus wireless | Wired normal with wireless abnormal points to the wireless path, not to the whole connection being dead |
| Separate band comparison | Same laptop | Same router, testing 2.4GHz and 5GHz one at a time | Only one band failing points to a band, DFS, channel, or support problem, not to the whole device or whole router |
Wi-Fi 6, Wi-Fi 6E, and Wi-Fi 7: band, encryption, driver, and mode fallback compatibility boundaries
The band comparison across Wi-Fi generations must be separated clearly first. Third-party guides state that Wi-Fi 6 covers 2.4GHz plus 5GHz, Wi-Fi 6E adds 6GHz on top of Wi-Fi 6, and Wi-Fi 7 likewise covers 2.4GHz, 5GHz, and 6GHz. That comparison already explains much disappointment after a router change: replacing the router but seeing no improvement on an old laptop does not mean the router is faulty, because an old device can only connect at its own highest capability. A Wi-Fi 6E router is itself a tri-band device supporting 2.4GHz and 5GHz at the same time, so old devices can still connect on 2.4GHz and 5GHz, just without the benefit of 6GHz. Wi-Fi 7 introduces wider channels, higher order modulation, and multi-link operation across bands, but realising its full capability requires both the router and the client to support the new standard, and replacing only the router will not give an old laptop Wi-Fi 7 speed. These are third-party guides, and they should not be written as original standard document text.
6GHz is a hardware threshold, not a pure software upgrade. Third-party guides state clearly that an old standard device without 6GHz radio cannot see the 6GHz band, and that 6GHz not being backward compatible with older devices is a hardware limitation rather than a firmware limitation. That boundary matters greatly, because it decides which problems are worth pursuing and which should not be pursued at all: if the wireless card in a laptop does not support 6GHz, no driver update and no router setting change will make 6GHz appear. On the Windows platform, taking one Intel 6E wireless card as an example, a third-party guide reporting Intel states that 6GHz requires a newer Windows version with the latest updates, a driver version reaching a certain threshold, a Wi-Fi 6E router, local permission for 6GHz, and activation by some laptop vendors, while an older Wi-Fi 6 card does not support 6GHz at all. That driver version threshold appears only in a single third-party guide reporting Intel, without the Intel official driver note checked in the original, as recorded in the unconfirmed items master table (first group), so any citation must be marked as reported, and the current latest version must be checked at the time.
Encryption mode is the second gate for 6GHz. Several sources agree that the 6GHz band requires a newer encryption standard (WPA3), and if the network still uses the older encryption standard (WPA2), only 2.4GHz and 5GHz will be available, and 6GHz will not appear (in other words, older devices that support only WPA2, and older encryption networks, cannot use 6GHz). The Wi-Fi Alliance requirement for newer encryption (WPA3) certification on Wi-Fi 6E devices operating on 6GHz, with no backward compatibility for the older encryption (WPA2) on 6GHz, appears in this research only through third-party guides reporting the requirement, without the Alliance original document link attached, so this article avoids writing it as if the Alliance original had been read. In practice, after replacing a router with a 6E model but seeing no 6GHz, WPA3 encryption settings should be checked first, rather than suspecting wireless card damage first. Likewise, updated drivers and firmware do not guarantee connection: in an Intel Community case, a user who had already updated the system, BIOS, and driver still could not connect to 6GHz, showing that updated does not mean certainly connected, and router settings, network security mode, and device settings must each be checked in turn.
Conflict between old devices and new encryption has a transitional compromise that must be explained clearly. If a router forces new encryption (WPA3) only, older encryption (WPA2) only devices cannot join. The compromise is a transition mode (WPA3 Transition Mode), letting new devices use new encryption (WPA3) and old devices use old encryption (WPA2), but transition mode itself is not the same security level as new encryption (WPA3) only. Transition mode is also not a cure-all: a second-hand guide citing a vendor document states that some older system versions and some devices using a particular chip had connection difficulty on WPA3 Transition Mode networks, and suggests a separate older encryption (WPA2) only network for old devices, but that list is a single second-hand report, as recorded in the unconfirmed items master table (first group), and should not be written as a verified complete incompatibility list. Older Intel wireless cards also show a gap: an Intel Community discussion states that one older wireless card technically supports new encryption (WPA3), but in practice easily disconnects repeatedly on some routers or mixed security modes, and becomes stable after returning to older encryption (WPA2), with suggested actions including WPA2/WPA3 mixed mode and driver updates, but that is community experience, not an Intel official conclusion.
| Generation | Bands | 6GHz threshold | Old device behaviour |
|---|---|---|---|
| Wi-Fi 6 | 2.4GHz plus 5GHz | No 6GHz | Connects at its own highest capability, and will not become faster because the router is newer |
| Wi-Fi 6E | 2.4GHz plus 5GHz plus 6GHz | Requires 6GHz capable hardware, a newer system and driver, WPA3 encryption settings, and local permission | Can still connect on 2.4GHz and 5GHz, just without the benefit of 6GHz |
| Wi-Fi 7 | 2.4GHz plus 5GHz plus 6GHz | Both ends must support the new standard to realise full capability | Replacing only the router will not give an old laptop new standard speed |
| Mixed network | Several generations coexisting | Older mode protection mechanisms may add extra overhead | Overall efficiency may be dragged down, which does not mean an individual device is faulty |
Disconnection only under load: six possible directions, all only possible, never asserted
This section on disconnection only under load must start with its writing red line: every direction in the whole section must keep the word possible in front of it, and assertive phrasing such as it is definitely because of overheating or certainly because the router cannot handle the load must not appear, nor may any percentage or statistical figure from third-party guides in this section be cited as evidence, because the original research source for complaint proportions mentioned in individual articles was not verified in this research. That red line is not a style habit, but an evidence level issue: load disconnection causes overlap to a very high degree, covering heat, router load, driver, power supply, interference, and setting residue, with symptoms that can be completely identical, so symptoms alone cannot separate which one is the main cause. The correct approach is to record observation conditions, then compare each direction in turn, rather than choosing the most comfortable explanation and treating it as the cause.
Need a laptop repair expert?
Free diagnosis · Transparent pricing · No fix, no fee · 180-day warranty
Possible direction one is heat. An Intel official community user case states that under high heat, Wi-Fi suddenly disappeared and required a complete shutdown and cooling for several minutes before recovering, and that user also suggested that an old machine under high heat might show abnormal motherboard power circuitry. That is a single user experience, not an Intel official conclusion, and it can only be written as a case where a user reported Wi-Fi disappearing under high heat. Possible direction two is router load or overheating. Third-party guides state that when many devices stream, download, or play games at the same time, router burden increases and overheating may lead to disconnection or slowing, with suggested directions including improving router ventilation and reducing simultaneous high load devices. That is only a possible direction, not a proven cause, and it cannot yet separate overheating from excessive load, insufficient bandwidth, and interference, as recorded in the unconfirmed items master table (second group). Possible direction three is driver instability under high load. Third-party guides list an outdated driver failing to handle high load well as one possible cause, alongside interference and old card hardware limits, but that statement has no specific driver version or test data behind it, and can only be written as a possible direction.
Possible direction four is power supply or power management intervening under high load. Third-party guides state that downloading a large file takes a long time, and if power management turns off the wireless card during that period, the download is interrupted. A forum case about disconnection while downloading large files was advised to set the wireless adapter power saving mode to maximum performance as a test, but the responder in that case stated that it had already been tried, with no change. That means power management is only one possible direction, and there is already a counterexample, so it cannot be written as certainly effective. Possible direction five is signal interference and distance being amplified under high load. Third-party guides state that neighbouring networks, Bluetooth devices, microwave ovens, and other interference sources, together with router distance and wall obstruction, make high load problems more obvious. That possible direction must be distinguished from router load itself: one is interference in the air, the other is load on the router, and their test methods differ, with the former requiring a position or band change, and the latter requiring fewer simultaneous devices or better ventilation. Possible direction six is network setting or protocol layer residue. One third-party guide states that for large file download disconnection, some user experience suggests resetting network protocols, firewall settings, Winsock, and clearing name resolution cache may help, but that is user experience level possible direction, and cannot be written as a guaranteed repair.
The observation method for load disconnection is test logic summarised in this article, not a source conclusion. First, record whether disconnection appears only during large file transfer, video meetings, or many people using the network at once, and never appears when idle. Second, whether other devices disconnect at the same time: if they disconnect together, the router or network side becomes more suspect; if only one machine disconnects, machine heat, driver, or power supply becomes more suspect. Third, whether cooling is required before recovery: if cooling is required, the heat direction deserves further checking. These three points are only observation methods, not diagnostic conclusions, and even less can one of them alone determine a cause. The advanced significance of load disconnection is that it reminds readers that a normal idle test does not mean a normal load test, and a normal close range test does not mean a normal distant test, and a comparison result under one condition cannot be generalised to all conditions.
Disconnection only after waking: two different power settings, Fast Startup, brand software, and one direct contradiction
Typical symptoms of wake disconnection, according to several official forum cases, include the Wi-Fi icon disappearing after waking, the Wi-Fi option not appearing, or showing as connected but with no internet access, with some answers stating that sleep sometimes prevents the wireless card from reinitialising correctly. The first differentiation clue is timing: if the problem appears only after waking and a full restart returns to normal, the power or wake path should be suspected first rather than the router itself, while if disconnection occurs at startup and at any time, power management becomes a secondary suspicion. That timing summary is differentiation logic summarised in this article based on symptom timing, not an original sentence from any source, but it is the most practical starting point in the whole chapter, because one simple test, namely a full restart comparison, already separates a wake path problem from a persistent failure.
Two different settings inside power management are most easily confused. The first is the power management tab in the wireless card properties inside Device Manager, with the option text Allow the computer to turn off this device to save power. The second is the wireless adapter setting inside the power plan, further divided into a power saving mode with three levels: maximum performance, balanced, and maximum power saving. These two settings are not the same switch, and changing the wrong one makes the test result meaningless. Intel official documentation lists the three power plan levels, warns that the default should not be changed casually, or faults or connection problems may result, and notes that using maximum performance on battery will drain power faster. Official forum suggested practice, as a test method, is to set the wireless adapter power saving mode to maximum performance for both the battery and plugged-in columns, and another suggestion is to set PCI Express link state power management to off as a test. These are test methods, and after testing, results should be recorded, rather than treating a test setting as a permanent formal setting.
The direct contradiction must be presented in full, and neither side may be presented alone. Intel official documentation states clearly that the Device Manager Allow the computer to turn off this device option has no effect on Wi-Fi power management, that it only affects how Windows and the driver handle device power-down during suspend or hibernation, and that it strongly recommends keeping the default checked setting. At the same time, a large number of Microsoft Q&A answers still recommend unchecking that option to solve disconnection after sleep or automatic Wi-Fi disabling, as a common troubleshooting step. The two sides directly contradict each other, and no ruling can be made, as recorded in the unconfirmed items master table (second group). This article only lists both positions plus a practical testing suggestion, and will not assert one-sidedly that unchecking definitely works, nor assert one-sidedly that unchecking definitely does nothing. The practical testing suggestion is: note the original setting before changing, then test each of four states after the change, namely waking, full restart, plugged-in, and battery, and record in which states recovery occurs and in which states disconnection persists. If the change makes no difference, restore the original setting, rather than leaving an ineffective change on the machine.
Fast Startup is another wake path. Microsoft Tech Community and Microsoft Q&A both suggest that turning off Turn on fast startup can stabilise behaviour after waking, because Fast Startup preserves system state, which sometimes conflicts with wireless card reconnection. The test method is to turn it off and then verify with a restart, rather than shutdown followed by power on. The key point of that test method is that restart and shutdown followed by power on are not equivalent under Fast Startup, and confusing the two reverses the test result completely. A special note for Windows 11 is that a Microsoft Q&A discussion states that on some models under Windows 11, the power management tab may not be visible in wireless card properties, and the alternative path is a group policy setting allowing network connectivity during connected standby, for plugged-in and on battery, set to enabled. That approach only applies to editions with a group policy editor, and the applicable edition range was not fully stated in the source, as recorded in the unconfirmed items master table (second group), so this article notes that it depends on model or edition.
The role of brand power software also cannot be generalised. A Lenovo older power manager document states that its power plan includes wireless power saving mode and PCI link state power management settings, proving that brand software can override or additionally provide settings beyond the Windows power plan. A Dell power manager official page states that its functions concentrate on battery information, advanced charge, peak shift, thermal management, and battery extender, with no explicit statement of directly controlling Wi-Fi power saving options. Lenovo also states that the Lenovo power and battery driver is a dependency for Lenovo Vantage power functions, formerly the Lenovo power manager driver. Whether brand power software changes Wi-Fi settings must therefore be checked brand by brand and model by model, and cannot be generalised. The MSI official FAQ position differs from Intel: MSI recommends setting the power plan to high performance and the wireless adapter power saving mode to maximum performance for both battery and plugged-in, to prevent unexpected disconnection and sudden speed drops. That contrasts with the Intel warning against changing defaults, so this article writes it as a disagreement among vendor recommendations, rather than a single instruction. Readers seeing different vendor recommendations should first note their own model brand software settings, then compare with Windows settings, to see which level actually takes effect.
VPN, proxy, and firewall hijacking: residue after disconnection, stopping only one item at a time, and turning it back on immediately after testing
No internet after a VPN disconnects is the hijacking scenario most likely to be mistaken for router failure. Third-party guides state that after a VPN connection, the system may retain incorrect routing or name resolution settings, leaving browsers and programs unable to go online, and common repairs include resetting network protocols and Winsock, releasing and renewing the address, clearing the name resolution cache, and restarting. That mechanism explains why the whole machine still has no internet even though the VPN is already disconnected: the tunnel is gone, but the settings left by the tunnel remain. The first differentiation question, from a vendor support suggestion, is whether internet access was normal when the VPN had never been connected, together with the simplest Wi-Fi toggle or restart first. If there was no internet even without ever connecting a VPN, the problem is not VPN residue. That question looks simple, but it already excludes the whole VPN direction, saving many pointless tests.
Kill Switch is the first item to exclude. Several sources agree that a VPN Kill Switch is intended to block all traffic when the VPN disconnects, to prevent leakage, but if the VPN program crashes, fails to rebuild the tunnel after waking from sleep, or the Kill Switch is not correctly reset, it creates the false impression that the VPN is disconnected but the whole machine still has no internet. The test method is to temporarily turn off Kill Switch and try again. Kill Switch defaults, reset behaviour, and whether manual turn-off is required differ across VPN vendors, and this research did not verify vendor documents one by one, as recorded in the unconfirmed items master table (second group), so this article uses the generic wording of checking the Kill Switch of the VPN you use, and cannot state the default behaviour of any particular vendor. The Microsoft Q&A handling order after VPN disconnection includes first checking VPN connection properties and advanced settings, unchecking use default gateway on remote network, then performing a network reset, and then uninstalling in Device Manager and restarting so Windows reinstalls the wireless card driver. That order moves from lighter setting checks to heavier resets, and should not jump straight to network reset, because network reset clears custom settings and belongs as a last resort.
Name resolution residue differentiation also needs layering. Third-party guides state that name resolution settings not correctly restored after VPN disconnection are a common cause, and test directions include clearing the name resolution cache, and returning network protocols to automatic address and name resolution, then trying again. For proxy setting checkpoints, HP official community states that the Windows path is settings, network and internet, proxy, ensuring automatically detect settings is on and use a proxy server is off, unless the organisation itself requires a proxy, while on macOS the network advanced proxies page should confirm no proxy is enabled. One third-party guide states that Windows has two proxy systems, one used by the settings application and browsers, and one used by background services, and that toggling only in the settings application affects only the former, while the latter requires a command to clear. That statement appears only in a single third-party guide, with no Microsoft official document directly verified in this research, as recorded in the unconfirmed items master table (second group), so this article downgrades it to a third-party guide statement, and reminds readers that organisation proxy settings must not be cleared without authorisation.
The one-by-one exclusion method for firewall and security software is the part of this chapter that most requires discipline. HP official community and several third-party guides agree on stopping only one item at a time, testing immediately after stopping, and turning it back on immediately after testing: first stop third-party antivirus or firewall and test, then stop Windows Firewall and test. If recovery follows stopping one item, that software is locked in, and the browser or network should then be allowed inside its settings, rather than leaving protection off long term. Partial functions of security software can also hijack traffic: third-party guides state that antivirus software with web filtering or secure scanning functions sometimes checks traffic through a local proxy and triggers proxy or connection errors, and in that case disabling that specific function rather than the whole antivirus is often enough for differentiation. At the browser level, proxy or name resolution interference also exists: if only one browser fails, check its secure name resolution setting and suspicious extensions, while other browsers each have their own secure name resolution settings for comparison testing.
| Exclusion step | What to do | How to judge | Caution |
|---|---|---|---|
| Check Kill Switch | Temporarily turn off the VPN Kill Switch and try going online | Recovery after turning it off points to Kill Switch residue blocking | Vendor defaults and reset behaviour differ, so check against the VPN you use |
| Fully exit the VPN and restart | Exit the VPN program, restart, and try again | Recovery after restarting points to VPN residue settings or a tunnel not rebuilt | Restart and wake from sleep are not equivalent, so verify with a restart |
| Check proxy settings | Check system proxy settings and ensure no extra proxy is enabled | Recovery after returning to automatic points to proxy residue | Organisation proxy settings must not be cleared without asking organisation IT |
| Stop one security item at a time | First stop third-party antivirus or firewall, test, turn it back on, then stop the system firewall | Recovery after stopping one item locks in that software or that function | Protection must never be left off long term; after locking in, change to an allow setting |
| Reset protocols and name resolution | Reset network protocols, Winsock, release and renew the address, and clear the name resolution cache | Recovery after resetting points to routing or name resolution residue | Network reset is a last resort, because it clears custom settings |
Antenna cables after a screen or hinge repair: angle, distance, and timing as three signs
The routing position of laptop Wi-Fi antennas is the key background for this chapter. Several forum cases agree that laptop Wi-Fi antennas run from the body through the screen hinge to the screen bezel or top cover, and during long term hinge opening and closing, or during repair disassembly, antenna cables can easily be pinched, crushed, or pulled loose. That routing design itself creates a natural link between screen or hinge repair and Wi-Fi problems: repair requires opening the screen or hinge area, and antennas pass exactly through that area. A link is not causation, and timing is the first differentiation step: if a Wi-Fi problem first appears after a screen or hinge repair while it was normal before, suspicion of antenna routing damage should rise; conversely, if the same symptom already existed before the repair, the repair alone should not be blamed. That timing summary is timing reasoning in this article, not an original source sentence, but it is the most basic defence against misattributing repair responsibility.
Hinge angle related symptoms are the most valuable differentiation sign. In one brand case, Wi-Fi was normal when the screen was opened gently, but froze or disconnected immediately when opened too wide, and the responder pointed directly to the hinge antenna as possibly damaged with unstable contact, noting that frequent hinge movement pinching cables is common. That symptom has differentiation value because driver problems, router problems, and setting problems do not disconnect immediately just because the screen is opened a little wider. Angle testing should be done very gently and slowly, recording which angle range is normal and which angle range starts disconnecting, without forcing the screen to provoke a symptom, because forcing itself may cause further damage. Angle and driver comparison should be done on the same network, at the same location, and under the same load state, or angle variables mixed with other variables make the result meaningless.
Distance related symptoms are a second strong sign. In one forum case, after a hinge loosened, Wi-Fi fell to one bar even when sitting beside the router, and nearby Wi-Fi networks could not be found, while using a phone as a hotspot, the closer the phone was to the laptop or screen, the stronger the signal, and moving it away dropped it to one bar. Another forum also has a case normal only very close to the router, with the responder judging antenna disconnection or loosening. The common point of these symptoms is an overall drop in signal reception ability, rather than one band or one network failing. Single antenna failure presentation needs careful wording: one forum reply states that laptops generally have two antennas connected to the Wi-Fi module, and if only one fails, the other can still maintain a connection, so a single failure may not show extreme symptoms, and only when both fail does the typical only close to the router pattern appear. Another forum case shows that a single cable pressed by a screw at the hinge still allowed Wi-Fi to work, but sometimes fell back to a slower standard. The two symptom ranges do not completely agree, as recorded in the unconfirmed items master table (second group), so this article will not set a unified rule that single side failure equals a particular symptom.
For physical evidence, in one model case, a user opening the machine personally saw the white main antenna and black secondary antenna already disconnected at the hinge, noting that both cables passed through or close to the left hinge. Another forum answer also states that a cable worn at the hinge cannot be rejoined in its original form, and the whole antenna assembly and hinge unit need replacement. A third-party guide reminds readers that only after trying network and power settings, while Wi-Fi still shows only one bar or zero bars, should antenna damage be suspected, listing antenna cable loosening from the Wi-Fi card and Wi-Fi card damage itself as two checkpoints. That source does not distinguish the hinge position from the card end, so this article should not write it as direct evidence for hinge diagnosis. The most direct physical check is whether the antenna connector on the wireless card has loosened: forum sources state that antenna connectors are held by friction on the round socket of the Wi-Fi card, and pressing a loosened connector back is a common and easily handled cause. Opening a machine for inspection itself carries risk, so readers should not open a machine without a diagnostic arrangement, and this article only explains differentiation logic, not disassembly steps.
| Differentiation clue | Antenna problem more likely | Driver problem more likely |
|---|---|---|
| Opening angle | Angle change causes disconnection or freezing, with a particular angle range markedly worse | Unrelated to opening angle, with consistent behaviour at any angle |
| Distance | Normal only very close to the router, with only one bar even beside the router | Unrelated to distance, with near and far differences matching normal signal attenuation |
| Network range | Nearby networks cannot be found, or all network signals are extremely weak | A specific network fails, while other networks are normal |
| Driver reinstall or rollback | Symptoms unchanged after reinstall or rollback | Symptoms change after reinstall or rollback, with timing matching a driver update |
| Device Manager | Generally no warning, with the problem concentrated in signal reception | Possible warning, or consistent failure across all networks |
Driver rollback versus BIOS or embedded controller updates: order decided by risk and reversibility
The order of driver rollback versus BIOS or embedded controller updates should not be decided by feeling, but by risk and reversibility. Third-party guides state that a BIOS update affects the motherboard and startup process, with an interruption carrying a bricking risk, while a driver update only affects individual hardware, is safer, and is easier to roll back. Another third-party guide also contrasts them: BIOS risk is higher, update frequency is lower, and impact is system wide, while driver risk is lower, update frequency is higher, and impact is limited to individual devices. That risk grading already decides the broad order: low risk and reversible steps first, high risk and hard to reverse steps later, and the latter only when clear conditions are met. Placing a high risk step first is the most common order error in advanced troubleshooting.
When to roll back a driver first is a judgement on which several sources agree. V1 already covers basic driver handling, so this article only covers advanced timing judgement, without repeating basic teaching. If a Wi-Fi problem appears immediately after a driver update, roll back first. Microsoft Q&A suggests using Device Manager, network adapters, the target wireless card, and the driver tab Roll Back Driver button. If the button is greyed out, Windows has kept no older driver, and the older version must instead be downloaded from the computer or wireless card vendor official website, then installed by browsing the computer for drivers. If rollback does not work, the next level actions include trying older drivers one by one from a manual selection list, or uninstalling the device and restarting so Windows reinstalls, and there is also a suggestion to use system restore to return to a point before the problem appeared. All of these actions belong to the driver level, with lower risk and higher reversibility, and they should be completed before considering BIOS.
When to consider BIOS must be stated strictly. Third-party guides state that BIOS should only be considered when a vendor explicitly lists a new BIOS as fixing the problem you are experiencing, or new hardware requires a new BIOS for support, or the update occurs within a controlled maintenance window, and the common position across several sources is that a stable system should not be updated just for the sake of updating. That position downgrades BIOS updating from a routine step to a conditional step: without explicit vendor correspondence, BIOS should not be updated for Wi-Fi disconnection. The new machine or new build order disagreement belongs to forum experience, as recorded in the unconfirmed items master table (second group): one view holds that a new build should install the operating system, updates, and drivers first, and only update BIOS at the end if needed, while another view holds that if an update is necessary, it should occur before the operating system is put into use, and by USB update rather than an in-system updater. That disagreement applies only to a new build situation, and should not be applied directly to a repair situation where a machine in use suddenly disconnects from Wi-Fi.
Pre-update backup principles for BIOS belong to several sources in agreement. Back up important data, keep the laptop connected to power, with some sources also requiring sufficient charge, use only a file exactly matching the model and version, and never interrupt power, shut down, or move the computer during the update. Special requirements for embedded controller updates come from official documents: one vendor official guide requires before an embedded controller or BIOS update, a certain battery charge level, connection to power, and resetting BIOS to defaults, warning that a wrong file can permanently damage the device and an interrupted update can damage the device, while another vendor official support also requires a charged battery, connected power, and no manual shutdown or movement during the update. An embedded controller is a microcontroller inside a laptop responsible for basic controls such as keyboard input, battery charging, and fan control. One vendor official FAQ states that embedded controller firmware versions should match the version noted in BIOS release notes, and on one product line, embedded controller firmware can only be updated together with a particular BIOS update method. That statement targets a particular product line, and cannot be generalised directly to all laptops, as recorded in the unconfirmed items master table (second group).
The suggested order summarised in this article is not an original sentence from any source, but it turns risk grading into a followable flow: first, driver rollback or reinstallation, low risk and reversible; second, software exclusions covering power, VPN, and proxy; third, BIOS or embedded controller updates only when vendor release notes explicitly correspond to the symptom, and after backup with power connected, high risk and hard to reverse. BIOS or embedded controller updates must never be the first step for Wi-Fi disconnection. That order also explains why this driver rollback chapter appears so late in this article: not because drivers are unimportant, but because basic driver handling already appears in v1, and this article must address the choice of order between driver and BIOS, rather than repeating basic teaching.
Company or school networks: captive portal login pages versus 802.1X identity authentication, with completely different symptoms
The largest difference between company or school networks and home networks is not speed, but the logic for granting access. Home Wi-Fi usually needs only one shared password, and connection gives internet immediately. A company or school network using a captive portal shows as connected but with no internet until the login page is completed, while a network using 802.1X shows as failing to connect at all or repeatedly asking for authentication, rather than connecting and then having no internet. That symptom comparison is a comparison summarised in this article from sources, presented here as a symptom comparison, rather than asserting that every enterprise network belongs to one of the two types. The first differentiation step is always to ask whether the machine is normal on a home network. Normal at home but abnormal on an enterprise network does not mean the machine has a problem, while abnormal on both home and enterprise networks should then raise suspicion about the device itself.
The nature of a captive portal is that the network requires login or acceptance of terms before granting internet access, and blocks secure websites before login. The browser shows a message that the network in use may require visiting its login page, and pressing connect and completing login grants access. A login page that does not appear is the most common blockage. Mozilla official support states that if the browser does not show a login page, try browsing any website to trigger a redirect, disconnect and reconnect Wi-Fi, restart the device, temporarily turn off VPN or proxy, and use a private window to avoid a cached session. Other third-party guides add countermeasures including turning off browser pop-up blocking, clearing the name resolution cache, directly using a plain hypertext transfer protocol address to trigger the login page, or directly entering the default gateway address. Those countermeasures run from light to heavy, and should be tried one at a time with a record each time, rather than changing everything at once.
The nature of 802.1X is that an enterprise network uses identity authentication, verifying user or device identity through the organisation authentication infrastructure, rather than a home style shared password. The certificate or account differentiation point is a comparison summarised in this article from captive portal and 802.1X sources: a captive portal usually only asks for a room number, an access code, or acceptance of terms, while 802.1X involves a username or password, commonly in domain and username format, or a device or user certificate, together with server certificate verification. If a login page asks for an organisation account rather than a visitor code, 802.1X settings should be suspected first rather than a captive portal. The specific error messages for certificate verification failure and the differences between authentication types were not verified one by one against official documents in this research, as recorded in the unconfirmed items master table (second group), so this article only writes the broad direction, without specific certificate operation steps.
A current affairs note must carry its time frame and source level, and cannot be written as an established official conclusion. According to third-party reports in October 2026, a Windows 11 update in mid-October 2026 was reported to break automatic sign-in for 802.1X with PEAP enterprise Wi-Fi, related to an older authentication protocol blocking setting changing from audit to enforce. Manual entry of domain and username with password was reported to still succeed, while home shared password networks were reported to be unaffected. That belongs to third-party reporting from mid to late October 2026, while Microsoft official release notes themselves were not directly verified in this research, as recorded in the unconfirmed items master table (second group), so this article must mark it as according to third-party reports in October 2026, and cannot write it as an established Microsoft official conclusion. For the long term direction, several reports agree that the long term direction moves from password based authentication toward certificate based authentication, and changing the blocking setting back to audit is only a temporary measure that weakens older protocol protection. This article should not teach readers to change system settings themselves to bypass authentication, but should direct them to contact organisation IT.
A site side cause is the last easily overlooked direction. A venue guide states that expired login page credentials are one common cause of sudden collective failure across a site, and testing must use a never authenticated fresh device or a device after forgetting the network, or an already authenticated device will bypass the login page and be misjudged as normal. The practical significance of that reminder is large: if the whole company or school cannot get online at the same time, suspect the site side first rather than an individual laptop, while if only your machine cannot get online and others on the same network are normal, then suspect your own machine settings. Distinguishing collective failure from individual failure should be done before seeking help, because it decides whether to contact organisation IT, or to arrange a diagnostic check for your own machine.
Advanced differentiation flow overview: from outside to inside, from light to heavy, with a record at every step
Taken together, the advanced differentiation flow should run from outside to inside, from light to heavy, with a record at every step, without skipping steps. First, identify the symptom: place it in one of the four advanced scenarios, and record band, location, time, load state, and wake state. Second, run comparisons: mobile hotspot comparison, same network with different devices, wired comparison, and separate band comparison, judging only when the four-column comparison table is complete. Third, separate the middle layers: when full bars show but no internet, check address, gateway, and name resolution, rather than looking only at the signal bar count. Fourth, separate band and generation: when only one band fails, check DFS, channel width, band support, encryption mode, and driver version thresholds, rather than treating band characteristics as a fault. Fifth, separate wake and load: for wake only disconnection, run power and Fast Startup comparisons; for load only disconnection, keep observation records for six possible directions, keeping the word possible in front of every direction. Sixth, separate hijacking: check Kill Switch, VPN residue, proxy settings, and security software, stopping only one item at a time and turning it back on immediately after testing. Seventh, separate antenna and driver: only when angle, distance, and timing clues are all present should antenna routing be suspected, and only when symptoms stay unchanged after driver rollback should antenna suspicion rise. Eighth, separate order: driver rollback first, software exclusions second, BIOS or embedded controller updates last, and only with explicit vendor correspondence plus backup and connected power. Ninth, separate site: for company or school networks, first separate collective failure from individual failure, then separate captive portal from 802.1X.
When seeking repair or help, provide together the model, the advanced scenario the symptom belongs to, comparison records, band test results, wake and load states, whether VPN or proxy settings were changed, driver rollback results, and angle and distance test results. That information is not for appearing professional, but because diagnostic checking itself needs those variables to narrow the cause. A help request without records often requires repeating the whole comparison from the start, wasting time. To arrange a diagnostic check, see the pricing page for the usual charge range, or book the diagnostic service, since only a diagnostic result can confirm a diagnosis, and the differentiation directions in this article are not a diagnostic conclusion. Stopping points must also be stated: abnormal heating at a connector, a burning smell, sparks, abnormal deformation of the body, or a power interruption risk during a BIOS update should stop testing immediately, without repeated testing.
Pricing
All repairs are subject to a written quotation after diagnostic checking. Confirmed usual charges are listed below, and anything beyond this range is subject to a written quotation after diagnostic checking.
| Item | Charge |
|---|---|
| Battery | from HK$580 |
| Screen | from HK$1,280 |
| Motherboard chip-level | from HK$880 |
| Keyboard | from HK$480 |
| Other repairs (including Wi-Fi related diagnostic checking, antenna inspection, and driver and setting diagnostic checking) | Subject to a written quotation after diagnostic checking |
Unconfirmed items master table: two groups of lists, labelled separately by group, never written as conclusions
The master table below collects in full first group items U1 to U12 and second group items U1 to U12, labelled separately by group, with the reason for uncertainty or disagreement explained for each item. None of the following is a conclusion, and each item must be verified again before publication, nor should readers treat any item below as an established fact for changing settings.
Unconfirmed items (first group U1–U12): A-U1, the Hong Kong 6GHz opening range, available channels, and power limits, where this research only found general descriptions for the United States, Europe, and Japan, with no Hong Kong official spectrum document found, so Hong Kong 6GHz details are unconfirmed, and Hong Kong cannot be assumed to match the United States or Europe. A-U2, DFS channel availability check duration, where one official context mostly states about one minute, ASUS official guidance states one to ten minutes depending on country, and another guide states weather radar channels in Europe can reach ten minutes, with three different contexts, so no single universal number is confirmed. A-U3, the non-occupancy period after radar, where some sources state about half an hour, and some sources state that different regional rules differ, with the accurate duration for Hong Kong or individual routers unconfirmed. A-U4, the total number of non-overlapping 5GHz channels, where sources state about nineteen, twenty-three, twenty-four, and twenty-five respectively, with differences arising from region, whether DFS channels are counted, and channel width assumptions, so no single universal number is confirmed. A-U5, whether an older Windows version can use 6GHz, where some guides state a newer Windows version is required, and some USB adapter notes state other systems are also possible while older Windows is limited to 2.4GHz and 5GHz, reflecting device or driver differences, with no universal rule confirmed. A-U6, signal bar to percentage conversion, where a per bar percentage claim appears only in a single third-party guide, with no Windows official definition found, and it should not be written as a standard. A-U7, the transition mode incompatibility device list, where older system versions and particular chip device lists appear only in a single second-hand guide reporting a vendor document, without independent checking of the original document, and should not be written as a complete list. A-U8, the Wi-Fi 7 certification or standard timeline, where sources mention different milestones in different years, referring to different milestones, so they should not be mixed together, nor should it be asserted that every marketed Wi-Fi 7 router necessarily includes multi-link operation, because one source calls that capability a certification requirement, while another source questions marketed labelling, which is a disagreement. A-U9, a wide channel necessarily falling back to a narrower channel after a radar event, where that claim comes from a second-hand guide reporting ASUS, while the ASUS DFS original visible in this research only confirms disconnection and channel change, without word for word confirmation of a fallback rule. A-U10, manually fixing 5GHz to a non-DFS channel to avoid DFS, which is forum experience advice, not verified item by item against official documents, and available channels differ by region, so it should not be written as a universal solution. A-U11, measured speed ranges for 2.4GHz and 5GHz, where different third-party guides differ widely, and are strongly affected by environment, device, and channel width, so this research adopts no single speed range as a conclusion. A-U12, individual model driver version thresholds, which appear only in a single third-party guide reporting Intel, without checking the Intel official driver note in the original, so any citation must be marked as reported and checked against the current latest version.
Unconfirmed items (second group U1–U12): B-U1, whether unchecking Allow the computer to turn off this device is effective, where Intel official documentation states that setting has no effect on Wi-Fi power management and recommends keeping the default checked setting, while a large number of Microsoft Q&A answers list unchecking as a preferred repair, in direct contradiction, with no ruling possible, so this article must present both sides, and the main text already presents both sides, confirmed here again as not to be asserted one-sidedly. B-U2, the specific effect of brand power software on Wi-Fi, where a Lenovo power manager document confirms its plan includes wireless power saving mode, but a Dell power manager official page does not explicitly list Wi-Fi control, and whether current brand versions cover Windows settings was not verified one by one, so it cannot be generalised. B-U3, the symptom range of single antenna failure, where one forum states that with only one antenna failed, the other can still maintain a connection, and only when both fail does an extreme symptom appear, while another forum case shows a single cable under pressure already causing a standard fallback, with inconsistent symptom ranges, so no unified rule that single side failure equals a particular symptom can be set. B-U4, whether operating without an antenna damages the amplifier, where third-party discussion cites reflected power possibly overheating the amplifier, but this research found no vendor official document directly confirming it, as a single source citation, which cannot be written as a conclusion. B-U5, causation between KB5127648 and 802.1X failure, where third-party reporting from mid to late October 2026 consistently points to an older authentication protocol blocking setting change, but this research did not directly verify Microsoft official release notes or support article originals, and the event is very recent, with later corrective updates possible, so this article must mark time frame and according to third-party reports, and direct readers to organisation IT. B-U6, whether router overheating is the main cause of high load disconnection, where several third-party guides list router overheating as a possible cause, but no controlled test data separates overheating from excessive load, insufficient bandwidth, and interference, with overlapping symptoms, so attribution is not possible. B-U7, the claim that high laptop heat causes power circuitry abnormality, which appears only in a single Intel community user case, as personal experience speculation, without official or multi-source confirmation, and cannot be written as a general cause across models. B-U8, the applicable scope of BIOS or embedded controller update order, where one forum view on installing the operating system before updating BIOS targets a new build situation, and one vendor statement on embedded controller updating with BIOS targets a particular product line, neither of which can be applied directly to the Wi-Fi fault repair order for a general laptop, and the order in the main text is summarised in this article, not an original source sentence. B-U9, the claim of two Windows proxy systems, which appears only in a single third-party guide, with no Microsoft official document directly verified in this research, so this article downgrades it to a third-party guide statement, and reminds readers that organisation proxy settings must not be cleared without authorisation. B-U10, Kill Switch residue behaviour across VPN vendors, where several sources agree Kill Switch may leave blocking residue, but vendor defaults, reset behaviour, and whether manual turn-off is required differ, and this research did not verify vendor documents one by one, so this article uses the generic wording of checking the Kill Switch of the VPN you use, and cannot state the default behaviour of any particular vendor. B-U11, 802.1X certificate details, where the certificate or account comparison in the main text is a comparison summarised in this article from captive portal and 802.1X sources, and specific error messages for certificate verification failure and differences between authentication types were not verified one by one against official documents in this research, so this article only writes the broad direction, without specific certificate operation steps. B-U12, the applicable scope of the missing power management tab under Windows 11, where a Microsoft Q&A discussion states that some models under Windows 11 do not show that tab, and proposes a group policy alternative path, but the applicable Windows editions and model range were not fully stated in the source, so this article notes that it depends on model or edition.
Frequently asked questions
Q1: If only 5GHz drops while 2.4GHz works, does that mean the router is faulty?
A1: Not necessarily. 2.4GHz penetrates obstacles better and covers a longer range, while 5GHz attenuates faster and passes through walls less well, so only 2.4GHz remaining at a distance or behind a wall does not by itself prove a fault. Also consider the DFS channel availability check during which 5GHz is temporarily unavailable, a channel change after radar detection, channel width settings, band steering, and whether the laptop itself supports 5GHz or the DFS channel in use at the time. Test the two bands separately, record the time and location, move closer to the router and test again, and only then narrow the cause, rather than concluding from one missing band that the router is already damaged.
Q2: If Wi-Fi drops after waking from sleep, will unchecking Allow the computer to turn off this device to save power definitely fix it?
A2: That cannot be asserted one-sidedly. Intel official documentation states that this setting has no effect on Wi-Fi power management, that it only affects how Windows and the driver handle device power-down during suspend or hibernation, and that it strongly recommends keeping the default checked setting. Yet many Microsoft Q&A answers still recommend unchecking it as a step for wake-from-sleep disconnection. The two positions directly contradict each other, and this article only presents both sides without ruling in favour of either. The setting that genuinely affects the Wi-Fi performance and power balance is the wireless adapter power saving mode inside the power plan, so when testing, record both the battery and plugged-in columns, as well as wake behaviour before and after changing the Fast Startup setting, and compare with behaviour after a full restart.
Q3: After a screen or hinge repair, Wi-Fi became worse. How can I tell whether it is an antenna problem or a driver problem?
A3: Look at three clues. First, timing: if Wi-Fi was normal before the repair and only appeared for the first time afterwards, suspicion of antenna routing damage should rise; if the same symptom already existed before the repair, the repair alone should not be blamed. Second, angle and distance: disconnection that changes with the screen opening angle, normal operation only very close to the router, or only one signal bar even when sitting beside the router, points more toward the antenna path; driver problems are usually unrelated to opening angle and distance, and behave consistently across all networks. Third, cross-testing: if symptoms stay unchanged after reinstalling or rolling back the driver, antenna suspicion rises; a loose antenna connector on the wireless card that recovers when pressed back is also a common and easily handled cause. These are only directions for differentiation, and opening the machine for inspection carries further risk, so it should be handled through a diagnostic check.
Q4: On a company or school network I appear connected but cannot get online. How do I distinguish a captive portal from 802.1X?
A4: Look at the symptom and the login form. A captive portal typically shows as connected but with no internet until the login page is completed, and usually only asks for a room number, an access code, or acceptance of terms; if the login page does not appear, try browsing any website to trigger a redirect, disconnect and reconnect, temporarily turn off the VPN or proxy, or use a private window to avoid a cached session. 802.1X typically shows as failing to connect at all or repeatedly asking for authentication, rather than connecting and then having no internet, and it involves an organisation account or a device certificate, so a home network working normally does not mean an enterprise network should work normally. According to third-party reports in October 2026, Windows 11 update KB5127648 was reported to break automatic sign-in for 802.1X with PEAP enterprise Wi-Fi, while the Microsoft official release notes themselves were not directly verified in this research, so in such cases contact the organisation IT department rather than changing system settings yourself to bypass authentication.
Need Professional Laptop Repair?
Laptop King has 15+ years of repair experience in Shek Mun, Sha Tin. Free diagnosis, transparent pricing, no fix no fee. 180-day warranty for your peace of mind.