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

    Wireless link dropping out but why?

    Scheduled Pinned Locked Moved General pfSense Questions
    6 Posts 3 Posters 373 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.
    • D Offline
      daleb
      last edited by

      I have pfsense 2.4.5-P1 configured to load balance 2 connections to the net here at home, ones an ADSL connection and the other is a wireless connection.

      The ADSL connection never has a problem but the wireless connection will connect then drop out anywhere from say 30 minutes to a few hours, then reconnect and it starts all over again, one change I did make was under system/routing/gateways and disable “gateway monitoring” and “gateway action” this brings everything back up and running once it reconnects if I don’t have these two options disabled the link doesn’t always come back up properly. Also, not sure if this is important or not but the wireless link uses PPPOE.

      If I use the ISP supplied router the link will hold no problem at all so this kind of rules out the dish I would think and makes me think it is something I’ve screwed up in the settings within pfsense maybe?

      And the ISP I’m using for the wireless link is of no use at all their answer is to use their router which I have no interest in doing.

      The closest option I can find within pfsense that might affect this is in interfaces and the option is “idle timeout” which has been left blank it won’t let me set this to 0

      Could this be something I’ve done in the setup process?

      I’m at a complete loss here and any ideas as to where I can start looking would be very much appreciated.

      Thanks in advance

      GertjanG 1 Reply Last reply Reply Quote 0
      • GertjanG Offline
        Gertjan @daleb
        last edited by

        @daleb said in Wireless link dropping out but why?:

        wireless connection

        So the issue totally excludes pfSense.

        The typical pfSense WAN connection is a double pair of wires to some other upstream device that offers the WAN (Internet) connection. An upstream switch ? router ? modem ? or a combination of these.

        An upstream radio signal based connection is also wired based, as from a pfSense point of view.
        The nasty thing : can you "see" the radio spectrum around you ? How is the signal behaving ? To make things worse : the "ISP supplied router" could have chosen to implement a radio connection that isn't standardized - it could use proprietary solutions. So other radio devices could fall out of sync.

        @daleb said in Wireless link dropping out but why?:

        the dish

        Yo mean a satellite connection ?
        Use the satellite ISP hardware. You could choose your own hardware as soon as the connections comes down to an RJ45.

        @daleb said in Wireless link dropping out but why?:

        I’m at a complete loss here

        Yet another reason to detail your network setup.

        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

          Yes, more info needed.

          What actually fails when it 'goes down'. The wireless link? The PPPoE session? The physical link to the wireless device?

          Steve

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

            @Gertjan

            The typical pfSense WAN connection is a double pair of wires to some other upstream device that offers the WAN (Internet) connection. An upstream switch ? router ? modem ? or a combination of these.

            The dish comes into the house through a cable and that cable terminates to a RJ45 socket on the wall.

            There is no switch, modem or router between the dish and the RJ45 socket.

            The nasty thing : can you "see" the radio spectrum around you ?

            I have no idea what you mean by that, I can't see radio waves no.

            To make things worse : the "ISP supplied router" could have chosen to implement a radio connection that isn't standardized - it could use proprietary solutions.

            Ok this I understand but not sure how it could be doing that when its accessing the dish on the roof through that same cable and RJ45 socket.

            Maybe their router does something different with the way its using PPPOE to login and keep the connection alive, thats the only difference so far I can see. But I'm pretty green with this stuff so correct me if I'm wrong by all means.

            Yo mean a satellite connection ?

            No its a wireless link, heres a picture of the dish

            dish.PNG

            You could choose your own hardware as soon as the connections comes down to an RJ45

            That is exactly where pfsense comes into play. I use their POE to power the dish seeing I'm not using their router which when used also supplies power to the dish.

            Another reason I have no interest in using their router is they like to maintain it and seem to be monitoring it as I made a small DNS change to it which was noticed straight away. I don't like the idea of other peoples hardware having access to my network. Although they said they can't access the LAN side, ah no thanks.

            Yet another reason to detail your network setup.

            Ok I'll do my best.

            @stephenw10

            Yes, more info needed.

            Ok on the way

            What actually fails when it 'goes down'. The wireless link? The PPPoE session? The physical link to the wireless device?

            Its not the physical link as that's a cable so we can rule that out straight away I think. And if I use their supplied router through that same cable the problem isn't there and the link holds no dramas. No drop outs.

            I don't think its the wireless link either for the same reason I posted above when using their router it doesn't drop out.

            Heres my current network.

            I have 2 WANS one is an ADSL connection that has no problems and the other is a wireless link that is having problems.

            The ADSL works 100% of the time and drops out maybe once a month if that. I don't think it plays any part in this problem to be honest.

            The wireless link through the dish (pic above) connects to another tower up on the hill about a kilometre away as the crow flys. Line of sight is pretty good.

            That black cable you see coming off the dish terminates to an RJ45 socket in the wall and thats where I can change things as in pfsense or their router.

            I can't think of anything else to add from there but if I've left something out then I'll add it later.

            The reason I'm here is because I don't know where to start looking, but from where I'm sitting now should I look at my PPPOE setup more do you think?

            Heres the logs from the last drop out till now, I don't know if the problems in there or not

            Dec 27 11:38:12	ppp		[opt1] IFACE: Rename interface ng0 to pppoe0
