Project

General

Profile

Actions

Bug #7145

closed

rc.newwanipv6 running in all cases, even for a renew

Added by Jim Pingle almost 8 years ago. Updated about 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
DHCP (IPv6)
Target version:
Start date:
01/19/2017
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:
All

Description

dhcp6c calls its script for every action, a new binding or a renew and so on. The problem is that rc.newwanipv6 is run even when nothing changed. For example, the address didn't get removed or changed, it just renews the lease and keeps on going. In this case, the interface wasn't altered at all and the actions it takes can be quite harsh/disruptive.

We may not be able to do anything about this yet since dhcp6c does not pass back the type of action it performed. It always sets REASON=NBI in the environment so the script can't tell what exactly happened. rc.newwanipv6 does check the old address vs the new, but it still does things like reset the routing and resets the monitor IP address routing.

It also appears to be triggered twice for each event. I added a "source" parameter to the dhcp6c_wan_script.sh:

Jan 19 10:22:04 clara php-fpm[298]: /rc.newwanipv6: rc.newwanipv6: Info: starting on vmx0, called by dhcp6c.
Jan 19 10:22:04 clara php-fpm[298]: /rc.newwanipv6: rc.newwanipv6: on (IP address: 2001:db8::ffff:f236) (interface: wan) (real interface: vmx0).
Jan 19 10:22:07 clara php-fpm[298]: /rc.newwanipv6: ROUTING: setting default route to 198.51.100.1
Jan 19 10:22:07 clara php-fpm[298]: /rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::290:bff:fe37:a324%vmx0
Jan 19 10:22:07 clara php-fpm[298]: /rc.newwanipv6: Removing static route for monitor fe80::290:bff:fe37:a324 and adding a new route through fe80::290:bff:fe37:a324%vmx0
Jan 19 10:22:07 clara check_reload_status: Reloading filter
Jan 19 10:22:07 clara php-fpm[299]: /rc.newwanipv6: rc.newwanipv6: Info: starting on vmx0, called by dhcp6c.
Jan 19 10:22:07 clara php-fpm[299]: /rc.newwanipv6: rc.newwanipv6: on (IP address: 2001:db8::ffff:f236) (interface: wan) (real interface: vmx0).
Jan 19 10:22:10 clara php-fpm[299]: /rc.newwanipv6: ROUTING: setting default route to 198.51.100.1
Jan 19 10:22:10 clara php-fpm[299]: /rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::290:bff:fe37:a324%vmx0
Jan 19 10:22:10 clara php-fpm[299]: /rc.newwanipv6: Removing static route for monitor fe80::290:bff:fe37:a324 and adding a new route through fe80::290:bff:fe37:a324%vmx0
Jan 19 10:22:10 clara check_reload_status: Reloading filter

Feel free to kick this forward to 2.4.1 if there is no immediately viable solution


Files

dhcp6c (156 KB) dhcp6c Martin Wasley, 01/24/2017 02:33 PM
patch-dhcp6c__script.c (894 Bytes) patch-dhcp6c__script.c Martin Wasley, 01/25/2017 01:04 AM
patch-dhcp6c.c (1.91 KB) patch-dhcp6c.c Martin Wasley, 01/25/2017 01:46 AM
patch-common.c (333 Bytes) patch-common.c Changed log message to show IA and/or PD address Martin Wasley, 01/30/2017 06:48 AM
patch-config.h (403 Bytes) patch-config.h Added new DHCP6S_EXIT state Martin Wasley, 01/30/2017 06:48 AM
patch-dhcp6c.c (3.32 KB) patch-dhcp6c.c Added new signal handling SIGUSER1, log changes and exit script call Martin Wasley, 01/30/2017 06:48 AM
patch-dhcp6c__script.c (16.6 KB) patch-dhcp6c__script.c Added Reason params Martin Wasley, 01/30/2017 06:48 AM
patch-common.c (333 Bytes) patch-common.c Martin Wasley, 01/30/2017 11:13 AM
patch-config.h (403 Bytes) patch-config.h Martin Wasley, 01/30/2017 11:13 AM
patch-dhcp6c.c (3.75 KB) patch-dhcp6c.c Martin Wasley, 01/30/2017 11:13 AM
patch-dhcp6c__script.c (16.6 KB) patch-dhcp6c__script.c Martin Wasley, 01/30/2017 11:13 AM
Actions #1

