Canon imageCLASS MF753Cdw II — sleep / network monitor

Does this printer fall off the network when it sleeps? Measured on the actual unit at 10.0.0.84, every 10 minutes, instead of arguing from forum posts.
Clock reset 2026-09-20 21:30 PT — Wi-Fi Power Save Mode On → Off.
All criteria below score only the current experiment (firmware 02.03 + 120-minute sleep timer + Wi-Fi Power Save Mode OFF). Verified on the device’s own page, not taken on trust. Experiment #1 (the 120-minute sleep timer, alone) failed — it died after under 9 hours. That epoch is kept in full below. The sleep timer stays at 120; the only new change is Power Save.

Confound now resolved: I had warned the 10-minute probe might itself be keeping the printer alive. It died anyway while being pinged, so the monitor was never propping it up — every clean stretch recorded here is genuine.
Open the printer → http://10.0.0.84 Remote UI (LAN only)
RETURN IT
The printer has failed at least one primary acceptance criterion. The defect is real on this unit and is not just a forum story.
3386probes
566.1hobserved
445hard dropouts
80.63%availability
18.87dropouts / 24h
0clean streak

Timeline

oldest → newestok degradedhard dropout

Acceptance criteria

IDCriterionResult
AC-1No hard network dropouts
Zero samples where the printer fails to answer ARP (NIC absent from the network) over a rolling 7-day window on default sleep settings.
Primary - this is the defect under test
FAIL
AC-2Availability >= 99%
At least 99% of 10-minute probes return a healthy ICMP + IPP response.
Primary
FAIL
AC-3Self-recovery, no power cycle
Any dropout observed must clear on its own by the next probe. A dropout that persists until someone physically power-cycles the unit fails this outright.
Primary - this is what makes the fault unacceptable rather than annoying
FAIL
AC-4Survives 7 days
At least 7 full days of continuous observation before a keep decision.
Gate - prevents deciding on a lucky afternoon
PASS
Decision rule: any primary criterion FAIL → return the unit. All PASS including the 7-day gate → keep it. Anything else → keep collecting. If AC-1 or AC-3 fails, the fallback before returning is to raise Auto Sleep Time (Menu → Preferences → Timer/Energy Settings) and re-run this monitor for 3 days; if that buys a clean run, it becomes a keep-with-workaround decision at the cost of idle power and some toner burn from auto-calibration.

What counts as what

ClassMeaning
okAnswered ICMP and a full IPP Get-Printer-Attributes query. Fully usable.
degradedAnswered ARP but not ICMP/IPP — typically a wake-transition window where the NIC is up before the main controller is. Annoying, not the defect.
hard failThe defect. No ARP reply at all. ARP is answered by the network chip below the OS, so silence means the radio is not associated with the access point — while the panel still claims Wi-Fi is connected.

Recent probes

