CliDeck
PlatformLog in
Workspace

Cisco Catalyst 9136I AP Factory Reset for ITAD: Button Reset, CAPWAP Erase, and Verification

ITAD & Refurbishment
#cisco-ap#catalyst-9136i#capwap#factory-reset#itad#network-device-wipe#serial-console#ITAD & Refurbishment
← Back to Blog

Short answer

For an authorized Cisco Catalyst 9136I AP reset, begin on an isolated bench with the physical reset-button recovery, then erase CAPWAP state and verify the post-reset console output. Keep before-and-after hardware and CAPWAP evidence so the asset record shows a clean result rather than only a reboot.

When This Applies

Use this workflow when a Catalyst 9136I arrives at an ITAD, refurbish, recycle, or resale bench with an unknown previous configuration and you need a repeatable proof record before listing or shipping it.

It fits best when you have:

  • physical possession of the AP
  • serial console access
  • permission to erase the AP configuration
  • an isolated PoE or power source
  • a requirement to prove model, firmware, serial, MAC, CAPWAP state, and post-erase condition

Keep the AP away from a live customer controller while you work. The goal is a quiet bench process, not a device trying to rejoin a production wireless environment during reset.

Bench Setup Before You Touch The Reset Button

CheckWhat to recordWhy it matters
Asset labelIntake ID, photos, visible label conditionTies the transcript to the physical unit
Console outputFull serial-console transcriptShows exactly what the technician did
Power pathPoE injector, switch port, or adapter usedHelps explain boot timing and link state
Network isolationNo customer LAN, no live WLC pathPrevents accidental controller join during processing
Model targetCatalyst 9136I / C9136I-B in this bench runAvoids copying a procedure to the wrong family
Sanitization scopeConfig and CAPWAP/AP state, not a firmware reimageKeeps the work order precise

On our bench unit, the AP was a Cisco Catalyst 9136I-B running AP image 17.12.4.22, with 17.12.4.22 as the primary boot image and 17.9.4.27 as the backup boot image. The erase workflow did not change those image versions; it reset the AP data/configuration state and rebooted the unit.

Step 1: Reset-Button Recovery

Use the physical button first when the AP comes in with unknown access state.

  1. Disconnect power from the AP.
  2. Press and hold the reset button.
  3. Apply power while keeping the button pressed.
  4. Continue holding the button for more than 30 seconds.
  5. Release the button and wait for the console login prompt.

In our verified 9136I bench run, holding the button while applying power for more than 30 seconds restored the AP to a state where the console accepted the factory recovery login Cisco / Cisco, followed by enable access with the same temporary credential. Treat that as a recovery state only. Do not stage, list, or ship an AP with bench credentials left as part of the workflow.

If the login prompt does not behave as expected, stop and repeat the physical recovery step. Do not connect the AP to a live controller just to make progress.

Step 2: Capture Pre-Erase Evidence

Disable noisy console logging and pagination first, then collect the identity and operating state. Do not start the erase until this transcript is saved to the work order.

logging console disable
terminal length 0
show version
show inventory
show capwap client config
show ip interface brief
show interfaces

A short form such as ter len 0 was accepted before the wipe in our run, and terminal length 0 was accepted after reboot. For a production bench script, keep the full command in the final evidence workflow because it is easier for a human reviewer to read later.

The important fields are:

  • model and PID/VID
  • AP running image, primary image, and backup image
  • base Ethernet MAC address
  • serial numbers from inventory
  • CAPWAP AP name and mode
  • configured controller names, if any
  • interface presence and link state
  • any customer-specific location, hostname, or controller reference

Step 3: Run The CAPWAP Erase

After the pre-erase capture is complete, run the CAPWAP erase command from privileged mode:

capwap ap erase all

The AP should display a warning that the command performs a data wipe on a COS AP, then ask for confirmation. Confirm only after the transcript is recording and the asset ticket is correct. In our bench run, the AP stopped services, rebooted, selected the primary boot partition, and came back to the console prompt.

