if_pppoe problems with php-fpm causing loops. (resolved)
-
@chrcoluk said in if_pppoe problems with php-fpm causing loops. (resolved):
@ajtuk Hi, I reported this to AAISP now, it makes sense to try and get them to work with pfSense dev's, if you can, you can contact them as well. As I mentioned there was another customer affected by the lack of auto reconnection.
Will do. I can also do some more testing next week and see if I get the same results. It's been "stable" the last few days, but no maintenance or issues on the AAISP end to cause it to drop.
-
Yup you can upload here: https://nc.netgate.com/nextcloud/s/isZqc6dRLsXfqYg
How exactly are you killing PPP?
-
@stephenw10 There should be 2 logs there, I am not sure it worked as it says uploading, but please let me know.
On your question, AAISP on their control panel has a button that you can click which will kill the PPP session from their side, so basically a server side kill, not client side kill. I was logged in with my mobile phone connection to ensure I didnt lose access to the control panel as it happened.
-
Yup I see the files there, thanks.
-
@stephenw10 My connection dropped tonight. ISP logged it as a "Planned PPP restart". I uploaded a log to the link here. Maybe it's helpful?
It was only my CityFibre connection which did not reconnect. FTTC reconnected OK. Both use PPPoE and both are with A&A.
Rebooting the appliance brought it back up.
-
@stephenw10 Thank you for providing these commands, and confirmation more logging is coming as well. The ISP is still investigating, I did setup an auto recovery mechanism which involved rebooting pfSense after 3 failed responses from the gateway in a 3 minute period, but now with the down up commands this will be a quicker and cleaner process, and since cycling the ppp is far less of an interruption than rebooting, I can do it without waiting 3 minutes as well.
https://forum.netgate.com/post/1223518
-
@stephenw10 I have another update on 2.8.1 and using the up down commands manually.
It turns out running 'ifconfig pppoe2 down' has the same issue, the 'ifconfig' after running the down command reports this for ppppoe2. Censoring IP's
pppoe2: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 description: WAN options=0 inet x.x.x.x --> x.x.x.x netmask 0xffffffff inet6 fe80::xxx:xxxx:xxxx:xxxx%pppoe2 prefixlen 64 scopeid 0x10 groups: pppoec nd6 options=121<PERFORMNUD,AUTO_LINKLOCAL,NO_DAD>So the inet is the VIP, the main IP is removed but VIP remains, link local IPv6 remains. Note it still has 'UP' status as well, but with a dead connection.
On the GUI WAN is showing as green up arrow but with blank ip information, no ip info there at all.
However as before, going in the GUI, disabling WAN. Save, Enabling WAN save, then Apply successfully does a full WAN cycle and brings back online. (or rebooting)
I hope this new info helps that the down command fails to take the PPPOE session offline.
Sadly although my ISP did start an investigation, no updates were provided after.
I will run the down command again another time with debug enabled, and upload that log to the link provided, I dont know when this will be, as I have people using this connection who are almost around the clock streaming. I hope the new more verbose logging enhancements made it into 2.8.1.
I have a sneaky feeling VIP may be the problem acting as a blocker on if_pppoe termination, when I do the later test I will remove VIP, then run down command.
-
Looks like VIP is the culprit, after I removed it, pppoe2 down worked, and up then brought it back up. So I guess wasnt just a VIP bug causing loops, but also one affecting pppoe termination.
'if_pppoe: pppoe2: lcp close(initial)' is the only log entry with VIP removed.
-
@ajtuk Forgot to ask, do you have any additional IP's added as virtual IP's on your install?
