Project

General

Profile

Bug #9634

rc.newwanipv6 is called although dhcp6c should discard Request messages

Added by Karl Klempner about 1 month ago. Updated 20 days ago.

Status:
New
Priority:
High
Assignee:
-
Category:
DHCP (IPv6)
Target version:
-
Start date:
07/15/2019
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.4.4-p3
Affected Architecture:
All

Description

pfsense sends DHCPv6 Request messsages to ff02::1:2 on its WAN interface at an interval of about 7 seconds. As this is a link-local multicast destination, it also receives those messages. This starts a chain reaction: Upon recieving the message, dhcp6c_wan_script.sh calls rc.newwanipv6 which triggers filter reload etc., pushing my APU's load from 9 to >70 %, leading to severe UDP packet loss, causing DNS request to fail, and rendering VoIP calls sustainably unbearable.

RFC 8415 (DHCPv6) clearly states, "Clients MUST discard any received Request messages" (section 16.4). Following this directive, would it be a solution to ignore REQUEST reasons in dhcp6c_wan_script.sh as we already do with RENEW and INFO reasons, or would this break something else?

Current workaround is to turn off IPv6 on the WAN interface (IPv6 Configuration Type: None).

History

#1 Updated by Flole Systems about 1 month ago

The entire script is broken, even RENEW should be ignored and just REBIND should actually matter. See #9357 for a patch, if it gets modified to ignore REQUEST reasons aswell that would already solve quite some issues, someone just has to do it.

#2 Updated by Karl Klempner 26 days ago

I am now testing the following, modified /var/etc/dhcp6c_wan_script.sh:

#!/bin/sh
# This shell script launches /etc/rc.newwanipv6 with a interface argument.
dmips=${new_domain_name_servers}
dmnames=${new_domain_name}
case $REASON in
# Removed for testing:
# REQUEST)
# /usr/local/sbin/fcgicli -f /etc/rc.newwanipv6 -d "interface=pppoe0&dmnames=${dmnames}&dmips=${dmips}" 
# ;;
REBIND)
;;
RELEASE)
/usr/local/sbin/fcgicli -f /etc/rc.newwanipv6 -d "interface=pppoe0&dmnames=${dmnames}&dmips=${dmips}" 
;;
# Replaced for testing:
# RENEW|INFO)
RENEW|INFO|REQUEST)
esac

At first sight the processor load spikes seem to have gone. Let me watch this for a few days.

#3 Updated by Karl Klempner 20 days ago

Seems to work just fine.
(I had to disable the periodic reset of the PPPoE-(WAN-)Interface for the test to work, because anytime the interface is reset, the directory /var/etc and my modified script would be flushed.)

Also available in: Atom PDF