CRASH in 19.1.8 when PPPOE refreshes

[maikel]

The problem still persists on my machine 

As already mentioned here, the panic is often triggered when using the "disconnect/connect" buttons in the webgui. Furthermore, the same occurs when the cron job performs a "periodic interface reset". So, I disabled the related cron job to check, whether its more stable.

We have the same issue, any result on disabling the cron?

[JDtheHutt]

As this is confirmed as a continuing fault in 19.7, should this thread be moved there or a new one started and linked back to here, with 19.7 discussion there.

[schnipp]

The problem still persists on my machine 

As already mentioned here, the panic is often triggered when using the "disconnect/connect" buttons in the webgui. Furthermore, the same occurs when the cron job performs a "periodic interface reset". So, I disabled the related cron job to check, whether its more stable.

We have the same issue, any result on disabling the cron?

Sorry for my late response. I made some progress with a hack, but this can only be a temporary solution. As I mentioned before (#23, #30) it looks like a kernel bug.

I replaced the cron triggered periodic interface reset with a solution, which only sends a system signal to the "mpd5" process. This allows me to re-establish the PPPoE connection without disassembling the netgraph (which probably crashes the kernel).

For the dirty hack, please create a new file (/usr/local/opnsense/service/conf/actions.d/actions_reconnect_pppoe.conf) with the following content:

Code: [Select]

[reload]
command:/root/reconnect_pppoe_ipv6.sh
parameters:
type:script
message:Force PPPoE Reconnect with IPv6 cleanup
description: Force PPPoE Reconnect with IPv6 cleanup

Afterwards, create a file (/root/reconnect_pppoe_ipv6.sh) with the following content and give the file executable permissions:

Code: [Select]

#!/bin/sh

kill -s USR2 `pgrep mpd5`
sleep 3

while i="`ifconfig pppoe0 | grep inet6 | grep -m 1 -v '%' | cut -f2 -d ' ' | tr -d '[:space:]'`"; do
 if [ -n "$i" ]
  then
   #echo "IPv6 Address found"
   ifconfig pppoe0 inet6 $i delete
  else
   #echo "NO IPv6"
   break
 fi
done

sleep 3
kill -s USR1 `pgrep mpd5`

This script is performing the following 3 steps:

• Release the PPPoE connection by sending the system signal "USR2" to the "mpd5" process
• Delete all public IPv6 addresses from PPPoE interface (considering IPv6 privacy extensions)
• Re-establish the PPPoE connection by sending the system signal "USR1" to the "mpd5" process

My system is now stable more than one month :-)

[tokade]

Hi all,

it seems I have the same problem since the last update to 19.7.8

I can't force the crash with the "disconnect/connect" buttons, only with edit or add button under point-to-point device. The nightly freezes of my system might have the same reason. This morning I could connect to the VNC console where I found lots of messages: "xn_txeof: WARNING: response is -1!"

Where can I find / disable the cron job you mentioned?

I will implement the last workaround and see if it helps. What time do you start your script? Before or after the "freeze" - mine happens between 4 and 5 am.

Kind regards
Torsten

[schnipp]

Where can I find / disable the cron job you mentioned?

I will implement the last workaround and see if it helps. What time do you start your script? Before or after the "freeze" - mine happens between 4 and 5 am.

Because my ISP drops internet connection for renewing my ip address every 24 hours, I'll force renewing the ip address at a fixed point in time. Under "System --> Settings --> Cron" you can periodically call a pre-programmed script "periodic interface reset", which drops and re-eastablishes the pppoe connection. Calling this script can crash the kernel due to modifications of the pppoe related netgraph. Instead of calling this script, I call my own script (see #62).

[tokade]

Hi,

the workaround doesn't prevent my system from freezing. My ISP doesn't drop connection and i haven't got the 'periodic interface reset' in use. So there must be another reason for the nightly freeze.

By further testing I found another command that crashes my system: sysctl -a

Bugs with crahses by sysctl are reported for freebsd and maybe something else uses sysctl during the night...

Kind regards
Torsten