Dec 27 11:38:12	ppp		[opt1] IFACE: Up event
Dec 27 11:38:11	ppp		[opt1] 103.22.x.x -> 103.22.x.x
Dec 27 11:38:11	ppp		[opt1] IPCP: LayerUp
Dec 27 11:38:11	ppp		[opt1] IPCP: state change Ack-Sent --> Opened
Dec 27 11:38:11	ppp		[opt1] SECDNS 103.22.x.x
Dec 27 11:38:11	ppp		[opt1] PRIDNS 103.22.x.x
Dec 27 11:38:11	ppp		[opt1] IPADDR 103.22.x.x
Dec 27 11:38:11	ppp		[opt1] IPCP: rec'd Configure Ack #3 (Ack-Sent)
Dec 27 11:38:11	ppp		[opt1] SECDNS 103.22.x.x
Dec 27 11:38:11	ppp		[opt1] PRIDNS 103.22.x.x
Dec 27 11:38:11	ppp		[opt1] IPADDR 103.22.x.x
Dec 27 11:38:11	ppp		[opt1] IPCP: SendConfigReq #3
Dec 27 11:38:11	ppp		[opt1] SECDNS 103.22.x.x
Dec 27 11:38:11	ppp		[opt1] PRIDNS 103.22.x.x
Dec 27 11:38:11	ppp		[opt1] 103.22.x.x is OK
Dec 27 11:38:11	ppp		[opt1] IPADDR 103.22.x.x
Dec 27 11:38:11	ppp		[opt1] IPCP: rec'd Configure Nak #2 (Ack-Sent)
Dec 27 11:38:11	ppp		[opt1] SECDNS 0.0.0.0
Dec 27 11:38:11	ppp		[opt1] PRIDNS 0.0.0.0
Dec 27 11:38:11	ppp		[opt1] IPADDR 0.0.0.0
Dec 27 11:38:11	ppp		[opt1] IPCP: SendConfigReq #2
Dec 27 11:38:11	ppp		[opt1] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Dec 27 11:38:11	ppp		[opt1] IPCP: rec'd Configure Reject #1 (Ack-Sent)
Dec 27 11:38:11	ppp		[opt1] IPV6CP: LayerFinish
Dec 27 11:38:11	ppp		[opt1] IPV6CP: state change Req-Sent --> Stopped
Dec 27 11:38:11	ppp		[opt1] IPV6CP: protocol was rejected by peer
Dec 27 11:38:11	ppp		[opt1_link0] LCP: protocol IPV6CP was rejected
Dec 27 11:38:11	ppp		[opt1_link0] LCP: rec'd Protocol Reject #2 (Opened)
Dec 27 11:38:11	ppp		[opt1] IPCP: state change Req-Sent --> Ack-Sent
Dec 27 11:38:11	ppp		[opt1] IPADDR 103.22.x.x
Dec 27 11:38:11	ppp		[opt1] IPCP: SendConfigAck #1
Dec 27 11:38:11	ppp		[opt1] 103.22.x.x is OK
Dec 27 11:38:11	ppp		[opt1] IPADDR 103.22.x.x
Dec 27 11:38:11	ppp		[opt1] IPCP: rec'd Configure Request #1 (Req-Sent)
Dec 27 11:38:11	ppp		[opt1] IPV6CP: SendConfigReq #1
Dec 27 11:38:11	ppp		[opt1] IPV6CP: state change Starting --> Req-Sent
Dec 27 11:38:11	ppp		[opt1] IPV6CP: Up event
Dec 27 11:38:11	ppp		[opt1] SECDNS 0.0.0.0
Dec 27 11:38:11	ppp		[opt1] PRIDNS 0.0.0.0
Dec 27 11:38:11	ppp		[opt1] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Dec 27 11:38:11	ppp		[opt1] IPADDR 0.0.0.0
Dec 27 11:38:11	ppp		[opt1] IPCP: SendConfigReq #1
Dec 27 11:38:11	ppp		[opt1] IPCP: state change Starting --> Req-Sent
Dec 27 11:38:11	ppp		[opt1] IPCP: Up event
Dec 27 11:38:11	ppp		[opt1] IPV6CP: LayerStart
Dec 27 11:38:11	ppp		[opt1] IPV6CP: state change Initial --> Starting
Dec 27 11:38:11	ppp		[opt1] IPV6CP: Open event
Dec 27 11:38:11	ppp		[opt1] IPCP: LayerStart
Dec 27 11:38:11	ppp		[opt1] IPCP: state change Initial --> Starting
Dec 27 11:38:11	ppp		[opt1] IPCP: Open event
Dec 27 11:38:11	ppp		[opt1] Bundle: Status update: up 1 link, total bandwidth 64000 bps
Dec 27 11:38:11	ppp		[opt1_link0] Link: Join bundle "opt1"
Dec 27 11:38:11	ppp		[opt1_link0] Link: Matched action 'bundle "opt1" ""'
Dec 27 11:38:11	ppp		[opt1_link0] LCP: authorization successful
Dec 27 11:38:11	ppp		[opt1_link0] MESG: Welcome.
Dec 27 11:38:11	ppp		[opt1_link0] CHAP: rec'd SUCCESS #1 len: 12
Dec 27 11:38:11	ppp		[opt1_link0] CHAP: sending RESPONSE #1 len: 46
Dec 27 11:38:11	ppp		[opt1_link0] CHAP: Using authname "dale.baker@yless4u.com.au"
Dec 27 11:38:11	ppp		[opt1_link0] Name: "YL4-DC-AGG-01"
Dec 27 11:38:11	ppp		[opt1_link0] CHAP: rec'd CHALLENGE #1 len: 34
Dec 27 11:38:11	ppp		[opt1_link0] LCP: LayerUp
Dec 27 11:38:11	ppp		[opt1_link0] LCP: auth: peer wants CHAP, I want nothing
Dec 27 11:38:11	ppp		[opt1_link0] LCP: state change Ack-Sent --> Opened
Dec 27 11:38:11	ppp		[opt1_link0] MAGICNUM 0x2f437865
Dec 27 11:38:11	ppp		[opt1_link0] MRU 1492
Dec 27 11:38:11	ppp		[opt1_link0] LCP: rec'd Configure Ack #2 (Ack-Sent)
Dec 27 11:38:10	ppp		[opt1_link0] MAGICNUM 0x2f437865
Dec 27 11:38:10	ppp		[opt1_link0] MRU 1492
Dec 27 11:38:10	ppp		[opt1_link0] LCP: SendConfigReq #2
Dec 27 11:38:10	ppp		[opt1_link0] PROTOCOMP
Dec 27 11:38:10	ppp		[opt1_link0] LCP: rec'd Configure Reject #1 (Ack-Sent)
Dec 27 11:38:10	ppp		[opt1_link0] LCP: state change Req-Sent --> Ack-Sent
Dec 27 11:38:10	ppp		[opt1_link0] MAGICNUM 0xdcd48657
Dec 27 11:38:10	ppp		[opt1_link0] MRU 1480
Dec 27 11:38:10	ppp		[opt1_link0] AUTHPROTO CHAP MD5
Dec 27 11:38:10	ppp		[opt1_link0] LCP: SendConfigAck #1
Dec 27 11:38:10	ppp		[opt1_link0] MAGICNUM 0xdcd48657
Dec 27 11:38:10	ppp		[opt1_link0] MRU 1480
Dec 27 11:38:10	ppp		[opt1_link0] AUTHPROTO CHAP MD5
Dec 27 11:38:10	ppp		[opt1_link0] LCP: rec'd Configure Request #1 (Req-Sent)
Dec 27 11:38:10	ppp		[opt1_link0] MAGICNUM 0x2f437865
Dec 27 11:38:10	ppp		[opt1_link0] MRU 1492
Dec 27 11:38:10	ppp		[opt1_link0] PROTOCOMP
Dec 27 11:38:10	ppp		[opt1_link0] LCP: SendConfigReq #1
Dec 27 11:38:10	ppp		[opt1_link0] LCP: state change Starting --> Req-Sent
Dec 27 11:38:10	ppp		[opt1_link0] LCP: Up event
Dec 27 11:38:10	ppp		[opt1_link0] Link: UP event
Dec 27 11:38:10	ppp		[opt1_link0] PPPoE: connection successful
Dec 27 11:38:10	ppp		PPPoE: rec'd ACNAME "YL4-DC-AGG-01"
Dec 27 11:38:10	ppp		[opt1_link0] PPPoE: Connecting to ''
Dec 27 11:38:10	ppp		[opt1_link0] LCP: LayerStart
Dec 27 11:38:10	ppp		[opt1_link0] LCP: state change Initial --> Starting
Dec 27 11:38:10	ppp		[opt1_link0] LCP: Open event
Dec 27 11:38:10	ppp		[opt1_link0] Link: OPEN event
Dec 27 11:38:10	ppp		[opt1] Bundle: Interface ng0 created
Dec 27 11:38:10	ppp		web: web is not running
Dec 27 11:38:10	ppp		process 66191 terminated
Dec 27 11:38:10	ppp		[opt1_link0] Link: Shutdown
Dec 27 11:38:10	ppp		[opt1] Bundle: Shutdown
Dec 27 11:38:09	ppp		waiting for process 66191 to die...
Dec 27 11:38:08	ppp		waiting for process 66191 to die...
Dec 27 11:38:08	ppp		[opt1_link0] LCP: state change Closed --> Initial
Dec 27 11:38:08	ppp		[opt1_link0] LCP: Down event
Dec 27 11:38:08	ppp		[opt1_link0] Link: DOWN event
Dec 27 11:38:08	ppp		[opt1_link0] LCP: LayerFinish
Dec 27 11:38:08	ppp		[opt1_link0] LCP: state change Closing --> Closed
Dec 27 11:38:08	ppp		[opt1_link0] LCP: rec'd Terminate Ack #3 (Closing)
Dec 27 11:38:08	ppp		[opt1_link0] LCP: LayerDown
Dec 27 11:38:08	ppp		[opt1_link0] LCP: SendTerminateReq #3
Dec 27 11:38:08	ppp		[opt1] IPV6CP: state change Closed --> Initial
Dec 27 11:38:08	ppp		[opt1] IPV6CP: Down event
Dec 27 11:38:08	ppp		[opt1] IPCP: state change Closed --> Initial
Dec 27 11:38:08	ppp		[opt1] IPCP: Down event
Dec 27 11:38:08	ppp		[opt1] IPV6CP: Close event
Dec 27 11:38:08	ppp		[opt1] IPCP: Close event
Dec 27 11:38:08	ppp		[opt1] Bundle: Status update: up 0 links, total bandwidth 9600 bps
Dec 27 11:38:08	ppp		[opt1_link0] Link: Leave bundle "opt1"
Dec 27 11:38:08	ppp		[opt1_link0] LCP: state change Opened --> Closing
Dec 27 11:38:08	ppp		[opt1_link0] LCP: Close event
Dec 27 11:38:08	ppp		[opt1_link0] Link: CLOSE event
Dec 27 11:38:08	ppp		[opt1] Bundle: closing link "opt1_link0"...
Dec 27 11:38:08	ppp		[opt1] Bundle: No NCPs left. Closing links...
Dec 27 11:38:08	ppp		[opt1] IPCP: LayerFinish
Dec 27 11:38:08	ppp		[opt1] IPCP: state change Closing --> Closed
Dec 27 11:38:08	ppp		[opt1] IPCP: rec'd Terminate Ack #4 (Closing)
Dec 27 11:38:08	ppp		[opt1] IPV6CP: state change Stopped --> Closed
Dec 27 11:38:08	ppp		[opt1] IPV6CP: Close event
Dec 27 11:38:08	ppp		[opt1] IFACE: Rename interface pppoe0 to pppoe0
Dec 27 11:38:08	ppp		[opt1] IFACE: Down event
Dec 27 11:38:08	ppp		[opt1] IFACE: Removing IPv4 address from pppoe0 failed(IGNORING for now. This should be only for PPPoE friendly!): Can't assign requested address
Dec 27 11:38:07	ppp		[opt1] IPCP: LayerDown
Dec 27 11:38:07	ppp		[opt1] IPCP: SendTerminateReq #4
Dec 27 11:38:07	ppp		[opt1] IPCP: state change Opened --> Closing
Dec 27 11:38:07	ppp		[opt1] IPCP: Close event
Dec 27 11:38:07	ppp		[opt1] IFACE: Close event
Dec 27 11:38:07	ppp		caught fatal signal TERM
Dec 27 11:38:07	ppp		waiting for process 66191 to die...
Dec 27 11:38:07	ppp		process 72527 started, version 5.8 (root@pfSense_v2_4_5_amd64-pfSense_v2_4_5-job-04 20:28 17-Dec-2019)
Dec 27 11:38:07	ppp		Multi-link PPP daemon for FreeBSD
Dec 27 10:13:02	ppp		[opt1] IFACE: Rename interface ng0 to pppoe0
Dec 27 10:13:02	ppp		[opt1] IFACE: Up event

            Thanks again.

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

              Ok so when you are not using the ISPs router you're using some other PoE injector to power the wireless hardware? Are you sure that is powerful enough?

              If the wireless device at the dish end is rebooting for some reason you would expect it to lose Ethernet link which pfSense would log in the main system log. You do not see that?

              The first thing shown in that log is the daemon starting the connection but it looks to have started before the previous connection had stopped. No timeouts or errors shown before that, something must have triggered that.

              Steve

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

                @stephenw10

                Ok so when you are not using the ISPs router you're using some other PoE injector to power the wireless hardware? Are you sure that is powerful enough?

                They gave me the POE power supply so unless its faulty then yes.

                The first thing shown in that log is the daemon starting the connection but it looks to have started before the previous connection had stopped. No timeouts or errors shown before that, something must have triggered that.

                Yeah I copied the log from the last time it had dropped out till the current time, but it all looked ok to me but I'm no expert in finding errors in logs.

                If the wireless device at the dish end is rebooting for some reason you would expect it to lose Ethernet link which pfSense would log in the main system log. You do not see that?

                I'll have a look through them then and see if anything sticks out.

                thanks

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