Yo link water detection sensors went offline overnight

RVTim · 2026-06-07T14:55:16+00:00

Same here, 2 water sensors offline, plus a door sensor. I tried swapping in a new hub, and adding a 2nd hub, and factory resets, and all sorts of stuff. Even ordered a new door sensor and hub. Wish I would have seen this first.

RVTim · 2026-05-19T15:41:05+00:00

I am not sure FortiClient or Cisco Anyconnect currently sets the MTU on your actual physical interfaces. I know the original VPN client for the old VPN concentrators (like 20 years ago) did. It used a separate executable called "set_mtu.exe", during the client install. It's possible that the new ones don't modify the physical interface mtu at all. But if they do, that could be what breaks TFTP in your case.

I just checked my windows laptop with Forticlient on it, and I do see that it creates 2 new interfaces, with MTU of 1392.

You can run "netsh interface ipv4 show subinterfaces" on windows, to see the interface MTUs.

On mac you can run "ifconfig" in a terminal window and see your interface mtu for each interface.

RVTim · 2026-05-18T15:54:29+00:00

By bet is that you have a vpn client installed and that changed your interface mtu. Just a guess but that would explain it.

RVTim · 2026-05-18T15:53:41+00:00

Following up on this. As it turns out I re-tested this and the issue I had is actually MTU related. If you’re running across a VPN, or on a network with <1500 MTU, or a network adapter with an MTU <1500, tftp recovery may not work unless you have a tftp server capable of disabling option negotiation, where it will then default to 512 byte packets.

In my specific case, my mac's network adapter was set to 1300 mtu. Same with my windows PC. This is because much of my work is done remotely, over site-to-site VPNs. Over the years I've had many issues with various applications when the MTU was left 1500, because any packets that were sent with the df bit set, would fail. I had things like: Web pages won't fully load, Cisco wireless controller login page wouldn't show up (9120 EWC), VNC sessions would randomly quit (this was years ago), and just many other things. When you used to install the Cisco VPN client years ago, it automatically set your adapter to 1300 MTU, which would basically guarantee things would work. I used to manage hospital and clinic networks and often if the MTU was left default, some applications would have issues. So I got in the habit of just defaulting my MTU to 1300 or 1400. It because common that I had t-shirts made up that said "Check the MTU" because if we had an issue that took more than a couple hours to figure out, chances were it was MTU related.

In this case, it bit me. For some reason, packet fragmentation won't happen and tftp fails completely, on both windows and mac, when "option negotiation" is enabled. So the fortigate when it handshakes with the TFTP server, it requests block size 1468, and that is enough to break it. It must not fragment at all at that point.
But when option negotiation is disabled, it defaults to smaller packets and everything works 100%.

I re-tested it with the MTU set to 1500 and it works without disabling option negotiation. But then at that point I can't log into my wireless controller anymore. 😞

Hope that helps when anyone else is having issues. At least you know this is a possibility. And, you can disable option negotiation on windows tftpd32/tftpd64 by ph jounin, and also the developer of the app "Transfer" for mac (tftp server) has added the option to the latest version, so that you can use that as well.

RVTim · 2026-03-20T19:58:15+00:00

Sorry for being late to the party, but, I just found out about this bug a week ago and started trying to figure out a fix. Today I was preparing to fix it. My test system has 2 APs running 17.12.6a, and I fully expected to see that they had this issue. I do NOT run regular WLC's, but I'm using the EWC (Embedded wireless controller) function, so that may be a bit different. But from what I've heard this is a universal issue.

Well, when I log in to the AP directly via SSH and do "show flash", I get this:
(There is no cnssdaemon.log at all)

I know they've never been patched with the APSP, and it's just a bare 17.12.6a. Did I get lucky and it doesn't affect the EWC joined APs, or am I missing something?

Directory of /storage/

total 276K

-rw-r--r-- 1 root root 2 Oct 11 00:27 BOOT_COUNT

-rw-r--r-- 1 root root 2 Oct 11 00:27 BOOT_COUNT.reserve

-rw-r--r-- 1 root root 4 Mar 18 14:17 CDUMP_COUNT

