25.03.b.20250507.1611 crash
-
@stephenw10 gif0 is the only gif tunnel I have, it is a tunnelbroker.net connection that provides IPv6 to the LAN (where the sleepy computer resides) and a number of VLANs.
Those LAN/VLANs all have static IPv6 configuration (/64) in the routed/48 tunnelbroker subnet.The router mode is set to Assisted with DHCPv6 servers running.
In addition to tunnelbroker.net I also have one VLAN that is configured with IPv6 by Tracking my ISP WAN which uses DHCPv6.
-
Hmm, curious. Yes, hard to see how that could create any sort of loop on any interface.
Is that client that goes to sleep attached directly to pfSense? Such that the link state could change when it goes into standby?
-
@stephenw10 said in 25.03.b.20250507.1611 crash:
Is that client that goes to sleep attached directly to pfSense?
No, there's an unmanaged switch inbetween
-
@stephenw10 said in 25.03.b.20250507.1611 crash:
Is that client that goes to sleep attached directly to pfSense?
I changed my network setup and have now tested with a direct connection between Sleepyhead and the pfSense and the pfSense behaviour is different for the same scenario:
I can still see the reception of the TCP retransmissions, but pfSense does not respond with ICMPv6 Destination Unreachable after a timeout like previously, it just seems to drop the package which eventually leads to a TCP reset from the other end. No ICMP == no gif0: loop detected in this scenario.
This all makes sense I guess, considering the amount of work pfSense does when it detects the LAN/igb1 going down at the point of going to sleep. It knows the LAN client is unavailable and acts accordingly.
So, a switch is required between pfSense and the LAN client to trigger the "loop detected" scenario.
-
I found an easier way of recreating the issue, saving me having to put the computer to sleep: all I need to do is to is to start a file transfer (wget for example) in one of the hyper-v guests that resides on the LAN (and therefore also exists over the gif interface), and then just pause the hyper-v guest. After a short while pfSense will answer incoming packets on the gif destined for the sleeping guest with ICMPv6 Destination Unreachable, and in the syslog the corresponding "gif0: loop detected" is added.
As I monitor the situation I can also see that the remaining "loop detected" that gets triggered are from Wi-Fi attached phones, which have a tendency to wake up and go back to sleep much more regularly.
I think I have now found all scenarios which triggers the "gif0: loop detected". One was down to my misconfiguration of firewall rules, I leave it to you to find out why the pfSense generated "ICMv6 Destination Unreachable" are regarded as "looped".
-
Hmm, interesting. I'd assume you still saw those loop warnings in 24.11?
I don't believe it's actually related to the crash though TBH. Have to wait on that.
-
@stephenw10 said in 25.03.b.20250507.1611 crash:
I don't believe it's actually related to the crash though
I agree, it is a side track, and I doubt it is actually 25.03-related either. I didn't run the gif in 24.11 so I have no history. If the beta config.xml is compatible with 24.11 I could try and load it and see if the pfSense behaviour has changed.
-
The config version has changed so it will complain if you try to load a 25.03 config into 24.11. It might work.
It depends what you actually have configured. -
@stephenw10 yes, I loaded the current 25.03 config into 24.11 earlier and there were some warnings and a few errors. Most things seemed to work well though, including the GIF tunnel, but there was a lot more "loop detected" than in the beta. They seemed triggered by other scenarios than just the beta's "ICMP6 Unreachable Desination, Unreachable Address". Not sure how much can be read into that considering the "invalid" config file (and I really don't feel like manually setting up the current config in 24.11!)
-
Ah, OK. So not a regression then. Yup I think we safely say it's unrelated to the crash.
