23.7 Fetch stops for unknown reason - Update not working

[BruceOS]

haha news - i downloaded one package ...wtf

Code: [Select]

  0) Logout                              7) Ping host
  1) Assign interfaces                   8) Shell
  2) Set interface IP address            9) pfTop
  3) Reset the root password            10) Firewall log
  4) Reset to factory defaults          11) Reload all services
  5) Power off system                   12) Update from console
  6) Reboot system                      13) Restore a backup

Enter an option: 12

Fetching change log information, please wait... fetch: transfer timed out

This will automatically fetch all available updates and apply them.

Proceed with this action? [y/N]: y

Updating OPNsense repository catalogue...
Fetching meta.conf: . done
pkg-static: http://mirror.fra10.de.leaseweb.net/opnsense/FreeBSD:13:amd64/23.7/latest/packagesite.pkg: Operation timed out
Fetching packagesite.txz: .......... done
Processing entries: .......... done
OPNsense repository update completed. 852 packages processed.
All repositories are up to date.
Updating OPNsense repository catalogue...
pkg-static: http://mirror.fra10.de.leaseweb.net/opnsense/FreeBSD:13:amd64/23.7/latest/meta.txz: Operation timed out
repository OPNsense has no meta file, using default settings
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (28 candidates): .......... done
Processing candidates (28 candidates): .......... done
The following 28 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        libedit: 3.1.20221030,1 -> 3.1.20230828,1
        opnsense: 23.7.5 -> 23.7.6
        php82: 8.2.10 -> 8.2.11
        php82-ctype: 8.2.10 -> 8.2.11
        php82-curl: 8.2.10 -> 8.2.11
        php82-dom: 8.2.10 -> 8.2.11
        php82-filter: 8.2.10 -> 8.2.11
        php82-gettext: 8.2.10 -> 8.2.11
        php82-ldap: 8.2.10 -> 8.2.11
        php82-mbstring: 8.2.10 -> 8.2.11
        php82-pcntl: 8.2.10 -> 8.2.11
        php82-pdo: 8.2.10 -> 8.2.11
        php82-session: 8.2.10 -> 8.2.11
        php82-simplexml: 8.2.10 -> 8.2.11
        php82-sockets: 8.2.10 -> 8.2.11
        php82-sqlite3: 8.2.10 -> 8.2.11
        php82-xml: 8.2.10 -> 8.2.11
        php82-zlib: 8.2.10 -> 8.2.11
        py39-Babel: 2.12.1 -> 2.13.0
        py39-boto3: 1.28.52 -> 1.28.62
        py39-botocore: 1.31.52 -> 1.31.62
        py39-cffi: 1.15.1 -> 1.16.0
        py39-charset-normalizer: 3.2.0 -> 3.3.0
        py39-numexpr: 2.8.6 -> 2.8.7
        py39-s3transfer: 0.6.2 -> 0.7.0
        py39-urllib3: 1.26.16,1 -> 1.26.17,1
        ruby31-gems: 3.4.19 -> 3.4.20
        syslog-ng: 4.3.1_1 -> 4.4.0

Number of packages to be upgraded: 28

24 MiB to be downloaded.
[1/28] Fetching php82-session-8.2.11.pkg: ..... done
pkg-static: http://mirror.fra10.de.leaseweb.net/opnsense/FreeBSD:13:amd64/23.7/latest/All/php82-zlib-8.2.11.pkg: Operation timed out
Starting web GUI...done.
Generating RRD graphs...done.


i guess
pkg-static: http://mirror.fra10.de.leaseweb.net/opnsense/FreeBSD:13:amd64/23.7/latest/packagesite.pkg
is the part which makes the update fail


later three fetches then - TImeout - any way to set the TImeout ?

Code: [Select]

