Opkg update issues after sysupgrade to 24.10.0 [solved]

This post concerns an issue very much like the one described at Can't Update the opkg update list - #2 by psherman. The main difference between what's described there and my setup is that the connection to the internet of my gateway/router/AP is through its WAN port that connects to a cable modem. Connectivity is working fine through the router for the most part and I can ping internet address by ip or name from the router itself as well as from most connected hosts. But somehow opkg will not update package lists, as the output below indicates (very much like the output posted in the linked thread):

Downloading https://downloads.openwrt.org/releases/24.10.0/packages/aarch64_cortex-a72/telephony/Packages.gz
Failed to send request: Operation not permitted
*** Failed to download the package list from https://downloads.openwrt.org/releases/24.10.0/packages/aarch64_cortex-a72/telephony/Packages.gz

Collected errors:
 * opkg_download: Failed to download https://downloads.openwrt.org/releases/24.10.0/targets/bcm27xx/bcm2711/packages/Packages.gz, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://downloads.openwrt.org/releases/24.10.0/packages/aarch64_cortex-a72/base/Packages.gz, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://downloads.openwrt.org/releases/24.10.0/targets/bcm27xx/bcm2711/kmods/6.6.73-1-2577896cea679d46fe670142cc9703c1/Packages.gz, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://downloads.openwrt.org/releases/24.10.0/packages/aarch64_cortex-a72/luci/Packages.gz, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://downloads.openwrt.org/releases/24.10.0/packages/aarch64_cortex-a72/packages/Packages.gz, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://downloads.openwrt.org/releases/24.10.0/packages/aarch64_cortex-a72/routing/Packages.gz, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://downloads.openwrt.org/releases/24.10.0/packages/aarch64_cortex-a72/telephony/Packages.gz, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

I tried one of the solutions posted in the linked thread, which was to add an additional DNS line for a public DNS server (1.1.1.1) via Luci interface Network > Interfaces > Edit (lan) > Advanced Settings > Use Custom DNS servers. That is reflected in other output I will post. The address 192.168.1.1 was already included there btw. But I still cannot update packages lists, even after adding the additional DNS entry.
Here's output from a couple of the other commands suggested in the linked thread.

ubus call system board
{
	"kernel": "6.6.73",
	"hostname": "pi4",
	"system": "ARMv8 Processor rev 3",
	"model": "Raspberry Pi 4 Model B Rev 1.1",
	"board_name": "raspberrypi,4-model-b",
	"rootfs_type": "ext4",
	"release": {
		"distribution": "OpenWrt",
		"version": "24.10.0",
		"revision": "r28427-6df0e3d02a",
		"target": "bcm27xx/bcm2711",
		"description": "OpenWrt 24.10.0 r28427-6df0e3d02a",
		"builddate": "1738624177"
	}
}

and

cat /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 'fd84:8760:6d55::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	list dns '192.168.1.1'
	list dns '1.1.1.1'

config interface 'eth0'
	option proto 'dhcp'
	option device 'eth0'

config interface 'WAN'
	option proto 'dhcp'
	option device 'eth1'

config device
	option name 'eth1'

I can post other such output if it will prove helpful in diagnosing this issue. Thanks

Delete this:

Reboot and try again. If that doesn't work, please post the updated network config as well as the firewall file.

Ok. I think that output was after I'd already rebooted but I'll reboot again just to be sure.

Commented out those lines and rebooted. Still no luck running opkg update (same error messages as above) or using the Luci "update lists" button. Below is the additional requested output.

cat /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 'fd84:8760:6d55::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	list dns '192.168.1.1'
	list dns '1.1.1.1'

config interface 'WAN'
	option proto 'dhcp'
	option device 'eth1'

config device
	option name 'eth1'

and

cat /etc/config/firewall
config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option masq '1'
	list network 'lan'
	list network 'eth0'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list network 'wan'
	list network 'wan6'
	list network 'WAN'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config rule
        option name 'stopsshd'
        option proto 'tcpudp'
        option dest_port '22'
        option target 'DROP'

config rule
        option name 'stophttp'
        option proto 'tcpudp'
        option dest_port '80'
        option target 'DROP'

config rule
        option name 'stophttps'
        option proto 'tcpudp'
        option dest_port '443'
        option target 'DROP'

config include
	option path '/etc/firewall.user'

config redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option proto 'tcp udp'
	option src_dport '60000'
	option dest_ip '192.168.1.106'
	option dest_port '22'
	option name 'ssh'

Remove the masq line and the network eth0 from the section above.

Delete all of the rules above.

Reboot and try again if that doesn’t work, let’s see the first two octets of the following command: ifstatus wan | grep address

Commenting out those rules and rebooting got opkg working again, thanks. So evidently I've once again gotten myself totally confused in thinking it was the update that was causing opkg/ddns problems whereas it was apparently instead one or more of the 3 firewall rules I'd recently added.
I'd like to ask nonetheless, is it one, two, or all of those rules that were causing the problem I was seeing? Also what is the mechanism by which the interference was occurring? I took those rules to be blocking incoming traffic on ports I never use for incoming traffic on my gateway/router/AP. Was I wrong in making those assumptions?
Additional clarification will be much appreciated.

It theoretically was blocking all the https traffic out of your router (at least the traffic originating from your router itself).

What was your intent with those rules? They aren't necessary in the vast majority of cases... not sure what you were trying to do.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! :slight_smile:

I ran an online port scan that showed those ports were open to the internet so I looked around for a solution for closing/hiding them and found those stanzas. I don't run any web servers or imap from my little home network so why should I have ports 80 and 443 open? And I sure don't want port 22 open since I run ssh on a non-standard port. So that was an attempt, as least in my understanding, to close those or hide those ports.

Depending on where that port scan actually runs (i.e. from your computer or from a server on the internet), it might have different results. Further, some of them are not accurate.

The default firewall configuration does not allow any unsolicited ingress from the wan.