Do not power-cycle the AP during this stage unless it is clearly hung for an abnormal amount of time. Let the erase and reboot complete so the transcript shows the natural service shutdown and boot path.

Step 4: Capture Post-Erase Verification

After the AP returns, log in through the console again and capture a smaller proof set:

logging console disable
terminal length 0
show version
show inventory
show capwap client config
show ip interface brief

Verify these points before the AP leaves the bench:

  • the model and PID still match the intake record
  • the AP image versions are recorded and did not unexpectedly change
  • CAPWAP controller names are blank or default for your resale workflow
  • no prior owner hostname, location, controller, or customer text remains in visible AP configuration output
  • interface output is consistent with the physical bench cabling
  • the transcript includes the erase command, confirmation, reboot, and post-erase checks

Immediately after reboot, one command in our run returned a message that the CAPWAP process socket was not ready yet. Waiting a few moments and rerunning the CAPWAP check is cleaner than treating the first transient message as a failure.

Sanitized Bench Snapshot From This Run

This is the kind of evidence block we would keep in the resale record. The identifiers below are sanitized from the real transcript.

Model: C9136I-B
Product family: Cisco Catalyst 9136I Series Access Point
AP running image: 17.12.4.22
Primary boot image: 17.12.4.22
Backup boot image: 17.9.4.27
Base Ethernet MAC: 58:8B:1C:DE:4E:35
Top assembly serial: FJC27341W6G
PCB serial: FOC27261NL5
CAPWAP AP name: AP588B.1CDE.4E35
CAPWAP mode: Local
Controller names: blank
SpamReboots before erase: 12
SpamReboots after erase: 1

Do not use the reboot counter alone as wipe proof. It is useful context, but the proof is the complete before/after transcript, the erase command, the reboot, and the absence of prior-owner identifiers in the post-erase outputs.

What This Workflow Does Not Do

This workflow is not a firmware reimage. In our run, the primary and backup AP images remained in place after the erase. If a buyer or internal grading policy requires reimaging, handle that as a separate work order with the correct image source, checksum policy, and post-install validation.

It also does not prove that an external wireless controller inventory record has been removed. If the prior owner still has a controller, cloud inventory, or asset-management record, that is outside the AP console transcript. For resale, document only what your bench can verify directly.

Technician Checklist

Use this checklist for each owned 9136I AP:

  • Photograph labels and physical condition.
  • Connect serial console and isolate the AP from customer networks.
  • Hold reset while applying power for more than 30 seconds.
  • Capture pre-erase identity and CAPWAP state.
  • Run capwap ap erase all and confirm the wipe.
  • Let the AP reboot naturally.
  • Capture post-erase identity and CAPWAP state.
  • Compare before/after output for prior-owner identifiers.
  • Save the transcript, photos, and result status to the asset ticket.
  • Mark exceptions when a command must be rerun because a process was not ready immediately after boot.

CliDeck Workflow Note

For repeatable ITAD work, the value is not just knowing the command. The value is making the console session deterministic: wait for the correct prompt, capture pre-wipe identity, run the erase, wait through reboot, capture post-wipe identity, and attach the transcript to the asset record.

That is the part a CliDeck-style workflow should automate for this AP family. The public article should explain the procedure, while the internal script remains an operational artifact controlled by the processing team.

Related CliDeck Field Guides

Safety note: This guidance applies only to devices your team owns or is authorized to process. Use the approved, device-specific procedure, customer policy, and your organization’s sanitization and evidence procedures.

Who this is for

This guide is for ITAD teams, refurbishment teams, network engineers, and operations teams who need to perform an owner-authorized reset, recovery, verification, or documented device-processing workflow on network devices that your team owns or is authorized to process.

When to use this

Use this guide when:

  • Your team owns or is authorized to process the device.
  • You need to reset, zeroize, recover, reimage, verify, or document a network device.
  • The result must be attached to an asset, resale, reuse, refurbishment, or recycling workflow.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • You need a certified data destruction procedure and your organization has not provided one.

