CliDeck
PlatformLog in
Workspace

EdgeRouter Reset and TFTP Recovery: A Console-Friendly Resale Workflow

ITAD & Refurbishment
#ubiquiti#ITAD#refurbishment#verification#ITAD & Refurbishment#serial-console#itad#network-device-processing
← Back to Blog

Short answer

Use a normal factory reset when an owned EdgeRouter boots correctly and only needs a default configuration. Use TFTP recovery when normal startup is unusable and the installed bootloader supports that recovery method. Match the recovery image to the model family, transfer it on an isolated segment, and verify the installed EdgeOS version and clean configuration after reboot.

Establish model and recovery compatibility

Record the exact model, current firmware if available, bootloader state, and starting symptom. The ER-X family, ERLite family, and ER-4 family do not share interchangeable recovery images. A file selected for a different platform is a reason to stop before transfer.

The automatic TFTP recovery path requires an appropriately updated bootloader. Older bootloaders use a separate manual console recovery procedure. Do not turn a failed automatic attempt into a series of guessed bootloader commands.

This process is destructive and belongs only on devices you own or are authorized to recover. Resolve customer backup or preservation requirements before beginning.

Build a small recovery segment

Connect the intended router's eth0 to the workstation or isolated recovery switch. Avoid a general office LAN, where DHCP and multiple similar devices make it easy to reach the wrong asset.

In direct-connect recovery, a workstation example is 192.168.1.10/24; the router can use 192.168.1.20 when no DHCP service provides another address. Confirm the actual target address before transferring. Remove competing interfaces or routes only on the dedicated bench workstation, and restore its normal network settings afterward.

Enter the selected mode and transfer the image

Reset-button hold duration distinguishes ordinary reset from TFTP recovery. Use the model-specific sequence and LED indication rather than counting a generic number for every device.

When recovery is active, use a TFTP client in binary mode to upload the signed image matched to the platform. A macOS-style interactive sequence is:

tftp
connect 192.168.1.20
binary
put <approved-model-recovery-image>.img.signed

Replace the filename and target address with the approved values. A successful transfer is not the final result: wait for firmware processing and the automatic reboot. Do not power-cycle during the write.

Verification note: recovery can install a different version

The recovery image determines the EdgeOS version installed. Record the version actually running afterward; do not assume the appliance retained the version it had at intake.

After startup, the normal default management path can differ from the recovery address. On the documented recovery path, normal management is available at 192.168.1.1 on eth0. Readdress the workstation if necessary rather than concluding that recovery failed because the old recovery address no longer answers.

Inspect the state before grading

Require normal startup, reachable authorized management, expected software, and absence of former customer configuration. Inspect the actual model for remaining files, storage, or recovery exceptions rather than claiming certified erasure from a default screen.

If transfer repeatedly fails, check target address, link, image family, bootloader support, and power. If the image writes but the device cannot boot normally, hold the unit for hardware or storage diagnosis.

Capture the selected image, transfer result, reboot observation, final address, and pass/fail decision in the asset record. CliDeck Workspace can preserve the console observations alongside the data-sanitization evidence checklist.

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