***GOT REQUEST TO UPDATE***
Currently running OPNsense 23.7.5 at Tue Oct 17 22:01:45 CEST 2023
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.pkg: .......... done
Processing entries: .......... done
OPNsense repository update completed. 852 packages processed.
All repositories are up to date.
Checking for upgrades (28 candidates): .......... done
Processing candidates (28 candidates): .......... done
The following 28 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
libedit: 3.1.20221030,1 -> 3.1.20230828,1
opnsense: 23.7.5 -> 23.7.6
php82: 8.2.10 -> 8.2.11
php82-ctype: 8.2.10 -> 8.2.11
php82-curl: 8.2.10 -> 8.2.11
php82-dom: 8.2.10 -> 8.2.11
php82-filter: 8.2.10 -> 8.2.11
php82-gettext: 8.2.10 -> 8.2.11
php82-ldap: 8.2.10 -> 8.2.11
php82-mbstring: 8.2.10 -> 8.2.11
php82-pcntl: 8.2.10 -> 8.2.11
php82-pdo: 8.2.10 -> 8.2.11
php82-session: 8.2.10 -> 8.2.11
php82-simplexml: 8.2.10 -> 8.2.11
php82-sockets: 8.2.10 -> 8.2.11
php82-sqlite3: 8.2.10 -> 8.2.11
php82-xml: 8.2.10 -> 8.2.11
php82-zlib: 8.2.10 -> 8.2.11
py39-Babel: 2.12.1 -> 2.13.0
py39-boto3: 1.28.52 -> 1.28.62
py39-botocore: 1.31.52 -> 1.31.62
py39-cffi: 1.15.1 -> 1.16.0
py39-charset-normalizer: 3.2.0 -> 3.3.0
py39-numexpr: 2.8.6 -> 2.8.7
py39-s3transfer: 0.6.2 -> 0.7.0
py39-urllib3: 1.26.16,1 -> 1.26.17,1
ruby31-gems: 3.4.19 -> 3.4.20
syslog-ng: 4.3.1_1 -> 4.4.0

Number of packages to be upgraded: 28

24 MiB to be downloaded.
[1/27] Fetching php82-zlib-8.2.11.pkg: ... done
[2/27] Fetching php82-dom-8.2.11.pkg: ......... done
[3/27] Fetching php82-simplexml-8.2.11.pkg: ... done
pkg-static: http://mirror.fra10.de.leaseweb.net/opnsense/FreeBSD:13:amd64/23.7/latest/All/php82-pdo-8.2.11.pkg: Operation timed out
Starting web GUI...done.
Generating RRD graphs...done.
***DONE***



[wired2network]

BruceOS

I am receiving this same error with only 1 WAN interface on multiple boxes. I too am at wits end, but the only solution I found was to disable the firewall and go and run updates which works but reinstating firewall goes back to the same issues. I receive the error of:

Fetching changelog information, please wait... fetch: transfer timed out
fetch: /usr/local/opnsense/changelog/changelog.txz appears to be truncated: 0/115144 bytes

The configs didn't change, so I am inclined to think the error isn't with that. I've tried the disabling IPS from previous posts that had something similar. I can use OPNsense to ping from LAN, WAN and 127.0.0.1 to 89.149.222.99 as well as computer with all pings going through. I can even open the URL for the updates without issue.

Performing a Status verification takes minutes, much longer than normal. At one point it showed a Firmware: Reporter error but I can't get it to show again. If I remember correctly, it was a phalcon MVC error in pulling the status.

[newsense]

Can you post a screenshot from Unbound Settings - General, Query Forwarding and DNSoverTLS please ?

This still loos like a misconfiguration, so reinstalling and importing the old configuration will bring you back to the same roadblock.

[wired2network]

Here are my screenshots from unbound

[newsense]

You need to forward the queries received by Unbound to an upstream resolver - preferably over TLS.

If using DoT then add 1.1.1.2 and 9.9.9.11 as IPs on port 853 - and it should suffice to get you going.


BruceOS - please check if you're in a similar situation as seen in the screenshots posted above.

[wired2network]

I figured out what I had changed that caused the issue! I had started to play with RSS and enabled it as per OPNsense's guide setting net.inet.rss.enabled = 1. I set it back to '0' and everything started to pull correctly!

newsense, thank you for your suggestions! I did set the query forward settings but that didn't resolve the issue. made the RSS change, removed the query forward configuration, and did a reboot and the system is still back to working.

BruceOS, if you set up the RSS try disabling and running again.

Franco, I think something may be off with RSS which is denying the ability to fetch update status and reach the update server.

[BruceOS]

net.inet.rss.enabled=0  (Fetching via IPv4 works again via WAN1)
  THANK YOU -Progress - added that rss value to tunables when going to multicore CPU - setting it to 0 solved fetching problem. - But it still does not update correctly. but with the knowledege i have i post a working setting for MultiWAN in the evening.


pkg-static  (fetch)  :   Systems -> Settings -> Tunables -> net.inet.rss.enabled=0  (Fetching via IPv4 works again via WAN1

pkg update            :    Systems -> Settings -> General ->  [ ] Prefer to use IPv4 even if IPv6 is available (NOT CHECKED)

for me the Problem is solved

PS: added "net.inet.rss.enabled=1" in 2022 and it was running until "now" without problems.

[rrosson]

@BruceOS You are not alone. I am also multi-wan and seeing the same issues as you are.