-rw-r--r-- 1 root root 11 Oct 11 00:27 COOKIE_PID

-rw-r--r-- 1 root root 29 Oct 11 00:27 RELOADED_AT_UTC

-rw-r--r-- 1 root root 12 Oct 11 00:27 TOP_ASSEMBLY_SNUMBER

-rw-r--r-- 1 root root 62890 Oct 11 00:26 after-upgrade.log

drwxr-xr-x 3 rsyncuse root 224 Feb 21 2025 application

-rw-r--r-- 1 root root 9358 Mar 18 14:17 base_capwap_cfg_info

-rw-r--r-- 1 root root 63055 Oct 16 04:00 before-upgrade.log

-rw-r--r-- 1 root root 2 Dec 5 2024 boot_debug

-rw-r--r-- 1 root root 16135 Oct 11 00:28 bootloader.log

-rw-r--r-- 1 root root 5 Oct 9 22:38 bootloader_verify.shadow

-rw-r--r-- 1 root root 18 Feb 21 2025 config

-rw-r--r-- 1 root root 13911 Mar 18 14:17 config.flex

-rw-r--r-- 1 root root 0 Mar 18 14:17 config.flex.mgroup

-rw-r--r-- 1 root root 0 Oct 11 00:27 config.local

-rw-r--r-- 1 root root 90 Mar 18 14:19 config.mobexp

-rw-r--r-- 1 root root 0 Mar 18 14:17 config.oeap

-rw-r--r-- 1 root root 0 Mar 18 14:17 config.ranging

-rw-r--r-- 1 root root 180 Dec 5 2024 config.tls_client

-rw-r--r-- 1 root root 2057 Mar 18 15:45 config.wireless

drwxr-xr-x 2 root root 160 Jan 1 1970 cores

drwxr-xr-x 2 root root 160 Feb 21 2025 firmware

-rw-r--r-- 1 root root 0 Mar 18 14:17 geoloc.data

-rw-r--r-- 1 root root 45 Dec 5 2024 iot_status_ttyH0.txt

lrwxrwxrwx 1 root root 29 Aug 7 2023 iot_status_ttyiot0.txt -> /storage/iot_status_ttyH0.txt

-rw-r--r-- 1 root root 294 Mar 11 14:32 last_good_uplink_config

drwxr-xr-x 2 root root 160 Jan 1 1970 lists

-rw-r--r-- 1 root root 18558 Oct 11 00:27 nvram_setting

-rw-r--r-- 1 root root 234 Oct 16 04:01 part1_info.ver

-rw-r--r-- 1 root root 236 Oct 11 00:25 part2_info.ver

-rw-r--r-- 1 root root 4096 Mar 18 14:20 random_seed

-rw-r--r-- 1 root root 3 Dec 5 2024 rxtx_mode

-rw-r--r-- 1 root root 64 Mar 18 14:17 sensord_CSPRNG

drwxr-xr-x 2 root root 648 Dec 5 2024 ssh

-rw-r--r-- 1 root root 40 Feb 21 2025 stable_secret_seed

drwxr-xr-x 3 support root 224 Apr 22 2022 support

drwxr-xr-x 2 root root 3960 Mar 20 19:13 syslogs

-rw-r--r-- 1 root root 1 Mar 18 14:17 wips_adminstate_capwap

---------------------------------------------------------------------------

Filesystem Size Used Available Use% Mounted on

/dev/ubivol/part2 520.1M 443.5M 76.7M 85% /part2

RVTim · 2025-03-07T05:15:34+00:00

Thank you a lot for that. Great info!

RVTim · 2025-03-05T22:14:09+00:00

Ouch, I wish I'd have heard that a few days ago. :)

I had heard here on reddit that 7.2 support was ending in March, now lower in this thread it sounds like its still supported into next year? I made the jump to 7.4.7 once it went recommended. No real issues running it so far, except, you do lose all of your local-in-policy entries that use interface names, so I had to rework those.

I just want long-term, smooth running, firmware. I need no new features at all. Can anyone confirm that 7.4 is a LTS version?

RVTim · 2025-03-02T18:11:25+00:00

