Wireless link dropping out but why?
-
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
-
@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.
-
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
-
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
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.
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.
-
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
-
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