Quick checklist

  • Identify the device and console connector
  • Use the correct console cable or adapter
  • Find the correct serial port or COM port
  • Start with the expected baud rate and 8N1 settings
  • Press Enter to confirm the prompt
  • If output is unreadable, check baud rate and line settings
  • If the port will not open, check permissions, drivers, and whether another program is holding the port
  • Save useful session notes or logs when the work matters

Traditional cable vs CliDeck workflow

A traditional USB serial cable is still the simplest option for quick local work. CliDeck becomes useful when the console session needs browser access, notes, runbooks, sharing, logs, remote hands support, or a portable controller workflow.

Console Server Go can work like a wired USB serial adapter when connected by USB, but it also adds SSH Console on SSH-enabled firmware builds, browser Workspace, live sharing, 24h+ battery operation, OLED status, and magnetic rack mounting.

Net Controller is the larger 12-port option for teams that need to process many network devices with approved workflows, barcode/API tracking, provisioning files, and evidence-style logs.

Workflow

  • Confirm ownership, processing scope, device identity, and approved procedure.
  • Connect through the console or approved management path and capture the session context.
  • Run the reset, zeroize, recovery, reimage, or verification steps required by the article and vendor documentation.
  • Reboot or reconnect as needed and verify the expected clean, default, or recovered state.
  • Attach logs, verification output, exceptions, and final pass/fail/exception status to the asset record.

Verification checklist

  • Device identity matches the asset record.
  • Console or session log is attached to the asset.
  • The reset, zeroize, recovery, or reimage method is recorded.
  • The post-reboot state matches the expected clean or recovered state.
  • Verification commands and outputs are captured.
  • Exceptions or failures are quarantined instead of marked ready.

Resale and evidence checklist

Before marking the device ready for resale, capture:

  • Device model and serial number
  • Console transcript or session log
  • Reset, zeroize, reimage, or recovery method used
  • Any confirmation prompts and operator decisions
  • Post-reboot state
  • Visible default or clean-state prompt
  • Verification commands and outputs
  • Hardware alarms or boot errors
  • License, entitlement, or customer identifiers handled according to policy
  • Exceptions, failures, or quarantine decisions
  • Final pass/fail/exception status attached to the asset record

What not to publish

Do not publish raw transcripts that include customer names, public IP addresses, VPN settings, license keys, entitlement IDs, serial numbers that must remain private, passwords, tokens, certificates, or other sensitive identifiers. Keep sensitive evidence in the customer-approved internal system and publish only sanitized examples.

Common mistakes

  • Processing a device without owner authorization or the correct asset record.
  • Treating a factory reset as certified data destruction.
  • Failing to capture confirmation prompts, reboot state, verification output, or exceptions.
  • Publishing raw logs that contain customer identifiers, licenses, keys, passwords, or configuration remnants.

CliDeck workflow fit

CliDeck can help turn this procedure into a repeatable workflow. Console Server Go is useful for portable rack-side console access and shared remote support. Net Controller is better for ITAD, refurbishment, and batch processing where multiple devices need barcode tracking, approved scripts, logs, API updates, and evidence-style results.

Net Controller can help operators connect devices, scan assets, run approved workflows, capture console logs, require verification steps, and attach the result to the asset record.

FAQ

Is this a certified data destruction procedure?

No. This article describes a practical, owner-authorized workflow and verification approach. Certification depends on your organization’s process, evidence requirements, customer contract, and any formal certification program that applies.

Does CliDeck provide vendor OS images?

No. CliDeck does not distribute vendor operating system images. Recovery or reimage workflows can use images already present on the device or images provided by the customer where the customer has appropriate rights and licenses.

Should I publish the full console log?

Usually no. Keep complete evidence in the approved internal system and publish only sanitized examples. Console logs can contain serial numbers, license details, customer names, IP addresses, keys, passwords, or configuration remnants.

Can CliDeck help with this workflow?

Yes. Console Server Go helps with portable rack-side console access and shared remote support. Net Controller is better for batch ITAD, refurbishment, recovery, provisioning, barcode/API tracking, and evidence-style results.

Related guides