wiki.TerraBase.info

Linksys AC Series Router Configuration Tips for OpenWRT: Difference between revisions

← Older editNewer edit →
VisualWikitext
Line 87: Line 87:
*The fourth time you turn the power switch on you can let the device boot and it should boot into the other partition.
*The fourth time you turn the power switch on you can let the device boot and it should boot into the other partition.


Remember: When attempting to utilize this within the LUCI GUI (if already logged in and connected), refresh the browser windows (CTRL Key plus Refresh Button in Firefox).
After some experimentation, 4-5 seconds seems to be the sweet spot.


So how does one upgrade OpenWRT firmware on the current / active boot partition when the process upgrades the other inactive partition?  What about changing the boot partition to the inactive one and then upgrade the firmware (See the [https://wiki.terrabase.info/wiki/Linksys_AC_Series_Router_Configuration_Tips#Switching Boot Partitions Switching Boot Partitions] section of this article for the commands to view or change the boot partition)? After several attempts, this trick didn't work.  Documentation exists that says this trick works with DD-WRT (https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=311117).  It seems the flashing of the NVRAM is left up to the Marvell SoS / CPU and there is no way around it via OpenWRT. Alternative? 
Here's what's happening "behind the scenes" when the the power switch is cycled in the above fashion.  The observations were made with a TTL / Serial / USB cable attached to the header on a router board.


The solution is to upgrade from the other partition.  IE, if Partition 1 needs to be upgraded, boot to Partition 2 and perform an upgrade, which will then upgrade Partition 1.  This will obviously work if OpenWRT is installed on both partitions. But how can one install DD-WRT on the other partition from OpenWRT?
* The Marvell firmware starts the boot process (equivalent to the BIOS of a PC)
* There is a 2-3 second pause where one can press a key on the command console to instruct the router to boot into a very basic environment for loading firmware (sort of equivalent to a BIOS setup utility on a PC)
* Before the 2-3 second window described above expires (and the boot process continues) is when the power button is turned off.


Solution: Use the command line.  IE, it won't work from the OpenWRT LUCI GUI.
Below are a few of lines of information displayed during the boot process;<syntaxhighlight lang="text">


*Download the DD-WRT Factory Firmware (factory-to-ddwrt.bin) to the /tmp Directory
---below is the boot information after the "3nd power cycle"
**For WGET to work, this may be needed: opkg install libustream-mbedtls
*Type the following command: sysupgrade -n -v -F /tmp/factory-to-ddwrt.bin (-n = do NOT keep current settings, -v = verbose, -F = Force)


The firmware will be installed on the other partition.
BootROM - 1.73
Booting from NAND flash


General initialization - Version: 1.0.0
Detected Device ID 6820
High speed PHY - Version: 2.0


Only Upgrade versions of OpenWRT can be flashed via the GUI. Factory firmware will result in an error.
Init RD NAS topology Serdes Lane 3 is USB3
, but not sure if it is possible to "cross update" between DD-WRT and OpenWRT.
Serdes Lane 4 is SGMII
board SerDes lanes topology details:
| Lane #  | Speed |  Type      |
--------------------------------
|  0    |  06  |  SATA0      |
|  1    |  05  |  PCIe0      |
|  2    |  06  |  SATA1      |
|  3    |  05  |  USB3 HOST1 |
|  4    |  05  |  PCIe1      |
|  5    |  00  |  SGMII2    |
--------------------------------
:** Link is Gen1, check the EP capability
PCIe, Idx 0: Link upgraded to Gen2 based on client cpabilities
:** Link is Gen1, check the EP capability
PCIe, Idx 1: remains Gen1
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.26.0
mvSysEnvGetTopologyUpdateInfo: TWSI Read failed
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR3 Training Sequence - Ended Successfully
Not detected suspend to RAM indication
BootROM: Image checksum verification PASSED
__  __                      _ _
|  \/  | __ _ _ ____  _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |  \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
        _  _    ____              _
        | | | |  | __ )  ___  ___ | |_
        | | | |___|  _ \ / _ \ / _ \| __|
        | |_| |___| |_) | (_) | (_) | |_
        \___/    |____/ \___/ \___/ \__|
** LOADER **


Use the OpenWRT Install / Factory image in this instance.
 
U-Boot 2013.01 (Mar 27 2015 - 16:50:46) Marvell version: 2014_T3.0p6
 
Boot version : v1.0.13
 
Board: RD-NAS-88F6820-DDR3
SoC:  MV88F6820 Rev A0
      running 2 CPUs
CPU:  ARM Cortex A9 MPCore (Rev 1) LE
      CPU 0
      CPU    @ 1600 [MHz]
      L2    @ 800 [MHz]
      TClock @ 200 [MHz]
      DDR    @ 800 [MHz]
      DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  512 MiB
 