Updated by Martin Wasley almost 8 years ago

I can have a look at dhcp6c, easy enough to add something. What do you want it do do, set an env stating what triggered the script?

Actions #2

Updated by Jim Pingle almost 8 years ago

It would probably be good enough if dhcp6c properly populated REASON with what actually happened. If it's a simple renew, then the script can detect that and do nothing. If it's a new binding or something else then it can take appropriate actions. The IPv4 equivalent gets to make a lot of decisions based on the REASON passed in from the client environment: https://github.com/pfsense/pfsense/blob/master/src/usr/local/sbin/pfSense-dhclient-script#L304

Actions #3

Updated by Martin Wasley almost 8 years ago

Try this...

These are pulled from the reply state, and are what is displayed in dhcp6c logs, well mine at least. The last dhcp6c patch never made it through. See if it does what you need.

REASON=INF Info
REASON=REP reply
REASON=REN Renew
REASON=REB Rebind
REASON=OFR Offer
REASON=REL Release
REASON=NBI Unkownm

Reply should be a response to a request and I think info is the response to a renew. I have never seen rebind happen so who knows about that one. :)

Actions #4

Updated by Jim Pingle almost 8 years ago

Got a source patch for that? If I do manage to try it, I am not keen on running binaries from outside sources.

Actions #5

Updated by Martin Wasley almost 8 years ago

Yes, attached..

As dhcp6c only calls the script function when the above reply states happen you don't get quite as many possible responses as you do with its v4 counterpart. I've kept it simple by using the existing fixed length static char variable reason[] used for the original REASON=NBI, that can be changed easily enough if you want it to be a full word rather than just three letters.

Would it be useful to pass the obtained lease(s) as a parameter too?

The binary doesn't do anything untoward... promise. :)

Actions #6

Updated by Martin Wasley almost 8 years ago

Use this too, just makes the logging a little tidier. If this is implemented then the dhcp6withoutRA PR I have currently submitted can be binned as I can then take advantage of these changes.

I can get rid of all the ctrl logging junk as well, but obviously that will not be able to be pushed upstream.

Actions #7

Updated by Martin Wasley almost 8 years ago

This is cool... it works nicely. I'm still messing around with it but I've changed the strings to full reply words such as 'REPLY' 'RELEASE' etc and modified the dhcp6c script to use the response and it's good. It will need you to decide what you want to do with RELEASE etc if that comes in. I assume the script is called for REPLY or REBIND and skipped for INFO or RENEW?

My dhcp6c_wan_dhcp6withoutra_script.sh Not sure what to do with the RELEASE so just call the script I guess.

#!/bin/sh
#This shell script launches rtsold.
dmips=${new_domain_name_servers}
dmnames=${new_domain_name}
dreason=${REASON}
echo $dmips > /tmp/igb0_domain_name_servers
echo $dmnames > /tmp/igb0_new_domain_name
echo $dreason > /tmp/igb0_reason
case $REASON in
REPLY|REBIND)
/usr/sbin/rtsold -1 -p /var/run/rtsold_igb0.pid -O /var/etc/rtsold_igb0_script.sh igb0
;;
RELEASE)
/usr/local/sbin/fcgicli -f /etc/rc.newwanipv6 -d "interface=igb0&dmnames=${dmnames}&dmips=${dmips}"
;;
RENEW|INFO)
/usr/bin/logger -t Info "dhcp6c renew, no change - bypassing update on igb0"
esac
Actions #8

Updated by Jim Thompson almost 8 years ago

  • Assignee set to Jim Pingle
Actions #9

Updated by Martin Wasley almost 8 years ago

Also added an EXIT as when the No-release flag it's useful to know that dhcp has exited. Would it be be useful to have it so that if it's sent a release to signal only that, and not the EXIT signal too? Otherwise it will issue a RELEASE and an EXIT.

