1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

Wireless router mode + disabled WAN

Discussion in 'Asuswrt-Merlin' started by RHF, Oct 22, 2019.

  1. RHF

    RHF Occasional Visitor

    Joined:
    Jan 9, 2019
    Messages:
    14
    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:

    Code:
    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
    
     
  2. Grisu

    Grisu Part of the Furniture

    Joined:
    Aug 28, 2014
    Messages:
    2,547
    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.
     
  3. RHF

    RHF Occasional Visitor

    Joined:
    Jan 9, 2019
    Messages:
    14
    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?
     
  4. Grisu

    Grisu Part of the Furniture

    Joined:
    Aug 28, 2014
    Messages:
    2,547
    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.