Time (PT)ClassARPLossRTT ms
2026-10-14 11:30:01hard failFAILED100%-
2026-10-14 11:20:01hard failFAILED100%-
2026-10-14 11:10:02hard failFAILED100%-
2026-10-14 11:00:01hard failFAILED100%-
2026-10-14 10:50:01hard failFAILED100%-
2026-10-14 10:40:01hard failFAILED100%-
2026-10-14 10:30:01hard failFAILED100%-
2026-10-14 10:20:01hard failFAILED100%-
2026-10-14 10:10:01hard failFAILED100%-
2026-10-14 10:00:01hard failFAILED100%-
2026-10-14 09:50:01hard failFAILED100%-
2026-10-14 09:40:01hard failFAILED100%-
2026-10-14 09:30:01hard failFAILED100%-
2026-10-14 09:20:01hard failFAILED100%-
2026-10-14 09:10:01hard failFAILED100%-
2026-10-14 09:00:01hard failFAILED100%-
2026-10-14 08:50:01hard failFAILED100%-
2026-10-14 08:40:01hard failFAILED100%-
2026-10-14 08:30:01hard failFAILED100%-
2026-10-14 08:20:01hard failFAILED100%-
2026-10-14 08:10:01hard failFAILED100%-
2026-10-14 08:00:01hard failFAILED100%-
2026-10-14 07:50:01hard failFAILED100%-
2026-10-14 07:40:01hard failFAILED100%-
2026-10-14 07:30:01hard failFAILED100%-
2026-10-14 07:20:01hard failFAILED100%-
2026-10-14 07:10:01hard failFAILED100%-
2026-10-14 07:00:01hard failFAILED100%-
2026-10-14 06:50:01hard failFAILED100%-
2026-10-14 06:40:01hard failFAILED100%-
2026-10-14 06:30:01hard failFAILED100%-
2026-10-14 06:20:01hard failFAILED100%-
2026-10-14 06:10:01hard failFAILED100%-
2026-10-14 06:00:01hard failFAILED100%-
2026-10-14 05:50:01hard failFAILED100%-
2026-10-14 05:40:01hard failFAILED100%-
2026-10-14 05:30:01hard failFAILED100%-
2026-10-14 05:20:01hard failFAILED100%-
2026-10-14 05:10:01hard failFAILED100%-
2026-10-14 05:00:01hard failFAILED100%-
2026-10-14 04:50:01hard failFAILED100%-
2026-10-14 04:40:01hard failFAILED100%-
2026-10-14 04:30:01hard failFAILED100%-
2026-10-14 04:20:01hard failFAILED100%-
2026-10-14 04:10:01hard failFAILED100%-
2026-10-14 04:00:01hard failFAILED100%-
2026-10-14 03:50:01hard failFAILED100%-
2026-10-14 03:40:01hard failFAILED100%-
2026-10-14 03:30:01hard failFAILED100%-
2026-10-14 03:20:01hard failFAILED100%-
2026-10-14 03:10:01hard failFAILED100%-
2026-10-14 03:00:01hard failFAILED100%-
2026-10-14 02:50:01hard failFAILED100%-
2026-10-14 02:40:01hard failFAILED100%-
2026-10-14 02:30:01hard failFAILED100%-
2026-10-14 02:20:01hard failFAILED100%-
2026-10-14 02:10:01hard failFAILED100%-
2026-10-14 02:00:01hard failFAILED100%-
2026-10-14 01:50:01hard failFAILED100%-
2026-10-14 01:40:01hard failFAILED100%-

Full timeline

