Timeout while connecting to the selected mirror.

[tre4bax]

This is getting pretty frustrating.

I have had an issue with the above message for some time now.  The conclusion the last time I raised this was I needed to rebuild from scratch.

Today I did that (finally on my own!).  Once I did this I had it working fine and ran a check for updates.  Off it went and installed 18.7.7  Job done  :-), or so I thought.

Having succeeded in doing an update I decided that I would now install the plugins again.  Guess what I am back to where I was with the timeout.  The only clue I have is that the above message is in the logs every time I try and do an update.

configd.py: [41b52d75-3aa2-43c3-a09b-abc3703b319f] Script action failed with Command 'pkg rquery "%n|||%v|||%c|||%sh|||0|||%L"' returned non-zero exit status 74 at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/processhandler.py", line 481, in execute stdout=output_stream, stderr=error_stream) File "/usr/local/lib/python2.7/subprocess.py", line 190, in check_call raise CalledProcessError(retcode, cmd) CalledProcessError: Command 'pkg rquery "%n|||%v|||%c|||%sh|||0|||%L"' returned non-zero exit status 74


This is really frustrating as now I have none of the plugins I want to use and no ability to load them.  None of the mirrors work and I will be back to being unable to get security updates.  Please can someone help?

[tre4bax]

Again I poke into this.

If I do opnsense-update -M then that returns back to me:

https://mirrors.dotsrc.org/opnsense/FreeBSD:11:amd64/18.7

now if I try and ping this from my desktop I find that it is at 130.225.254.116 and I get 100% of pings back in 53ms.  This desktop is conected to the internet via the opnsense router.

If I go to the router and Interfaces->Diagnostics->Ping and run a ping on 130.225.254.116 it does not find it.  0% packets are returned.  This also fails if I telnet into the console and run ping.  Trace route fails too and gives me nothing to show where the break is occuring.

This is my routing status printed out (no idea why the IPV6 stuff is there as I have turned IPV6 off in both interfaces).  This seems to work fine when accessed from the LAN, so my understanding issue is somewhere in the internal structure of the program.

ipv4   default                                           212.158.250.36   UGS    1814   1492   pppoe0   wan   
ipv4   1.0.0.1                                           212.158.250.36   UGHS   3823   1492   pppoe0   wan   
ipv4   1.1.1.1                                           212.158.250.36   UGHS   2865   1492   pppoe0   wan   
ipv4   90.255.226.54                                   link#9           UHS    0   16384   lo0       
ipv4   127.0.0.1                                           link#6           UH    4656 16384   lo0       
ipv4   192.168.1.0/24                                   link#3           U    1162628   1500   em2     lan   
ipv4   192.168.1.1                                   link#3           UHS    0   16384   lo0       
ipv4   212.158.250.36                                 link#9           UH    7479   1492   pppoe0   wan   
ipv6   ::1                                                   link#6           UH    0   16384   lo0       
ipv6   fe80::%em2/64                                   link#3           U    0   1500           em2     lan   
ipv6   fe80::ee8:5cff:fe68:bac2%em2           link#3           UHS    0   16384   lo0       
ipv6   fe80::%em3/64                                   link#4           U    0   1500     em3       
ipv6   fe80::ee8:5cff:fe68:bac3%em3           link#4           UHS    0   16384   lo0       
ipv6   fe80::%lo0/64                                   link#6           U    0   16384   lo0       
ipv6   fe80::1%lo0                                   link#6           UHS    0   16384   lo0       
ipv6   fe80::%pppoe0/64                           link#9           U    0   1492           pppoe0   wan   
ipv6   fe80::ee8:5cff:fe68:bac0%pppoe0   link#9           UHS    0   16384   lo0       


something weird is going on and I have run out of ideas again.  I did try running the update locally from the boot menu option 12, that also said it could not find the mirror.  Which clearly nothing on the firewall itself can.  Is there some kind of security setting that makes the device itself unable to send packets external or receive from those locations whilst still passing through traffic from the network?  If not then I am completely stumped and any suggestion of something to try would be appreciated.

[tre4bax]

And now I know why I have seperate entries for the DNS servers.

In the Settings-> General tab I have added a WAN route for the DNS servers.  This should be optional however if I remove this entry the DNS servers become unavailable.

Something is very strange about my configuration. 

[tre4bax]

Having followed this through to the logical conclusion.

If I access the shell of the opnsense device and Ping anything it fails with the exception of the DNS on 1.0.0.1 and 1.1.1.1.

These are different because in the settings general area I gave them a gateway.  This created the route shown above in my routing table.  Therefore my logic was if I add a static route to the update server I should be able to contact it and it should work.

I did opnsense-update -M which returned a url starting with pkg.opnsense.org.  This returned an IP address of 212.32.245.132.   I added a route to 212.32.245.0/24 in the routes area.  Now I can ping the update server fine.  Running an update works fine too.

I don't know why I need to do this and if the update server is using a range of addresses this will fail again if they are not in that subnet.  I can't see why the device cannot use the default route.  However with the knowledge from this I can at least keep fixing the problem as I go.

[franco]

Are you using Multi WAN?


Cheers,
Franco

[tre4bax]

Nope just a regular PPPoE wan to a domestic broadband using a Huawei HG612 as a modem.  Opnsense Box is a dedicated mini PC with 4 network ports.  Just one WAN and one LAN connected at present.

[Stifler]

Just registered to share my issue that caused this same problem.

If you installed the Sunny Valley Networks "Sensei" package for OPNSense, and then uninstalled it, it leaves behind traces in the /etc/local/etc/pkg/repo folder.

The best thing to do is open the file left behind (sunneyvalley.conf) and disable the repo. Then update the pkg system.

pkg update -f

Might not be Sensei, but could be something installed that left cruft on your system.

[tre4bax]

Ta Stifler,

In my case I did refresh the switch from scratch using a USB stick.  As soon as it did an update to a more modern version the issue started to happen.  I'd not installed anything personally.  It may be something that gets updated in the upgrade process causes this though

[mojojojotroi]

Hi,

Since I added in the web GUI a static route 0.0.0.0/0 to my ISP WAN gateway, all web GUI wizards/tools who connect to internet seems to work well.
It seems that some web GUI tools don't use the existing system routes table...