PPPoE WAN does not restart correctly after reconfiguring interfaces.
-
One of the multiwan configured interfaces is PPPoE. Sometimes after interface changes, for example adding some port to some LAGG, PPPoE interface just disconnects and never connecting again.
This is what happening in the logs:Nov 11 18:16:51 ppp 90180 process 90180 terminated Nov 11 18:16:51 ppp 90180 [wan_link0] Link: Shutdown Nov 11 18:16:51 ppp 90180 [wan] Bundle: Shutdown Nov 11 18:16:49 ppp 90180 [wan_link0] LCP: state change Closed --> Initial Nov 11 18:16:49 ppp 90180 [wan_link0] LCP: Down event Nov 11 18:16:49 ppp 90180 [wan_link0] LCP: Close event Nov 11 18:16:49 ppp 90180 [wan_link0] Link: giving up after 0 reconnection attempts Nov 11 18:16:49 ppp 90180 [wan_link0] Link: DOWN event Nov 11 18:16:49 ppp 90180 [wan_link0] LCP: LayerFinish Nov 11 18:16:49 ppp 90180 [wan_link0] LCP: state change Closing --> Closed Nov 11 18:16:49 ppp 90180 [wan_link0] LCP: rec'd Terminate Ack #255 (Closing) Nov 11 18:16:49 ppp 90180 [wan_link0] LCP: LayerDown Nov 11 18:16:49 ppp 90180 [wan_link0] LCP: SendTerminateReq #255 Nov 11 18:16:49 ppp 90180 [wan] IPV6CP: state change Closed --> Initial Nov 11 18:16:49 ppp 90180 [wan] IPV6CP: Down event Nov 11 18:16:49 ppp 90180 [wan] IPCP: state change Closed --> Initial Nov 11 18:16:49 ppp 90180 [wan] IPCP: Down event Nov 11 18:16:49 ppp 90180 [wan] IPV6CP: Close event Nov 11 18:16:49 ppp 90180 [wan] IPCP: Close event Nov 11 18:16:49 ppp 90180 [wan] Bundle: Status update: up 0 links, total bandwidth 9600 bps Nov 11 18:16:49 ppp 90180 [wan_link0] Link: Leave bundle "wan" Nov 11 18:16:49 ppp 90180 [wan_link0] LCP: state change Opened --> Closing Nov 11 18:16:49 ppp 90180 [wan_link0] LCP: Close event Nov 11 18:16:49 ppp 90180 [wan_link0] Link: CLOSE event Nov 11 18:16:49 ppp 90180 [wan] IPCP: rec'd Terminate Ack #6 (Closed) Nov 11 18:16:49 ppp 90180 [wan] IPV6CP: rec'd Terminate Ack #4 (Closed) Nov 11 18:16:49 ppp 90180 [wan] Bundle: closing link "wan_link0"... Nov 11 18:16:49 ppp 90180 [wan] Bundle: No NCPs left. Closing links... Nov 11 18:16:49 ppp 90180 [wan] IPV6CP: LayerFinish Nov 11 18:16:49 ppp 90180 [wan] IPV6CP: state change Closing --> Closed Nov 11 18:16:49 ppp 90180 [wan] IPV6CP: rec'd Terminate Ack #3 (Closing) Nov 11 18:16:49 ppp 90180 [wan] IPCP: LayerFinish Nov 11 18:16:49 ppp 90180 [wan] IPCP: state change Closing --> Closed Nov 11 18:16:49 ppp 90180 [wan] IPCP: rec'd Terminate Ack #5 (Closing) Nov 11 18:16:49 ppp 90180 [wan] IPCP: SendTerminateReq #6 Nov 11 18:16:49 ppp 90180 [wan] IPV6CP: SendTerminateReq #4 Nov 11 18:16:49 ppp 90180 [wan] IFACE: Set description "WAN" Nov 11 18:16:49 ppp 90180 [wan] IFACE: Rename interface pppoe0 to pppoe0 Nov 11 18:16:49 ppp 90180 [wan] IFACE: Down event Nov 11 18:16:46 ppp 90180 [wan] IPV6CP: LayerDown Nov 11 18:16:46 ppp 90180 [wan] IPV6CP: SendTerminateReq #3 Nov 11 18:16:46 ppp 90180 [wan] IPV6CP: state change Opened --> Closing Nov 11 18:16:46 ppp 90180 [wan] IPV6CP: Close event Nov 11 18:16:46 ppp 90180 [wan] IFACE: Removing IPv4 address from pppoe0 failed(IGNORING for now. This should be only for PPPoE friendly!): Can't assign requested address Nov 11 18:14:57 ppp 80297 can't lock /var/run/pppoe_wan.pid after 30 attempts Nov 11 18:14:56 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:56 ppp 84348 can't lock /var/run/pppoe_wan.pid after 30 attempts Nov 11 18:14:55 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:55 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:54 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:54 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:53 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:53 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:52 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:52 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:51 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:51 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:50 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:50 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:49 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:49 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:48 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:48 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:47 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:47 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:46 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:46 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:45 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:45 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:44 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:44 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:43 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:43 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:42 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:42 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:41 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:41 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:40 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:40 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:39 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:39 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:38 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:38 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:37 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:37 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:36 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:36 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:35 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:35 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:34 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:34 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:33 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:33 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:32 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:32 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:31 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:31 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:30 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:30 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:29 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:29 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:28 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:28 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:27 ppp 80297 waiting for process 90180 to die... Nov 11 18:14:27 ppp 80297 process 80297 started, version 5.9 Nov 11 18:14:27 ppp 80297 Multi-link PPP daemon for FreeBSD Nov 11 18:14:27 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:26 ppp 84348 waiting for process 90180 to die... Nov 11 18:14:26 ppp 90180 [wan] IPCP: LayerDown Nov 11 18:14:26 ppp 90180 [wan] IPCP: SendTerminateReq #5 Nov 11 18:14:26 ppp 90180 [wan] IPCP: state change Opened --> Closing Nov 11 18:14:26 ppp 90180 [wan] IPCP: Close event Nov 11 18:14:26 ppp 90180 [wan] IFACE: Close event Nov 11 18:14:26 ppp 90180 caught fatal signal TERM Nov 11 18:14:26 ppp 84348 process 84348 started, version 5.9 Nov 11 18:14:26 ppp 84348 Multi-link PPP daemon for FreeBSDWhen it stopped, I can manually connect it via GUI or issuing
/etc/rc.linkup start wanI can replicate this, when PPPoE WAN is up and running, just by issuing
/usr/local/sbin/pfSctl -c 'interface reload wan'Even more… Once I've accidentally run this several times then I got fatal trap 12
db:1:pfs> bt Tracing pid 0 tid 100011 td 0xfffffe00c636ae40 kdb_enter() at kdb_enter+0x32/frame 0xfffffe001b15e160 vpanic() at vpanic+0x163/frame 0xfffffe001b15e290 panic() at panic+0x43/frame 0xfffffe001b15e2f0 trap_fatal() at trap_fatal+0x40c/frame 0xfffffe001b15e350 trap_pfault() at trap_pfault+0xae/frame 0xfffffe001b15e3c0 calltrap() at calltrap+0x8/frame 0xfffffe001b15e3c0 --- trap 0xc, rip = 0xffffffff80f6c27e, rsp = 0xfffffe001b15e490, rbp = 0xfffffe001b15e680 --- ip6_output() at ip6_output+0xc6e/frame 0xfffffe001b15e680 syncache_respond() at syncache_respond+0x6f6/frame 0xfffffe001b15e750 syncache_add() at syncache_add+0xb89/frame 0xfffffe001b15e8d0 tcp_input_with_port() at tcp_input_with_port+0x15c1/frame 0xfffffe001b15ea40 tcp6_input_with_port() at tcp6_input_with_port+0x6a/frame 0xfffffe001b15ea70 tcp6_input() at tcp6_input+0xb/frame 0xfffffe001b15ea80 ip6_input() at ip6_input+0xc95/frame 0xfffffe001b15eb60 netisr_dispatch_src() at netisr_dispatch_src+0x218/frame 0xfffffe001b15ebc0 ether_demux() at ether_demux+0x17a/frame 0xfffffe001b15ebf0 ether_nh_input() at ether_nh_input+0x392/frame 0xfffffe001b15ec40 netisr_dispatch_src() at netisr_dispatch_src+0xad/frame 0xfffffe001b15eca0 ether_input() at ether_input+0xd9/frame 0xfffffe001b15ed00 iflib_rxeof() at iflib_rxeof+0xe6c/frame 0xfffffe001b15ee00 _task_fn_rx() at _task_fn_rx+0x7a/frame 0xfffffe001b15ee40 gtaskqueue_run_locked() at gtaskqueue_run_locked+0xa8/frame 0xfffffe001b15eec0 gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xd3/frame 0xfffffe001b15eef0 fork_exit() at fork_exit+0x82/frame 0xfffffe001b15ef30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe001b15ef30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- db:1:pfs> show registers cs 0x20 ds 0x3b es 0x3b fs 0x13 gs 0x1b ss 0x28 rax 0x12 rcx 0xffffffff814b1aaf rdx 0xffffffff814a2070 rbx 0x100 rsp 0xfffffe001b15e160 rbp 0xfffffe001b15e160 rsi 0x80 rdi 0xffffffff83024090 cnputs_mtx r8 0 r9 0 r10 0 r11 0 r12 0 r13 0 r14 0xffffffff81416f5e r15 0xfffffe00c636ae40 rip 0xffffffff80d33722 kdb_enter+0x32 rflags 0x86 kdb_enter+0x32: movq $0,0x234c163(%rip) db:1:pfs> show pcpu cpuid = 0 dynamic pcpu = 0x12a0cc0 curthread = 0xfffffe00c636ae40: pid 0 tid 100011 critnest 1 "if_io_tqg_0" curpcb = 0xfffffe00c636b360 fpcurthread = none idlethread = 0xfffffe00c63673a0: tid 100003 "idle: cpu0" self = 0xffffffff84210000 curpmap = 0xffffffff83023ab0 tssp = 0xffffffff84210384 rsp0 = 0xfffffe001b15f000 kcr3 = 0x80000000c58aa002 ucr3 = 0xffffffffffffffff scr3 = 0x35bc64bde gs32p = 0xffffffff84210404 ldt = 0xffffffff84210444 tss = 0xffffffff84210434 curvnet = 0xfffff80001177f40 spin locks held: db:1:pfs> run lockinfo db:2:lockinfo> show locks db:2:lockinfo> show alllocks Process 99938 (dpinger) thread 0xfffffe011d6473a0 (124557) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xfffff800178ad180) locked @ /var/jenkins/workspace/pfSense-Plus-snapshots-23_09-main/sources/FreeBSD-src-plus-RELENG_23_09/sys/kern/uipc_socket.c:4036 Process 98790 (dpinger) thread 0xfffffe011f808c80 (124552) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xfffff800178d4900) locked @ /var/jenkins/workspace/pfSense-Plus-snapshots-23_09-main/sources/FreeBSD-src-plus-RELENG_23_09/sys/kern/uipc_socket.c:4036 Process 98092 (dpinger) thread 0xfffffe011e4241e0 (124548) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xfffff800173a6180) locked @ /var/jenkins/workspace/pfSense-Plus-snapshots-23_09-main/sources/FreeBSD-src-plus-RELENG_23_09/sys/kern/uipc_socket.c:4036 db:2:lockinfo> show lockedvnods Locked vnodes db:1:pfs> acttraceCan anyone else test this behavior and confirm it?
-
@w0w said in PPPoE WAN does not restart correctly after reconfiguring interfaces.:
Can anyone else test this behavior and confirm it?
Yes.
Annoying isn't it?
️ -
That could be separate issues. The panic is almost certainly this: https://redmine.pfsense.org/issues/14431
Do you have VIPs on the PPPoE? That first issue could be this: https://redmine.pfsense.org/issues/14434
-
@stephenw10 said in PPPoE WAN does not restart correctly after reconfiguring interfaces.:
That could be separate issues. The panic is almost certainly this: https://redmine.pfsense.org/issues/14431
Hope so.
@stephenw10 said in PPPoE WAN does not restart correctly after reconfiguring interfaces.:
Do you have VIPs on the PPPoE? That first issue could be this: https://redmine.pfsense.org/issues/14434
I have VIP on parent interface, but not on the PPPoE itself. Anyway, will try to remove it and test again.
-
No VIPs, same problem.
Nov 12 08:56:45 ppp 15723 process 15723 terminated Nov 12 08:56:45 ppp 15723 [wan_link0] Link: Shutdown Nov 12 08:56:45 ppp 15723 [wan] Bundle: Shutdown Nov 12 08:56:43 ppp 15723 [wan_link0] LCP: state change Closed --> Initial Nov 12 08:56:43 ppp 15723 [wan_link0] LCP: Down event Nov 12 08:56:43 ppp 15723 [wan_link0] LCP: Close event Nov 12 08:56:43 ppp 15723 [wan_link0] Link: giving up after 0 reconnection attempts Nov 12 08:56:43 ppp 15723 [wan_link0] Link: DOWN event Nov 12 08:56:43 ppp 15723 [wan_link0] LCP: LayerFinish Nov 12 08:56:43 ppp 15723 [wan_link0] LCP: state change Closing --> Closed Nov 12 08:56:43 ppp 15723 [wan_link0] LCP: rec'd Terminate Ack #3 (Closing) Nov 12 08:56:43 ppp 15723 [wan_link0] LCP: LayerDown Nov 12 08:56:43 ppp 15723 [wan_link0] LCP: SendTerminateReq #3 Nov 12 08:56:43 ppp 15723 [wan] IPV6CP: state change Closed --> Initial Nov 12 08:56:43 ppp 15723 [wan] IPV6CP: Down event Nov 12 08:56:43 ppp 15723 [wan] IPCP: state change Closed --> Initial Nov 12 08:56:43 ppp 15723 [wan] IPCP: Down event Nov 12 08:56:43 ppp 15723 [wan] IPV6CP: Close event Nov 12 08:56:43 ppp 15723 [wan] IPCP: Close event Nov 12 08:56:43 ppp 15723 [wan] Bundle: Status update: up 0 links, total bandwidth 9600 bps Nov 12 08:56:43 ppp 15723 [wan_link0] Link: Leave bundle "wan" Nov 12 08:56:43 ppp 15723 [wan_link0] LCP: state change Opened --> Closing Nov 12 08:56:43 ppp 15723 [wan_link0] LCP: Close event Nov 12 08:56:43 ppp 15723 [wan_link0] Link: CLOSE event Nov 12 08:56:43 ppp 15723 [wan] IPCP: rec'd Terminate Ack #5 (Closed) Nov 12 08:56:43 ppp 15723 [wan] IPV6CP: rec'd Terminate Ack #4 (Closed) Nov 12 08:56:43 ppp 15723 [wan] Bundle: closing link "wan_link0"... Nov 12 08:56:43 ppp 15723 [wan] Bundle: No NCPs left. Closing links... Nov 12 08:56:43 ppp 15723 [wan] IPV6CP: LayerFinish Nov 12 08:56:43 ppp 15723 [wan] IPV6CP: state change Closing --> Closed Nov 12 08:56:43 ppp 15723 [wan] IPV6CP: rec'd Terminate Ack #3 (Closing) Nov 12 08:56:43 ppp 15723 [wan] IPCP: LayerFinish Nov 12 08:56:43 ppp 15723 [wan] IPCP: state change Closing --> Closed Nov 12 08:56:43 ppp 15723 [wan] IPCP: rec'd Terminate Ack #4 (Closing) Nov 12 08:56:43 ppp 15723 [wan] IPCP: SendTerminateReq #5 Nov 12 08:56:43 ppp 15723 [wan] IPV6CP: SendTerminateReq #4 Nov 12 08:56:43 ppp 15723 [wan] IFACE: Set description "WAN" Nov 12 08:56:43 ppp 15723 [wan] IFACE: Rename interface pppoe0 to pppoe0 Nov 12 08:56:43 ppp 15723 [wan] IFACE: Down event Nov 12 08:56:40 ppp 15723 [wan] IPV6CP: LayerDown Nov 12 08:56:40 ppp 15723 [wan] IPV6CP: SendTerminateReq #3 Nov 12 08:56:40 ppp 15723 [wan] IPV6CP: state change Opened --> Closing Nov 12 08:56:40 ppp 15723 [wan] IPV6CP: Close event Nov 12 08:56:40 ppp 15723 [wan] IFACE: Removing IPv4 address from pppoe0 failed(IGNORING for now. This should be only for PPPoE friendly!): Can't assign requested address Nov 12 08:55:47 ppp 6735 can't lock /var/run/pppoe_wan.pid after 30 attempts Nov 12 08:55:46 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:45 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:44 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:43 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:42 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:41 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:40 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:39 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:38 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:37 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:36 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:35 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:34 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:33 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:32 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:31 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:30 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:29 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:28 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:27 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:26 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:25 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:24 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:23 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:22 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:21 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:20 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:19 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:18 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:17 ppp 6735 waiting for process 15723 to die... Nov 12 08:55:17 ppp 6735 process 6735 started, version 5.9 Nov 12 08:55:17 ppp 15723 [wan] IPCP: LayerDown Nov 12 08:55:17 ppp 15723 [wan] IPCP: SendTerminateReq #4 Nov 12 08:55:17 ppp 15723 [wan] IPCP: state change Opened --> Closing Nov 12 08:55:17 ppp 15723 [wan] IPCP: Close event Nov 12 08:55:17 ppp 15723 [wan] IFACE: Close event Nov 12 08:55:17 ppp 15723 caught fatal signal TERM Nov 12 08:55:17 ppp 6735 Multi-link PPP daemon for FreeBSDSystem log also contains:
Nov 12 08:56:58 php-fpm 29419 /rc.filter_configure_sync: GW States: Gateway is down but its IP address cannot be located. Skipping state kill.: WAN_PPPOESo no, it is not related to VIPs
-
Hmm, interesting. It's still two competing mpd processes though, each one starts a new process when it dies even though another one is already running.
-
@stephenw10
Yep…
ps aux | grep mpd5
right arter /usr/local/sbin/pfSctl -c 'interface reload wan'
shows two mpd5 with same command line used, not sure what was caused that. Will triple check if I have some forgotten scripts somewhere
-
It's probably the same race condition caused by VIPs on PPPoE. Not sure what would trigger it in your case though.
-
@stephenw10
Can PPPoE itself be comparable to a VIP - it is a tunnel within a real interface IP?️ -
@stephenw10
Any thoughts how to debug this? -
@RobbieTT said in PPPoE WAN does not restart correctly after reconfiguring interfaces.:
@stephenw10
Can PPPoE itself be comparable to a VIP - it is a tunnel within a real interface IP?Yes interesting question. Certainly there are plenty of people doing that. If you get a 'business' connection with a /29 from BT for example that is how you might use them.
But is that valid on a point to point connection? It seems like a regression but possibly it worked previously just by luck. -
Continuing the thinking, do all the different IPv6 addresses we create on an interface count as VIPs?
️ -
No, not in the same way that's triggering that flapping. I've never seen the competing mpd instances here for example.
-
@stephenw10
Well, can’t the mpd itself be the cause? It starts with the -k key, but for some reason it cannot access the PID file of the previously started process. I looked at your competitors project, it seems like they have a similar problem and Franco suggested that it’s the MPD itself, their patch calls a external non mpd function that kills the process by the PID, this is, of course, if I understood everything correctly. -
It's certainly possible. It feels more like a regression in the boot code though. Or at least a change there. It didn't used to do this in earlier versions and mpd really hasn't changed much. Though it was never that great!
-
I have two WAN interfaces, and both are configured for DHCP6 (next to PPPoE for IPv4 on one of them, and DHCP on the other). In that case an automatic periodic reset configured for PPPoE or manually issuing
/usr/local/sbin/pfSctl -c 'interface reload wan'will break PPPoE, and a second mpd is active for about 30 seconds before it vanishes.
However, as soon as I disable DHCP6 on either of them, issuing the command will not break PPPoE, and a second mpd is active for only about 5 seconds before it vanishes.
Note that this happens even if one of the WAN interfaces actually has no communication because I interrupted the link one hop behind the router. So the bug seems to be related to multiple IPv6 configurations (and not primarily to multiple PPPoE or DHCP communications)?Is there a bug associated to this issue?
-
Hmm, do those IPv6 link both work initially? There have been problems with dual PPPoE link carrying IPv6 in the past: https://redmine.pfsense.org/issues/13939
There is only a problem when it resets?
-
@stephenw10 said in PPPoE WAN does not restart correctly after reconfiguring interfaces.:
Hmm, do those IPv6 link both work initially? There have been problems with dual PPPoE link carrying IPv6 in the past: https://redmine.pfsense.org/issues/13939
That is not the issue here. My configuration is
- WAN1: PPPoE and DHCP6
- WAN2: DHCP and DHCP6
When I remove one of the DHCP6 configurations and reload, the PPPoE on WAN1 immediately activates. If I keep both and reload, even after hours PPPoE on WAN1 remains dead.
-
Ah I see. Does restarting the DHCP WAN also trigger it?
-
I do not know the syntax to send a reload command just for interface WAN2.
/usr/local/sbin/pfSctl -c 'interface reload wan2'does not work.
Using the GUI though, when I enable interface WAN2 with a DHCP6 configuration where it didn't have one before, that does not kill PPPoE on interface WAN1. But I am not sure whether that is equivalent to an 'interface reload' command.