Map:  Code:                    0x1fea9000:0x1ff7632c
      BSS:                    0x1ffef6b4
      Stack:                  0x1f9a8f20
      Heap:                    0x1f9a9000:0x1fea9000
raise: Signal # 8 caught
U-ENV offset == 0x200000
raise: Signal # 8 caught
U-ENV offset == 0x200000
      U-Boot Environment:      0x00200000:0x00220000 (NAND)
 
NAND:  128 MiB
MMC:  mv_sdh: 0
DEVINFO offset == 0x900000
U-ENV offset == 0x200000
U-ENV offset == 0x200000
S-ENV offset == 0x240000
 
 
#### auto_recovery ####
[u_env] get auto_recovery == yes
[u_env] get auto_recovery == yes
[u_env] get boot_part == 1
[u_env] get boot_part_ready == 3
auto_recovery enabled:1, boot_part:1, boot_part_ready:3
 
S-ENV offset == 0x240000
[boot_count_read] block:0x240000, size:128KB, records:64
[boot_count_read_record] boot_count:2, next_record:53
 
[boot_count_write] erase:0, auto_recovery->block_offset:0x240000 offset=0x25A800
 
Updating boot_count ...
[boot_count_write] offset:0x25A800 , length:2048
done
 
PCI-e 0 (IF 0 - bus 0) Root Complex Interface, Detected Link X1, GEN 2.0
PCI-e 1 (IF 1 - bus 1) Root Complex Interface, Detected Link X1, GEN 1.1
USB2.0 0: Host Mode
USB3.0 1: Host Mode
USB3.0 0: Host Mode
Board configuration detected:
mvEthE6171SwitchBasicInit init
Net: 
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |  RGMII  |    0x01    |
| egiga1 |  SGMII  |    0x00    |
egiga0 [PRIME], egiga1
auto_recovery_check changes bootcmd: run nandboot
Hit any key to stop autoboot:  2  <-- This is the countdown timer that starts at 3
 
--- and below is what it changes to after the "3rd power cycle / 4th power on" (minus all of the lines similar to above that come before it)
 
#### auto_recovery:2 ####
auto_recovery_check changes bootcmd: run altnandboot
Hit any key to stop autoboot:  0
 
</syntaxhighlight>


===Upgrading the "Other Partition" from OpenWRT (be it another OpenWRT installation, Linksys firmware, DD-WRT, etc.)===
===Upgrading the "Other Partition" from OpenWRT (be it another OpenWRT installation, Linksys firmware, DD-WRT, etc.)===
Using LuCI to upgrade firmware, as of about 19.07.3, the upgrade process in the GUI has changed slightly and states: "Upload a sysupgrade-compatible image here to replace the running firmware."  That might lead one to believe that the "running firmware", IE the currently booted and running version of OpenWRT will be upgraded.  That is NOT the case.  The LuCI GUI upgrade will upgrade the firmware on the ''other'' partition and then boot from the other partition.  The OpenWRT message is probably related to the fact most routers do not have the special dual boot flash partitions that the AC Series has.
As of 9.20.2020 much of the below is in question.  It has been determined that when using the LuCI GUI and an upgrade firmware image (not Linksys Factory to OpenWRT) that the ''CURRENT'' partition (not the other partition) will be upgraded...  Sometimes...  ...but not always.  The pattern seems to be very erratic.  This is not good.  Linksys Factory to OpenWRT seems to reliably flash the other partition.  None of this is noted in the OpenWRT documentation.
 