Every outage, intervention, configuration change, finding and correction in this investigation, in order.
When (PT)What
2026-09-17 09:03Panel touch — no recovery
Screen woke normally and showed Wi-Fi connected. Printer still absent from the LAN.
2026-09-17 09:05Printer absent from three full /24 ARP sweeps
68-69 hosts up each pass, zero Canon MACs. No Canon in mDNS. Not in ARP table.
2026-09-17 09:13Panel photo gives the address
IPv4 10.0.0.84, mask 255.255.255.0, gateway 10.0.0.1, DHCP On — same subnet we were sweeping.
2026-09-17 09:13Targeted probe proves it is off the network
ping 0/3. ARP FAILED. nmap 0 hosts up. Neighbours .80 .83 .85 all answered in the same second.
2026-09-17 09:16POWER CYCLE #1 — recovered
Back within seconds: five ports open, Remote UI answering as MF750C II Series.
2026-09-17 09:18Firmware read over IPP = 02.01
Canon's site published 02.02 — the unit was a version behind. Earlier claim that it was on 02.02 was unverified and wrong.
2026-09-17 09:2802.02 release notes are security-only
One line: 'Addressed vulnerabilities.' All 7 CVEs are document/font parser overflows. Nothing in the Wi-Fi or power path.
2026-09-17 10:31Slept 75 minutes and stayed reachable
Fault is intermittent, not every-sleep. Earlier 'you cannot keep it' verdict was overstated.
2026-09-17 10:40Monitor deployed
10-minute probe logging ARP + ICMP + IPP separately. Interval chosen so the probe cannot hold the printer awake and mask the bug.
2026-09-17 13:30OUTAGE #1 begins
First hard dropout. Nobody touched the printer.
2026-09-17 14:17Panel touch — NO recovery
20/20 pings lost over a continuous 60s window. ARP FAILED. Waking the screen did not bring it back.
2026-09-17 15:41ROOT CAUSE — printer fell back to 169.254.x.x
Panel reported the IP had changed. 169.254 is APIPA: the address a device assigns itself when DHCP fails. It was off-subnet, which is why ARP for 10.0.0.84 failed while Wi-Fi still showed connected.
2026-09-17 15:42Panel touch — recovered this time
Packet capture caught the whole thing: DHCP Request from 0.0.0.0, gratuitous ARP claiming 10.0.0.84, then mDNS re-announcing. Touch-to-recover is inconsistent.
2026-09-17 15:44AP-scan message retracted as a symptom
'Could not find any access points' appeared while the printer was provably healthy at 2ms. It is not a discriminator; it was wrong to call it one.
2026-09-17 15:50FIRMWARE FLASHED 02.01 → 02.03
Done over Wi-Fi against the USB advice. Monitor paused first so it could not disturb the flash.
2026-09-17 17:23It landed on 02.03 — newer than Canon publishes
Canon's download page still only offers 02.02. The USB tool would have installed the known-broken version. Sahir's call was better than the advice.
2026-09-17 19:22Artifact was hiding the old evidence
Resetting the clock at the flash dropped the 02.01 failures from view. Restored in full — not scoring old failures against new firmware never required hiding them.
2026-09-18 08:26First clean night on 02.03
54/54 samples clean through the 22:00-07:00 idle window. Also found and fixed a bug in my own probe that logged fractional packet loss as total failure.
2026-09-18 18:00OUTAGE #2 begins
02.03 fails after a 24.4h clean streak. A full clean day on this printer proves nothing.
2026-09-19 08:16POWER CYCLE #2 — recovered
Outage #2 ran 14h16m, ended only by Sahir.
2026-09-19 08:18Forum research changes the plan
Canon fixed this on the NON-II via firmware 7.04 (confirmed by a user after a week of daily testing). Static IP ruled out — three reporters tried it and all still failed. Continuous ping reported to keep it online.
2026-09-19 15:02Auto Sleep Time was set to 1 minute
The absolute minimum of the 1-120 range. The printer had been sleeping after one minute idle this whole time.
2026-09-19 23:50OUTAGE #3 begins
Third consecutive overnight death.
2026-09-20 08:35POWER CYCLE #3 — recovered
Inferred from the data, not reported at the time. Outage #3 ran roughly 8h45m.
2026-09-20 09:01Auto Sleep Time changed 1 → 120 minutes
CURRENT EXPERIMENT. Confirmed reading 120. Everything else left unchanged: no static IP, no exit-time timer, no auto-shutdown.
2026-09-20 18:00OUTAGE #4 — the 120-minute sleep timer failed
Degraded 17:50, hard dead 18:00 through 21:10. Survived under 9 hours on the new setting. shdwlark's 120-min result does not reproduce here.
2026-09-20 21:10The monitor was never a keepalive
It died while being pinged every 10 minutes. The confound I had been flagging is resolved in our favour — every clean stretch recorded is genuine.
2026-09-20 21:19POWER CYCLE #4 — recovered
Fourth power cycle. Still the only reliable recovery.
2026-09-20 21:27Wi-Fi is the only network page Canon locks
Surveyed all 33 network sub-pages: 31 expose an Edit button, Wi-Fi Settings is the sole exception. Not a page I failed to find — a deliberate lock, since editing Wi-Fi over Wi-Fi would cut the session.
2026-09-20 21:30EXPERIMENT #2 — Wi-Fi Power Save Mode On → Off
CURRENT EXPERIMENT. Done at the panel by Sahir, then verified by me on the device's own page. Sleep timer stays at 120; nothing else changed.
2026-09-21 00:00Latency collapsed 10x when Power Save went Off
Mean RTT was 67-76 ms on 17-20 Sep with Power Save On; 7.6 ms from 21 Sep onward. Independent physical proof the setting took effect and behaves exactly as Canon documents - a dozing radio waits for the next router beacon.
2026-09-23 11:00Printer moved to another room — power disconnected
Unlogged at the time. Landed inside a monitoring blind spot: this VM rebooted three times for the ESXi CPU swap, so there is no data 10:40-13:13. Means the run is segmented, not one continuous 82h.

