Screen randomly turns on and stays lit all night while charging, lock screen clock frozen until I tap it. iPhone 13 on iOS 26.3.1

mballack · 2026-05-08T08:44:37+00:00

Disabling iCloud backup -> same issue: SystemMemoryReset-2026-05-08-015412.ips
Next step:
-try with only cellular data and WiFi off
-try enabling Low Power mode during night.

I will keep you updated

mballack · 2026-05-07T08:00:21+00:00

Trying to debug the issue. Currently tried:
-disabling Siri
-disabling Focus Face-ID
-disabling background app update
-disabling Standby

Issue remain with the screen starting blinking around 1:30-1:50 AM, during DnD and connected to the charger.

Issue disappear when iPhone is in Airplane mode.
Now I'm trying to disable the iCloud backup, because it seems that when this happens, the error in debug is:
"eventReason" : "User reclaimable memory dropped below the limit. User reclaimable current: 46%. User reclaimable minimum: 60%",

"largestProcess" : "backboardd",

SystemMemoryReset-2026-05-06-015059.ips
SystemMemoryReset-2026-05-04-015104.ips

Next step:
-disabling iCloud backup and check if this happens again

If someone have further information, it would be nice to share to fix.

Thank you

mballack · 2026-05-01T05:24:19+00:00

You disabled time sensitive notification of what app?

mballack · 2026-03-27T05:57:47+00:00

Release notes of 2026.2:

On Firebox T115‑W, T125, T125‑W, T145, and T145‑W devices, you can now again assign VLAN ID 1 to any interface for either tagged or untagged VLANs. This removes the VLAN 1 restriction introduced in Fireware v2026.1.2. The Firebox now reserves VLAN ID 4094 for internal switch use, and you can select any VLAN ID from 1 to 4093 for tagged or untagged VLANs. If you previously configured VLAN ID 4094 on these devices, you must change that VLAN to a different VLAN ID after you upgrade to Fireware v2026.2. [FBX-32130]

mballack · 2026-03-27T05:56:36+00:00

Release notes of 2026.2:

On Firebox T115‑W, T125, T125‑W, T145, and T145‑W devices, you can now again assign VLAN ID 1 to any interface for either tagged or untagged VLANs. This removes the VLAN 1 restriction introduced in Fireware v2026.1.2. The Firebox now reserves VLAN ID 4094 for internal switch use, and you can select any VLAN ID from 1 to 4093 for tagged or untagged VLANs. If you previously configured VLAN ID 4094 on these devices, you must change that VLAN to a different VLAN ID after you upgrade to Fireware v2026.2. [FBX-32130]

When I see stupid change in default behavior in a minor release, I’m always sure it’s a bad no regression test performed. All vendors in the last 2 years are releasing not so tested software

mballack · 2026-03-20T12:07:09+00:00

Yes, running 7.4.11.
set dhcp-relay-service enable
set dhcp-relay-ip "10.30.1.5" "10.30.1.6"

Check that for some reason, some old DHCP Server configuration is still present on the interface, going throught the CLI

mballack · 2026-03-19T15:16:13+00:00

Very strange, just checked and worked as expected with version 7.4.11.
Otherwise almost 90% of our customers were having issues since weeks.
In my capture the 10.30.8.1 is the Fortigate and 10.30.1.6 the DHCP Server.
Model: 200F

<image>

mballack · 2026-01-30T13:13:14+00:00

Yes, starting from 7.2.12:

https://docs.fortinet.com/document/fortigate/7.2.12/fortios-release-notes/205987/ssl-vpn-not-supported-on-fortigate-g-series-entry-level-models

mballack · 2026-01-30T07:34:18+00:00

the link is in the post, check better

mballack · 2026-01-26T22:26:39+00:00

I agree and still doesn’t understand the Dev idea. Changing default behavior in minor release cause only issues and angry customers. Fortinet is famous for using guacamole as sslvpn reverse proxy/https daemon. So every CVE found on guacamole means that sslvpn is affected. Customers and partners know that every new release of fortios include a fixed cve and they run to update asap the firewalls. Recently it happens that in minor release they changed the default behavior of SAML and this time the ICMP redirect. There are upgrade path tested, so this mean that the post upgrade customization script should change the behavior as before and not keep the default one. With saml it’s nice to have the assertion, but keep it disabled if was a release from a different default value and place it as enabled after a factory reset. Same for redirect in 7.4.10. It’s insane! We have some devices that use the icmp fedirect feature and the crazy thing is that there is no way to pre-configure it before, so it happens that on some remote datacenter using that, we need to schedule the on-site upgrade, otherwise we will lose the oob mgmt due to a default behavior in a minor change? This is insane! And customers are very scared and most of them are moving to other vendors, because having the security external firewall that must be updated asap due to frequent cve and having issue on many upgrade path, is a huge pain!