Additionally, if flashing DD-WRT (there's a reason) to the other partition, per this site: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318917&sid=ead6f3133aa640d078354c986b7c3981 and experimenting, it just does not seem possible to flash any recent version of DD-WRT to the other partition that works and doesn't create a "kernel panic" when booting.  The solution?
 
* From an OpenWRT partition, flash the other partition with OpenWRT
* Get an old firmware version of DD-WRT (Linksys Factory to DD-WRT), version 37xxx or below, sometime in 2018, and flash that
* The router won't reboot properly, but give it a minute or so to make sure the image is copied, then turn the router off, then on.  It will then boot to DD-WRT
* Note, if using Firefox or any other browser to access the DD-WRT GUI, it will probably keep redirecting to the LuCI GUI.  Clear the browsing history or open a private tab in Firefox to solve that issue.
* Get a more recent version of DD-WRT (upgrade version), flash that, good to go with OpenWRT on one partition and DD-WRT on the other.
 
OK, why DD-WRT?  Well, as it turns out, DD-WRT has a bunch of development tools that OpenWRT does not.  That means it is much, much easier to compile one's own sofware (packages, not firmware) on a router.  This includes perl packages, etc.  And, as tested, the binary / executables on DD-WRT are completely functional on OpenWRT as long as all the dependencies are in place.  It is even possible to have a huge chunk of DD-WRT software in the /opt Directory available on OpenWRT.  The easiest way to not run into conflicts is to only install software that is not available in OpenWRT in the /opt Directory.  That way environment paths can be set up to search /opt first, then the normal OpenWRT binary / executables.
 
One thing to keep in mind about OpenWRT VS DD-WRT is how each refers to the CPU / SoC of the Marvell based hardware.  OpenWRT refers to it as a Cortex A9.  And it is.  DD-WRT refers to it as ARMv7 and it is.  Technically (see above section for details on the hardware).  It's the same thing with both firmwares making a partial reference to the hardware's name.  Arm, DD-WRT, and OpenWRT can all share the blame on this.  See the chart on Wikipedia for some clarity: https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures
 
<s>Using LuCI to upgrade firmware, as of about 19.07.3, the upgrade process in the GUI has changed slightly and states: "Upload a sysupgrade-compatible image here to replace the running firmware."  That might lead one to believe that the "running firmware", IE the currently booted and running version of OpenWRT will be upgraded.  That is NOT the case.  The LuCI GUI upgrade will upgrade the firmware on the ''other'' partition and then boot from the other partition.  The OpenWRT message is probably related to the fact most routers do not have the special dual boot flash partitions that the AC Series has.</s>
 
<s>Using the command line to upgrade the firmware will upgrade the ''other'' partition, the subsequent boot will be to the current partition (IE, the one it was flashed from): sysupgrade -n -v -F /tmp/factory-to-ddwrt.bin (-n = do NOT keep current settings, -v = verbose, -F = Force)</s>
 
<s>So how does one upgrade OpenWRT firmware on the current / active boot partition when the process upgrades the other inactive partition?  What about changing the boot partition to the inactive one and then upgrade the firmware (See the [https://wiki.terrabase.info/wiki/Linksys_AC_Series_Router_Configuration_Tips#Switching&#x20;Boot&#x20;Partitions Switching Boot Partitions] section of this article for the commands to view or change the boot partition)?  After several attempts, this trick didn't work.  Documentation exists that says this trick works with DD-WRT (https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=311117).  It seems the flashing of the NVRAM is left up to the Marvell SoS / CPU and there is no way around it via OpenWRT. Alternative?</s>
 
<s>The solution is to upgrade from the other partition.  IE, if Partition 1 needs to be upgraded, boot to Partition 2 and perform an upgrade, which will then upgrade Partition 1.  This will obviously work if OpenWRT is installed on both partitions.  But how can one install DD-WRT on the other partition from OpenWRT?</s>
 
<s>Solution: Use the command line.  IE, it won't work from the OpenWRT LUCI GUI.</s>
 
*<s>Download the DD-WRT Factory Firmware (factory-to-ddwrt.bin) to the /tmp Directory</s>
**<s>For WGET to work, this may be needed: opkg install libustream-mbedtls</s>
*<s>Type the following command: sysupgrade -n -v -F /tmp/factory-to-ddwrt.bin (-n = do NOT keep current settings, -v = verbose, -F = Force)</s>
 
<s>The firmware will be installed on the other partition.</s>
 
<s>Remember: When attempting to utilize this within the LUCI GUI (if already logged in and connected), refresh the browser windows (CTRL Key plus Refresh Button in Firefox).</s>
 
<s>Only Upgrade versions of OpenWRT can be flashed via the GUI, not factory (unless the other partition is LinkSys firmware).</s>


Using the command line to upgrade the firmware will upgrade the ''other'' partition, the subsequent boot will be to the current partition (IE, the one it was flashed from): sysupgrade -n -v -F /tmp/factory-to-ddwrt.bin (-n = do NOT keep current settings, -v = verbose, -F = Force)
<s>Use the OpenWRT Install / Factory image in this instance.</s>


==OpenWRT System Logging==
==OpenWRT System Logging==
Line 2,437: Line 2,579:
Configuration File: /etc/vsftpd.conf
Configuration File: /etc/vsftpd.conf


* Be sure to read the  
*Be sure to read the
* The default configuration file (/etc/vsftpd.conf) for VSFTPD will never work under any circumstances for an OpenWRT router that is in a "normal" / default configuration in regards to its firewall and several other items.  It is understood that the OpenWRT developers have better things to do than configuring an old FTP server, but they may as well leave the configuration file blank or perhaps include all of the options, but comment everything out rather than having a configuration file that does nothing more than give an end user false hope.
*The default configuration file (/etc/vsftpd.conf) for VSFTPD will never work under any circumstances for an OpenWRT router that is in a "normal" / default configuration in regards to its firewall and several other items.  It is understood that the OpenWRT developers have better things to do than configuring an old FTP server, but they may as well leave the configuration file blank or perhaps include all of the options, but comment everything out rather than having a configuration file that does nothing more than give an end user false hope.
* The OpenWRT Package creates an /etc/vsftpd Directory, but it isn't used.  Case in point: The default userlist_file name for the OpenWRT version of VSFTPD is /etc/vsftpd.user_list.  For other platforms such as CentOS, that file is located in the /etc/vsftpd Directory, but for OpenWRT it is located in the /etc Directory.  So why is the /etc/vsftpd Directory created (with nothing in it)?  Best guess is that since other Platforms like CentOS that put configuration files in the /etc/vsftpd Directory, there might be some "template" in the vsftpd source code that creates that Directory by default and the OpenWRT developers forgot to disable that function.
*The OpenWRT Package creates an /etc/vsftpd Directory, but it isn't used.  Case in point: The default userlist_file name for the OpenWRT version of VSFTPD is /etc/vsftpd.user_list.  For other platforms such as CentOS, that file is located in the /etc/vsftpd Directory, but for OpenWRT it is located in the /etc Directory.  So why is the /etc/vsftpd Directory created (with nothing in it)?  Best guess is that since other Platforms like CentOS that put configuration files in the /etc/vsftpd Directory, there might be some "template" in the vsftpd source code that creates that Directory by default and the OpenWRT developers forgot to disable that function.
* The /etc/init.d/vsftpd startup script is very simple.  So simple in fact that it requires a setting (listen=YES) in the .conf file for vsFTPD for vsFTPD that documentation indicates is set to "yes" if vsFTPD is NOT run via an init.d script.  In OpenWRT's case, the startup script is so simple it essentially runs vsFTPD as if it were starting from the command line.  This causes no issues, but is a bit counter intutive if one reads the vsFTPD documentation on the "listen" directive.
*The /etc/init.d/vsftpd startup script is very simple.  So simple in fact that it requires a setting (listen=YES) in the .conf file for vsFTPD for vsFTPD that documentation indicates is set to "yes" if vsFTPD is NOT run via an init.d script.  In OpenWRT's case, the startup script is so simple it essentially runs vsFTPD as if it were starting from the command line.  This causes no issues, but is a bit counter intutive if one reads the vsFTPD documentation on the "listen" directive.


Below is a working configuration file;<syntaxhighlight lang="text">
Below is a working configuration file;<syntaxhighlight lang="text">
Line 2,603: Line 2,745:
It seems very odd that the choice for FTP server that OpenWRT provides is vsFTPD as the latest version is half a decade old.  Why not use something that still gets updated on a regular basis like ProFTPD?  Perhaps the developers of OpenWRT are attempting to send a quiet message that FTP is not a good thing to use because it is not encrypted.  But if that's the case, why not remove every FTP server package that doesn't contain SFTP (SSH FTP) or FTPS (SSL/TSL FTP) functionality?
It seems very odd that the choice for FTP server that OpenWRT provides is vsFTPD as the latest version is half a decade old.  Why not use something that still gets updated on a regular basis like ProFTPD?  Perhaps the developers of OpenWRT are attempting to send a quiet message that FTP is not a good thing to use because it is not encrypted.  But if that's the case, why not remove every FTP server package that doesn't contain SFTP (SSH FTP) or FTPS (SSL/TSL FTP) functionality?


==== Tips for Troubleshooting ====
====Tips for Troubleshooting====
As with anything related to computers, it can be difficult to figure out what is wrong with a configuration of a service and why it isn't working as expected.  vsFTPD is no exception.  To eliminate a potential issue, namely the firewall, consider configuring vsFTPD to listen on a LAN interface.  This will eliminate problems related to PASV / Passive FTP issues.  Also consider using a command line version of FTP as opposed to a browser version.  Command line versions of FTP will often times display more error information than a web browser that has FTP capability.
As with anything related to computers, it can be difficult to figure out what is wrong with a configuration of a service and why it isn't working as expected.  vsFTPD is no exception.  To eliminate a potential issue, namely the firewall, consider configuring vsFTPD to listen on a LAN interface.  This will eliminate problems related to PASV / Passive FTP issues.  Also consider using a command line version of FTP as opposed to a browser version.  Command line versions of FTP will often times display more error information than a web browser that has FTP capability.


Retrieved from "https://wiki.terrabase.info/wiki/Linksys_AC_Series_Router_Configuration_Tips_for_OpenWRT"