[bug] Nag killer not working on HW4 2026.14.6.x — need 0x370/0x39B captures

[hypery11]

Summary

Tracking issue for the nag killer failing on HW4 / 2026.14.6.x firmware. First report came in from a HW4 2026.14.6.6 user (via email) who can't get nag suppression to work. No confirmed nag-killer-working report exists on any 2026.14.x firmware yet, so this is an open problem, not a misconfiguration.

Background

• The nag killer targets 0x370 EPAS3P_sysStatus (counter+1 echo, handsOnLevel spoof, organic torsion-bar torque). This is a different CAN ID from 0x3FD, so in principle it is not blocked by the 2026.14.x preflight enforcement that disables autosteer on 0x3FD injection (Tesla Started Banning Users Who use CAN Bus and Similar Devices #18, 14.3 Protection Mode — auto-warn on 2026.14.x firmware (v2.15) #73).
• DAS-aware gating reads das_hands_on_state from 0x39B (HW4) / 0x399 (HW3) — byte 5 bits [5:2]. The echo only fires when DAS is actually demanding hands-on.
• v2.15 added an on-demand grip pulse ([bug] Nag killer torque baseline — escalates to yellow nag (2 sec) #70 / feat(nag): on-demand grip pulse on nag-demand rising edge #83) but it is itself unverified on real 14.x hardware (pending @deftdawg's bench).

Hypotheses (both need on-car data to confirm)

1. 0x39B DAS_status layout moved on 14.6.x → das_hands_on_state is misparsed → the DAS-aware gate skips the echo (reads as NOT_REQD/0) or never gates correctly. Precedent: @JakNo found 0x293 DAS_settings shifted on 14.2 ([question] Is the 0x238 frame still STW_ACTN_RQ on newest software? #43), so DAS-frame layout drift between 14.x point releases is established.
2. 0x370 EPAS reformatted on 14.6.x → handsOnLevel / torsionBarTorque bit positions or the checksum changed (e.g. additive → CRC8) → our echo is malformed and the column ECU drops it silently.

(Less likely: the broad "any injected frame trips enforcement" behavior also catching 0x370.)

What we need to diagnose

From anyone on HW4 2026.14.6.x:

1. Build + board (Flipper, or which ESP32 target). Please use v2.15-beta — it has the improved on-demand grip pulse, not in v2.14.
2. RX / TX / Err counters from the running screen after a drive.
3. Does Autopilot engage at all on the car?
4. Listen-Only CAN capture of 0x370 and 0x39B during an actual hands-on nag (candump or CSV). This is the key artifact — it shows directly whether the DAS-status layout moved or the EPAS frame changed.

With those captures we can diff against the v2.14-era layout and pin which frame drifted, then fix the parse/echo.

Related

• [bug] Nag killer torque baseline — escalates to yellow nag (2 sec) #70 — nag killer torque baseline / on-demand grip pulse (@deftdawg)
• 14.3 Protection Mode — auto-warn on 2026.14.x firmware (v2.15) #73 — 2026.14.x protection mode tracker
• Tesla Started Banning Users Who use CAN Bus and Similar Devices #18 — 14.x enforcement (any-TX-disables-autosteer) research
• [question] Is the 0x238 frame still STW_ACTN_RQ on newest software? #43 — precedent for DAS-frame layout moving between 14.x releases (@JakNo)

[jewelrylin]

Issue #100 Reply Draft

Title (already exists, this is a reply comment)

Topic: HW4 Model Y Juniper RWD on 2026.14.3 — Bus 6 capture, key finding for nag killer DAS-aware gate.

---

Hardware / Setup

• Car: Model Y Juniper (Highland refresh) RWD — 26-pin X179
• HW: HW4
• Firmware: 2026.14.3 (not 14.6 — adds a different-version data point)
• Region: Taiwan
• Board: Waveshare ESP32-S3-RS485-CAN (TWAI, 500 kbps)
• Tap: X179 pin 13/14 (Bus 6 — gateway-forwarded subset of Vehicle CAN)
• Mode: Listen-Only (all TX toggles OFF — FSD/EAP/NagKiller/AP-First all disabled)
• Recording method: Local SD-equivalent ring buffer via /api/can-log/dump (not the port-82 stream), so this is NOT affected by the Full-rate single-ID capture: hardware acceptance filter (web-stream captures are RX-queue decimated) #104 RX-queue decimation issue. Full-rate verified: 0x129 SteeringAngle recorded at 100.1 Hz across all four captures.

Captures attached

Four scenarios, candump format (sec.usec) can0 ID#DATA:

File	Scenario	Duration	Frames
14.3_A_baseline.log	Parked, ON, no driver input	18.5 s	7,535
14.3_B_gear.log	Parked, gear shifts P→D→R→N→P	30.2 s	12,291
14.3_C_stalk.log	Parked, all scroll-wheel / lane-change button presses (no physical stalk on Juniper)	23.2 s	9,459
14.3_D_nag.log	Driving + AP engaged + intentional hands-off until nag escalates	124.2 s	50,496

🔑 Key finding for the nag-killer gate

The current code (per #100) reads das_hands_on_state from 0x39B (HW4) / 0x399 (HW3).

On this car (HW4 Juniper RWD, 14.3), Bus 6 does NOT carry 0x39B at all. Zero frames across all four captures (185 s total observation). What we DO have on Bus 6 is 0x399, at ~2 Hz.

ID        A_baseline  B_gear   C_stalk  D_nag
0x39B          0         0        0       0      <- HW4 DAS_status — ABSENT
0x399         37        62       48     271      <- "HW3" DAS — actually present on HW4
0x370       1855      3016     2324   12417      <- EPAS3P_sysStatus (100 Hz)
0x129       1857      3019     2326   12430      <- SteeringAngle (100 Hz) — full-rate verified
0x3FD        112       183      140     745      <- UI_autopilotControl (6 Hz)
0x485, 0x229, 0x3C2: all ZERO on Bus 6

Implication: on this HW4 trim, the HW-aware DAS gate is reading the wrong frame (0x39B, absent) instead of the only DAS frame that actually reaches Bus 6 (0x399). The gate consequently never sees DAS demanding hands-on, and the echo path is starved.

This matches my reported symptom: NagHandler echo counter does increment (~100k) but the visual nag still escalates to yellow within seconds.

Cross-checking the actual hands-on escalation

In the D_nag capture, during the intentional hands-off period:

• 0x370 byte 4 bits [6:7] (the field NagHandler reads): constant 0 across all 12,417 frames. Our echo overrides bit 6 → handsOn=1, but the car ignores it for visual nag.
• 0x399 byte 5 bits [5:2] (das_hands_on_state): observed values 1 → 2 → 3 during the same window (3 = ESCALATED / yellow alarm). This is what actually drove the visible warning.

So on HW4 Juniper RWD 14.3, the visible nag escalation is gated by 0x399 das_hands_on_state, not by 0x370 handsOnLevel. Echoing 0x370 alone does not suppress the visual warning.

Suggested next step (humbly)

1. Confirm on another HW4 Juniper unit whether 0x39B is really absent from Bus 6, or whether it's a trim-specific quirk (RWD vs Performance).
2. If confirmed, the HW4 DAS-aware gate may need to fall back to 0x399 when 0x39B is not seen for N seconds.
3. The 0x39B → Vehicle CAN forwarding question is now scoped: it's the same "selectively forwarded subset" story as 0x3C2 (commit 19d33c6). Tapping pin 9/10 should show 0x39B.

Other relevant data points (also useful for #103 and #95)

• 0x485 (Highland gear): 0 frames on Bus 6 — confirms Call for testing: CAN Capture (v2.16-beta) — grab a candump on your car #103 needs pin 9/10 for this car too.
• 0x229 (pre-Highland stalk): 0 frames on Bus 6 — expected (this is a Juniper with capacitive buttons, not a physical stalk).
• 0x3C2 (VCLEFT_switchStatus): 0 frames on Bus 6 — re-confirms the negative finding from 14.3 Protection Mode — auto-warn on 2026.14.x firmware (v2.15) #73.
• 0x129 (SteeringAngle): captured at 100.1 Hz, demonstrating that /api/can-log/dump does NOT suffer the port-82 RX-queue decimation in Full-rate single-ID capture: hardware acceptance filter (web-stream captures are RX-queue decimated) #104 — useful as an independent capture path for any HW that has the firmware.

Happy to recapture in different conditions if useful. ZIP of all four logs attached.

---

cc: 14.3_HW4_Juniper_RWD_BusSixCaptures.zip

14.3_HW4_Juniper_RWD_BusSixCaptures.zip

[hypery11]

@jewelrylin excellent capture and a real finding — thank you. The methodology (four scenarios, per-ID frame counts, full-rate confirmed via 0x129 at 100 Hz) is exactly what makes this actionable.

The key result: on your HW4 Juniper RWD 14.3, Bus 6 carries 0x399 (~2 Hz) but zero 0x39B, and during hands-off the escalation tracks 0x399's das_hands_on_state (1→2→3) while 0x370 byte 4 stays flat. Our HW4 nag gate reads das_hands_on_state from 0x39B, so on this trim it reads nothing and the echo path is starved — which matches your "~100k echoes but still escalates to yellow" symptom exactly.

Fix direction this implies: when 0x39B isn't seen for N seconds on HW4, fall back to 0x399 for das_hands_on_state. I'll scope that against the handler. Two asks before I touch the gate:

1. Can anyone confirm on a second HW4 Juniper unit (RWD vs Performance) whether 0x39B is genuinely absent on Bus 6, or only appears on Vehicle CAN (pin 9/10)? Your 0x3C2 / 19d33c6 precedent says some IDs are a selectively-forwarded subset.
2. Can you share the raw 0x399 bytes across the 1→2→3 transition? I want to confirm the byte-5 bit field before wiring it in.

[hypery11]

Landed the fallback on main in e7168e9. I verified the field against your D_nag capture myself before wiring it: 0x399 byte 5 bits [5:2] steps 1→2→3 and hits 3 (yellow) around the 33s mark of your hands-off window, while 0x39B is genuinely 0 frames — exactly your read.

What it does: on HW4, when 0x39B hasn't been seen, the nag gate now reads das_hands_on_state from 0x399's byte5[5:2] instead of starving. It's gated, so HW4 cars that do broadcast 0x39B and all HW3 cars are untouched, and it reads only the hands-on field (not ap_state — the HW4 0x399 byte0 layout isn't confirmed). Host-tested with your actual captured frame.

It'll ride the next beta once it's validated on a car. Two things still help:

1. A second HW4 Juniper unit (RWD vs Performance) confirming 0x39B is really absent on Bus 6 and not just your trap.
2. If you flash a build with this and run the same hands-off test, does the visual nag actually hold off now? That's the real proof.

Thanks again — this is the kind of capture that turns a guess into a fix.

[jewelrylin]

Issue #100 — On-car test result of the 0x399 fallback

Flashed tesla-fsd-waveshare-s3-can.bin from v2.16-beta.3 (fw_build: Jun 3 2026 17:28:11) on the same setup as my earlier capture: HW4 Juniper RWD 2025, 2026.14.3, Taiwan, X179 pin 13/14 (Bus 6).

Status confirmed via /api/status before driving:

"op_mode": 1,                           // Active
"hw_version": 2,                        // HW4
"ap_das_profile": "HW3: DAS 0x399",     // ← 0x399 fallback engaged
"nag_killer": true,
"force_fsd": false,
"can_vehicle_detected": true,
"fps": 2892.1,
"rx_count": 1535559,
"tx_count": 10214,
"tx_modified": 1131,
"crc_errors": 0

The "HW3: DAS 0x399" label on the HW4 car is the fallback announcing itself — exactly what we wanted.

On-car test — hands-off run

Highway, ≥ 50 km/h, double-pull right stalk to engage AP, both hands off the wheel, eyes on the screen with stopwatch.

Two distinct nag events:

1. ~10 s — first nag: steering-wheel icon turned blue with the "apply steering torque" text.
   Hands stayed completely off. After 3–5 s the prompt cleared itself, with no driver input. This is new behavior — on v2.14.0 the prompt does not self-clear without a driver torque input. The fallback is suppressing this first wave.

2. ~25 s — second nag (roughly 10 s after the first one cleared): blue icon + "apply torque" text reappeared. This time it did not clear, escalated normally, and would have disengaged EAP if I hadn't taken over.

So the 0x399 fallback works on the first nag wave but does not hold across the second. Reading this as a partial fix — directional but incomplete.

What this might mean

Three plausible interpretations, in order of how I'd rank them:

1. One-shot echo per cycle. The fallback fires once when the gate first sees das_hands_on_state ≥ 1, then doesn't re-arm for the next escalation window.
2. Cooldown / debounce. A 10–15 s post-echo cooldown that drops the second wave's first frames.
3. State-coverage gap. Fallback handles 0x399 byte5[5:2] = 1 (REQUEST) but not the escalation to 2 (ATTENTION) before it reaches 3 (ESCALATED). The first wave may stay at 1; the second wave may jump directly to 2.

Useful next step

Plan to do a Listen-Only run (nag_killer disabled, op_mode=0) capturing 0x399 + 0x370 across both wave events, so we can see exactly what byte5[5:2] does at ~10s, ~25s, and what triggers the second wave to escalate where the first didn't. Will post the candump in a follow-up.

Summary

• ✅ Fallback engages on HW4 Juniper RWD (status confirms ap_das_profile: "HW3: DAS 0x399").
• ✅ First nag wave observably suppressed for the first time — auto-cleared in 3–5 s without driver input.
• ⚠️ Second wave persists and escalates normally.
• 🎯 Suggests the fallback needs to keep echoing across consecutive nag-demand windows, not just the first one.

Happy to test follow-up builds — this is the same setup hypery11 verified against my D_nag capture.

[DrStrangeglovebox]

tesla_can_20260605_070904.dump.txt

Left hands of the wheel to near point of disengagement, then saved can dump.

MYP 2026 Berlin HW4 2026.14.6 pins 13, 14, latest beta.

[jewelrylin]

Issue #100 follow-up — Second HW4 unit (@DrStrangeglovebox) confirms 0x39B absent + reveals 0x399 escalation pattern

Pulled @DrStrangeglovebox's dump from the comment above and aligned it against my 14.3 captures. Same picture, on a second HW4 unit, with one important addition.

Headline findings

1. 0x39B is also 0 frames in @DrStrangeglovebox's dump — second-unit confirmation that the HW4 nag gate has nothing to read.

   • My dump (Bus 6, pin 13/14): 0x39B = 0 across 185 s.
   • Their dump (looks like Vehicle CAN — has 0x131, 0x488 and a much wider ID list than Bus 6): 0x39B = 0 across 44.3 s.
   • That makes the absence look generation-wide on HW4 Juniper, not a bus-forwarding quirk specific to Bus 6.

2. 0x399 escalation has two distinct patterns — and this matches my "first wave suppressed, second wave persists" symptom exactly.

   From their 0x399 byte 5 bits [5:2] (das_hands_on_state) timeline:

   t = 2.92s   das = 2  (ATTENTION)   ← starts at 2, skips 1
   t = 7.66s   das = 3  (ESCALATED, yellow)
   t = 21.26s  das = 2  (ATTENTION)
   t = 35.05s  das = 3  (ESCALATED again)
   

   They never see das = 1. The car goes straight to ATTENTION (2) and cycles between 2 and 3.

What this tells us about the fallback gate

This corroborates hypothesis 3 from my on-car test ("state-coverage gap"). If the gate is das_hands_on_state >= 1, then in principle a value of 2 or 3 should also trigger it — but the observed behavior says otherwise. Two possibilities I can think of:

• The gate is == 1 not >= 1, so it really does skip the ATTENTION/ESCALATED transitions.
• The gate is >= 1 but only rising-edge (e.g. prev == 0 && now >= 1); a 0 → 2 jump never hits the edge condition the code is looking for.

Both fit DrStrangeglovebox's data (never 1) and my run (first wave 0→1 caught, second wave 2→3 missed).

Suggested fallback adjustment

For HW4 with the 0x399 fallback:

• Re-arm the echo on every transition into das_hands_on_state >= 1, including 0→2 and 2→3, not just the first edge.
• Keep echoing while das_hands_on_state >= 1, not just once per cycle.
• Maybe re-arm when das_hands_on_state drops back to 0 between cycles (the ~10 s gap I saw between my two waves, and the 21.26 s revert in DrStrangeglovebox's run).

Setup parity for the two captures

	jewelrylin	DrStrangeglovebox
Trim	Juniper RWD 2025	(presumably HW4 Juniper; please confirm)
Firmware	2026.14.3	(please confirm)
Tap	X179 pin 13/14 (Bus 6)	wider ID list — looks like Vehicle CAN / pin 9/10
0x39B count	0	0
0x399 count	271 / 185 s	33 / 44.3 s

@DrStrangeglovebox — if you can post your trim / firmware version / which pins you tapped, that closes the loop on whether 0x39B is genuinely gone everywhere on HW4 Juniper or specific to certain pin taps.

I'll plan the Listen-Only 0x399 + 0x370 capture on my 14.3 car next so we have both wave events at full byte resolution on Bus 6 to cross-check against DrStrangeglovebox's wider-bus run.

[DrStrangeglovebox]

MYP 2026 Berlin HW4 2026.14.6 pins 13, 14, latest beta.

Please let me know if I should do specific dumps. This was a highway dump.