For Piso WiFi operators: When devices join the SSID but cannot reach the portal or internet, check whether they received a valid client IP, subnet, gateway and DNS. DHCP and DNS failures can look like a broken captive portal even when the Wi-Fi radio itself is fine.
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. The diagnostic method applies broadly; addresses and DHCP/DNS controls depend on the installed platform.
Step-by-step checklist
- On a failing client, record IP address, subnet/prefix, gateway and DNS before reconnecting.
- Confirm the address belongs to the intended Piso WiFi LAN rather than 169.254.0.0/16 self-assigned IPv4 space.
- Ping or open the local gateway if the platform permits it.
- Test a known IP and then a domain name to separate WAN reachability from DNS resolution.
- Operator: verify only the intended DHCP service is active on the client LAN.
- Check DNS forwarding/upstream resolvers and portal exceptions before rebooting or resetting the controller.
What not to assume
Do not fix a DNS symptom by adding random public DNS servers to every device. Captive portals can rely on local DNS behavior; diagnose the intended design first. 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.
Read the client network values before changing anything
Record the failing device’s IPv4 address, subnet/prefix, default gateway, and DNS servers. A self-assigned 169.254.x.x address points toward DHCP failure. An address from the upstream home/ISP router can mean the customer has bypassed the controller LAN. A valid Piso subnet with the correct gateway but no domain resolution points toward DNS or WAN policy rather than Wi-Fi association.
Test reachability and name resolution separately
First test the local gateway or portal. Then, where the platform permits, test reachability to a known public IP. Finally test a domain name. If IP reachability works but names fail, investigate resolver configuration, DNS forwarding, captive-portal exceptions, and encrypted/private DNS on the client. If neither works, move back toward WAN routing and authorization.
One DHCP server per client segment is the normal goal
An extra consumer router or misconfigured access point can start a second DHCP service and hand out the wrong gateway/DNS. If clients randomly receive different subnets, inspect every router/AP connected to the customer LAN and disable unintended DHCP/routing functions.
DHCP checklist for intermittent problems
Compare a working client and a failing client: subnet, gateway, DNS, lease age, DHCP server, and whether both joined the same SSID/AP. If addresses alternate between two ranges, look for a second DHCP server—often a consumer router or AP left in router mode. If the pool is exhausted, shorten/expand the lease strategy only after confirming the subnet size and realistic client turnover; randomly enlarging a pool cannot fix an overlapping network design.
DNS checklist after authentication
Use the configured resolver first. If the gateway is reachable and a public IP works but domain names do not, inspect controller/upstream DNS forwarding and any captive-portal walled-garden rules. Client Private DNS/DoH can change the path; test one controlled device with those features temporarily disabled to isolate the issue. Do not permanently block encrypted DNS without understanding the privacy/compatibility tradeoff and the actual platform requirement.
Frequently asked questions
What does a 169.254.x.x client address suggest?
It usually indicates the device did not receive normal IPv4 configuration from DHCP and self-assigned a link-local address. Check the customer LAN, DHCP service, VLAN/AP path, and physical/controller connectivity.
How can I detect a second DHCP server?
Compare several client leases. If customers randomly receive different subnets, gateways, or DNS servers, inspect APs and consumer routers for an unintended DHCP/router mode.
What if public IPs work but domain names do not?
That points toward DNS/resolver policy rather than basic routing. Check assigned DNS, controller/upstream forwarding, captive-portal rules, and client Private DNS/DoH behavior.
Should I set every client to a static IP to fix DHCP?
No. That hides rather than fixes the service problem and is unmanageable on a public hotspot. Repair the intended DHCP path; reserve/static-address only infrastructure that genuinely needs predictable management addresses.