Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    wifi disconnects when changing settings

    Scheduled Pinned Locked Moved General pfSense Questions
    14 Posts 3 Posters 883 Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • stephenw10S Offline
      stephenw10 Netgate Administrator @dfairley
      last edited by

      Check the system, resolver and dhcp logs when you trigger it. What is actually being run at that point?

      Wifi clients actually lose link with the wifi or just connection to resources?

      Steve

      D 1 Reply Last reply Reply Quote 1
      • D Offline
        dfairley @stephenw10
        last edited by dfairley

        @stephenw10 Sorry for the late response, went to the office to try this out.

        So I deleted a DHCP reservation, and clicked the green Apply Changes up the top and my pings to LAN on wifi stopped working for ~20 seconds. In my initial post I said that the wifi fully disconnected, but I was mistaken. Wifi stays connected from both the AP's perspective and the laptop's perspective.

        This is the DHCP log from when I clicked Apply:

        Dec 16 13:08:16	dhcpd		DHCPREQUEST for 192.168.0.44 from 42:42:a2:83:15:d9 via lagg0.4091
        Dec 16 13:08:14	dhcpd		Server starting service.
        Dec 16 13:08:14	dhcpd		Sending on Socket/fallback/fallback-net
        Dec 16 13:08:14	dhcpd		Sending on BPF/lagg0.4091/00:08:a2:10:10:9a/192.168.0.0/24
        Dec 16 13:08:14	dhcpd		Listening on BPF/lagg0.4091/00:08:a2:10:10:9a/192.168.0.0/24
        Dec 16 13:08:14	dhcpd		Sending on BPF/lagg0.4093/00:08:a2:10:10:9a/192.168.40.0/21
        Dec 16 13:08:14	dhcpd		Listening on BPF/lagg0.4093/00:08:a2:10:10:9a/192.168.40.0/21
        Dec 16 13:08:14	dhcpd		Sending on BPF/lagg0.42/00:08:a2:10:10:9a/10.42.0.0/23
        Dec 16 13:08:14	dhcpd		Listening on BPF/lagg0.42/00:08:a2:10:10:9a/10.42.0.0/23
        Dec 16 13:08:14	dhcpd		Sending on BPF/lagg0.50/00:08:a2:10:10:9a/10.50.0.0/24
        Dec 16 13:08:14	dhcpd		Listening on BPF/lagg0.50/00:08:a2:10:10:9a/10.50.0.0/24
        Dec 16 13:08:14	dhcpd		Sending on BPF/lagg0.60/00:08:a2:10:10:9a/10.60.0.0/24
        Dec 16 13:08:14	dhcpd		Listening on BPF/lagg0.60/00:08:a2:10:10:9a/10.60.0.0/24
        Dec 16 13:08:14	dhcpd		Wrote 103 leases to leases file.
        Dec 16 13:08:14	dhcpd		Wrote 0 new dynamic host decls to leases file.
        Dec 16 13:08:14	dhcpd		Wrote 0 deleted host decls to leases file.
        Dec 16 13:08:14	dhcpd		For info, please visit https://www.isc.org/software/dhcp/
        Dec 16 13:08:14	dhcpd		All rights reserved.
        Dec 16 13:08:14	dhcpd		Copyright 2004-2018 Internet Systems Consortium.
        Dec 16 13:08:14	dhcpd		PID file: /var/run/dhcpd.pid
        Dec 16 13:08:14	dhcpd		Internet Systems Consortium DHCP Server 4.4.1
        Dec 16 13:08:14	dhcpd		Database file: /var/db/dhcpd.leases
        Dec 16 13:08:14	dhcpd		Config file: /etc/dhcpd.conf
        Dec 16 13:08:14	dhcpd		For info, please visit https://www.isc.org/software/dhcp/
        Dec 16 13:08:14	dhcpd		All rights reserved.
        Dec 16 13:08:14	dhcpd		Copyright 2004-2018 Internet Systems Consortium.
        Dec 16 13:08:14	dhcpd		Internet Systems Consortium DHCP Server 4.4.1
        

        In DNS forwarder, I deleted a DNS entry and then when I clicked the green Apply Changes button, the same situation with losing wifi happened:

        Dec 16 13:11:14	dnsmasq	28872	using nameserver 8.8.8.8#53
        Dec 16 13:11:14	dnsmasq	28872	ignoring nameserver 127.0.0.1 - local interface
        Dec 16 13:11:14	dnsmasq	28872	reading /etc/resolv.conf
        Dec 16 13:11:12	dnsmasq	28872	read /etc/hosts - 323 addresses
        Dec 16 13:11:12	dnsmasq	28872	using nameserver 1.1.1.1#53
        Dec 16 13:11:12	dnsmasq	28872	using nameserver 8.8.8.8#53
        Dec 16 13:11:12	dnsmasq	28872	ignoring nameserver 127.0.0.1 - local interface
        Dec 16 13:11:12	dnsmasq	28872	reading /etc/resolv.conf
        Dec 16 13:11:12	dnsmasq	28872	compile time options: IPv6 GNU-getopt no-DBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect no-inotify dumpfile
        Dec 16 13:11:12	dnsmasq	28872	started, version 2.80 cachesize 10000
        Dec 16 13:11:11	dnsmasq	54701	exiting on receipt of SIGTERM
        

        Weirdly, a ping running on LAN with no wifi involved didn't have the issue.

        Edit: It looks like dnsmasq and dhcpd both received SIGTERM at the same time as eachother in both tests.

        1 Reply Last reply Reply Quote 0
        • stephenw10S Offline
          stephenw10 Netgate Administrator
          last edited by

          Anything in the system log?

          None of that looks unexpected. Those events are complete in a few seconds and lack of access to dhcp or dns should not prevent anything that's already open.

          Steve

          D 1 Reply Last reply Reply Quote 1
          • D Offline
            dfairley @stephenw10
            last edited by dfairley

            @stephenw10 System > General looks like what I'd expect:

            Dec 16 13:10:52	php-fpm		/services_dnsmasq.php: End of configuration backup to https://acb.netgate.com/save (success).
            Dec 16 13:10:47	php-fpm		/services_dnsmasq.php: Beginning configuration backup to https://acb.netgate.com/save
            Dec 16 13:10:47	check_reload_status		Syncing firewall
            Dec 16 13:08:08	php-fpm		/services_dhcp.php: End of configuration backup to https://acb.netgate.com/save (success).
            Dec 16 13:08:03	php-fpm		/services_dhcp.php: Beginning configuration backup to https://acb.netgate.com/save
            Dec 16 13:08:03	check_reload_status		Syncing firewall
            

            System > Routing looks a bit weird, and looks like it's timezoned differently:

            Dec 17 02:39:40	radvd	70402	removing /var/run/radvd.pid
            Dec 17 02:39:40	radvd	70402	sending stop adverts
            Dec 17 02:39:40	radvd	70402	exiting, 1 sigterm(s) received
            Dec 17 02:20:22	radvd	70283	invalid all-zeros prefix in /var/etc/radvd.conf, line 9
            Dec 17 02:20:22	radvd	70283	version 2.17 started
            Dec 17 01:49:59	radvd	10014	returning from radvd main
            Dec 17 01:49:59	radvd	10014	removing /var/run/radvd.pid
            Dec 17 01:49:59	radvd	10014	sending stop adverts
            Dec 17 01:49:59	radvd	10014	exiting, 1 sigterm(s) received
            
            The radvd.conf file only contains:
            `# Automatically Generated, do not edit`
            stephenw10S GertjanG 2 Replies Last reply Reply Quote 0
            • stephenw10S Offline
              stephenw10 Netgate Administrator @dfairley
              last edited by

              Hmm, nothing much there. It should not stop responding to local pings just by doing that.

              Are you running 2.4.5p1? 2.4.5 had a performance bug that could present very much like that.
              https://redmine.pfsense.org/issues/10414
              Though even that was not 20s!

              Steve

              D 1 Reply Last reply Reply Quote 1
              • GertjanG Offline
                Gertjan @dfairley
                last edited by

                @dfairley said in wifi disconnects when changing settings:

                System > General
                Dec 16 13:10:52
                ...
                System > Routing
                Dec 17 02:39:40

                That's strange.
                radvd is a "IPv6" process. You are using IPv6 ?
                And why would it start stop every 10 minutes between 1 and 2 PM ??

                @dfairley said in wifi disconnects when changing settings:

                Multi-wan is configured as a failover

                Mtake a backup of your settings, and then goto classic-single-WAN setup. make your settings as standard as possible. Just to eliminate possible issues.

                @dfairley said in wifi disconnects when changing settings:

                when clicking Refresh

                What refresh (button ?) ?

                No "help me" PM's please. Use the forum, the community will thank you.
                Edit : and where are the logs ??

                1 Reply Last reply Reply Quote 1
                • D Offline
                  dfairley @stephenw10
                  last edited by

                  @stephenw10 said in wifi disconnects when changing settings:

                  Are you running 2.4.5p1?

                  I am, yep.

                  @gertjan said in wifi disconnects when changing settings:

                  radvd is a "IPv6" process. You are using IPv6 ?
                  And why would it start stop every 10 minutes between 1 and 2 PM ??

                  Not intentionally - I have "Allow IPv6" unchecked, and "Prefer IPv4 over IPv6" checked.
                  I'm not sure why it start-stopped. It only happened those two times yesterday and prior to that, December 12. Seems to coincide with config changes.

                  @gertjan said in wifi disconnects when changing settings:

                  Mtake a backup of your settings, and then goto classic-single-WAN setup. make your settings as standard as possible. Just to eliminate possible issues.

                  I'll try this out over Christmas. Thank you for the idea.

                  @gertjan said in wifi disconnects when changing settings:

                  What refresh (button ?) ?

                  Sorry, I meant the green Apply Config button that appears up the top when you save a config change.

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S Offline
                    stephenw10 Netgate Administrator
                    last edited by

                    Hmm, I'd probably be running a packet capture to see what's actually happening at that point.

                    If pings are arriving there's no reason pfSense would not respond for that long.

                    Steve

                    1 Reply Last reply Reply Quote 0
                    • D Offline
                      dfairley
                      last edited by

                      So I confirmed that packets are only dropped if I'm connected with wifi. With LAN there's no interruption.
                      Then, I disabled snort, and switched to a basic single-wan setup. Restarted everything. The issue still occured: packets are dropped for ~30 seconds when I apply a DNS Forwarder or DHCP server config change.
                      I updated my unifi APs + controller and no change. Then I unchecked "Block LAN to WLAN Multicast and Broadcast Data" on the unifi AP side of things. Now I only lose packets for ~1 second. Zoom calls no longer drop out. Works for me!

                      Thank you both for helping me figure it out.

                      GertjanG 1 Reply Last reply Reply Quote 2
                      • GertjanG Offline
                        Gertjan @dfairley
                        last edited by

                        @dfairley said in wifi disconnects when changing settings:

                        Then I unchecked "Block LAN to WLAN Multicast and Broadcast Data"

                        Blocking broadcasts coming from LAN, for example pfSEnse ?
                        Right away I thought : what about DHCP transactions ?

                        And bingo

                        No "help me" PM's please. Use the forum, the community will thank you.
                        Edit : and where are the logs ??

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S Offline
                          stephenw10 Netgate Administrator
                          last edited by

                          Mmm, that's fun!

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.