Project

General

Profile

Actions

Bug #13555

open

When WAN is lost, ipv6 interface will not renew upon WAN availability

Added by ahx cjb 4 months ago. Updated 3 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
DHCP Client (IPv6)
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Release Notes:
Default
Affected Plus Version:
22.05
Affected Architecture:

Description

See: https://forum.netgate.com/topic/174029/if-internet-goes-down-ipv6-won-t-work-until-reboot

Steps to reproduce:
- Remove WAN cable from pfSense
- Re-insert WAN cable

Observations:
- ipv4 interface comes back up with IP immediately
- ipv6 interface (local-link) is down.
- No RA packets are observed.

[22.05-RELEASE][admin@root: /sbin/rtsol -DF ix0
rtsol: checking if ix0 is ready...
rtsol: ix0 is tentative
rtsol: set timer for ix0 to 1s
rtsol: New timer is 1s
rtsol: timer expiration on ix0, state = 4
rtsol: checking if ix0 is ready...
rtsol: ix0 is ready
rtsol: set timer for ix0 to 0s
rtsol: New timer is 0s
rtsol: timer expiration on ix0, state = 1
rtsol: sendmsg on ix0: Network is down
rtsol: set timer for ix0 to 4s
rtsol: New timer is 4s

- To fix:
Reboot pfSense
NB: You must 'reboot', not 'reroot'.

Replicatable? Yes. Every single time.

Actions #1

Updated by ahx cjb 4 months ago

IPv4 WAN setup ?

Ethernet to [Nokia] Fibre ONT [Verizon US]

Multi WAN or not ?

Single WAN.

What is your IPv6 setup ?

Configuration Type: DHCP6
Prefix: /56
Send IPv6 prefix hint: enabled
Do not wait for RA: Enabled.
Do not allow PD/Address release: Enabled

Actions #2

Updated by Kris Phillips 4 months ago

I'm unable to reproduce this. I have two WANs with IPv6 and when I unplug the cable on either one, then reconnect it 30 seconds later, they immediately show both IPv4 and IPv6 as available and online.

Actions #3

Updated by Kris Phillips 4 months ago

Correction: I was able to reproduce this with one of my two ISPs after I changed some settings.

Disabling the option "Do not wait for RA" caused the mentioned issue. However, enabling this option on the WAN caused IPv6 to work normally.

Likely your ISP doesn't send RAs until a DHCP6 request is received (like mine). This is likely not a bug, but expected behavior with some ISPs.

Actions #4

Updated by ahx cjb 3 months ago

Kris Phillips wrote in #note-3:

Correction: I was able to reproduce this with one of my two ISPs after I changed some settings.

Disabling the option "Do not wait for RA" caused the mentioned issue. However, enabling this option on the WAN caused IPv6 to work normally.

Likely your ISP doesn't send RAs until a DHCP6 request is received (like mine). This is likely not a bug, but expected behavior with some ISPs.

I believe RAs are sent prior to a DHCP6 request being sent. My ISP is Verizon (USA). I simply do not see any once the ip6 link is broken (pulling cable from WAN port). Rebooting immediately brings back the ip6 link. This is not normal / expected behaviour.

[22.05-RELEASE][@pfSense] sudo /sbin/rtsol -DF igc0
rtsol: checking if igc0 is ready...
rtsol: cap_llflags_get() failed, anyway I'll try
rtsol: set timer for igc0 to 1s
rtsol: New timer is 1s
rtsol: timer expiration on igc0, state = 1
rtsol: sendmsg on igc0: Can't assign requested address
rtsol: set timer for igc0 to 4s
rtsol: New timer is 4s
rtsol: rtmsg type 2, len=240
rtsol: New timer is 4s
rtsol: timer expiration on igc0, state = 2
rtsol: sendmsg on igc0: Can't assign requested address
rtsol: set timer for igc0 to 4s
rtsol: New timer is 4s
rtsol: rtmsg type 2, len=240
rtsol: New timer is 4s
rtsol: rtmsg type 2, len=240
rtsol: New timer is 1s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=272
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: rtmsg type 4, len=336
rtsol: New timer is 0s
rtsol: timer expiration on igc0, state = 2
rtsol: sendmsg on igc0: Can't assign requested address
rtsol: set timer for igc0 to 1s
rtsol: New timer is 1s
rtsol: timer expiration on igc0, state = 2
rtsol: No answer after sending 3 RSs
rtsol: stop timer for igc0
rtsol: there is no timer

Actions #5

Updated by Kris Phillips 3 months ago

This redmine can be closed as Not a Bug

Actions #6

Updated by ahx cjb 3 months ago

Kris Phillips wrote in #note-5:

This redmine can be closed as Not a Bug

No. It can't. It is reproducable on every Verizon line I have tried this on. Did you reproduce this on a Verizon FTTP ONT connection? I suspect not.

Disabling the option "Do not wait for RA" caused the mentioned issue.

..and yet, I have that option checked and the issue still occurs.

This is likely not a bug, but expected behavior with some ISPs.

This is a bug. If this was 'expected behaviour', how does an ip6 lease only ever get assigned when the router is rebooted. This is ridiculous. What logs can I supply to help get this fixed?

Actions #7

Updated by Marcos M 3 months ago

It may be helpful to have DHCP6 debugging enabled under System / Advanced / Networking and getting the full logs both while it's working and not working. Additionally if possible, testing the latest 2.7 snapshot to see if the issue is already resolved there.

Actions

Also available in: Atom PDF