Searching through both the official source code (GPL tarball) and .bin firmware of this routor provided by TP-Link, I saw lines of codes related to RTC0 and hwclock which signify its presence but at the same time something strange is going on when I do as follows on ssh through sftp protocol :
root@openwrt:~# hwclock
hwclock: can't open '/dev/misc/rtc': No such file or directory
root@openwrt:~# hwclock --help
BusyBox v1.36.1 (2023-11-14 13:38:11 UTC) multi-call binary.
Usage: hwclock [-swul] [--systz] [-f DEV]
Show or set hardware clock (RTC)
-s Set system time from RTC
-w Set RTC from system time
--systz Set in-kernel timezone, correct system time
if RTC is kept in local time
-f DEV Use specified device (e.g. /dev/rtc2)
-u Assume RTC is kept in UTC
-l Assume RTC is kept in local time
(if neither is given, read from /etc/adjtime)
Above behaviour of hwclock makes it seem like a ghost, present at one time while not at another time.
Please tell me how can I check and confirm this before continuing forward with this howto:
The rule of thumb is that if it is a consumer all-in-one wifi router device (or even a consumer router without wifi), it will not have a built-in RTC module. That is typically only found on 'larger' systems like x86 or high end router systems.
Are you attempting to access an RTC in your C6 (hint: there isn't one), or are you trying to add one by physically hacking it a bit as in the link you shared?
hwclock is a userspace program-- it's only the topmost part of a hardware clock stack. It depends on the kernel having a kernel space hardware driver, and of course the underlying hardware.
In other words:
user runs hwclock
hwclock opens /dev/rtcX which triggers the kernel driver
kernel driver accesses I2C SPI etc bus -> reads time from the clock hardware
In OpenWrt and the TP-Link stock firmware, hwclock is compiled into busybox. TP-Link did not bother to compile it out on this model which has no clock. This is also the case with most builds of OpenWrt.
The first run failed with an error because the rtc device did not exist. The second run with --help (which only shows usage syntax and exits) succeeded since it did not try to open an rtc device.
So, RTC is not present on this router TP-Link Archer C6 v3.2. That ends it.
But after just randomly picking any unknown local routor from market, how can we check with 100% certainity that RTC is present or not without any assumptions or norms, just through factual and logical deduction whether hardware or software wise or by using some command, as it might be possible that an unused/redundant RTC hardware present already in routor might not have been coded for in its firmware for a router like from local brands. In that case, a user using custom firmware like OpenWrt can benefit.
Credit for solution, specifically for TP-Link Archer C6 v3.2 and generally RTC supporting devices' architecture, in chronological order goes to @psherman, @mk24 :
But general method, which I expected would apply to all devices/routors to check RTC presence physically or software wise or by using some command is still unknown/unsolved for all random devices/routors
most consumer router devices don't actually require accurate absolute/eternally-referenced time, or at the very least can assume that it is possible to obtain via other non-hardware based methods.
Point 1 should speak for itself, but it is a hardware feature that can be omitted as a function of point 2. In the case of the second point, a hardware based RTC is not required to do standard things like obtain a DHCP lease or setup a PPPoE connection, provide DHCP leases, perform basic routing and DNS queries, etc.
Accurate and real-time clocks become necessities when you are dealing with higher level protocols that use SSL/TLS or other encryption which uses time as part of the cryptographic algorithm (basically to prevent 'replay attacks'). So things like DoH/DoT, VPNs and other similar technologies do require real time. But, most consumer routers don't do this out of the box, or if they do, it is also safe to assume that they have a functioning upstream network connection and can thus set time against upstream NTP servers (or, browser sync is an option, too).
With that backdrop, manufacturers will cut all hardware that is not needed to save costs, thus reducing the MSRP of a given device. So any consumer grade router device will simply lack this component. x86 devices almost always contain RTCs, although it is possible that the cheapest of them may not (i.e. STBs, very low end thin-client type systems or those designed as routers at the absolute lowest end of the x86 spectrum).
I don't know that there is any absolute way to know about the presence (or lack thereof) of a real hardware RTC for Openwrt supported devices, but based on the above description, you should be able to deduce that info (possibly on original MSRP, too).
Just to make things a bit worse, there are also a few devices with a seemingly real RTC device, but without battery power...
So, once they get the proper time, they stay correctly in time, independently of the CPU load and drift.
But originally at boot, the hardware RTC has a wrong initial time, so our boot time-setting scripts need to try to detect that.
Latest fix for that "fake RTC" was merged last year:
Nice of you to tell me. Its needed information
I guess Raspberry Pi s are more modular and flexible and can fit in any work condition according to one's need as it gets extended with more hardware additions according to needs of people.
I never tried a Raspberry Pi but a/c to what I have heard, they are quite expensive for one's need instead of readymade routors as we have to buy separate modular parts and assemble them, and each of these parts are somewhat expensive.
Please correct me as I might be wrong
This comes down to what you'll be doing with a Pi.
For example, if you're running a wired router, it's actually quite capable and not very expensive for this purpose. Most users will opt to add a second NIC via USB (around $10-25 USD). While not the cheapest option, it does actually perform very well.
Wifi, on the other hand, is low end on all Raspberry Pi devices, and therefore it's always better and more cost effective to buy a purpose built AP (or wifi-router all-in-one unit) if wifi performance matters. The use of USB wifi adapters is hit-or-miss and generally still results in poor wifi performance (albeit better than the Pi's built-in wifi).
I've just freed up a Pi4 from another task and put OpenWrt on it as my VPN applicance -- it is so much faster than my previous VPN that it is silly I hadn't done this earlier.
Thanks for informing as I was considering to buy Raspberry Pie for use only as a wireless routor
As a last hopeful resort though it might sound dumb, is it possible to increase wifi performance if its possible to connect external antennas to Raspberry Pi ?
If performance is so well, then I will try Raspberry Pi as wired routor considering its flexibility and modularity for different usecases
I thought people bought Raspberry Pi s because they were 'all in ones' due to their flexibility and worked in all usecases. So, Raspberrry Pi also has its own advantages and disadvantages a/c to different uses, good information before buying.
Thank you
Nope. Spend the money on a proper AP device -- even an older 802.11n AP can outperform the Pi's built-in wifi.
This is reasonable... but keep in mind that if you are also buying another wifi AP, you may or may not want an integrated all-in-one unit instead of separate devices. That comes down to your network design, though.
not as wifi routers. Some people do use it for wifi (especially as a travel router), but there are much better options out there.
For other things -- wired router, general linux box, cheap/low power desktop replacement for basic web and such, automation controllers, etc... they're great.
