Piso WiFi Slow Internet: Find the Real Bottleneck

Start with the correct platform and role

Piso WiFi is a category of prepaid/captive-portal deployments, not one standardized router firmware. A vending/controller platform, the upstream ISP router, and separate Wi-Fi access points can all have different addresses and credentials. The customer portal and the operator admin page are also different security roles. General performance method; queue/AP controls vary by platform.

Step-by-step checklist

1. Test wired speed/latency at the internet source.
2. Test wired through the controller path if architecture allows.
3. Measure Wi-Fi near the AP and at the complaint area.
4. Check concurrent users and per-user shaping.
5. Inspect channel utilization/interference and mesh/backhaul quality.
6. Add capacity or AP coverage only after identifying the limiting layer.

What not to assume

A stronger antenna does not create more ISP capacity. Very high transmit power can also make clients hear the AP when the AP cannot hear weak client transmissions reliably. Likewise, 10.0.0.1 is only a private IPv4 address. Its presence does not identify the software by itself, and changing the address does not change how the vending/session system works.

Customer-side checks

• Stay connected to the Piso WiFi SSID and turn off a VPN temporarily if the portal will not open.
• Do not type operator credentials into a public search result.
• If a portal fails only on one phone, test browser captive-portal state, Private DNS, MAC randomization and date/time before blaming the machine.
• Keep payment/voucher proof until the session is confirmed.
• For pause/resume or voucher issues, use the same device when the platform ties sessions to a device identity.

Operator-side checks

Troubleshoot in layers. Confirm stable power, then WAN internet, controller WAN/LAN interfaces, DHCP/DNS, access-point reachability, captive-portal service, payment input, and finally the user/session database. If every client fails, focus on shared infrastructure. If one client fails, compare that client with a working one before rebooting or resetting the system.

Security and reliability

• Change initial/factory administrator credentials after setup.
• Keep customer traffic separated from the management LAN where the platform supports it.
• Use official software updates and make backups before upgrading.
• Protect the controller, coin acceptor and power hardware from moisture, heat and unstable power.
• Use a proper access point for coverage and capacity rather than assuming the controller board’s radio can serve a busy area.
• Never expose the admin dashboard directly to the public internet through an unrestricted port forward.

Network architecture matters more than the portal IP

A healthy installation normally has a clear upstream/downstream design: ISP modem or ONT, then the device responsible for routing/session control, then switches/access points serving customers. Avoid accidental double DHCP, overlapping subnets and a consumer Wi-Fi router running NAT behind the vending controller unless the design intentionally calls for another routed boundary. Label WAN and LAN cables so a maintenance visit does not silently reverse them.

Payment and session integrity

When money or vouchers are involved, troubleshoot payment confirmation separately from internet access. Keep transaction/session logs long enough for legitimate support and reconciliation, but do not collect secrets that the payment provider does not require. For digital wallets, the operator should never request a customer PIN or one-time password. Test duplicate payments, failed callbacks, controller restarts and recovery after power loss before advertising a new payment option.

Maintenance checklist

• Keep the controller/router and access-point software on supported releases from the official vendor.
• Back up configuration before updates and store a copy away from the machine.
• Check power supply, ventilation, storage health and cable condition.
• Review peak-hour WAN utilization, loaded latency and access-point client counts.
• Audit admin accounts after staff/vendor changes and remove access that is no longer needed.
• Test the customer journey—from joining Wi-Fi through payment, portal access, session expiry and reconnect—after every major change.

Check the exact platform before using credentials or reset steps

Piso WiFi systems are not one standardized firmware. Match the machine name, installed version, controller type and local network before applying a login, password-recovery or reset instruction. If the device label or installed platform shows a different address or workflow, use the information for that exact machine rather than forcing a value from another platform.

Find whether the bottleneck is WAN, Wi-Fi, or shaping

Run a wired test at the controller/upstream router, then compare a nearby Wi-Fi client and a client in the problem area. If wired performance is already poor, investigate the ISP/backhaul. If wired is healthy but nearby Wi-Fi is poor, inspect access-point load, channel use, band, and backhaul. If only paying users are slow while local management is responsive, inspect bandwidth limits and traffic shaping.

Peak-hour latency matters more than an empty network speed test

A 100 Mbps connection can feel unusable if upstream queues are saturated or dozens of clients contend for one access point. Measure loaded latency and packet loss when the hotspot is busy. Per-user and global shaping can protect interactivity, but no queue can create bandwidth that the WAN or radio layer does not have.

Coverage and capacity are different

A powerful access point may make the SSID visible far away while still providing poor capacity to many distant clients. Add access points with sensible placement and preferably wired backhaul when one radio serves too many users. Keep 2.4 GHz channel overlap and interference in mind; do not solve every complaint by increasing transmit power.

Measure four different bottlenecks

Test (1) wired WAN capacity at the controller/upstream router, (2) controller forwarding/shaping under load, (3) AP/backhaul performance, and (4) the individual client radio link. Record both throughput and loaded latency. A fast wired test plus slow Wi-Fi points toward the wireless layer; slow wired WAN points upstream; good Wi-Fi link rates with poor authenticated throughput can point toward shaping, session policy, or controller resource limits.

Radio capacity planning

Place APs for usable client signal rather than maximum visible bars at the AP itself. Prefer wired backhaul for busy areas, avoid excessively wide channels in crowded spectrum, and distribute clients across APs/bands where the equipment supports it. One powerful AP is not automatically better than several well-placed APs: clients have limited transmit power, and too many users sharing one radio compete for the same airtime.

Frequently asked questions

Useful next steps