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

NVRAM full, router does not boot. Restore config?

Discussion in 'Tomato Firmware' started by philess, Mar 26, 2013.

  1. philess

    philess Networkin' Nut Member

    Hey guys,

    i just borked a router of a friend of mine (did set up OpenVPN remotely on it through Web-UI), last thing i saw was that NVRAM was almost full (0,4% free), luckily i exported the working config a few minutes before that. I uninstalled some Optware packages (mostly lighttpd+php5) and then rebooted the router. But now it seems that it doesnt boot up anymore.

    Quick question: Can i tell the guy to do a 30/30/30 reset and then import the saved config?
    Should that work? Or do i have to get on a train and setup everything myself there?

    Router is a RT-N16 with 9013 R1.0 Victek mod on it. Optware is installed to a mounted USB drive.
     
  2. jerrm

    jerrm Network Guru Member

    The optware probably don't impact nvram at all. 30/30/30 should clear nvram and get you back to defaults. I probably would NOT restore the old configuration if it was after, or you'll be back at the same problem again. Instead I would judiciously re-build keeping an eye on nvram after each change.

    VPN setup can easily exhaust available nvram. We really need an option to store keys on usb.

    If you're setting up vpn, and can live with password only ssh after the vpn is functional, then remove ssh keys to save about 400 bytes nvram each.

    Make sure the https cert is NOT stored in nvram (if https is enabled).

    You can carefully "nvram unset" variables for features you don't use. If you're not using QOS, clearing the default rule set could save about 1.9K (on shibby). I don't think victek has transmission included in any builds, but shibby has about 700 bytes for transmission related info, even on builds that don't include it.

    I wish the nvram tool was smart enough to only write non-default values to nvram, and respond with the default values for missing items. The potential nvram savings would be significant. The downside is a fairly innocent change could suddenly blow up nvram. For instance making a minor change to the default qos ruleset would suddenly require 2K additional nvram
     
    philess likes this.
  3. philess

    philess Networkin' Nut Member

    Thank you for the quick reply jerrm!

    Now that i actually think about it, that all makes sense to me. Especially the VPN and HTTPS certificates taking up so much space, and on top of that i had QoS enabled with a good bunch of rules. I will try to restore the config after 30/30/30, just hoping that atleast it will come online again, even if very slow (NVRAM almost full). And then turn some stuff off for now.

    Shouldnt it be possible to manually edit the OpenVPN config and point to keys stored on USB?
    Going to try to make a startup script that copies my own config.ovpn over and then starts the daemon,
    trying to avoid the Web-UI, should work.
     
  4. jerrm

    jerrm Network Guru Member

    QOS is probably not taking up that much over the default settings, unless you have actually added a lot of new entries. The default QOS ruleset starts out in nvram whether you have it enabled or not.

    That should be fine, I've done similar.

    I wish if we entered a valid filename in the key/cert boxes, the system would build the VPN config using the referenced files. No GUI change involved, just some tweaks to the process that writes out the config.

    Now that I've got a working build environment I might tackle it, but already have another item more important to me that I've not had time to get to yet.
     
  5. Riddlah

    Riddlah Networkin' Nut Member

    I currently have ca.crt, dh1024.pem, server.crt and server.key on my USB. In the Custom Configuration box i have the following commands:

    Code:
    ca /tmp/mnt/Cruzer/OpenVPN/Server/ca.crt
    dh /tmp/mnt/Cruzer/OpenVPN/Server/dh1024.pem
    cert /tmp/mnt/Cruzer/OpenVPN/Server/server.crt
    key /tmp/mnt/Cruzer/OpenVPN/Server/server.key
    The commands take up roughly 180 bytes of nvram. Not sure how much nvram the regular way uses to compare.
     
    Monk E. Boy likes this.
  6. philess

    philess Networkin' Nut Member

    Again, thank you both for the replies!

    I now have the following .sh executed after USB mount:

    Code:
    #!/bin/sh
    rm -rf /etc/openvpn/server1/config.ovpn
    cp /opt/tomato/config.ovpn /etc/openvpn/server1/config.ovpn
    service vpnclient1 restart
    sleep 1
    nvram unset vpn_server1_static
    nvram unset vpn_server1_key
    nvram unset vpn_server1_crt
    nvram unset vpn_server1_ca
    nvram unset vpn_server1_custom
    Seems like the folder structure for openvpn is only generated when the daemon is actually started,
    so i have "Start on WAN" enabled in the Web-UI and then i have to replace the config, restart daemon.
    I even delete the custom confguration from NVRAM since i included everything in my own config.ovpn now,
    this just gave me about 7000 bytes more free (on a different router right now tho).

    To save the HTTPS certificate on the USB instead NVRAM, i do the following (also after USB mount):

    Code:
    #!/bin/sh
    service httpd stop
    sleep 1
    rm -rf /etc/cert.pem
    rm -rf /etc/key.pem
    cp /opt/tomato/my_cert.pem /etc/cert.pem
    cp /opt/tomato/my_key.pem /etc/key.pem
    rm -rf /tmp/cert.tgz
    tar -C / -czf /tmp/cert.tgz etc/cert.pem etc/key.pem
    sleep 5
    nvram setfb64 https_crt_file /tmp/cert.tgz
    sleep 5
    nvram commit
    sleep 5
    nvram unset https_crt_file
    rm -rf /tmp/cert.tgz
    sleep 5
    nvram commit
    service httpd start
    Seems all to be working, for now atleast. Any objections or hints?

    Edit: Actually, scratching my head right now. The HTTPS certs are NOT stored on /opt (=USB) right now though, correct?

    And i just realised, its probably a bad idea to unset all those variables, instead, i should do nvram set variable=""
     
  7. jerrm

    jerrm Network Guru Member

    Perfect! Could have sworn I tried in the past and it didn't work. Probably was user error and I just grumbled and moved on. No need for any system changes with this. Glad to be proven wrong!
     
    Monk E. Boy and philess like this.

Share This Page