DHCPv6 Client Broken in latest snapshot

jimp

Do you have a different piece of hardware (real or virtual) you can try here to see if it's isolated to those hnX NICs or your environment (hyperv?)?

Also we recently, in the last few days, resynchronized with FreeBSD 11.2 so it's possible we picked up a bug fix, so it's worth testing on the latest snapshot.

bimmerdriver

@jimp said in DHCPv6 Client Broken in latest snapshot:

Do you have a different piece of hardware (real or virtual) you can try here to see if it's isolated to those hnX NICs or your environment (hyperv?)?

Also we recently, in the last few days, resynchronized with FreeBSD 11.2 so it's possible we picked up a bug fix, so it's worth testing on the latest snapshot.

Unfortunately, I don't have any other hardware to try.

I just updated to the latest snapshot and unfortunately, the error is exactly the same.

If it would be useful to you, I could set up teamviewer so you can get on the system and take a look.

darkfire

@jimp is there something we can do to help you?

darkfire

a link to a related issue on the pfsense bug tracker
https://redmine.pfsense.org/issues/8489

jimp

@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).

bimmerdriver

@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/8489

Issue 8489 isn't a "related issue". It's the bug report for the issue I reported in this thread.

bimmerdriver

@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.

bimmerdriver

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.

bimmerdriver

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.

jimp

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.

bimmerdriver

@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.

lakekeman

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 Solicit

My pfsense is a Hyper-v VM.
Internet provider is Vodafone Cable in germany - and yes I need the "do not wait for RA" option.

xpxp2002

@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 Solicit

My 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.

chrisheacock

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.

kmo12345

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.

darkfire

the same for me, but my pfsense is running on bare metal.

kmo12345

@darkfire can you post on the redmine bug page. https://redmine.pfsense.org/issues/8489

@jimp was looking for someone with this problem happening on bare metal.

darkfire

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?

mattund

I have not received an IPv6 address since upgrading to 2.4.4 either. Also on Hyper-V 2016, hn driver in use.

mattund

I found a fix for this on Hyper-V I think...

The only real places Input/output error (aka 5 or EIO) really happen in hn in FreeBSD without printing an error to the system log are in /sys/dev/hyperv/netvsc/if_hn.c

The 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 ifconfig and 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 -txcsum6

And ran dhcp6c -c /var/etc/dhcp6c_wan.conf -f hn0 after. 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.