Just to provide an update here that the Ethernet connectivity issue turned out to be caused by corrupt NVRAM - speaking of which, one way to detect that is if the MAC address of the scope's Ethernet adapter shows in the configuration screen as 08:00:11:01:02:03.
I obtained an NVRAM dump file from another scope and used it on this scope and now network connectivity has been restored.
Thanks to users YetAnotherTechie and Galen on the forum here for their help sorting this out!
Jusy FYI to the guys here based on my research.
My TDS3014B has a failing DS1742W as well, not yet completely died, since I can still read the MAC address as 08:00:11:xx:xx:xx on the network config page.
TDS3014B can still be powered up correctly, and I can set the time and date without problem, this means READ/WRITE mode for DS1742W is allowed since Vcc acrossed the Vpf.
However, the MAC address can not be read by CPU in this case, which also caused the ethernet connection fails to work.
This is really odds to me, if the DS1742W can run into READ/WRITE mode, then the MAC address should be able to read by CPU.
I then install another working DS1742W from another TDS3014B of mine, and now ethernet connection works well.
I suspect that maybe there might be a period during boot up, the DS1742W can not be read since Vcc is not yet across the Vpf limit,
which causing the MAC address is not read correctly.
So, I give it a try by soldering a CR2025 to pin 24 and 7 of the almost-gone DS1742W, and keep pin 24 lifted (so DS1742W is powered by CR2025 instead of Vcc),
and install it into the IC socket on TDS3014B.
I think this should keep DS1742W powered by the CR2025, so that it is kept in READ/WRITE mode.
But the result is the same, after powering up TDS3014B, the MAC address doesn't work still.
So I'm curious, why the MAC address on an "almost-failed" DS2741W can not be read successfully while the date/time is well read?