After certain kind of ISP outages MPD 5.9 stops to retry re-establish the connection using the following configuration:
startup:
# configure the console
set console close
# configure the web server
set web close
default:
pppoeclient:
create bundle static wan
set bundle no noretry
set bundle enable ipv6cp
set iface name pppoe0
set iface description "WAN"
set iface disable on-demand
set iface idle 0
set iface enable tcpmssfix
set iface up-script /usr/local/sbin/ppp-linkup
set iface down-script /usr/local/sbin/ppp-linkdown
set ipcp ranges 0.0.0.0/0 0.0.0.0/0
set ipcp enable req-pri-dns
set ipcp enable req-sec-dns
#log -bund -ccp -chat -iface -ipcp -lcp -link
create link static wan_link0 pppoe
set link action bundle wan
set link disable multilink
set link keep-alive 10 60
set link max-redial 0
set link disable chap pap
set link accept chap pap eap
set link disable incoming
set link mtu 1492
set auth authname "dvxoynzwkt@isp.com"
set auth password 826018765
set pppoe service ""
set pppoe iface mvneta0.4090
open
After numerous "IPCP: SendConfigReq" messages
there is a "IPCP: parameter negotiation failed" message
then the link closing down and there is no more attempt to reconnect.
When the outage is over I can manually establish the connection again without problem.
There are other users having the same issue. https://redmine.pfsense.org/issues/1811
Could you please help me how to configure MPD to keep reconnecting after a "IPCP: parameter negotiation failed" event?
Thank you!
Last edit: David G 2022-04-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is known problem. Fortunately, it has a work-around and I advise you to try it and report back.
The work-around uses mpd's embedded bandwidth control that monitors available "bandwidth" for (possibly multi-link) bundle and will forcibly bring disconnected link back on if enabled.
To enable it, add the following to the bundle context of mpd.conf:
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
I will add these lines to the bundle section.
I can't promise that I will come back with the result shortly, because I am unable to replicate the issue and I need to wait for an ISP outage for this to happen.
Do you know by chance the ticket ID for this issue? so I can follow the progress of the fix.
Thank you!
Best regards,
David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for checking if there is a ticket. The only reason I asked about it that redundant lines can be removed after a fixed version.
The fact that there is no ticket suggests to me that the workaround might be as good as a fixed version and it is not worth to invest time in the fix development / testing / etc.
However if you think if a fixed version will give a more stable and reliable end result I will be happy to test the patch, but I might need some help. I also don't know how to reproduce the issue, because it occurs only at certain outages which (fortunately) happen rarely, therefore waiting for an outage might take too long.
I have an upcoming travel and will be back in mid/later June.
Please let me know.
Thank you!
David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have not forget about your question but it will take several more days for me to address the problem. If you have not time next week, it is not a problem.
I can tell you how to reproduce the problem with simple ipfw rule to simulate and reproduce the problem before applying a patch. And then apply the patch to verify if it's gone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you Eugene for fixing it. I will try mpd5-5.9_11. I am not sure if my service provider had outages lately, but since I applied the patch in May I havn't had to restart my device.
Earlier you have mentioned you have a procedure to replicate the problem with ipfw rule. Just for curiosity I would like to do the tests, would you please share this procedure?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I have to admit that my tries with ipfw to reproduce the problem were not successful really. Then I got an idea how to fix it permanently, so I spent some time on that instead.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After certain kind of ISP outages MPD 5.9 stops to retry re-establish the connection using the following configuration:
startup:
# configure the console
set console close
# configure the web server
set web close
default:
pppoeclient:
create bundle static wan
set bundle no noretry
set bundle enable ipv6cp
set iface name pppoe0
set iface description "WAN"
set iface disable on-demand
set iface idle 0
set iface enable tcpmssfix
set iface up-script /usr/local/sbin/ppp-linkup
set iface down-script /usr/local/sbin/ppp-linkdown
set ipcp ranges 0.0.0.0/0 0.0.0.0/0
set ipcp enable req-pri-dns
set ipcp enable req-sec-dns
#log -bund -ccp -chat -iface -ipcp -lcp -link
create link static wan_link0 pppoe
set link action bundle wan
set link disable multilink
set link keep-alive 10 60
set link max-redial 0
set link disable chap pap
set link accept chap pap eap
set link disable incoming
set link mtu 1492
set auth authname "dvxoynzwkt@isp.com"
set auth password 826018765
set pppoe service ""
set pppoe iface mvneta0.4090
open
Jun 30 00:45:00 ppp [wan] IFACE: Rename interface ng0 to pppoe0
Jul 2 02:21:46 ppp [wan] IPCP: rec'd Configure Request #2 (Opened)
Jul 2 02:21:46 ppp [wan] IPADDR 202.138.4.64
Jul 2 02:21:46 ppp [wan] 202.138.4.64 is OK
Jul 2 02:21:46 ppp [wan] IPCP: LayerDown
Jul 2 02:21:47 ppp [wan] IFACE: Down event
Jul 2 02:21:47 ppp [wan] IFACE: Rename interface pppoe0 to pppoe0
Jul 2 02:21:47 ppp [wan] IPCP: SendConfigReq #76
Jul 2 02:21:47 ppp [wan] IPADDR 218.214.186.153
Jul 2 02:21:47 ppp [wan] PRIDNS 203.134.24.70
Jul 2 02:21:47 ppp [wan] SECDNS 203.134.26.70
Jul 2 02:21:47 ppp [wan] IPCP: SendConfigAck #2
Jul 2 02:21:47 ppp [wan] IPADDR 202.138.4.64
Jul 2 02:21:47 ppp [wan] IPCP: state change Opened --> Ack-Sent
Jul 2 02:21:50 ppp [wan] IPCP: SendConfigReq #77
Jul 2 02:21:50 ppp [wan] IPADDR 218.214.186.153
Jul 2 02:21:50 ppp [wan] PRIDNS 203.134.24.70
Jul 2 02:21:50 ppp [wan] SECDNS 203.134.26.70
Jul 2 02:21:52 ppp [wan] IPCP: SendConfigReq #78
Jul 2 02:21:52 ppp [wan] IPADDR 218.214.186.153
Jul 2 02:21:52 ppp [wan] PRIDNS 203.134.24.70
Jul 2 02:21:52 ppp [wan] SECDNS 203.134.26.70
Jul 2 02:21:54 ppp [wan] IPCP: SendConfigReq #79
Jul 2 02:21:54 ppp [wan] IPADDR 218.214.186.153
Jul 2 02:21:54 ppp [wan] PRIDNS 203.134.24.70
Jul 2 02:21:54 ppp [wan] SECDNS 203.134.26.70
Jul 2 02:21:56 ppp [wan] IPCP: rec'd Configure Request #3 (Ack-Sent)
Jul 2 02:21:56 ppp [wan] IPADDR 202.138.4.64
Jul 2 02:21:56 ppp [wan] 202.138.4.64 is OK
Jul 2 02:21:56 ppp [wan] IPCP: SendConfigAck #3
Jul 2 02:21:56 ppp [wan] IPADDR 202.138.4.64
Jul 2 02:21:56 ppp [wan] IPCP: SendConfigReq #80
Jul 2 02:21:56 ppp [wan] IPADDR 218.214.186.153
Jul 2 02:21:56 ppp [wan] PRIDNS 203.134.24.70
Jul 2 02:21:56 ppp [wan] SECDNS 203.134.26.70
Jul 2 02:21:58 ppp [wan] IPCP: SendConfigReq #81
Jul 2 02:21:58 ppp [wan] IPADDR 218.214.186.153
Jul 2 02:21:58 ppp [wan] PRIDNS 203.134.24.70
Jul 2 02:21:58 ppp [wan] SECDNS 203.134.26.70
Jul 2 02:22:00 ppp [wan] IPCP: SendConfigReq #82
Jul 2 02:22:00 ppp [wan] IPADDR 218.214.186.153
Jul 2 02:22:00 ppp [wan] PRIDNS 203.134.24.70
Jul 2 02:22:00 ppp [wan] SECDNS 203.134.26.70
Jul 2 02:22:02 ppp [wan] IPCP: SendConfigReq #83
Jul 2 02:22:02 ppp [wan] IPADDR 218.214.186.153
Jul 2 02:22:02 ppp [wan] PRIDNS 203.134.24.70
Jul 2 02:22:02 ppp [wan] SECDNS 203.134.26.70
Jul 2 02:22:04 ppp [wan] IPCP: SendConfigReq #84
Jul 2 02:22:04 ppp [wan] IPADDR 218.214.186.153
Jul 2 02:22:04 ppp [wan] PRIDNS 203.134.24.70
Jul 2 02:22:04 ppp [wan] SECDNS 203.134.26.70
Jul 2 02:22:06 ppp [wan] IPCP: rec'd Configure Request #4 (Ack-Sent)
Jul 2 02:22:06 ppp [wan] IPADDR 202.138.4.64
Jul 2 02:22:06 ppp [wan] 202.138.4.64 is OK
Jul 2 02:22:06 ppp [wan] IPCP: SendConfigAck #4
Jul 2 02:22:06 ppp [wan] IPADDR 202.138.4.64
Jul 2 02:22:06 ppp [wan] IPCP: SendConfigReq #85
Jul 2 02:22:06 ppp [wan] IPADDR 218.214.186.153
Jul 2 02:22:06 ppp [wan] PRIDNS 203.134.24.70
Jul 2 02:22:06 ppp [wan] SECDNS 203.134.26.70
Jul 2 02:22:08 ppp [wan] IPCP: parameter negotiation failed
Jul 2 02:22:08 ppp [wan] IPCP: state change Ack-Sent --> Stopped
Jul 2 02:22:08 ppp [wan] IPCP: LayerFinish
Jul 2 02:22:08 ppp [wan] Bundle: No NCPs left. Closing links...
Jul 2 02:22:08 ppp [wan] Bundle: closing link "wan_link0"...
Jul 2 02:22:08 ppp [wan_link0] Link: CLOSE event
Jul 2 02:22:08 ppp [wan_link0] LCP: Close event
Jul 2 02:22:08 ppp [wan_link0] LCP: state change Opened --> Closing
Jul 2 02:22:08 ppp [wan_link0] Link: Leave bundle "wan"
Jul 2 02:22:08 ppp [wan] Bundle: Status update: up 0 links, total bandwidth 9600 bps
Jul 2 02:22:08 ppp [wan] IPCP: Close event
Jul 2 02:22:08 ppp [wan] IPCP: state change Stopped --> Closed
Jul 2 02:22:08 ppp [wan] IPV6CP: Close event
Jul 2 02:22:08 ppp [wan] IPV6CP: state change Stopped --> Closed
Jul 2 02:22:08 ppp [wan] IPCP: Down event
Jul 2 02:22:08 ppp [wan] IPCP: state change Closed --> Initial
Jul 2 02:22:08 ppp [wan] IPV6CP: Down event
Jul 2 02:22:08 ppp [wan] IPV6CP: state change Closed --> Initial
Jul 2 02:22:08 ppp [wan_link0] LCP: SendTerminateReq #42
Jul 2 02:22:08 ppp [wan_link0] LCP: LayerDown
Jul 2 02:22:10 ppp [wan_link0] LCP: SendTerminateReq #43
Jul 2 02:22:12 ppp [wan_link0] LCP: state change Closing --> Closed
Jul 2 02:22:12 ppp [wan_link0] LCP: LayerFinish
Jul 2 02:22:12 ppp [wan_link0] Link: DOWN event
Jul 2 02:22:12 ppp [wan_link0] LCP: Down event
Jul 2 02:22:12 ppp [wan_link0] LCP: state change Closed --> Initial
Jul 2 12:01:11 ppp Multi-link PPP daemon for FreeBSD
After numerous "IPCP: SendConfigReq" messages
there is a "IPCP: parameter negotiation failed" message
then the link closing down and there is no more attempt to reconnect.
When the outage is over I can manually establish the connection again without problem.
There are other users having the same issue. https://redmine.pfsense.org/issues/1811
Could you please help me how to configure MPD to keep reconnecting after a "IPCP: parameter negotiation failed" event?
Thank you!
Last edit: David G 2022-04-29
This is known problem. Fortunately, it has a work-around and I advise you to try it and report back.
The work-around uses mpd's embedded bandwidth control that monitors available "bandwidth" for (possibly multi-link) bundle and will forcibly bring disconnected link back on if enabled.
To enable it, add the following to the bundle context of mpd.conf:
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
This feature is documented here:
http://mpd.sourceforge.net/doc5/mpd22.html#22
Thank you Eugene for the information.
I will add these lines to the bundle section.
I can't promise that I will come back with the result shortly, because I am unable to replicate the issue and I need to wait for an ISP outage for this to happen.
Do you know by chance the ticket ID for this issue? so I can follow the progress of the fix.
Thank you!
Best regards,
David
I don't think we have a ticket. Are you willing to test a patch that eliminates the need to use work-arounds if I give it to you?
Thank you for checking if there is a ticket. The only reason I asked about it that redundant lines can be removed after a fixed version.
The fact that there is no ticket suggests to me that the workaround might be as good as a fixed version and it is not worth to invest time in the fix development / testing / etc.
However if you think if a fixed version will give a more stable and reliable end result I will be happy to test the patch, but I might need some help. I also don't know how to reproduce the issue, because it occurs only at certain outages which (fortunately) happen rarely, therefore waiting for an outage might take too long.
I have an upcoming travel and will be back in mid/later June.
Please let me know.
Thank you!
David
I have not forget about your question but it will take several more days for me to address the problem. If you have not time next week, it is not a problem.
I can tell you how to reproduce the problem with simple ipfw rule to simulate and reproduce the problem before applying a patch. And then apply the patch to verify if it's gone.
Apologies for the late response. I am available again and if I can still help with the test I am happy to do it.
I went ahead and presumably fixed that long-standing problem. You should use mpd5-5.9_11 or newer that does not require any work-arounds.
Thank you Eugene for fixing it. I will try mpd5-5.9_11. I am not sure if my service provider had outages lately, but since I applied the patch in May I havn't had to restart my device.
Earlier you have mentioned you have a procedure to replicate the problem with ipfw rule. Just for curiosity I would like to do the tests, would you please share this procedure?
Well, I have to admit that my tries with ipfw to reproduce the problem were not successful really. Then I got an idea how to fix it permanently, so I spent some time on that instead.