18.06-SNAPSHOT 'Distribution Feeds' 404

I see that my 18.06-SNAPSHOT 'Distribution Feeds' are now 404:

src/gz openwrt_core http://downloads.openwrt.org/releases/18.06-SNAPSHOT/targets/ramips/mt7621/packages
src/gz openwrt_base http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/base
src/gz openwrt_luci http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/luci
src/gz openwrt_packages http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/packages
src/gz openwrt_routing http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/routing
src/gz openwrt_telephony http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/telephony

Assuming they all exist: Is it acceptable to just replace all of them with the last release in that series? ie:18.06.9 ?

src/gz openwrt_core http://downloads.openwrt.org/releases/18.06.9/targets/ramips/mt7621/packages
src/gz openwrt_base http://downloads.openwrt.org/releases/18.06.9/packages/mipsel_24kc/base
src/gz openwrt_luci http://downloads.openwrt.org/releases/18.06.9/packages/mipsel_24kc/luci
src/gz openwrt_packages http://downloads.openwrt.org/releases/18.06.9/packages/mipsel_24kc/packages
src/gz openwrt_routing http://downloads.openwrt.org/releases/18.06.9/packages/mipsel_24kc/routing
src/gz openwrt_telephony http://downloads.openwrt.org/releases/18.06.9/packages/mipsel_24kc/telephony

Or is it even safe to jump to the latest 23.05.0?

Yes, snapshots would be gone...

No. Not okay. It will probably not work when you attempt to install packages. If packages do install, it will likely brick your device.

Maybe... it's certainly not safe to use 18.06 which has been EOL and unsupported for years. It has many known vulnerabilities that will never be patched, so you shouldn't be using this version anymore.

The jump to 23.05 will absolutely require resetting to defaults and configuring from scratch. The process of installing the new version (and the question about if you can even run it) depends on your device.

What is the ouput of:

ubus call system board
1 Like
root@router:~# ubus call system board
        "kernel": "4.14.137",
        "hostname": "router",
        "system": "MediaTek MT7621 ver:1 eco:3",
        "model": "Newifi-D2",
        "board_name": "d-team,newifi-d2",
        "release": {
                "distribution": "OpenWrt",
                "version": "18.06-SNAPSHOT",
                "revision": "r7835-89808e211c",
                "target": "ramips\/mt7621",
                "description": "OpenWrt 18.06-SNAPSHOT r7835-89808e211c"

There shouldn't be any issue with that hardware on contemporary OpenWrt (mt7621a+mt7603e+mt7612, 32/512), nor anytime soon.

1 Like

Your device will have made a transition to the new DSA architecture in 21.02, so you may have difficulty upgrading directly from the current version to 21.02 or higher.

Therefore, my recommendation for the upgrade path is:

current (18.06-snapshot) -> 19.07.10
19.07.10 > 21.02.7 <<<--- see note below
21.02.7 > 23.05.0

Note about the 19.07 > 21.02 upgrade: you will very likely see a warning about an unsupported image or similar. As long as you verify that you have downloaded the correct file and that the checksum matches the website, you can force the upgrade.

In all cases, you'll be using the sysupgrade images. And you should reset to defaults during each upgrade -- this means unchecking the box for keep settings (or using the -n argument if you are using the command line sysupgrade process).

You can make a backup of your current config if you like -- this can be useful as a human readable reference as you reconfigure from scratch when you're done with the upgrades. Do not, under any circumstances, attempt to restore the backup file or manually copy the files back to your router -- you'll almost certainly soft-brick your device in that case.

1 Like

Not completely horrifying, looks like I'll have to put my brain on for that process and the settings recovery though.

Presumably there will be many lines that will be safe to simply paste over.... but how to know...

Given that you are talking about four major releases spanning half a decade of time, the only sensible answer to this is 'no'.

Yes, there will be 'some things', but for upgrading one device, it's more time to disentangle what can and what cannot be kept is more effort, than just starting from a clean slate. And all of the major configuration files will require 'some changes', including quite a few (plural) that will (soft-)brick your device if you don't get it right.

1 Like

Generally, don't even try. But, if you have things like DHCP reservations or firewall rules, those may transfer.

You can post your current config here and we can help you determine what is safe to transfer over (and how to do it).

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall

(and if you have any other services enabled such as OpenVPN or anything else, let us know.

1 Like

True, to some extent - but even there are significant gotchas.
dhcp - ujail, keep the old config and dnsmasq will fail to start, no DHCPd, no DNS resolution.
firewall - firewall.user sourcing, which will blow up with fw4.
Things like this will affect all major config files between all those versions (network (DSA), system (compat_version, LED/ GPIOs), wireless (interface naming), …)

If you really know what you're doing, are comfortable with diff and audit each line, full steam ahead - for the normal user who can't remember the details of what needs changing between all those versions, not so much, just a guarantee for a disaster.

1 Like


In most cases, I would not recommend trying to preserve any previous bits of the configs...

If the OP has a config that has what I'll call 'tedius complexities' (i.e. lots of DHCP reservations or a whole bunch of basic firewall rules like port forwards and such), it might be possible to copy/paste certain sections safely.

Seeing the config will certainly help us understand the scope of the OP's reconfiguration process, and we can advise on what is safe/not-safe to migrate and when it is worth or not worth that potential risk.

Absent those 'tedius complexities', I think that many basic-to-moderate complexity configurations can be recreated from scratch in under 20 minutes when referencing the previous config.... but yeah, entering in a few dozen MAC/IP address pairs might be annoying.

This does give me a FR idea -- not sure if it's worth the development effort, but a CSV or JSON file export/import of DHCP reservation data could be a time saver for people who do have a lot of reservations they wish to preserve.
1 Like

That IS the basic kind of thing I'm thinking of. The syntax i'm seeing from the commands you requested looks like stuff i can mostly paste into the right spots.
My setup is pretty basic, but there are probably more computers/devices than the usual household has... and frankly the wrt interface is often a little alien, especially between variants and versions. ... plus my familiarity with it is lacking. So I'm just checking some boxes before I start thinking how to record settings and approach the no-internet-resurrection-with-potential-device-death phase.
I really wonder why dual boot routers arent standard every time I go to do something like this.

also: can someone point me at the best "how do i flash/upgrade wrt" guide please?

I'm happy to review your configs to help advise if it is safe and how you might go about the process.

The commands I listed were just to output the current configurations for the 4 files so that you can copy/paste that for review. It doesn't have anything to do with how you would migrate the config elements or if it is safe to do so.

Do you have the LuCI web interface (i.e. can you reach your router using a standard web browser)? Yes, there are more options available than most vendor firmware, but for the most part is is pretty common stuff and mostly well organized.

If you're looking at the command line interface via ssh, yes, that can be daunting.

Generate a backup an then you can just open the tar.gz file to see all the config files within. Also, if you want us to review your config before you go further, we can probably give you an idea about any likely gottchas you may need to know about before you start (or, conversely, if the default config will be more or less plug and play).

One thing to know is that you will need to be connected to your router via ethernet. Wifi is disabled by default.

Not to say that there is zero risk (there is always some risk of problems when you flash a device), but the OpenWrt sysupgrade process is quite reliable and robust. If you follow the process I described, it should go smoothly. (I cannot guarantee trouble-free, but I would make any concerns/risks clear if there were any beyond the general idea of 'yes, a flash can fail in rare circumstances')

They are becoming more common... but it's more expensive, so that's why it's not entirely common.

If you have the LuCI web interface running on your device now, that's the easiest way. If not, the CLI method is still pretty straightforward.

Thanks. I will paste them here when i have time to look through them myself. This process is just a tangent to somehting else I was doing.... so i'll have to get back to you on that :slight_smile:

Yeah. But no doubt I'll be ssh'ing too.
I just recall finding it needed extra braincells to follow youtube tutorials of different versions/forks; and 2023-2018 is not a trivial version/fork span.


Yup. But it looms none-the-less, as soon as the router is down and an issue arises which the internet could otherwise answer.


IMO, you're overthinking it... you don't need to watch youtube videos (which are often too long/complex or even wrong)

  1. Connect via ethernet (you could use wifi, but you'll need ethernet after this), create a backup file of your existing config.

  2. Download the sysupgrade file for 19.07.10

  3. Use the LuCI web interface to do the upgrade -- simply uncheck the "keep settings box"

  4. Download the sysupgrade file for 21.02.7

  5. Use the LuCI web interface to do the upgrade -- simply uncheck the "keep settings box" and you'll probably also need to select the "force upgrade" box.

  6. Download the sysupgrade file for 23.05.0

  7. Use the LuCI web interface to do the upgrade -- simply uncheck the "keep settings box"

  8. reconfigure.

Probably, but any time I dont overthink things I end up with an issue. As someone for whom using a phone to research linux issues feels like I'm dying of nerf... i like to know the internet will be PC accessible again asap when i start prodding my router.

Youtube: This was just to figure out how to add something a few weeks ago. But it was apparent the options were reasonably different from my 2018 gui.

that checklist


Just be aware that some YT videos may be great, and other may give bad information (sometimes bad = unnecessary steps and/or making it seem more complex than it really is; other times bad = misinformation that will cause headaches and/or harm).

So there are certainly differences between the versions of OpenWrt, but some of them come down to the "themes" -- literally just the visual appearance of the GUI. The upgrade screens, though, are usually pretty self-explanatory.

Yep. I'm not entirely new to this. :slight_smile:
Thanks, I will report in with configs and/or results...later.

OK, it's done. I survived, the router survived.
As expected there was a small lack of preparatory overthinking in some areas: I forgot to read up on VLAN before starting, so naturally that became a problem for half an hour until I figured out how to connect PPPoE to it.... and of course the networked notes that always I take for granted and was referring to during the process dropped out, so I had to brain a little harder till I got that back.
But in all the rummaging I did also notice that one port is only running at base100, so thats nice to notice and look into why.

Nice. Many thanks for the assist.

Now I just need to figure out how to make my 5GHz radio into isolated guest access again. Somehow when I did it last month I utterly forgot to document it one iota..and that never happens.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.