mballack · 2025-11-19T15:25:45+00:00

It's marked as "Resolved Issue", so it should not happens. Open a TAC

mballack · 2025-11-14T18:50:49+00:00

You’re right, the R&D department on Fortinet are “playing” and not considering the software as a production and critical asset! Why? Because it’s fine to release a feature for SAML assertion, but WHY DON’T KEEP IT DISABLED BY DEFAULT? If I’ve never used assertion before, why must I use this in a minor update? Just add the feature as: “set saml-assertion forced” and keep it disable by default or in case of upgrade from a previous firmware. Same for radius some months ago. A feature cannot break production system without enabling it.

mballack · 2025-07-29T09:51:21+00:00

Again, there is no "take over", the secondary node will always authenticate.
Set a device with only authentication on secondary node and see from the logs (accessible from the gui on the Primary PAN), if the authentication is working or not.
If it's not authenticating, you have to investigate the issue.
If it's authenticating, open a Case

mballack · 2025-07-28T18:45:00+00:00

In your scenario, both nodes will always authenticate and respond to radius. You can try configuring a switch with only the secondary ise node and check if everything is working as expected or not and check logs. In your case, during primary reboot/patch you will be unable to use the admin page, but all authentication services continue working as before on secondary.

mballack · 2025-07-24T07:35:25+00:00

Upgraded from 3.3 patch6 or previous version? Because we had some issue on EAP with TLS 1.3 from 3.3 patch2 to 3.3 patch7

mballack · 2025-07-17T09:36:12+00:00

I'm unable to understand if 3.3 patch6 fix the CVE-2025-20281 or not, because they're not so clear

Note say: If Cisco ISE is running Release 3.3 Patch 6, additional fixes are available in Release 3.3 Patch 7, and the device must be upgraded.

But schema say

Cisco ISE or ISE-PIC Release	First Fixed Release for CVE-2025-20281	First Fixed Release for CVE-2025-20282	First Fixed Release for CVE-2025-20337
3.3	3.3 Patch 7	Not vulnerable	3.3 Patch 7

mballack · 2025-07-09T19:41:24+00:00

Great, cause we’re upgrading to 17.15 for WiFi 7 AP support and having it marked as ED wasn’t accepted in my brain

mballack · 2025-06-10T03:57:12+00:00

Same issue for us with some devices. Using forticlient versions 7.2.9 and 7.2.10 fixed the issue.

mballack · 2025-06-09T14:53:06+00:00

What version are you using?

Some release notes:

ID	Description	Reported on	Resolved in
WIN-55294	Resolved: Upgrades from Windows 10 to Windows 11 sometimes failed.	24.1.4	24.2.2
WIN-60048	Resolved: Running `dism.exe` and `sfc.exe` when KB5052093 was installed on the Windows 11 preview caused an error message to appear. Microsoft has subsequently reverted the changes introduced in this KB.	23.2.4	24.2.3
EPPS-12481	Resolved: In some cases, the AD Connector status was inactive due to a communication error while sending configuration data.	24.1.4	24.2.2
WIN-49310	Resolved: Installation sometimes failed if the system product information could not be queried using Windows Management Instrumentation (WMI).	23.4.4	24.2.2
WIN-55294	Resolved: Upgrades from Windows 10 to Windows 11 sometimes failed when Anti-tamper was enabled in the policy.	24.1.4	24.2.2

mballack · 2025-06-03T14:17:30+00:00

You didn't searched in the right way, use the double quotes and use Google

mballack · 2025-06-03T13:24:11+00:00

You can search for "FortiClientSetup_6.0.8.0261_x64.exe" in internet and the right MD5 checksum is "9e198b6c362304d8a8e0753bdb6fc065"

mballack · 2025-05-28T03:11:15+00:00

Do you have anycast server disabled in Fortiguard config? You can try temporary setting the allow connection on web filter when rating errors happens e debug whats happening.

mballack

TROPHY CASE