Actions #10

Updated by Martin Wasley almost 8 years ago

OK, before I do a PR upstream for this, there is one issue left. This only applied in the default mode not dhcp6withoutRA. When releasing, if the EXIT is used to trigger the script dhcp6c_wan_script.sh there is an issue as that file has been deleted before dhcp6c has exited. The dhcp6c_wan_dhcp6withoutra_script.sh is not deleted, I suspect because I have not cleaned up that file during release. If the exit parameter is used then that needs changing. Also on a WAN down event, dhcp6c sits there sending release signals for about 30 seconds but cannot as the interface has been taken down. The only way around this is a forced exit kill -9 and that means no EXIT script run.

  • STOP PRESS ***

Added new signal to dhcp6c, SIGUSR1, sending this signal will cause dhcp6c to cleanly exit even if wan interface is down. Sets the no-release internally and then exits normally..

Actions #11

Updated by Martin Wasley over 7 years ago

Additions and changes to dhcp6c

Actions #12

Updated by Martin Wasley over 7 years ago

Final version. Changed static chars to pointers for exit script call. As it's possible to have multiple interfaces on dhcp6c with multiple scripts ( not used ) I have used the first interface configured ( script-path ) as the script to be called on exit, thus getting rid of an earlier version that used a static char array.

Sorry there are so many updates but as soon as I've posted one lot I get another idea which is better. This should be it though.

Actions #13

Updated by Martin Wasley over 7 years ago

PR Pushed upstream as fix needed for dhcp6c PID issue - Redmine #7185.

Actions #14

Updated by Øyvind Hvidsten over 7 years ago

Having issues with this in 2.3.3
Every 30 minutes, my IPv6 address is refreshed, causing rc.newwanipv6 to fire on all cylinders, which in turn restarts unbound, which makes DNS lookups for internal addresses get relayed to external DNS servers for a split second, which then makes lookups for those addresses fail, as the external server has never heard of the internal names.

I've tested this by resolving an internal address (static DHCP assignment) with nslookup every 0.5 seconds, and at the exact time unbound restarts, I get:

Name: vault.mydomain.org
Address: 192.168.5.92

Wed Mar 15 19:20:26 UTC 2017
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: vault.mydomain.org
Address: 192.168.5.92

Wed Mar 15 19:20:26 UTC 2017
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: vault.mydomain.org
Address: 192.168.5.92

Wed Mar 15 19:20:27 UTC 2017
Server: 193.213.112.4
Address: 193.213.112.4#53

-- server can't find vault: NXDOMAIN

..and any cronjob or other thing attempting to resolve that address at that point in time will fail.

This loop was run on pfSense itself, so one can see all the previous replies coming from 127.0.0.1

Actions #15

Updated by Martin Wasley over 7 years ago

This is fixed in 2.4. DHCP6C client modified to give REASONS and only call the update script when needed.

Actions #16

Updated by Jim Pingle over 7 years ago

  • Status changed from New to Feedback
  • Affected Architecture All added
  • Affected Architecture deleted ()
Actions #17

Updated by Jim Pingle over 7 years ago

  • Status changed from Feedback to Resolved

This seems to behave much better now. On a DHCPv6 VM, before these changes I had a never-ending stream of rc.newwanipv6 calls happening for any event even a simple renew, and now it only happens when it's supposed to.

Actions #18

Updated by Rodrigo Ferraz about 7 years ago

Are there any plans to have this fixed with a 2.3.* release?

I'm having the same problem (https://forum.pfsense.org/index.php?topic=136181.msg745462#msg745462) which is impacting user browsing on several of our customers who had purchased ALIX appliances.

Since 2.4 has dropped i386 and nanobsd support we and our customers who started rolling IPv6 in production are fundamentally doomed.

Actions #19

Updated by Jim Pingle about 7 years ago

Given the scope of the changes and what had to be done, it's unlikely to make it to 2.3.x.

Actions

Also available in: Atom PDF