Interventions only

This printer has never recovered on its own. Every recovery in the data is a human, so every outage duration below is a lower bound — it says how long the outage lasted before someone intervened, not how long it would have lasted.
When (PT)ActionOutcomeSource
2026-09-17 09:03:00panel touch
Woke screen; Wi-Fi icon shown
no_recoverysahir_report (high)
2026-09-17 09:16:50power cycle
Power cycle #1
recoveredsahir_report (high)
2026-09-17 14:17:00panel touch
Woke screen during outage
no_recoveryverified_by_probe (high)
2026-09-17 15:42:00panel touch
Woke screen; DHCP re-acquired, captured in tcpdump
recoveredverified_by_probe (high)
2026-09-17 15:47:00config change
Firmware update started over Wi-Fi from panel
n/asahir_report (high)
2026-09-17 15:50:48firmware flash
Main Controller 02.01 -> 02.03 (confirmed via IPP)
n/averified_by_ipp (high)
2026-09-19 08:16:00power cycle
Power cycle #2, ended 14h16m outage
recoveredsahir_report (high)
2026-09-20 08:35:00power cycle
Power cycle #3 - inferred from recovery between 08:30 and 08:40 probes; Sahir reports power-cycling as outages appear
recoveredinferred_from_data (medium)
2026-09-20 08:59:00config change
Auto Sleep Time changed from 1 -> intended 120 (UNITS UNCONFIRMED - see PLAN)
n/asahir_report (low)
2026-09-20 21:19:00power cycle
Power cycle #4 - ended the 120-min-timer outage that began 18:00
recoveredsahir_report (high)
2026-09-20 21:30:00config change
Wi-Fi Power Save Mode On -> Off, done at the panel. VERIFIED by me via Remote UI: 'Power Save Mode: Off', Wi-Fi Status Normal, no errors
n/averified_remote_ui (high)
2026-09-23 11:00:00power cycle
Sahir MOVED the printer to a different room - power disconnected. Exact time unknown; fell inside my monitoring blind spot (this VM rebooted 3x for the ESXi CPU swap, 11:50/12:45/13:13). Reported to me 2026-09-24.
recoveredsahir_report (medium)

Experiment #1 — 120-minute sleep timer (failed)

Raising the sleep timer from 1 min to the 120-minute maximum did not fix it. Dead within nine hours.
74probes
20hard dropouts
71.6%availability
200 minworst outage
12.2hobserved
2026-09-20 09:10:01 → 2026-09-20 21:20:01

Firmware 02.03 on the 1-minute timer — also kept in full

The new firmware alone did not fix it. This is the window between the flash and the sleep-timer change.
384probes
139hard dropouts
63.0%availability
860 minworst outage
63.6hobserved
2026-09-17 17:23:44 → 2026-09-20 09:00:01

Firmware 02.01 — the original evidence (kept in full)

