Bug #13092
closed
PPPoE WANs fail to reconnect after parameter negotiation failure
Added by Chris W over 2 years ago. Updated almost 2 years ago.
100%
Description
Opened on behalf of TAC ticket 881570903.
After a six hour ISP outage, the service was restored but pfSense didn't automatically re-establish the PPPoE connection and a reboot of the router (Netgate 1100) was required to re-establish. Shorter outages don't seem to affect automatically reauthenticating.
Files
| Log-PPP-Last 1000 entries.txt (70.3 KB) Log-PPP-Last 1000 entries.txt | From customer's Status Output | Chris W, 04/23/2022 07:55 PM | |
| PPP log 1.txt (4.64 KB) PPP log 1.txt | David G, 04/23/2022 08:54 PM | ||
| PPP log 2.txt (4.47 KB) PPP log 2.txt | David G, 04/23/2022 08:54 PM |
Updated by David G over 2 years ago
- File PPP log 1.txt PPP log 1.txt added
- File PPP log 2.txt PPP log 2.txt added
I've seen cases when the PPP client stops to retry re-establishing the connection within a minute after the outage started. Please find attached logs.
The similarities between all cases (including the ones posted here https://redmine.pfsense.org/issues/1811) is that
after numerous "IPCP: SendConfigReq" messages
there is a "IPCP: parameter negotiation failed" message
then the link closing down and there is no more attempt from the PPP client to reconnect.
Updated by Viktor Gurov over 2 years ago
- Assignee set to Viktor Gurov
- Target version set to 2.7.0
- Plus Target Version set to 22.05
- Affected Version set to 2.6.0
see also https://forum.netgate.com/topic/37353/pppoe-reconenction-fix-mpd-fix-100
solution:
https://sourceforge.net/p/mpd/discussion/44693/thread/b5db2242/ -
"max-redial 0" only means infinite connection retries, but not reconnects. Add set bundle no noretry to your config file. It's default was changed in 4.1.
fix:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/742
Updated by Jim Pingle over 2 years ago
- Status changed from New to Pull Request Review
Updated by Viktor Gurov over 2 years ago
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
Applied in changeset 77fa7b2937c0a14fc3d8db3058ff11db9e0210f2.
Updated by Steve Wheeler over 2 years ago
- Status changed from Feedback to New
'noretry' is no longer a valid bundle option in mpd5.
Apr 29 09:34:20 pfSense ppp[17480]: option "noretry" unknown
Updated by David G over 2 years ago
The reported issue is known. The workaround is to add the following config.
set bundle period 6
set bundle lowat 0
set bundle hiwat 0
set bundle min-con 3
set bundle min-dis 6
set bundle enable bw-manage
https://sourceforge.net/p/mpd/discussion/44693/thread/7a19aeb247/
Updated by Viktor Gurov over 2 years ago
David G wrote in #note-6:
The reported issue is known. The workaround is to add the following config.
set bundle period 6
set bundle lowat 0
set bundle hiwat 0
set bundle min-con 3
set bundle min-dis 6
set bundle enable bw-managehttps://sourceforge.net/p/mpd/discussion/44693/thread/7a19aeb247/
Thank You!
MR:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/754
Updated by Jim Pingle over 2 years ago
- Status changed from New to Pull Request Review
Updated by Viktor Gurov over 2 years ago
- Status changed from Pull Request Review to Feedback
Applied in changeset 75363ea828a165b14de9c8e750a92378ecb4acbf.
Updated by Jim Pingle over 2 years ago
- Subject changed from PPPoE connection fails to establish after long upstream outages to PPPoE WANs fail to reconnect after long upstream outages
Updating subject for release notes.
Updated by David G over 2 years ago
The subject is incorrect.
As stated in the TAC, after further analyzing additional cases it became clear that the duration of an outage is irrelevant. The important factor is the occurrence of an "IPCP: parameter negotiation failed" event. This can happen hours later after the outage (Log-PPP-Last 1000 entries.txt) or within less than a minute (PPP log 1.txt & PPP log 2.txt).
Users in Ticket #1811 https://redmine.pfsense.org/issues/1811 experienced the same issue but it was closed because the subject was not correct.
To maintain the accuracy of this current ticket as well as the release notes I would propose to change the subject to "PPP won't reconnect after IPCP: parameter negotiation failed" or something similar with better wording.
Updated by Jim Pingle over 2 years ago
- Subject changed from PPPoE WANs fail to reconnect after long upstream outages to PPPoE WANs fail to reconnect after parameter negotiation failure
Updated by Robert Hardy over 2 years ago
David G wrote in #note-6:
The reported issue is known. The workaround is to add the following config.
[ details omitted ]
I too was having persistent PPPoE WAN fail to reconnect problems over many releases most recently 2.6.0. There seemed to be a lot of threads like Bug #1943 without a clear resolution.
I was being forced to power cycle my DSL bridge every time to fix it. This was extremely unreliable and painful. I did not want to hijack this thread with that problem. I was eventually able to hack this into my 2.6.0 install by editing with vi /etc/inc/interfaces.inc and searching for create bundle static and inserting the lines in the diff on this. I am very happy this now allows my system to connect/disconnect my WAN PPPoE session without needing to power cycle my bridge. I look forward to 2.7.0.
Updated by Jim Pingle over 2 years ago
- Status changed from Feedback to Resolved
Updated by David G almost 2 years ago
According to the developers the issue has been fixed in mpd5-5.9_11 and later versions, therefore the above workaround in the configuration file won't be needed anymore with these versions.
Will the workaround be removed once pfSense will include an mpd5 version with the fix?
Updated by Jim Pingle almost 2 years ago
David G wrote in #note-15:
According to the developers the issue has been fixed in mpd5-5.9_11 and later versions, therefore the above workaround in the configuration file won't be needed anymore with these versions.
Will the workaround be removed once pfSense will include an mpd5 version with the fix?
Current dev builds of pfSense Plus/CE have MPD 5.9_12, so you could try reverting the commit above to see if it functions without the workaround in place. If it does, we'd need a new issue opened to consider its removal.