PPPoE WAN does not restart correctly after reconfiguring interfaces.

stephenw10

No, not in the same way that's triggering that flapping. I've never seen the competing mpd instances here for example.

w0w

@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.

stephenw10

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!

pFence

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?

stephenw10

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?

pFence

@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.

stephenw10

Ah I see. Does restarting the DHCP WAN also trigger it?

pFence

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.

stephenw10

You'd have to use the internal interface name there so possibly:
/usr/local/sbin/pfSctl -c 'interface reload opt1'

Check the config or console menu to see those like:

 WAN (wan)   -> ix3  -> v4/DHCP4: 172.21.16.23/24
 LAN (lan)   -> igc0 -> v4: 192.168.23.1/24
 WAN2 (opt1) -> ix2  -> 
 WAN3 (opt2) -> ix0  -> 
 WAN4 (opt3) -> ix1  -> 
 LAN2 (opt4) -> igc1 ->

pFence

It is indeed opt1. And no, issuing

/usr/local/sbin/pfSctl -c 'interface reload opt1'

does not break PPPoE on interface WAN1. Only

/usr/local/sbin/pfSctl -c 'interface reload wan'

does.

stephenw10

We're probably going to need to see some logs.

How do you have the periodic reset configured?

pFence

It is configured as "Custom" periodic reset within the PPPoE configuration of interface WAN1.

stephenw10

OK, that should work.

If the second WAN is disabled does the dhcpv6 on WAN reconnect correctly?

pFence

Yes, both PPPoE (IPv4) and DHCP6 connect correctly.

stephenw10

Ok I thing we're going to need to see some logs of the reconnection to see what's happening there.

pFence

Here's the PPP log when it failed.
PPPoE failing.txt

stephenw10

That reads like there was other stuff happening before that log except starts?

When was the reset?

What does the system log show over that period?

pFence

The reset is at 5:55. Here is the system log starting at 4:00:
log.txt

stephenw10

Hmm, so it appears that something prevents the old mpd process closing for an excessively long time!

It doesn't actually close out until here:

Apr 17 05:57:30 gate1 check_reload_status[457]: updating dyndns opt8
Apr 17 05:57:30 gate1 check_reload_status[457]: Rewriting resolv.conf
Apr 17 05:57:30 gate1 ppp[47767]: [wan] IFACE: Down event

By which time the new mpd5 has given up.

Unclear why that would delay it. Or why a second dhcpv6 instance would make any difference.

With the other WAN disabled for v6 does the mpd process finish without that min wait?

Konstanti

hi
, the main problem I see is that when a new mpd process is started, the previously started processes are checked (whether the file /var/run/pppoe_wan.pid exists) if the file exists, a command is sent to terminate the process.

Apr 17 05:55:01 gate1 ppp[90881]: process 90881 started, version 5.9
Apr 17 05:55:01 gate1 ppp[90881]: waiting for process 47767 to die...

Then, within 30 seconds (30 attempts), the closing of the previous mpd process is checked again. If this does not happen, then the program terminates (your case)

Apr 17 05:55:31 gate1 ppp[90881]: waiting for process 47767 to die...
Apr 17 05:55:32 gate1 ppp[90881]: can't lock /var/run/pppoe_wan.pid after 30 attempts

. In your case, the previous process, for some unknown reason, was completed not within 30 seconds, but after 2 minutes and 30 seconds .

Apr 17 05:57:32 gate1 ppp[47767]: process 47767 terminated