I used OpenWRT long enough to know that package settings of the packages not included in the official published image don’t get saved by the config backup utility. There are even several scripts that were written by the community members that specifically address the fact that the config backup in OpenWRT doesn’t save settings of the packages not included in the official image. So, these scripts - when run - dump the settings of these images into a directory that gets backed up by the backup utility.
As for choosing the packages to be included into the image, are you referring to the image builder process? If so, this is the same image compilation from source that I used except this one runs on publicly available servers and has a simplified web GUI to front the compilation process. This is still compiling an image from source rather than downloading the pre-compiled image and having the device flash itself while preserving all the settings.
As for the sysupgrade process, again this method has some caveats that are not equal to pushing the update button, having the system flash itself, and having all the setting survive the process. I never used this method because at one point I found that it wouldn’t work for me. I don’t remember exactly the reason. I want to say it’s because this method is only for the squash partition images, but because I don’t remember for sure, I’m not going to claim it here. I know that I researched this method, and it didn’t work for me.
By the way, my days with the Raspberry Pi 4B running OpenWRT started before the official image was released, so I had to compile my own images from snapshots. But even after the official image for Raspberry Pi 4B became available, I researched all the different ways to upgrade my system and concluded that compiling my own image from
source was the most streamlined method.
The beauty of the pfSense or UniFi UXG is in that I don’t have to be an expert in different ways the system can update itself. All I need to do is to push the update button, and in a couple minutes the system reboots on the updated software image with all the packages properly updated too and all the settings having survived the update process. And this is how any viable firewall / router / security appliance works from free ones like pfSense to very expensive ones and everything in between. OpenWRT is majorly lacking in this area, and after 20 years of existence, it’s time to fix this issue.
The same Chinese special forces operatives that compile the FriendlyWRT images that are trying to hack your network could be the ones publishing the OpenWRT forks on GitHub and communicating with you on here. Why do you consider these OpenWRT images compiled by someone else with newer Linux kernes any more secure than the images compiled by FriendlyWRT? How do you know the authors of these OpenWRT forks are not trying to steal your data?
The answer is, You never know for sure. I decided not to worry about it with FriendlyWRT, as it’s a tailor made image by a manufacturer of a relatively small-volume device. If this were Huawei, I would be much more concerned, as it would be worth it to the CCP to pay for a backdoor into the device. With FriendlyElec, I think the chances of this image having a backdoor or phoning home is close to zero.
Once the official OpenWrt image is released, you should absolutely stop using the FriendlyWRT image, but then you will have to deal with the update issue that I got tired of.
I'm sorry, I'm just a rookie here, but this is categorically false.
I just finished working on a BPI-R3 where I duplicated my final configuration from NAND to NOR. I have ~15 extra packages (plus their dependencies), which I know is not a lot compared to some people, but literally all I did to transfer my complete config was use the "Backup" in LuCI with default settings and then "Restore" after booting to NOR. All of the extra package configs transferred. And if they hadn't (suppose you have configs in non-standard directories) it is trivially easy to add extra files and directories to the backup.
The backup system works and you're not helping anyone by trying to claim otherwise.
Maybe because you are new to this, you don't know the whole truth?
However, after you insisted that everything gets saved and then restored, I wonder which process you use exactly for this? Could you elaborate?
How do you update your software between maintenance updates?
How do you update your software between major versions?
How do you make sure your update contains all the packages that you had installed prior to the update?
How do you make sure all of your configs are restored after the update?
Now, after doing a little bit of searching around, I'm finding posts about the attended sysupgrade feature that appears to be relatively new. Supposedly, this feature now allows you to select the version you want to update to, select the packages that you want to be incorporated into the new software image and even have all your settings restored onto the new image. Your custom image then gets built in the publicly available server with the packages you requested, and then the image gets downloaded and the system gets flashed with this custom image. Then, all of the package settings get restored. This, however, appears to be a relatively new feature that addresses most of the issues that I had with running updates on OpenWRT.
I don't know exactly when the attended sysupgrade feature became fully functional with both the restored packages and the settings post upgrade, but it appears to date back about a year, which is quite possible why I may have missed this, as I transitioned to the R6S on FriendlyWRT about a year ago. Let me assure you that prior to this feature being available, updating OpenWRT with a non-squash image that had non-standard-set of packages installed was a major pain in the rear in both restoring the packages and restoring the settings for these packages.
January 9, 2023
Categories: OpenWRT
OpenWrt now has a feature called Attended Sysupgrade that removes the friction required to do a sysupgrade. Previously, we needed to take note of the user installed packages on a system so they could be manually re-installed after the sysupgrade, but now the ASU backend dynamically builds an image with our custom packages pre-installed.
The new package installations will have installed new, default versions of package configuration files. If existing configuration files are in place, opkg displays a warning about this and saves the new configuration file versions under /etc/config/*-opkg filenames.
The new package-provided config files should be compared with your older customized files to merge in any new options or changes of syntax. The diff tool is helpful for this.
Searching further, I see a page on OpenWRT wiki about the Luci package for attended sysupgrade that is dated December 12, 2023 without any previous versions for this document listed:
I'm not sure when this Luci package was first released, and I do know there is a CLI version of this process as well.
So, to sum up, perhaps the issue I was referring to is now a non-issue anymore, but it was a huge issue not so long ago. Like I said, I switched from Raspberry Pi 4B to the R6S about a year ago, so I stopped running OpenWRT and switched to FriendlyWRT about a year ago. If attended sysupgrade actually works, then the major obstacle to using OpenWRT has been removed. It's still not as smooth as with other firewalls, as you have to wait for the custom image to be built in the server (hence "attended"), but at least it's seems to be a much smoother and almost completely automated process.
Will be looking forward to the official OpenWRT support of the R6S to leverage the attended sysupgrade process.
That’s a good point. I think the difference for me is the close proximity between the source code and the release image hosted on GitHub. I guess if I really want to be sure I could build a FriendlyWRT imagine myself. I was genuinely asking whether there is a way (maybe checksum?) to verify that the file I download from google drive is a product of the untampered code we expect.
What power adapter do you use? I'm planning to use cake for sqm (configured to operate on the performance cores), so I'm not sure whether this might require more than 5V 4A.
Even the lowest power PD charger like the one coming with Pixel phones (18W) can deliver 5V3A or 9V2A, so R6S can virtually powered by any PD charger as long as they are in compliance with USB-IF. And in fact normal USB-A 5V power also works on R6S as well, I just did some tests with USB power meter:
Testing with a 60W USB-C power plug, R6S auto negotiate with 20V (which is good! you can send more power without using a very thick cable!) and it only consumes 0.43A (~8.5W)
Testing with a usual USB-A 5V 2.1A power plug, R6S can run with 5V but drawing ~1.6A which is similar to #1
Both cases are R6S running DietPi, with stress-ng putting stress on CPU + memory and CPU running hot at around 55C (network connecting 1GbE only). Since the Linux upstream of video core driver isn't there yet so unless you use FriendlyElec's image otherwise you almost have no way to use it, which means for server applications with both 2.5GbE together, I don't really think it can use more than 15W on full load, so 5V3A should be pretty safe.
I upgraded to 6.6.x (I don't recall the patch version), and I noticed that here were opkg dependency warnings that led me to believe there was kernel incompatibility. I don't really understand how packages work with OpenWRT and this fork, but I suspect that the snapshot releases targeting 6.1 the kernel have something to do with it.
Ultimately I reinstalled 6.1.77 to avoid the dependency issues mentioned above and stay somewhat align to snapshots, and it's been both stable and fast for me. Once the upstream snapshots use 6.6 I might upgrade again (or hopefully use the official OpenWRT repo by then).
I just use a compiled image from GitHub. This one to be precise. I boot from eMMC.
Yeah, I noticed that too. I'm also hopeful that the R6S will soon be supported officially, although I'm thankful for mj22226's fork in the meantime. Hopefully soon in snapshots and if we're lucky the next stable release.
I flashed 6.6 (using kernel 6.6.20) but ran into two issues:
The device doesn't reboot. When a reboot is issued, I have to physically power cycle the device.
When I download a backup (System -> Backup / Flash Firmware -> Generate archive) , it is 0 kb.
Has anybody else run into this and happen to know how to resolve these?
As an aside: I wanted to give shadowsocks a shot, and while I was having trouble getting it to install on a 6.1 image it installs on 6.6. I also noticed that less CPU (and clock speed) is used when running waveform's speed test, and I believe results in being able to use a higher ingress/egress value without added latency.
I noticed when flashing mj22226's latest openwrt and also the latest friendlywrt, eth2 shows as unavailable. Anyone else seeing this or know what I'm doing wrong? It's on of the 2.5gb ports so I really want to fix this.
I haven't noticed exactly what you're describing, but I have noticed with 6.6 (multiple patch versions) that the device seemingly doesn't boot at times. I just discovered it's because the two 2.5gb ports sometimes swap. I confirmed this by switching the cables (wan/lan) after it failed to start up correctly, and sure enough the device worked as expected afterwards. A few reboots later I needed to swap them again (back to their proper ports).
So...it would appear that there is some bug with respect to interface <--> port assignments on boot. Note that I haven't encountered this with 6.1, only 6.6.
Update: I was hoping that this solution would help with my issue seeing as how the problem is very similar, but I already have mac addresses explicitly specified in /etc/config/network:
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd3c:c5bc:e7f5::/48'
option packet_steering '1'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
list ports 'eth2'
config device
option name 'eth2'
option macaddr '0a:c9:3f:5d:79:be'
config device
option name 'eth0'
option macaddr '0a:c9:3f:5d:79:be'
config interface 'lan'
option device 'eth2'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
option delegate '0'
list dns '1.1.1.1'
list dns '8.8.8.8'
config device
option name 'eth1'
option macaddr '0a:c9:3f:5d:79:bd'
config interface 'wan'
option device 'eth1'
option proto 'dhcp'
I am on 6.6.22 posted last week but I still have the port swapping issue. I am using mjs image clean with no extra plugins. Once it switches it seems to stay that way so I have just swapped the cables around. I also noticed the same issue on immortalwrt with 6.1
