Maybe a bit off topic...
But I leave this here for people that have to use a double NAT setup.
For example if you have to use your ISP router and your OpenWRT box behind it.
UPNP also passes the public IP as info to the clients.
(I'm sure PS4 uses this info)
In a double NAT setup this will not work. (Because a private IP is passed over to the clients)
To fix this, change/add option external_ip 'your public ip address'
to your miniupnpd conf.
It also possible to modify the miniupnpd init script to automatically get the public IP address.
And enable DMZ mode on your ISP router. (to the IP address of your OpenWRT box)
Or forward all high ports (1024-65535) to your OpenWRT box.
But for cgNAT, your ISP has to open/forward the ports or to give a public IP.
I'm aware of that. But with the current speed of the 21.02 release, it's highly unlikely that the mainstream/core devices can be brought up to 5.10 kernel target before the end of the year. Focus right now is on getting 21.02 into a final stage, then the update to kernel-5.10, and only after that will we have a new release branch.
I also hope that the new major version gets branched before the end of the year - and also that a biannual release schedule can be picked up for faster device support - but realistically, it's not going to happen until early next year, hence the 22.02 prediction. It might be that we do get a 21.12 release, but it's getting more and more unlikely as we go into the second half of the year.
@daniel seems to know more about the status of master, so maybe he can confirm some details (like, how many devices are targeting 5.10 in master right now, if there's any blocking issues, etc.).
That question can be easily answered by anyone, just check the source:
KERNEL_TESTING_PATCHVER existing, and being specified as kernel 5.10 at least suggests that someone has taken the effort of porting the target in question and that the basics work to a considerable extent. Yes, you do have to traverse into the sub-targets, to get the full picture, e.g.:
Yeah, one can do that - I was more thinking that a core developer working on OpenWrt might have a slightly quicker, OTOH answer, something like "most targets are running 5.10 without issues, but we have arch X having issues with this and that".
Could someone offer me a few pointers, on how to chase-down a problem?
I've got snapshot r17443-90e167abaa / git-21.226.86205-376af36 (UBI) installed on my E8450. After a spontaneous reboot, I find all the settings disappeared, and it seems that nothing but tempfs is mounted. This means I can't make any durable changes, and it seems I can't upgrade, as well, which I had thought might fix the default mount points. (I've tried via a direct install of downloaded images, and via luci-app-attendedsysupgrade.)
FWIW, it was behaving nicely for several weeks, before the reboot, with wi-fi and SQM, excellent throughput, etc.
Oops. I can't build the installer on OSX. But using the pre-built images at https://github.com/dangowrt/linksys-e8450-openwrt-installer/releases, with "force" on the recovery-installer, then installing the ubi-squashfs update, then reboot ... puts me right back into snapshot r17443-90e167abaa, with nothing but tmpfs.
I was somehow stuck in initramfs/recovery mode. I force (re-)installed the ubi-squashfs-sysupgrade.itb that I originally used to install v0.5.3. This now showed /rom mounted.
Then, I used ssh and opkg to get 'auc' installed, and 'auc -f' was able to pull and install the new image.