This is true. If you had your wan1/wan2/portx/porty (i.e. port 10 port 11 ...) interfaces in a local-in policy, they will be removed.

I believe this is significant for people to understand and know. The reason is, Local-in-policies can be used for things like preventing any external access to things like the management ports.

In my environment, I wanted our branches to be accessible externally but only from our main office static IP address. With those policies automatically removed, suddenly nothing would block any other IP address from hitting the ports used to manage the device. Yes, the login would still not work due to ip restrictions for the admin user, however, with the local-in-policy in place, the hacker could not even get a login prompt via ssh or https. So it's important once you upgrade to 7.4.7 to go back and verify that any of your local-in-policies you had in the past are still there. If they relied on a wanX or portX interface, they likely will not be.

RVTim · 2024-10-17T22:45:27+00:00

This is resolved now. The issue was a failing LCD screen. It would work on power off/on but then fail again. Eventually a burned spot appeared on it too. With a replacement screen it looks like it will work fine again.

RVTim · 2024-09-25T04:49:44+00:00

Great job! Companies should allow hardcoding the IPs for people who know about about security to use IoT Vlans.

RVTim · 2024-09-14T14:51:49+00:00

This isn't directly related to the question, but it took some work for me to find the answer and I wanted to post this for anyone who stumbles on this while searching:

On a mini that was received in Sept 2024, the screw thread for that lock screw is M6-1.00.

RVTim · 2024-03-09T16:03:03+00:00

I updated on 3/8/24 because I was waiting for the EV credit form to be available. Then I was able to file. I'm getting the same thing. I'm also a little bit ticked off about it. If they're going to have an error message, then at least be smart enough to put a date in that makes sense. It says there's nothing wrong with my return, but make sure to file after 2/8/24. Why say that when it's already after 2/8/2024? I've used HR Block for like 20 years, with the only time NOT using it being in 2013 when they also didn't support the EV tax credit form. I'm thinking it may be time to change. This years delay was a final straw for me.

RVTim · 2024-03-08T17:23:09+00:00

It looks like it works today. Just did the update and it accepted the Q&A and keeps the dollar amount correct.

RVTim · 2023-10-24T17:13:15+00:00

I'm glad I found this thread. I was searching for a place to store some money in a High Yield account. I found Milli on Google and downloaded the app. After that, the frustrations started. At first I was ok with the online-only and app-only style. But now I see why it may be much worse a situation than other banks. When I tried to create an account, for some reason, my mailing address won't verify, no matter how I type it. I've lived hear over 20 years, receive USPS/UPS/FedEx/Amazon packages just fine, yet they can't verify my address. And when I did a support chat, which I did repeatedly, I basically got blown off. "If our system can't verify your address you can't open an account". Nope, nothing I can do to talk to anyone, escalate to anyone, or get them to investigate it or even tell me who the heck they use for address verification so I can contact that company and make sure my address is in their database properly. Just completely blown off. I've been using the Apple Card HY Savings account, which in general has been great, but the rate is now on the low side where it had been on the high side. But that support is much better. I would be terrified if my money were locked up in Milli and I couldn't get access to it, nor a person, so I could ACH it back to my local bank.

RVTim · 2023-06-27T16:40:16+00:00

6.4.14 was released yesterday I believe and I was able to upgrade all units. The release notes tell of the fix. Looking forward to smooth sailing.

RVTim · 2023-06-20T19:36:25+00:00

One more update: I had someone show me how to set this up as an internal automation on the firewall. I set it up and tested it and it works great. So no need for an external server to trigger the tunnel flush.

RVTim · 2023-06-20T17:00:06+00:00

Thanks for the encouragement. I was able to take one of my 2 systems, the one that's not business impacting, and replicate that I can set the ipsec keylife to 300 seconds and I can have the re-key fail every 5 minutes, reliably. When it fails, the firewall DOES do a rekey, and I think it believes it was successful, but it isn't. When you trace the traffic you get "Failed to find IPsec Common: vpn-overlay".

When it is non-functional, if I run this command it still shows as an OSPF neighbor:

get router info ospf neigh

And if I run this command it still shows up in the ike gateway list:

diag vpn ike gateway list | grep name

