@Kevin_Z @Ram_Eswar Maybe this helps to fix the issue.
If you need the log file, I can send it separately by mail, not publicly. I turned on System Log Debug level. When the issue triggered again, I saved the log and analysed it with AI. This is what AI is telling.
Yes, the log explicitly proves that once the optical signal dropped, the router completely gave up and never made a single attempt to reconnect to the internet when the power and fiber signal returned an hour later.
Here is exactly what the log reveals about that power cut:
1. The Router Never Lost Power
The log confirms that your TP-Link router itself stayed powered on during the entire event. We know this because there is no system initialization message (like BBA Platform version:3.1.9-rc5) in the middle of the log.
-
Instead, the log shows a continuous flow of local network activity (Mesh clients connecting and disconnecting, local DHCP handing out 192.168.x.x IPs) straight through the blackout.
-
This means your router was on a UPS/inverter, but the BSNL exchange (OLT) or the intermediate optical splitters in your neighborhood lost power.
2. The Drop (18:53)
When the local power cut hit the ISP's equipment, the optical signal vanished.
-
At 18:53:57, the router realized the physical line was dead, so it tore down the PPPoE connection (LCP TermReq id=0x2 "User request").
-
At 18:54:03, the VoIP stack crashed because its IP address vanished.
3. The Silence After the Power Returned
There is a massive gap in the log between 18:54:03 and 20:07:48 (roughly 1 hour and 13 minutes), which aligns perfectly with your 1-hour power cut timeline.
When the power came back on and the machines came online around 20:07, your local devices started asking for IP addresses again (DHCPD: Send OFFER messages begin reappearing).
However, there is not a single PPP or DHCPC log entry after 18:54.
-
If the router was functioning normally, you would see it broadcasting a PADI (PPPoE Active Discovery Initiation) request to say, "Hey BSNL, I'm back, let me log in!" * Instead, there is total silence on the WAN side.
The Conclusion
This confirms the exact nature of the TP-Link firmware bug. When the BSNL OLT lost power and the laser died, the TP-Link's optical auto-sense driver crashed. When the fiber signal finally lit back up an hour later, the TP-Link was permanently stuck in the "EPON Registering" loop. Because the hardware driver was trapped in that loop and disabled the TX laser, the router's operating system never even bothered trying to dial the PPPoE connection.
