I believe I’m having this issue, and have been for some time now. I always wondered why sometimes PPP would drop, and I’d drive out to site only to do a reboot and everything works. Sometimes I’d even have people put on site reboot for me, but it wouldn’t work. Is there any update on this issue?
Below log is newest on top, so read in reverse.
Feb 21 09:25:12 ppp 98216 [wan] IFACE: Down event
Feb 21 09:25:08 ppp 98216 [wan] IPV6CP: LayerDown
Feb 21 09:25:08 ppp 98216 [wan] IPV6CP: SendTerminateReq #38
Feb 21 09:25:08 ppp 98216 [wan] IPV6CP: state change Opened --> Closing
Feb 21 09:25:08 ppp 98216 [wan] IPV6CP: Close event
Feb 21 09:25:08 ppp 98216 [wan] IPCP: LayerDown
Feb 21 09:25:08 ppp 98216 [wan] IPCP: SendTerminateReq #76
Feb 21 09:25:08 ppp 98216 [wan] IPCP: state change Opened --> Closing
Feb 21 09:25:08 ppp 98216 [wan] IPCP: Close event
Feb 21 09:25:08 ppp 98216 [wan] Bundle: Status update: up 0 links, total bandwidth 9600 bps
Feb 21 09:25:08 ppp 98216 [wan_link0] Link: Leave bundle "wan"
Feb 21 09:25:08 ppp 98216 [wan_link0] LCP: state change Opened --> Stopping
Feb 21 09:25:08 ppp 98216 [wan_link0] LCP: peer not responding to echo requests
Feb 21 09:25:08 ppp 98216 [wan_link0] LCP: no reply to 5 echo request(s)
Feb 21 09:24:58 ppp 98216 [wan_link0] LCP: no reply to 4 echo request(s)
Feb 21 09:24:48 ppp 98216 [wan_link0] LCP: no reply to 3 echo request(s)
Feb 21 09:24:38 ppp 98216 [wan_link0] LCP: no reply to 2 echo request(s)
Feb 21 09:24:27 ppp 98216 [wan_link0] LCP: no reply to 1 echo request(s
Name = PFSENSE-FD #you have to put same name in bareos-dir on the backup server!
Maximum Concurrent Jobs = 20
Name = backup-dir ##YOUR DIRECTOR NAME
Password = "PASSWORD" ##YOUR DIRECTOR PASSWORD
Name = Standard
director = backup-dir = all, !skipped, !restored
Now go to /etc/usr/local/rc.d and remove all bareos startup files except bareos-fd
After that edit /etc/rc.conf and add:
As of pfSense 2.4.
Go to http://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/
fq_codel is already coming to FreeBSD (and most likely pfSense), but it will not be an ALTQ queueing discipline, it will instead be implemented within "dummynet", which is what pfSense calls "limiters".
Whether this will be useful to us, I do not know, but it sure seems like good news to me.
Implementing fq_Codel in the limiters should work well and be easy to setup. Also I think it will allow the limiters to function better. I still think that cake_Codel is the future and hope it will be implemented in BSD.
I have tried HFSC, PRIQ, and CBQ all of these did a good job of keeping my internet running smoothly but bufferbloat was always a problem. I have since found that FairQ with Codel as the scheduler I do not have to limit my Bulk traffic and my network performance is largely unaffected.
Cake will never come to BSD. Cake is deeply entrenched in Linux-only features. Many of the features do not exist at all in BSD, so the whole porting effort would be very complicated and/or expensive.
Hi Miken, how do you plan to interface between pfsense and PMS? (sql queries, webservice)?
PMS systems generally have an interface. Either serial or telnet. They speak a specific protocol.
What is the PMS in question?
Yes, as mentioned it needs to work for either TCP or serial as we don't know what sort of environment we'll be working with. It's for Comtrol's UHLL, which isn't a PMS interface per se, but rather a translation layer for a number of other PMS interfaces – mostly small operations, nothing like Opera or Galaxy. The protocol itself is fairly simple, just sending plain text and getting plain text back.
Yes, this is meant for bounties relating to pfSense.
I've had a lot of luck with ODesk in the past. The best thing to keep in mind is that if you're getting wildly-varying quotes or quotes WAY higher than you expected, then you haven't spec'd out the project adequately. Just because it makes sense to you, doesn't mean that others will get it and as such will tend to pad their estimates a LOT when accepting a fixed-bid project.
We've done a number of setups like this for support customers that work great.
The HA functionality you linked isn't relevant to this type of circumstance, that's for active/active clustered machines.
Dynamic DNS is likely to be a requirement with any solution along these lines that offers multi-WAN failover on both sides, as that's the only way you can tell endpoints where they need to be connecting. Strictly referring to IPsec tunnel mode, if you go with transport mode, tunnels and a routing protocol, that's not a requirement. Which options are workable will depend on what the remote endpoints are, since OpenVPN isn't an option, I presume they're third party IPsec devices.
I have no problem to pay for something - but if it only works now in beta and I have later problems with the final version… I have to buy a gold membership and 2 hours support for again 500$. I'm not that money thrower.
So I think I'm not that fair traded from you. You bully me that I should pay immediately but I already stated that I will. Cause I'm not a native english speaking person I can't express this in the right words and the length i wish, but we don't get an agreement so this ends here.
Or the controller for the AP even.. What APs are you using? Pinging the management IP of the AP does little to tell you if wireless is actually up and running - are you wanting to ping a wireless client connected to that specific AP?
Simple no way to ping stuff and get an alert is smokeping.
The most straightforward way (well, the only one I can think about), involves using dynamic DNS services. You just set the local interface of the tunnel to a failover gateway group, and destination to a dynamic DNS host which is tied to the failover gateway group on the other side. Repeat on the other side. That's it.