PPPoE WAN does not restart correctly after reconfiguring interfaces.
-
Yes, of course the labels should be swapped.
-
@stephenw10
Have you been able to dig into this?
It seems one of the changes made to version 24.03 was Revision 30d46b63. Since the behaviour changed with 24.03, the fault might be related to one of the files touched in that change. -
@stephenw10
Have you passed this on to the developers or do I need to somehow open a bug on Redmine? -
Mmm, checking what happened here...
-
After Update to 24.03 i have the same issue. Every night my ISP forces a reset and every night my PPPOE (Netgate 4100) will not reconnect. This is really frustrating:
°PPPOE Log°(Sep 15 03:20:01 ppp 48609 Multi-link PPP daemon for FreeBSD
Sep 15 03:20:01 ppp 48609 process 48609 started, version 5.9
Sep 15 03:20:01 ppp 4389 caught fatal signal TERM
Sep 15 03:20:01 ppp 4389 [wan] IFACE: Close event
Sep 15 03:20:01 ppp 4389 [wan] IPCP: Close event
Sep 15 03:20:01 ppp 4389 [wan] IPCP: state change Opened --> Closing
Sep 15 03:20:01 ppp 4389 [wan] IPCP: SendTerminateReq #4
Sep 15 03:20:01 ppp 4389 [wan] IPCP: LayerDown
Sep 15 03:20:01 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:01 ppp 4389 [wan] IFACE: Removing IPv4 address from pppoe0 failed(IGNORING for now. This should be only for PPPoE friendly!): Can't assign requested address
Sep 15 03:20:01 ppp 4389 [wan] IPV6CP: Close event
Sep 15 03:20:01 ppp 4389 [wan] IPV6CP: state change Opened --> Closing
Sep 15 03:20:01 ppp 4389 [wan] IPV6CP: SendTerminateReq #2
Sep 15 03:20:01 ppp 4389 [wan] IPV6CP: LayerDown
Sep 15 03:20:02 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:03 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:04 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:05 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:06 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:07 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:08 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:09 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:10 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:11 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:12 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:13 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:14 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:15 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:16 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:17 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:18 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:19 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:20 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:21 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:22 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:23 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:24 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:25 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:26 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:27 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:28 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:29 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:30 ppp 48609 waiting for process 4389 to die...
Sep 15 03:20:31 ppp 48609 can't lock /var/run/pppoe_wan.pid after 30 attempts
Sep 15 03:20:52 ppp 4389 [wan] IFACE: Down event
Sep 15 03:20:52 ppp 4389 [wan] IFACE: Rename interface pppoe0 to pppoe0
Sep 15 03:20:52 ppp 4389 [wan] IFACE: Set description "WAN"
Sep 15 03:20:52 ppp 4389 [wan] IPV6CP: SendTerminateReq #3
Sep 15 03:20:52 ppp 4389 [wan] IPCP: SendTerminateReq #5
Sep 15 03:20:52 ppp 4389 [wan] IPCP: rec'd Terminate Ack #4 (Closing)
Sep 15 03:20:52 ppp 4389 [wan] IPCP: state change Closing --> Closed
Sep 15 03:20:52 ppp 4389 [wan] IPCP: LayerFinish
Sep 15 03:20:52 ppp 4389 [wan] IPV6CP: rec'd Terminate Ack #2 (Closing)
Sep 15 03:20:52 ppp 4389 [wan] IPV6CP: state change Closing --> Closed
Sep 15 03:20:52 ppp 4389 [wan] IPV6CP: LayerFinish
Sep 15 03:20:52 ppp 4389 [wan] Bundle: No NCPs left. Closing links...
Sep 15 03:20:52 ppp 4389 [wan] Bundle: closing link "wan_link0"...
Sep 15 03:20:52 ppp 4389 [wan_link0] LCP: rec'd Terminate Request #3 (Opened)
Sep 15 03:20:52 ppp 4389 [wan_link0] LCP: state change Opened --> Stopping
Sep 15 03:20:52 ppp 4389 [wan_link0] Link: Leave bundle "wan"
Sep 15 03:20:52 ppp 4389 [wan] Bundle: Status update: up 0 links, total bandwidth 9600 bps
Sep 15 03:20:52 ppp 4389 [wan] IPCP: Close event
Sep 15 03:20:52 ppp 4389 [wan] IPV6CP: Close event
Sep 15 03:20:52 ppp 4389 [wan] IPCP: Down event
Sep 15 03:20:52 ppp 4389 [wan] IPCP: state change Closed --> Initial
Sep 15 03:20:52 ppp 4389 [wan] IPV6CP: Down event
Sep 15 03:20:52 ppp 4389 [wan] IPV6CP: state change Closed --> Initial
Sep 15 03:20:52 ppp 4389 [wan_link0] LCP: SendTerminateAck #4
Sep 15 03:20:52 ppp 4389 [wan_link0] LCP: LayerDown
Sep 15 03:20:52 ppp 4389 [wan_link0] PPPoE: connection closed
Sep 15 03:20:52 ppp 4389 [wan_link0] Link: DOWN event
Sep 15 03:20:52 ppp 4389 [wan_link0] Link: giving up after 0 reconnection attempts
Sep 15 03:20:52 ppp 4389 [wan_link0] LCP: Close event
Sep 15 03:20:52 ppp 4389 [wan_link0] LCP: state change Stopping --> Closing
Sep 15 03:20:52 ppp 4389 [wan_link0] LCP: Down event
Sep 15 03:20:52 ppp 4389 [wan_link0] LCP: LayerFinish
Sep 15 03:20:52 ppp 4389 [wan_link0] LCP: state change Closing --> Initial
Sep 15 03:20:52 ppp 4389 [wan_link0] Link: CLOSE event
Sep 15 03:20:52 ppp 4389 [wan_link0] LCP: Close event
Sep 15 03:20:54 ppp 4389 [wan] Bundle: Shutdown
Sep 15 03:20:54 ppp 4389 [wan_link0] Link: Shutdown
Sep 15 03:20:54 ppp 4389 process 4389 terminated)I have to downgrade to an older Version of Pfsense as i only have this problem with 24.03.
-
@Malec
Same for me.
I still encounter a race condition that causes mpd to start twice and get stuck, but I wrote my own script as a workaround. Not sure what the real status of the problem is. Still waiting for development snapshots available to re-test. -
@w0w Were you able to test with the older 24.08 public snapshot?
-
@stephenw10
Yes, it is my current snapshot, so the problem remains the same.
However, I should point out that my configuration is far from standard. I also use CARP for failover, VIP addresses on a PPPoE parent interface, and much more, which is why I don’t want to file a bug report prematurely. Additionally, there is hope that something may have changed in the newer code. -
Hmm, OK. Well with any luck we should have a new Plus dev snapshot very soon so hopefully you can test that and at least confirm if the issue still exists. Though there is a lot of new stuff so I anticipate some issues initially.
-
@stephenw10
Unfortunately, yes, the issue still exists.
I am using an unsupported CARP configuration to maintain PPPoE links automatically. There are two firewalls, and the parent PPPoE interfaces on both are configured with static local IP addresses like 10.0.111.2 and 10.0.111.3, with a VIP in CARP mode set to 10.0.111.1. The primary idea is that the master firewall automatically establishes the PPPoE link when it becomes the master. This part works fine. The problem occurs when I unplug the power cable from the ISP’s dumb switch, and it always results in two mpd daemons running simultaneously. -
Urgh, that's in the new 24.08 snapshot?
-
@stephenw10
Yes.24.08-DEVELOPMENT (amd64) built on Wed Sep 25 9:00:00 EEST 2024 FreeBSD 15.0-CURRENT
-
Hmm, let me try to replicate that...
-
@stephenw10
Any luck? -
Not yet. I'll try to get the config back in place today.
-
In April/May I gave a pretty precise problem description including a hint on which files probably contained the error. Was this really just for the bin? Is there any better way to address bugs in the paid product than this forum?
-
You can open a bug report directly: https://redmine.pfsense.org/
At the time there were numerous back end changes going into 24.08 and it was felt that any issues would need to be confirmed as still present after those went in.
Since that does seem to be the case in at least one variant of this issue I'll raise it again and try to replicate it locally.
-
-
-
@w0w Starting with https://forum.netgate.com/post/1162532.
-
@pFence
hmm ok…
And you also can replicate this on the latest snapshot?