DHCPv6 Client Broken in latest snapshot
-
@darkfire said in DHCPv6 Client Broken in latest snapshot:
@jimp is there something we can do to help you?
Find a way to reproduce it reliably that doesn't rely on being connected to an ISP that requires "do not wait for RA".
As far as I'm aware, nobody here has been able to replicate the problem behavior or error message(s).
-
@darkfire said in DHCPv6 Client Broken in latest snapshot:
a link to a related issue on the pfsense bug tracker
https://redmine.pfsense.org/issues/8489Issue 8489 isn't a "related issue". It's the bug report for the issue I reported in this thread.
-
@jimp said in DHCPv6 Client Broken in latest snapshot:
@darkfire said in DHCPv6 Client Broken in latest snapshot:
@jimp is there something we can do to help you?
Find a way to reproduce it reliably that doesn't rely on being connected to an ISP that requires "do not wait for RA".
As far as I'm aware, nobody here has been able to replicate the problem behavior or error message(s).
That doesn't bode well for this ever getting fixed. Something changed in April and without the snapshots being available to isolate which one introduced the change that's causing the problem, the uselessly vague error message is all there is to go on.
-
I made some configuration changes on my hyper-v server. It's using Intel I350 NIC for WAN and LAN. I updated to the latest version of the Intel driver. I also disabled VMQ. Neither change made any difference. I'm still seeing the same error in the log and ipv6 is not working.
-
Just to be clear, the configuration change included switching the WAN from the built-in HP NIC to the Intel NIC. So the WAN is using different hardware, a proven NIC with the latest driver. My other system was on 2.3.5 and is now on 2.4.3 and it's working fine. I don't see what else this could be but a regression.
-
I agree, it could be a regression, but that still doesn't explain why it only affects certain people or configurations. We need a reliable way to reproduce the error. So far, just setting that one option doesn't produce that error for any system I've tried. There must be some other component to it.
-
@jimp said in DHCPv6 Client Broken in latest snapshot:
I agree, it could be a regression, but that still doesn't explain why it only affects certain people or configurations. We need a reliable way to reproduce the error. So far, just setting that one option doesn't produce that error for any system I've tried. There must be some other component to it.
If you would like to try my system, you're welcome to. We can use teamviewer.
-
I have this problem after upgrading to 2.4.4-RELEASE.
No more IPv6 addresses for me.
Sep 24 20:38:29 dhcp6c 6839 transmit failed: Input/output error
Sep 24 20:38:29 dhcp6c 6839 Sending SolicitMy pfsense is a Hyper-v VM.
Internet provider is Vodafone Cable in germany - and yes I need the "do not wait for RA" option. -
@lakekeman said in DHCPv6 Client Broken in latest snapshot:
I have this problem after upgrading to 2.4.4-RELEASE.
No more IPv6 addresses for me.
Sep 24 20:38:29 dhcp6c 6839 transmit failed: Input/output error
Sep 24 20:38:29 dhcp6c 6839 Sending SolicitMy pfsense is a Hyper-v VM.
Internet provider is Vodafone Cable in germany - and yes I need the "do not wait for RA" option.Mine also broke. Also running Hyper-V 2016. Only difference is I can run without Do not wait for RA. Regardless of whether that option is turned on or off, I no longer get a DHCP6 address on my WAN interface or a PD for my other networks.
-
Broken for me as well! I too am running hyper-v and the "do not wait for RA" makes no difference for me.
This was broken in the devel snapshots for me as well, but I had hoped this would be addressed before pushing it live!
Pretty bummed that this issue was ignored for folks virtualizing their firewalls.
-
I am running Server 2016 Datacenter with pfsense as a gen2 guest.
I have also lost IPv6 connectivity after updating to 2.4.4
Not that it seems to make a difference but I need the "Do not wait for RA" option.
-
the same for me, but my pfsense is running on bare metal.
-
-
I found out that there is no IPv6 link local address on my Wan interface, does anyone have an idea why and how can I fix it?
-
I have not received an IPv6 address since upgrading to 2.4.4 either. Also on Hyper-V 2016,
hndriver in use. -
I found a fix for this on Hyper-V I think...
The only real places
Input/output error(aka 5 orEIO) really happen inhnin FreeBSD without printing an error to the system log are in/sys/dev/hyperv/netvsc/if_hn.cThe only thing I noted that's relative to sending packets is the send TCP Checksum Offload, and notably, for IPv6. So, I looked at my
ifconfigand suuuure enough,options=480018<VLAN_MTU,VLAN_HWTAGGING,LINKSTATE,TXCSUM_IPV6>- I had it enabled!
So I took a wild guess, and ran
ifconfig hn0 -txcsum6And ran
dhcp6c -c /var/etc/dhcp6c_wan.conf -f hn0after. I now have IPv6. This might be a start!EDIT:
I logged a bug report ASAP with upstream FreeBSD just in case there is some substance to what I found: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231797. In the meantime, disabling all hardware checksum offloading seems to be working perfectly, including across reboot.
-
@mattund It looks like you are onto something. I was in communication with a couple of the developers who reviewed the commit that you referenced, so I sent them an email.
-
@mattund I tried the steps you posted and immediately saw the IPv6 gateway come back online on the Dashboard.
I rebooted and lost IPv6 again so I went to System / Advanced / Networking and disabled Hardware Checksum Offloading. Looking at the output of ifconfig this definitely removed the IPv4 offloading as well but it seems to give me IPv6 that persists across reboots.
Interestingly, I still don't seem to have any IPv6 for my clients.
EDIT: Looks like the prefix size got reset somehow. I set that properly and I am back in business minus hardware offloading.
-
@bimmerdriver Thank you!
@kmo12345
I'm glad it helped -
I was able to reproduce the checksum disable box not actually disabling IPv6 transmit checksums, I opened an issue for that here: https://redmine.pfsense.org/issues/8980
