Site Tools


remote_upgrade_poc

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
remote_upgrade_poc [2023/07/13 16:51] – [Concerns, Issues, and Known Challenges] -formatting hogwildremote_upgrade_poc [2023/07/13 17:05] (current) – [Concerns, Issues, and Known Challenges] -formatting hogwild
Line 89: Line 89:
   - A form of permanent storage is needed. A full erase/reset of NVRAM-stored parameters via //mtd-erase// \\ is not committed until the next reboot/power cycle.   - A form of permanent storage is needed. A full erase/reset of NVRAM-stored parameters via //mtd-erase// \\ is not committed until the next reboot/power cycle.
     - What is the difference betweeen the //mtd-erase// and //nvram erase// commands?     - What is the difference betweeen the //mtd-erase// and //nvram erase// commands?
-      - Issuing the //nvram erase// command still erases the nvram mtd. However, upon actions like a reboot, \\ NVRAM is saved to mtd from RAM. Thus, it will not wipe everything unless power is removed \\ right after the command completes. However, //nvram erase// clears the NVRAM in RAM then writes to flash, \\ but doesn't zero out all the flash. See also: [[https://wiki.dd-wrt.com/wiki/index.php/Hard_reset_or_30/30/30#Erasing_NVRAM|Hard reset or 30/30/30 - DD-WRT Wiki]]+      - Issuing the //nvram erase// command still erases the nvram mtd. However, on actions like a reboot, \\ NVRAM is saved to mtd from RAM. Thus, it will not wipe everything unless power is removed \\ right after the command completes. However, //nvram erase// clears the NVRAM in RAM then writes to flash, \\ but doesn't zero out all the flash. See also: [[https://wiki.dd-wrt.com/wiki/index.php/Hard_reset_or_30/30/30#Erasing_NVRAM|Hard reset or 30/30/30 - DD-WRT Wiki]]
       - The //nvram erase// command maintains the NVRAM header/checksum/length structure but erases variables. \\ The //mtd// command erases a flash partition's sectors, leaving its data values set to "FF" (flash erase state). \\  \\       - The //nvram erase// command maintains the NVRAM header/checksum/length structure but erases variables. \\ The //mtd// command erases a flash partition's sectors, leaving its data values set to "FF" (flash erase state). \\  \\
   - Thus, options for storage persistence would seem to be:   - Thus, options for storage persistence would seem to be:
Line 97: Line 97:
     - Automount mounts all partitions to subdirectories in "/mnt". The //nvram usb_automount// parameter \\ defaults to "1" (enabled), at least in recently compiled ".trx" firmware builds).     - Automount mounts all partitions to subdirectories in "/mnt". The //nvram usb_automount// parameter \\ defaults to "1" (enabled), at least in recently compiled ".trx" firmware builds).
     - Logic is needed to tell if the .autorun file ran right after an upgrade or on reboot during normal operation. \\  \\     - Logic is needed to tell if the .autorun file ran right after an upgrade or on reboot during normal operation. \\  \\
-  - Performing an upgrade via the shell is safer than via the web interface. From the shell, you download a .zip \\ and check for magic number errors when extracting the archive. Most devices have enough RAM \\ to host the .zip. Uploading a ".trx" file via the web interface increases risk, especially on a less stable connection, \\ such as a WiFi client. \\  \\ +  - Performing an upgrade via the shell is safer than via the web interface. From the shell, you download a .zip \\ and check for magic number errors when extracting the archive. Most devices have enough RAM \\ to host the .zip. Uploading a ".trx" file via the web interface is more risky, especially on a less stable connection, \\ such as a WiFi client. \\  \\ 
   - Clearing NVRAM and restoring variables remotely via a script could lead to a serious lockout or bootloop. \\ Even if such an approach (having a list of nvram set commands) saved time, too many things can go wrong.\\  \\    - Clearing NVRAM and restoring variables remotely via a script could lead to a serious lockout or bootloop. \\ Even if such an approach (having a list of nvram set commands) saved time, too many things can go wrong.\\  \\ 
-  - Having a stable basic Internet connection, VPN, and LAN parameters could allow an internal device \\ (like a PC or small service/maintenance appliance RPI) to announce its availability. This could allow it \\ to be accessed remotely for finalizing the whole post-upgrade configuration. A VPN might not be needed \\ if a remote access tool such as Teamviewer were available). \\  \\  +  - Having a stable basic Internet connection, VPN, and LAN parameters could allow an internal device \\ (like a PC or small service/maintenance appliance RPI) to announce its availability. This could allow it \\ to be accessed remotely for finalizing the whole post-upgrade configuration. A VPN may not be needed \\ if a remote access tool such as Teamviewer were available). \\  \\  
-  - Upgrade options using TFTP wouldn't be viable because of the need to trigger the transfer during a short \\ (a few seconds) service window during power-up. Such options might also require specific button combinations \\ which would not be practical.\\  \\ +  - Upgrade options using TFTP wouldn't be viable because of the need to trigger the transfer during a short \\ (a few seconds) service window during power-up. Also, such options may require specific button combinations \\ which would not be practical.\\  \\ 
   - Other options to do a controlled reconfiguration during upgrade might include leaving specific entry points, \\ hooks, or callback scripts. However, this would require thorough examination, development and testing. \\ Such work might be unfeasible if developer resources were limited.   - Other options to do a controlled reconfiguration during upgrade might include leaving specific entry points, \\ hooks, or callback scripts. However, this would require thorough examination, development and testing. \\ Such work might be unfeasible if developer resources were limited.
  
remote_upgrade_poc.txt · Last modified: 2023/07/13 17:05 by hogwild