Wireless router mode + disabled WAN

[RHF]

Hello everyone,

I have an AC68U in "Wireless Router" mode (sw_mode=1) with the WAN interface disabled. Why not just use "Access Point" mode? --> I want GUI access to OpenVPN client configuration (among others... here's the full story for those interested).

Furthermore, I've added the WAN interface (Port 0) to the LAN bridge. As far as I've been able to figure out, that can't be done via the GUI, only via command line using robocfg.

I've noticed that, when I configure the router as described above, several services don't start automatically:

1. Default route - Fixed by adding "ip route default via 192.168.x.y" to /jffs/scripts/services-start
   
2. Resolver - Fixed by adding "/sbin/service updateresolv" to /jffs/scripts/services-start
3. NTP Client - Fixed by adding "/sbin/service restart_ntpd" to /jffs/scripts/services-start
   
4. Firewall - Fixed by adding "/sbin/service restart_firewall" to /jffs/scripts/services-start
5. OpenVPN Clients - Fixed by adding "/sbin/service start_vpnclient1" and "/sbin/service start_vpnclient2" to /jffs/scripts/nat-start

Two questions:

1. Those workarounds get the job done, but that seems like a clunky approach. Is there a better way to get these services up and running without having to force that through scripts?
2. Is there a way to avoid the clock getting reset back to 2018 with every reboot? According to my logs, init-start gets executed at 2018-05-05T07:05:01+0200.

Thanks in advance!

For reference, here's the sequence of scripts during the startup sequence:

init-start (2018-05-05T07:05:01+0200):
services-start (2018-05-05T07:05:16+0200): <-- script begin
------------
ip route ls
192.168.37.0/24 dev br0  proto kernel  scope link  src 192.168.37.6
127.0.0.0/8 dev lo  scope link
------------
cat /etc/resolv.conf 
<blank>
------------
nslookup www.google.es
Server:    0.0.0.0
Address 1: 0.0.0.0
------------
service-event (2018-05-05T07:05:20+0200):  updateresolv <-- manually triggered through script
service-event (2018-05-05T07:05:22+0200): restart ntpd <-- manually triggered through script
service-event (2018-05-05T07:05:25+0200): restart firewall <-- manually triggered through script
nat-start (2018-05-05T07:05:26+0200):
firewall-start (2018-05-05T07:05:26+0200): eth0
service-event (2018-05-05T07:05:27+0200): restart leds
services-start (2018-05-05T07:05:27+0200): <-- script end
service-event (2018-05-05T07:05:30+0200): restart nasapps
service-event (2019-10-19T08:59:51+0200): restart diskmon
service-event (2019-10-19T08:59:56+0200): start vpnclient1 <-- manually triggered through script
service-event (2019-10-19T08:59:59+0200): start vpnclient2 <-- manually triggered through script
service-event (2019-10-19T09:00:05+0200):  updateresolv
openvpn-event (2019-10-19T09:00:05+0200): tun11 1500 1605 10.35.0.6 10.35.0.5 init
service-event (2019-10-19T09:00:07+0200):  updateresolv
openvpn-event (2019-10-19T09:00:07+0200): tun12 1500 1605 10.33.0.6 10.33.0.5 init
openvpn-event (2019-10-19T09:00:08+0200): tun11 1500 1605 10.35.0.6 10.35.0.5
openvpn-event (2019-10-19T09:00:09+0200): tun12 1500 1605 10.33.0.6 10.33.0.5

 

[Grisu]

you could write time/date every 5 min to jffs and after reboot as first command check time for 2018 and change to safed value plus 1 min, so you wont be far off. There is no RTC inside to hold the time.

 

[RHF]

you could write time/date every 5 min to jffs and after reboot as first command check time for 2018 and change to safed value plus 1 min, so you wont be far off. There is no RTC inside to hold the time.

Thank you! That answers question 2.

I'm assuming that any write operation to jffs will shorten the flash memory life just as nvram commit does (see last sentence in this post). Is that correct?

 

[Grisu]

Dont know how this very small amount of bytes will effect NVRAM (will it be written to the same address or different ones?), but then better use an USB stick.