OPNsense Forum
Archive => 18.1 Legacy Series => Topic started by: elektroinside on January 16, 2018, 04:32:19 pm
-
Figured i should not keep this to myself and open a new topic not to flood another.
So, sometimes the PPPoE interface is not loading when it should (18.1.r1, 18.1.r2) and pf restart is required after an OPNsense reboot in order for the interface to work (otherwise, no internet connection for LAN clients, just the OPNsense box).
@Franco, i have sent you a PM with system logs, as you asked me the other day.
Thank you!
-
Hi elektroinside,
Ok, the new debug message triggered... It's what we have guessed last time:
Ironically everything is ok, but new IP assignments are not acted upon during boot time, specifically this block:
https://github.com/opnsense/core/blob/edbcdd0ffec89c436391f477a195fa1ce48141f4/src/etc/rc.newwanip#L42-L45
I'm unsure if this was ever handled differently or your PPPoE is lightning fast... A bit of research is required. If anybody else has an idea that would be splendid as well.
Cheers,
Franco
-
Well, all i can say at the moment is that everything was fine with 17.7.12
I have a cron job to reboot every early morning, did not wake up before without a working internet connection.
Maybe i should create a startup script or cron job which runs a command which executes a pf restart from the console.
Didn't research yet.
I hope it's possible, at least until a fix is available.
-
It is a timing issue that surfaces now. It's not great but it means we're going in the right direction.
You can set a syshook script with:
https://docs.opnsense.org/development/backend/autorun.html
The "start" hooks are executed after boot. You want to call /usr/local/etc/rc.interfaces_wan_configure and that should work around it.
Cheers,
Franco
-
Thanks Franco!
This is what i noticed:
-calling /usr/local/etc/rc.interfaces_wan_configure from the console breaks the connection entirely, not even pf restart (or any other service exposed in the GUI for that matter) repairs it, i need to reboot the box
-with the script, pf restart fixes it, but still needed..
-
Whoops, does not sound so nice. And if you call /usr/local/etc/rc.newwanip in that script?
Possible permanent workaround in the works that would require the above info.
Cheers,
Franco
-
So this is for ordering the debug message...
https://github.com/opnsense/core/commit/cd5e23
And this on top is remembering that newwanip should be executed... at this stage experimental but not worse than before...
https://github.com/opnsense/core/commit/257a93a
# opnsense-patch cd5e23 257a93a
I'm not 100% sure if opnsense-patch does this correctly, it may needs the following, too:
# chmod 755 /usr/local/etc/rc.syshook.d/10-newwanip.start
Cheers,
Franco
-
So far so good, i'll reply again if i manage to reproduce.
I can also see the IP renew in the logs (same gdrive link as in the last pm).
Thank you Franco!
-
I've seen something similar in my system. With 17.7 and 18.1 series. Usually, the first boot after a system upgrade but not always. If i can help, just tell me.
Cheers,
-
I'll test this latest version of the patch in the office today.
https://github.com/opnsense/core/commit/386938
If all goes well, the behaviour should be fixed in the final 18.1 builds.
Cheers,
Franco
-
Mine survived the nightly reboot only with this: https://forum.opnsense.org/index.php?topic=6891.msg30086#msg30086
Just noticed, essentially the same thing as #386938 :)
-
Yes, the only change that was made was moving the reload to the backend daemon for serialisation. The commit is now on master, pending merge to stable/18.1.
Cheers,
Franco
-
Works fine, will be in 18.1.
Cheers,
Franco
-
Confirming, works as expected.
Thanks again Franco!
-
Okay, thanks!
Final commit was this, it also prints what it's doing during boot now:
https://github.com/opnsense/core/commit/f2d600f5b7
-
Yep, great, up and running, i have not (yet) managed to reproduce any issue, 5+ reboots and still everything is fine (lan, wan, vpn, aliases etc.)
-
Hi!
After aplying both patches, no problems about PPPOE on boot but, as a side effect, FRR does not start. I've seen various references to errors in quagga (it is not installed) and FRR inside init.log. I've attached the file.
Cheers,
-
I don't think that's a side effect of the patch as it does serialise before the services are started so it does not mess with the order of things. The quagga/frr thing has been reported here:
https://github.com/opnsense/core/issues/2100
Cheers,
Franco
-
@Franco, are these patches likely to fix my alias issue?
-
Not yet, will fix that one tomorrow.