IPV6 Renew WAN interface
-
There may be something in that. I have packet captures from both when the prefix changed and when it didn't. On the one that didn't change, the capture starts with a couple of renew XID lines, then some release XID etc. The one that changed goes right to several release XID lines and no renew XID at all.
Perhaps this is a bug with pfSense, but I don't know enough to say for certain.
Also, the capture that has the change was made with Wireshark on a different computer and the one that didn't change was captured by pfSense. However, I wouldn't expect that to make a difference. I used the separate computer as I found pfSense wasn't capturing the ones that changed, perhaps because I was disconnecting the cable modem, causing the interface to drop.
I'm running pfSense 2.3.2-RELEASE-p1 (amd64).
If someone wants to examine them, I could post the captures as attachments or send them via email.
-
It's not intrinsically a bug with pfSense, more a feature of ISP's using dynamic allocations.
When the wide-dhcp6c client was originally written and even to the current FreeBSD version it seems no-one thought of the issue of PD delegations being dynamic and changing, not all ISP's do it like this, but a few do, mine being one of them!
When dhcp6c is shut down by pfSense, remember that dhcp6c is part of FreeBSD ( all be it with some minor changes ) then as part of its shutdown dhcp6c will send a release signal.
What I have done, is to prevent that release signal from ever being sent.
-
What I have done, is to prevent that release signal from ever being sent.
How did you do that?
-
What I have done, is to prevent that release signal from ever being sent.
How did you do that?
I modified the client to add an extra parameter in the command line, then I modified interfaces.php to create the option to turn the 'no release' option on or off and modified the interfaces.inc to handle the option.
Job done.
-
Perhaps you can list the details. Also, as I mentioned earlier, the captures show a renew was not issued when the prefix changed. When a renew was sent the prefix didn't change. In either situation releases were sent.
-
Perhaps you can list the details. Also, as I mentioned earlier, the captures show a renew was not issued when the prefix changed. When a renew was sent the prefix didn't change. In either situation releases were sent.
And as I said earlier, this appears to be ISP specific, some do - some don't, and some do sometimes. It's a belt and braces job, remove all the possibilities and then see what you are left with. In our case it has solved the issue. A similar issue occurred with the DHCP6 and sending a solicit before RA, it only affects certain ISP's.
-
A network architect at my ISP is already looking into this. However, I'm still curious as to why pfSense did not send a renew on the occasion when the prefix changed. This is something that's beyond the control of the ISP.
When dhcp6c is shut down by pfSense, remember that dhcp6c is part of FreeBSD ( all be it with some minor changes ) then as part of its shutdown dhcp6c will send a release signal.
In my testing, psSense dhcp6c is not being shut down. I just unplug the Ethernet cable from the WAN interface. This should be seen as a failure to be recovered from rather than a deliberate shut down. Again, I see a release in both instances, but no renew when the prefix changes.
-
A network architect at my ISP is already looking into this. However, I'm still curious as to why pfSense did not send a renew on the occasion when the prefix changed. This is something that's beyond the control of the ISP.
In that particular case the BNG of your provider is seeing a lost connection and is arbitrarily giving you a new allocation, and yes your ISP should look into it.
When dhcp6c is shut down by pfSense, remember that dhcp6c is part of FreeBSD ( all be it with some minor changes ) then as part of its shutdown dhcp6c will send a release signal.
In my testing, psSense dhcp6c is not being shut down. I just unplug the Ethernet cable from the WAN interface. This should be seen as a failure to be recovered from rather than a deliberate shut down. Again, I see a release in both instances, but no renew when the prefix changes.
So you are seeing a release, this is what I am stopping with my changes, in our case the BNG does the correct thing and releases the allocation. DHCP6C cannot send a renew as it has released the allocation, along with timeout and the other putty it needs, It should now go back to square one and start the procedure for a new addess, if your ISP had no issues then you should get the same address again.
-
So why the difference with sending a renew on some occasions and not on others, when in both cases I just pulled the cable?
If you want, I can send you a PM to provide links to the captures, on Google Drive. Then you'll be able to compare the 2 situations.
-
So why the difference with sending a renew on some occasions and not on others, when in both cases I just pulled the cable?
If you want, I can send you a PM to provide links to the captures, on Google Drive. Then you'll be able to compare the 2 situations.
I'm not talking about renew I'm talking about release, two different things.
