Dhcp6c[xxxxx]: client6_recvadvert: XID mismatch
-
…2.2.6 (full) running on sg2440...
Today my cable modem (time warner) got reprogrammed by the telco and thus warm-rebooted. Don't think the physical Ethernet link to pfsense ever went down although hard to tell. I have dual-wan, Verizon FIOS on WAN1 and TimeWarner on WAN2. TimeWarner supports IPv6 via DHCP6, on FIOS it is set to none. I didn't restart the pfsense router and after the TW modem reset, the interface has lost it's IPv6 address. LAN still had a v6 assigned but v6 routing was not working.
My dhcp logs showed a swath of```
dhcp6c[xxxxx]: XID mismatch I found the relevant PFSenseDocs page… https://doc.pfsense.org/index.php/DHCPv6_Client_XID_Mismatch Running the commands manually via ssh fixed things right up. My question is... could this be automated somehow? If there should only be 1 instance of dhcp6c running then would it be possible/desirable to automatically detect >1 of them and kill/reload as part of the ip detection scripts? -
Im assuming the IPv6 address changed after the warm reset?
-
To be honest I did not note what it was prior to the reset. It may not have changed but I'm not sure I have any way to find out.
-
To be honest I did not note what it was prior to the reset. It may not have changed but I'm not sure I have any way to find out.
I have found it changes every time you reboot your pfSense box or if you restart the dhcp6 client.
-
Right - I started the thread not about the IP changing (that's fine and expected with DHCP) but the fact that DHCPv6 actually breaks until you ssh into the router and manually kill the dhcp6c process. I happened to be aware of this reboot as I was on the phone with them when it happened, so going in manually and fixing it wasn't a huge deal. But generally I would never have known that IPv6 was broken until much later.
So I was wondering if that situation was possible to automatically detect and self-repair.
-
And did you already evaluate the David_W Patch ?
https://forum.pfsense.org/index.php?topic=101967.msg584693#msg584693
-
Wasn't aware of the "David_W patches" thanks. I will definitely give these a try and report back.
-
This is certainly a situation where the patch linked to by hda might help. The patch has now been accepted by the pfSense team and has been merged into both the master (2.3) and RELENG_2_2 (2.2) branches. Another pfSense 2.2 release is unlikely unless a sufficiently serious security issue arises as the focus is on getting 2.3 released.
Those using 2.3 just need to update and they will be running code that includes the patch.
At the moment, the instructions for 2.2 will still work, though I may delete the feature branch from my pfSense repository, which will invalidate the published URL for the patch. It should be possible to fetch the patch using ec0643f7f1537ab6a18ed05fc015ecba598fcffc instead of that URL, which is the commit ID for the patch being merged to the RELENG_2_2 branch of the main pfSense repository. If there is a pfSense 2.2.7 release for some reason, my patch will be included in that release.
All this said, I fear that the scenario covered by this thread might fall outside the issues I addressed in that patch. My work has been focused on correcting issues with PPP / PPPoE connections and IPv6, where the mpd5 daemon used for PPP and PPPoE knows about transitions in link state from the LCP layer and signals pfSense to take appropriate action via the ppp-ipv6 script that I wrote (it appears in pfSense from 2.2.5 onwards).
It may well be that pfSense needs to monitor for repeated XID mismatch errors from the same dhcp6c process and, when they occur, either restart dhcp6c or take the full range of actions taken by ppp-ipv6 when a PPP(oE) link goes down and comes back up.
I think there might also be issues with pfSense failing to handle changes in prefixes delegated to it via DHCP-PD correctly - again, this is a scenario I've yet to explore fully as my ISP uses static prefix delegations.
-
I think there might also be issues with pfSense failing to handle changes in prefixes delegated to it via DHCP-PD correctly - again, this is a scenario I've yet to explore fully as my ISP uses static prefix delegations.
Just for a quick aside from the main topic…
This will definitely need to be fixed in 2.3, if they're going to allow access to the DHCPv6 Server and RA settings for interfaces using Track Interface... because a change in prefix delegated via PD means that DHCPv6 server and radvd configurations need to be adjusted and the services restarted... and I await seeing how DHCPv6 static leases are handled for a Track Interface interface. :)
-
Sorry to dredge this up but— I've been on 2.3.2-p1 for a while now and this continues to plague me almost every week. I thought the "David_W patch" had been merged to fix this issue? But it still happens to me, most often after a Time Warner modem power cycle but sometimes out of "nowhere" as well. Today I wound up with 3 identical copies of dhcp6c running and had to kill them off from the console and re-save the WAN interface to get things right.
My WAN v6 config is set to "DHCP6" and RA mode is "Assisted" if that is relevant.
Is there a redmine for this? I did a quick search for dhcp6c and came up with a few possibilities but none seemed identical and all were at 0% progress… :(
https://redmine.pfsense.org/issues/6880
https://redmine.pfsense.org/issues/6981
https://redmine.pfsense.org/issues/7145I didn't search the github commits but, has anything changed in 2.4 that might help this situation? It's pretty frustrating to have to babysit the firewall like this, especially because there's no way to know you've hit this until things kind of just fall apart and you log in and check.
-
In response to the thread on Redmine, how did you get on with 2.4?
-
Yesterday I upgraded from 2.3.2 to 2.3.3 and from there up to 2.4. My build is now 2.4.0.b.20170131.2311. Took a bit of time to get the cobwebs brushed away, remove some no-longer-needed Patches, etc but for the most part it was smooth and painless.
So far so good, can't say if the dhcp6c issue is resolved yet but I'll know soon enough. I saw some additional fixes were pushed today that haven't made it into snaps yet so that should get even better.
-
Yesterday I upgraded from 2.3.2 to 2.3.3 and from there up to 2.4. My build is now 2.4.0.b.20170131.2311. Took a bit of time to get the cobwebs brushed away, remove some no-longer-needed Patches, etc but for the most part it was smooth and painless.
So far so good, can't say if the dhcp6c issue is resolved yet but I'll know soon enough. I saw some additional fixes were pushed today that haven't made it into snaps yet so that should get even better.
Yes, the PR today has gone upstream, a strange one that, deleting the pid file before all processes are complete is not nice. :)