This is the record that made the case for returning the unit. It is not scored against 02.03 above — different firmware — but nothing here has been deleted, and every one of these samples is still in monitor/reachability.csv.
34probes
14hard dropouts
52.9%availability
140 minworst single outage
5.2hobserved
2026-09-17 10:32:35 → 2026-09-17 15:46:55
Time (PT)ClassARPLossRTT ms
2026-09-17 15:46:55okDELAY0%7.103
2026-09-17 15:40:01hard failFAILED100%-
2026-09-17 15:30:01hard failFAILED100%-
2026-09-17 15:20:01hard failFAILED100%-
2026-09-17 15:10:01hard failFAILED100%-
2026-09-17 15:00:01hard failFAILED100%-
2026-09-17 14:50:01hard failFAILED100%-
2026-09-17 14:40:01hard failFAILED100%-
2026-09-17 14:30:01hard failFAILED100%-
2026-09-17 14:20:01hard failFAILED100%-
2026-09-17 14:10:01hard failFAILED100%-
2026-09-17 14:00:01hard failFAILED100%-
2026-09-17 13:50:02hard failFAILED100%-
2026-09-17 13:40:01hard failFAILED100%-
2026-09-17 13:30:01hard failFAILED100%-
2026-09-17 13:20:01degradedDELAY100%-
2026-09-17 13:10:01okDELAY0%66.408
2026-09-17 13:00:01okDELAY0%50.952
2026-09-17 12:50:01okDELAY0%88.054
2026-09-17 12:40:01okDELAY0%113.819
2026-09-17 12:30:02okDELAY0%69.304
2026-09-17 12:20:01okDELAY0%71.326
2026-09-17 12:10:01okDELAY0%92.765
2026-09-17 12:00:01okDELAY0%137.497
2026-09-17 11:50:01okDELAY0%55.196
2026-09-17 11:40:01okDELAY0%66.212
2026-09-17 11:30:01okDELAY0%66.003
2026-09-17 11:20:01okDELAY0%114.295
2026-09-17 11:10:01okDELAY0%83.919
2026-09-17 11:00:01okDELAY0%61.259
2026-09-17 10:50:01okDELAY0%87.401
2026-09-17 10:40:01okDELAY0%149.758
2026-09-17 10:33:14okREACHABLE0%50.563
2026-09-17 10:32:35degradedDELAY100%-

Established facts

ModelCanon MF750C II Series (MF753Cdw II)
Address10.0.0.84 · MAC 20:0b:74:cc:01:58
Firmware installed02.03 — one behind
Firmware available02.02 on the website; 02.03 via the on-device updater (2026-02-06) — changelog is "Addressed vulnerabilities" only; all 7 CVEs are document/font parser overflows, none in the Wi-Fi or power-management path
Fault reproduced2026-09-17 09:05 PT — ARP FAILED, 100% packet loss, absent from three full /24 sweeps, while neighbours .80/.83/.85 all answered and the panel showed Wi-Fi connected with a valid lease on 10.0.0.84
RecoveryPower cycle at 09:16 PT restored it within seconds — five ports open
Root causeDHCP collapse, not a dead radio. On 2026-09-17 15:41 PT the panel reported the address had changed to a 169.254.x.x APIPA address — the self-assigned address a device falls back to when DHCP fails. Packet capture of the recovery shows a from-scratch 0.0.0.0 → 255.255.255.255 DHCP Request, then a gratuitous ARP who-has 10.0.0.84 tell 10.0.0.84, then mDNS re-announcing A 10.0.0.84. The Wi-Fi association stays intact the whole time — which is why the panel truthfully says "connected" while the printer is unreachable: it is off-subnet, so nothing owns 10.0.0.84 and ARP for it fails.
Touching the panel does not reliably fix it2026-09-17 14:17 PT — after Sahir woke the screen, 20/20 pings lost over a continuous 60 s window, ARP FAILED, IPP refused, nmap 0 hosts up. At 15:42 a panel touch did kick DHCP back into life. So the touch-to-recover behaviour is inconsistent — sometimes it works, sometimes only a power cycle does.
Not deterministicSlept and stayed reachable for 75+ min afterwards, so on this unit the fault is intermittent, not every-sleep

Share

Canon MF753Cdw II sleep/network monitor
Status: RETURN IT
Observed: 566.1h, 3386 probes
Hard dropouts: 445 (18.87/24h)
Availability: 80.63%
Firmware: 02.03 (latest 02.02 on the website; 02.03 via the on-device updater)
https://artifact.sahirm.com/a/canon-mf753cdw-ii-monitor/
Last updated 2026-10-14 11:35:01 PDT · regenerates automatically · probe interval 10 min (auto-sleep is ~3 min, so each cycle leaves ~7 min of genuine idle — the monitor cannot hold the printer awake and hide the bug).