Messages

1

22.1 Legacy Series / Re: pkg, fetch & update check issues after updating to 22.1

« on: January 15, 2022, 02:46:41 am »

NP - it was your other post that prompted me to test it.

I wonder if franco has any thoughts on why this happened to some of us. Either way, I'm glad it's fixed.

2

22.1 Legacy Series / Re: pkg, fetch & update check issues after updating to 22.1

« on: January 15, 2022, 02:21:40 am »

I think this only partially upgrades the firewall.

With that being said, you can actually set the firewall to prefer ipv4. I did this and the update process worked again. Now that I'm on 22.1rc1, I unset the prefer ipv4 option, rebooted to be safe, and update checks are still working fine.

I'm wondering if there was just some issue with pkg/fetch and ipv6 connectivity on some of the dev builds? I know ipv6 works fine for me on the latest community build and it now seems fine again on 22.1rc1.

3

22.1 Legacy Series / Re: pkg, fetch & update check issues after updating to 22.1

« on: January 14, 2022, 01:02:18 pm »

Code: [Select]

root@OPNsense:~ #  ping -c4 -s1500 pkg.opnsense.org
PING6(1548=40+8+1500 bytes) 2600:8805:7f20:200:f0c0:8e63:4c48:70d3 --> 2001:1af8:4f00:a005:5::
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=0 hlim=51 time=100.618 ms
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=1 hlim=51 time=98.166 ms
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=2 hlim=51 time=98.463 ms
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=3 hlim=51 time=98.095 ms

--- pkg.opnsense.org ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 98.095/98.835/100.618/1.038 ms
root@OPNsense:~ #
root@OPNsense:~ #
root@OPNsense:~ # ping6 -c4 -s1500 pkg.opnsense.org
PING6(1548=40+8+1500 bytes) 2600:8805:7f20:200:f0c0:8e63:4c48:70d3 --> 2001:1af8:4f00:a005:5::
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=0 hlim=51 time=98.541 ms
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=1 hlim=51 time=98.151 ms
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=2 hlim=51 time=99.409 ms
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=3 hlim=51 time=99.212 ms

--- pkg.opnsense.org ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 98.151/98.828/99.409/0.506 ms
root@OPNsense:~ #
root@OPNsense:~ #
root@OPNsense:~ # ping -c4 -s1500 mirror.dns-root.de
PING6(1548=40+8+1500 bytes) 2600:8805:7f20:200:f0c0:8e63:4c48:70d3 --> 2606:4700:3036::ac43:ce5d
1508 bytes from 2606:4700:3036::ac43:ce5d, icmp_seq=0 hlim=58 time=13.659 ms
1508 bytes from 2606:4700:3036::ac43:ce5d, icmp_seq=1 hlim=58 time=13.070 ms
1508 bytes from 2606:4700:3036::ac43:ce5d, icmp_seq=2 hlim=58 time=11.723 ms
1508 bytes from 2606:4700:3036::ac43:ce5d, icmp_seq=3 hlim=58 time=12.884 ms

--- mirror.dns-root.de ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 11.723/12.834/13.659/0.702 ms
root@OPNsense:~ #
root@OPNsense:~ # ping6 -c4 -s1500 mirror.dns-root.de
PING6(1548=40+8+1500 bytes) 2600:8805:7f20:200:f0c0:8e63:4c48:70d3 --> 2606:4700:3034::6815:16b3
1508 bytes from 2606:4700:3034::6815:16b3, icmp_seq=0 hlim=58 time=12.176 ms
1508 bytes from 2606:4700:3034::6815:16b3, icmp_seq=1 hlim=58 time=12.748 ms
1508 bytes from 2606:4700:3034::6815:16b3, icmp_seq=2 hlim=58 time=13.794 ms
1508 bytes from 2606:4700:3034::6815:16b3, icmp_seq=3 hlim=58 time=12.641 ms

--- mirror.dns-root.de ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 12.176/12.840/13.794/0.591 ms
root@OPNsense:~ #
root@OPNsense:~ #
root@OPNsense:~ # ping -4 -c4 -s1500 mirror.dns-root.de
PING mirror.dns-root.de (172.67.206.93): 1500 data bytes
1508 bytes from 172.67.206.93: icmp_seq=0 ttl=59 time=13.823 ms
1508 bytes from 172.67.206.93: icmp_seq=1 ttl=59 time=14.634 ms
1508 bytes from 172.67.206.93: icmp_seq=2 ttl=59 time=13.123 ms
1508 bytes from 172.67.206.93: icmp_seq=3 ttl=59 time=12.400 ms

--- mirror.dns-root.de ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 12.400/13.495/14.634/0.828 ms
root@OPNsense:~ #

----

My update issue occurs right after upgrading from latest community to dev build. It seems I can't even try to get on 22.1rc1 due to the issues with fetch and pkg after switching to dev.

On community, no issues with updates. If I roll back my VM, no issues.

It doesn't seem to matter which mirror I select. In fact, fetch seems to act up with any url I throw it, and it is not a DNS issue from what I can see.

4

22.1 Legacy Series / Re: pkg, fetch & update check issues after updating to 22.1

« on: January 14, 2022, 01:47:17 am »

I experienced the same issue with updates in a VM but with physical nics passed through (no virtual nic). Does this rule out fragmenation due to running in a VM?

5

21.7 Legacy Series / Re: pkg, fetch & update check issues in 21.7.5

