OK, this has been partly solved - the ACB failure was down to a subscription issue which has now been sorted. However, I still think there is a bug with the ACB module, in that if the ACB registration fails, it messes up the GUI in a major way until you reboot. Cheers, Keith

Good to know it wasn't a problem – if it was, it would have been quite unusual given it appeared to be working correctly in every way. :-)

Don't do that. Replacing entire files is a bad idea, and this is one example why. If that was a more critical system file, your config would have rendered any system it was restored on inoperable. Using a patch is much better way to accomplish that task, and if things change too much, the patch won't apply, but the system will still be operational.

@phil.davis: I did mine by editing the config: Diag->Backup/Restore - download the config. Edit the config, look for the package name (e.g. I did tftp yesterday on a box) and delete the sections related to it - probably a menu entry, services entry, and a package settings section. Restore the config. (System will reboot) Thanks ill try this.

@robi: Nut package does not exist on 2.3. Yet….  :)

Hello! Thanks - switching to always R/W helped a lot  :)

The "Live CD" it mentions is an older platform that was removed. It literally ran the entire time from CD. If you installed to a disk in the firewall, it's not a Live CD after it's been installed, it's a Full Install.

https://redmine.pfsense.org/issues/6147

No VMs, this is an Alix 2D13 box. I don't think it's a problem with my connection (residential cable 60/10) or Google getting slammed. This is a ping and trace route from a Windows 10 PC on my LAN: C:\Users\Max>ping /n 10 8.8.8.8 Pinging 8.8.8.8 with 32 bytes of data: Reply from 8.8.8.8: bytes=32 time=17ms TTL=57 Reply from 8.8.8.8: bytes=32 time=17ms TTL=57 Reply from 8.8.8.8: bytes=32 time=15ms TTL=57 Reply from 8.8.8.8: bytes=32 time=18ms TTL=57 Reply from 8.8.8.8: bytes=32 time=15ms TTL=57 Reply from 8.8.8.8: bytes=32 time=16ms TTL=57 Reply from 8.8.8.8: bytes=32 time=15ms TTL=57 Reply from 8.8.8.8: bytes=32 time=15ms TTL=57 Reply from 8.8.8.8: bytes=32 time=17ms TTL=57 Reply from 8.8.8.8: bytes=32 time=15ms TTL=57 Ping statistics for 8.8.8.8:     Packets: Sent = 10, Received = 10, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 15ms, Maximum = 18ms, Average = 16ms C:\Users\Max>tracert 8.8.8.8 Tracing route to google-public-dns-a.google.com [8.8.8.8] over a maximum of 30 hops: 1    15 ms    8 ms    <1 ms  alix.xxxxxxx.ca [192.168.1.1]   2    13 ms    15 ms    9 ms  10.106.198.129   3    48 ms    19 ms    16 ms  67.231.220.33   4    20 ms    62 ms    22 ms  van58-9-231-73.dynamic.rogerstelecom.net [209.148.231.73]   5    71 ms    54 ms    46 ms  van58-9-229-225.dynamic.rogerstelecom.net [209.148.229.225]   6    57 ms    17 ms    34 ms  209.85.255.197   7    80 ms    36 ms    65 ms  209.85.244.81   8    16 ms    16 ms    39 ms  google-public-dns-a.google.com [8.8.8.8] Trace complete. This is from the Alix box (used the diag tools) just few seconds apart from previous test: PING 8.8.8.8 (8.8.8.8 ) from 24.xx.xx.xx: 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=58 time=417.078 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=15.511 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=15.816 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=730.556 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=58 time=15.938 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=58 time=16.812 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=58 time=734.701 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=58 time=731.509 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=58 time=730.188 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=58 time=725.335 ms –- 8.8.8.8 ping statistics --- 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 15.511/413.344/734.701/336.799 ms Traceroute (using ICMP): 1  10.106.198.129  847.450 ms  814.365 ms  195.907 ms 2  67.231.220.33  1021.659 ms  19.124 ms  244.071 ms 3  209.148.231.73  749.957 ms  184.235 ms  823.869 ms 4  209.148.229.225  24.710 ms  576.026 ms  191.700 ms 5  209.85.255.197  210.232 ms  999.869 ms  227.566 ms 6  209.85.244.81  450.445 ms  17.743 ms  319.402 ms 7  8.8.8.8  14.587 ms  161.061 ms  823.111 ms There is no noticeable latency from any of the clients on the LAN. Speed test, ping tests are all normal, even playing online games is smooth. The problem seems to be when testing from the Alix box. In 2.2.6 apinger was reporting reporting the correct values.

Thanks, we've updated the sticky thread.

Phil, what'd you do to replicate? And on what kind of system? I'm testing on relatively fast hardware or VMs on fast systems, maybe something replicable on an ALIX or something? It was in a VirtualBox VM on my Windows10 laptop. I just tried rebooting it twice again and can't get the error to happen again. But for some reason the VM is booting much faster than usual at the moment, so maybe it is a timing thing.

the post was delete. This is a user to user forum and it is moderated and watched by admins and mods. So it is more common or usual that something will be corrected, deleted, pushed, baned, or lead to the right area by admins or mods.

Take a look at the possible fixes in: https://forum.pfsense.org/index.php?topic=109690.0

That's why I got no answers, the answer was here: https://forum.pfsense.org/index.php?topic=109690.0 Sorry for wasting hard drive space on the forums.

https://forum.pfsense.org/index.php?topic=105399.msg588219#msg588219 https://forum.pfsense.org/index.php?topic=105399.msg588787#msg588787