Project

General

Profile

Actions

Bug #13487

open

GUI IPV6-WAN-status stays "Offline, Packetloss" after a short communication hick up

Added by Louis B 3 months ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Gateway Monitoring
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
Affected Architecture:
amd64

Description

After what is probably a short communication hick up, the GUI IPV6-WAN-status stays "Offline, Packetloss"
I noticed this issue at least five times. Luck-ally it only seems to be the GUI-status. Luckily the real traffic seems to be OK.

What happens:
- at certain moment pfsense detect that the GW is gone (see alarms below)
- the communication returns (a ping shows that the GW is back again)
- however the GUI keeps the error state for ever
- so the gateway status return is not properly detected by pfSense

I did setup a syslog server (graylog) in order to fetch all potential related alarms.

In the logging I found messages which draw my attention. when filtering the log using message like "ppp"
- <12>1 2022-09-09T04:12:53.468066+02:00 pfSense.lan dpinger 76225 - - WAN_DHCP6 fe80::9217:3fff:fe7f:e4a1%pppoe1: Alarm latency 3558us stddev 4502us loss 22%

Using the time as new selection criteria I selected the alarms occurring around this time. Starting and ending with an alarm which IMHO is not related. Here they are:
<134>1 2022-09-09T04:12:35.879325+02:00 pfSense.lan filterlog 72340 - - 1316,,,1559467905,lagg0.13,match,pass,in,4,0x0,,1,64738,0,none,103,pim,46,192.168.13.1,224.0.0.13,datalength=26
<12>1 2022-09-09T04:12:53.468066+02:00 pfSense.lan dpinger 76225 - - WAN_DHCP6 fe80::9217:3fff:fe7f:e4a1%pppoe1: Alarm latency 3558us stddev 4502us loss 22%
<30>1 2022-09-09T04:12:53.474315+02:00 pfSense.lan rc.gateway_alarm 30961 - - >>> Gateway alarm: WAN_DHCP6 (Addr:fe80::9217:3fff:fe7f:e4a1%pppoe1 Alarm:1 RTT:3.558ms RTTsd:4.502ms Loss:22%)
<13>1 2022-09-09T04:12:53.474964+02:00 pfSense.lan check_reload_status 391 - - updating dyndns WAN_DHCP6
<13>1 2022-09-09T04:12:53.474990+02:00 pfSense.lan check_reload_status 391 - - Restarting OpenVPN tunnels/interfaces
<13>1 2022-09-09T04:12:53.474983+02:00 pfSense.lan check_reload_status 391 - - Restarting IPsec tunnels
<13>1 2022-09-09T04:12:53.474997+02:00 pfSense.lan check_reload_status 391 - - Reloading filter

For more info see the forum https://forum.netgate.com/topic/173356/issues-with-ipv6

Actions #1

Updated by Flole Systems about 2 months ago

I'm pretty sure this is one of those beautiful filter-reload issues that causes packet loss. It's a regression that was introduced at some point, then it was improved but it's still worse than before. The filter reloads, causes packet loss, which triggers another reload, at this point the gateway is offline, it doesn't matter if additional loss is introduced due to the last reload, it was offline before. After some time it calmed down again so it switches to online again, that is detected and another reload is issued and the entire thing starts from the beginning.

Actions

Also available in: Atom PDF