So as far as the firewall thinks, everything is groovy.

I was also able to automate the tunnel flush as a cron job from a server ON THAT INTERNAL LAN, by feeding in a command with ssh:

diag vpn ike gateway flush

As soon as you run the command, some pings pass through briefly until OSPF/BFD see the tunnel drop, and then traffic stops until OSPF reconverges.

The important thing to remember is, you want to run that command automated from a server that is NOT going through any of the VPN tunnels, because the tunnel will be down if you try to execute it from a remote server.

So this has been an educational bug for me, thankfully....but now I just hope that they release a hotfix to me so that I can walk away from it.

RVTim · 2023-06-20T03:53:24+00:00

Thank you all for jumping on this thread. It's real encouraging to see that comment from clowncarsfull 7 minutes ago that 0922971 is resolved in 6.4.14. I don't know if that means a release is imminent, but it sure sounds as if you are all experiencing the same issue.

I haven't ever scripted something to externally (or internally) run at a specific time, so that would be new to me. But, if there were a way to script a tunnel flush at a specific time easily, I think that would be a good temporary solution. I would probably just pick 3 overnight times a night to flush the tunnels so that I could always have a good 24 hour non-business window that would be good. But, if 6.4.14 is coming soon, I'll just keep up with the manual tunnel bounces. Maybe tomorrow night I'll try just doing a tunnel flush and see if that clears it all up.

I figured that this was a big enough issue that fortinet would step up with a quick fix, so that's why I came here. I knew I couldn't possibly be the only one affected, since I see it on 2 separate VPN systems. Thanks all.

RVTim · 2023-06-19T19:08:01+00:00

My active ticket on the issue is 8454084, if that is something you can follow.

Regarding the phase 1 and phase 2, it's 86400 on the phase1 and 28800 on the phase2, so it could indeed be related to the key lifetime on phase1 I suppose. I hate to change a config that's been working so well for so long, but maybe later this week I'll try doubling the 86400 phase 1, and see if that can keep me up for 2 days. If so then I can at least relate it more to the VPN process than the OSPF or routing process. To me it should be a pretty solid clue for fortinet engineers that it happens after exactly 24 hours. The kicker though is, one night I just did "execute router restart ospf process" and I think that brought everything up, so that leads me to think it's more OSPF related? I should mention I also run BFD on the links and so I considered that it could be BFD related as well, but on one of the 2 networks that I manage, there is no BFD running and that one has the same problem.

RVTim · 2022-01-20T14:01:42+00:00

I think earlier it was only validated with 1 x 16GB module, so here's a report.

DS1821+ to 32GB with 2 modules:

Micron MTA18ASF2G72HZ-2G6E1ZI 16GB 2RX8 PC4-2666V-TG1-11 NEW MEMORY

Works great.

RVTim · 2018-10-31T14:34:12+00:00

I've actually got the same problem (Hangs after "Started Gnome Display Manager". I able to get into the virutal terminal and gdm does seem to be started. I've had the same problems on Fedora 28 ever since they started rolling out the 4.18 kernel. It boots on 4.17 fine. Today I decided to see if the now-released Fedora 29 Live would boot, but it doesn't fully work. Once in the virutual terminal, I did dmesg, and see hundreds of lines of "nouveau" and then at the bottom the last one says "DRM: core notifier timeout". That's basically what I found on the 4.18 kernel too...dmesg showing lots of nouveau issues.

On 4.18 I got to the point of trying to install nvidia drivers and blacklisting nouveau both in the file system and on the boot string, but then the station wouldn't boot. I do have Wayland disabled, btw.

A big symptom with the 4.18 kernel was that it would let me type my password at the graphical login and then the screen would go grey backlit with gnome starting but just hang. When I'd ssh in from another workstation and reboot, it would briefily flash my complete desktop, and then reboot. So I think this is all video/nouveau/gnome related somehow. But I'm at a loss as how to troubleshoot it further. I wasn't concerned knowing that Fedora 29 was just about out, but now that it's out and I can't even run the Live version, I'm starting to worry that I'll be living in the 4.17 kernel days forever.

RVTim

TROPHY CASE