« on: January 14, 2022, 01:44:05 am »

I experienced the same issue with updates in a VM but with physical nics passed through (no virtual nic). Does this rule out fragmenation due to running in a VM?

6

Hardware and Performance / Re: Poor Throughput (Even On Same Network Segment)

« on: December 05, 2021, 07:48:25 pm »

I'm chiming in to say I have seen similar issues. Running on proxmox, I can only route about 600 mbps in opnsense using virtio/vtnet. A related kernel process in opnsense shows 100% cpu usage and the underlying vhost process on the proxmox host is pegged as well.

Trying a Linux VM on the same segment (i.e. not routing the opnsense) saturates my 1gig nic on my desktop with only 25% cpu usage on the associated vhost process for the VMs nic.

I know some blame has been put on CPU speed/etc., but I think there is some sort of performance issue with the vtnet drivers. Even users of pfsense have had similar complaints. I also tried the new opnsense development build (freebsd 13) with no improvement.

I passed my nic through to the opnsense VM and reconfigured the interfaces and can route 1gbps no sweat. This is with the em driver (which supports my nic).

Note: I can get 1gbps with multiple queues set on the vtnet adapters for the opnsense VM. However, this still doesn't fix the performance issue with a single "stream."

7

21.1 Legacy Series / Re: Two reboot commands needed to reboot opnsense (WebUI)

« on: April 10, 2021, 05:44:28 pm »

I think this issue should be resolved for opnsense via this commit (not in a released version yet).

https://github.com/opnsense/core/commit/7316071974b790b6262b65465649df61aa55c500

8

21.1 Legacy Series / Re: Route to Pihole from Guest Vlan

« on: April 02, 2021, 03:49:31 am »

That rule looks right. What do you mean by "use my Pihole server on my Home vlan"? Are you trying to force the clients to use the pihole server? Or just set the DNS servers for your guest machines to point to the pihole? You could probably set source to Guest Network.

Mine looks pretty similar. (attached screenshot)

9

21.1 Legacy Series / Re: Two reboot commands needed to reboot opnsense (WebUI)

« on: April 02, 2021, 03:41:20 am »

It's been reported previously. We would suggest taking this to ntopng since we can't do much about it.


Cheers,
Franco

Hi Franco,

Is it possible that something like this would help?

https://github.com/iamperson347/core/commit/cb75a0003389d6181403c0d10ef425423b6ce12f

I tested it on my machine and it seems to fix the issue. I don't know if this would have any ill effects, but shutting things down in the reverse of rcorder seems logical when the rc.freebsd file is called with "stop."

What do you think?

10

21.1 Legacy Series / Re: Two reboot commands needed to reboot opnsense (WebUI)

« on: March 31, 2021, 12:30:04 pm »

It looks like someone reported it. We will see what ntopng devs have to say.

https://github.com/ntop/ntopng/issues/5127

Does the opnsense plugins build process generate the rc scripts, or does it come from the upstream package?

11

21.1 Legacy Series / Re: Two reboot commands needed to reboot opnsense (WebUI)

« on: March 31, 2021, 04:33:20 am »

It seems this may be related to ntopng and redis. When I manually ran /usr/local/etc/rc.reboot, it appears redis gets shutdown before ntopng. This causes ntopng to hang while shutting down.

I'll have to look into changing the order to see if that will fix the issue. I tried modifying the ntopng rc script to REQUIRE redis, but that didn't seem to help.

12

21.1 Legacy Series / Two reboot commands needed to reboot opnsense (WebUI)

« on: March 31, 2021, 02:53:10 am »

Hi All,

I'm running into an odd issue where my install of opnsense will not reboot through the WebUI the first time. The dialog pops up that the reboot is happening, and the "shutdown chime" plays on the physical machine, but after a few seconds I get sent back to the dashboard. If I go to the reboot screen and select to reboot again, the system then properly reboots.

This also appears to affect reboots required/triggered by upgrades.

However, using "reboot" command via ssh shell session works fine.

I was trying to look through logs to see if I could determine what is going on but the system log doesn't really show anything at the time the issue occurs. The configd.log says "rebooting system" (or something to that effect), but that is it.

Any ideas on where else I can look to determine what might be holding things up?

13

18.7 Legacy Series / Re: [SOLVED] DHCPv6 Static DNS Server - Some Clients Not Receiving Address

« on: September 12, 2018, 03:12:25 am »

No worries! Thank you all for all that you do for the project.

Interestingly enough, the old patch from marjohn56 still worked, so I just applied that in the mean time.

Thanks again!

14

18.7 Legacy Series / Re: [SOLVED] DHCPv6 Static DNS Server - Some Clients Not Receiving Address

« on: September 11, 2018, 03:01:47 am »

Hey again.

I looked through the pull requests and I thought it looked like this was resolved for 18.7.2. However, it looks like the problem returned.

15

18.7 Legacy Series / Re: WAN DHCP6 - Odd Gateway Issue

« on: September 02, 2018, 04:06:24 pm »

It appears it might be some sort of strange interaction with the ipv6 gateway for my ISP. I switched do a different monitoring ip on the gateways and things seems to be stable. I can also disable and re-enable the openvpn client and the gateways monitoring my ISP connection still report up as expected. I wish I had more info as to what is happening with the ISP gateway on ipv6, but that's not a discussion for this forum.