RouterOS Device Mode Can Silently Disable PisoWiFi HotSpot
Tech GuruQuick Answer
Before rebuilding a broken PisoWiFi portal, inspect RouterOS device mode and the HotSpot inactive reason. Home and Basic modes disable HotSpot by default, and individual feature settings also matter. A mode change needs authorized physical confirmation and reboots the device. Preserve the complete feature configuration and paid-session records first; changing the whole mode can discard overrides. A working login page alone does not prove vouchers, payments or automation recovered.
Evidence status: The current MikroTik device-mode manual was checked. No router was inspected or changed, and no portal/payment/reboot recovery test was performed.
What To Check
In the current device-mode manual, a configuration can exist while its feature is inactive. Compare the effective HotSpot permission with the inactive reason before reinstalling packages or replacing portal files.
The security flagged state is a different concern from a feature disabled by the selected mode. Preserve evidence and investigate an unexpected flagged condition; do not clear it merely to make the portal appear healthy.
Key Concepts In Plain Language
- Device mode: a set of permitted features, with possible individual overrides.
- Inactive configuration: an object that exists but cannot operate under the effective restrictions.
- Portal recovery: restoring authentication, accounting and paid entitlement behavior, not just restoring an HTML page.
Technical Checklist
- Record RouterOS release, device-mode value, flagged inactive configuration, HotSpot packages, scripts, fetch, scheduler, containers, and remote recovery.
- Confirm which current device-mode capabilities disable HotSpot or related automation before changing packages or rebuilding portal configuration.
- Plan the physical activation requirement, local presence, downtime, backup, export, and management path before changing device mode.
- After activation, test portal redirect, DNS, walled garden, login, voucher or payment, pause, logout, scripts, and failover.
Interactive Operating Model
Use the planned checks below with this overview. No test result is implied by the diagram.
Before You Start: Safe Defaults
Arrange authorized local access, a service window and independent management recovery. Preserve a supported backup/export, full effective device-mode settings, portal files and separate payment/voucher records. Explain the reboot impact to the operator before requesting physical confirmation.
- Back up router, portal, voucher, payment, and session records before changing authentication or routing.
- Keep portal, DNS, payment, and management destinations reachable through the intended main path.
- Use test accounts and low-value test transactions with the payment provider's documented environment or process.
- Define a customer-credit, refund, and exception procedure before intentionally testing retries or link failure.
Go, Hold, Recover, Or Escalate
Change only the necessary reviewed feature set. Hold if no one can safely confirm locally or if the router's integrity is in question. Avoid selecting Advanced merely as a blanket repair; neither its name nor a reboot proves every required automation feature is allowed.
Planned Checks And Recovery
Read /system/device-mode/print and /system/device-mode/print config, or open WinBox > System > Device Mode. Compare hotspot, relevant automation permissions and flagged. These inspection paths do not approve a change. The vendor warns that specifying mode= replaces the mode configuration and loses unspecified per-feature overrides; confirmation triggers a reboot.
Step 1: Separate restriction from configuration failure
Record RouterOS version, effective mode and each relevant feature permission. Compare the HotSpot inactive comment with package/configuration and logs. List fetch, scheduler, containers or other automation the portal actually uses instead of enabling everything.
Step 2: Plan a narrow authorized change
Use the current vendor procedure for the installed hardware/release. Retain the full old setting set and identify exactly which feature is needed. Arrange the documented local confirmation and interruption; do not repeatedly issue competing update requests.
Step 3: Confirm and re-inspect
After the approved confirmation/reboot, read the effective settings again and compare all relevant overrides, not only HotSpot. If the change timed out, diagnose that state rather than assuming the request was accepted. Verify management and monitoring before accepting customer sessions.
Step 4: Test entitlement and automation
Exercise redirect, DNS, walled garden, login, voucher/payment, pause where supported, logout, scripts and failover with test accounts. Reconcile session/credit records after restart. Recover through the supported configuration path without overwriting newer financial activity.
Validation Checklist
- Before/after mode and per-feature settings explain the HotSpot active/inactive state.
- The intended authorized physical confirmation and reboot have recorded outcomes.
- Automation permissions and management recovery survive the change.
- Customer login and paid entitlement tests reconcile with the transaction records.
Troubleshooting
- HotSpot configuration exists but is inactive: Read its inactive reason and effective hotspot permission before rebuilding the portal.
- HotSpot returns but scripts stop: Compare scheduler/fetch and other overrides with the complete pre-change configuration.
- Router unexpectedly reports flagged: Preserve configuration/log evidence and investigate integrity using vendor guidance; this is not simply another feature toggle.
Security, Privacy, Legal, And Recovery Boundaries
Security
Protect portal administration, payment secrets, router management, voucher generation, and session APIs with least privilege and auditable access.
Privacy
MAC addresses, phone identifiers, payment references, and connection history can identify customers; minimize collection and set a retention policy.
Legal
Comply with payment-provider terms, consumer-protection duties, tax and record requirements, and applicable privacy law; never test against another operator.
Recovery
Keep exportable transaction and voucher records, a router rollback, a manual credit path, and an exception queue that survives portal or webhook downtime.
Record any local exception, its owner, its expiration condition, and the evidence required to remove it.
What The Evidence Does Not Prove
No hardware-specific confirmation/recovery procedure was exercised. A permitted feature does not prove the portal's code, payment integration or router integrity. Read-only command syntax was checked against the manual but not executed in RouterOS.
Related TechGeeks Resources
- PisoWiFi Operations Notes: Start Here
- Networking Field Notes: Start Here
- 15 Router Security Settings to Audit Before Something Breaks
References
Next Action
Capture device-mode output and the HotSpot inactive reason first. Approve the smallest required change only after the local confirmation and financial-state recovery paths are clear.
