On-site network troubleshooting without an observability stack
A branch office where the Wi-Fi keeps dropping, a datacenter row after a change window, a home lab you are still learning, or an event where ticket scanners slow down minutes before doors: the quickest way to find out what the equipment is reporting is to collect it where you are. This guide is a practical playbook for using MobiObs on a mobile device, tablet or laptop to see syslog, traps and flows as they arrive, without standing up an observability stack first.
MobiObs is not released yet. It is coming to Google Play first, then the App Store and desktop. Join the launch list to get one email when it is available.
Timing the capture
Most faults follow a schedule, whether that is a change window, the start of the working day or the doors opening at an event, and each phase stresses something different:
- Setup. Before the change, the busy hour or the event, point the equipment at MobiObs. New devices, temporary cabling and re-patched switch ports show up here, and it is the calm moment to confirm that every source is arriving.
- Peak. The start of the working day, a backup or replication window, or, at an event, doors opening with every ticket scanner validating at once. The highest client and authentication load of the day: a slow API, a saturated uplink or an exhausted DHCP scope shows up here first.
- Wind-down. Clients roam and leave in a wave. Controller logs fill with roaming and disassociation, which is normal, and useful as a baseline for next time.
In a home lab the schedule is yours: point a router, a switch or a Raspberry Pi at the device and watch what a configuration change actually does, with nothing else to install.
Where to put the device
The collector has to be reachable from the equipment. That rules out guest and public SSIDs, where client isolation stops devices on the same SSID from reaching one another. Good choices are a staff or operations SSID without isolation, a management VLAN, or a wired port through a USB-C Ethernet adapter where the device supports one. If the device sits on a different subnet, make sure the equipment VLANs are routed to it and that no ACL drops UDP to the collector ports.
The Network screen in MobiObs shows the address, gateway and Wi-Fi details the device is using, and the exact URLs to give to each sender.
What to send, and why
| Source | Send | Answers |
|---|---|---|
| Wireless controller | Syslog udp/5514, traps udp/1162 | 802.1X and PSK failures, roaming, AP reboots, RF events |
| Application servers (ticket scanners, point of sale, badge readers) | Syslog udp/5514 | Transaction results, API timeouts, retries |
| Linux hosts, NAS or Raspberry Pi | Syslog via rsyslog | Service failures, authentication, disk and kernel warnings |
| Core and access switches | Syslog, traps | Link flaps, PoE faults, spanning-tree changes |
| Border router or firewall | NetFlow udp/2055 or sFlow udp/6343 | Uplink use, top talkers, traffic to key services and APIs |
| FortiGate or similar | Syslog as CEF | Denied sessions, policy hits, VPN state |
Configuration lines for each platform are in the vendor guides: Cisco, Aruba, Fortinet, Juniper and MikroTik and Linux rsyslog. A single logging host added on each device is enough, and removing it afterwards restores the original configuration.
Telling the usual faults apart
"The network is slow" can have several causes, and each leaves a different trace:
- Application or API timeouts. Application logs show timeouts to one address and port, while the Wi-Fi logs look normal and clients stay associated. Check flows to that API: if traffic leaves but responses are slow, the problem is upstream of the site.
- 802.1X or PSK failures. The controller logs authentication failures for client MAC addresses, and those clients drop off the network. Look for a RADIUS server that is unreachable or slow, or an expired certificate.
- Uplink flaps.
linkDownandlinkUptraps and%LINK-3-UPDOWNmessages from one switch, lined up in time with one area's clients going quiet. - DHCP scope exhaustion. Clients associate but never get an address. Syslog from the DHCP server or firewall reports no free leases, and flows from the new clients never appear.
Because syslog, traps and flows share one timeline on the device, you can see which of these happened first, which is usually the question that matters.
Watching it live
Overview shows event and flow rates, the severity split and the top hosts, so a switch that has gone quiet or a controller that has suddenly become noisy stands out. The same dashboards are served on port 8080, or HTTPS on 8443, so you can put them on a NOC screen or a colleague's laptop while you carry the device to the wiring closet. Browsers pair with the token shown in the app.
Before blaming a device or controller, prove the path. Sender mode on a second MobiObs device sends test syslog, flows or traps from the same VLAN as the equipment. If those arrive, the network path works and the problem is in the equipment configuration.
Practical caveats
- Android runs the collectors as a foreground service, so collection continues with the screen off. Exempt MobiObs from battery optimization for a long capture.
- iPhone and iPad suspend background apps, and a suspended app receives no UDP. Keep MobiObs in the foreground and set Auto-Lock to Never.
- Retention. The Free tier keeps one hour. For a whole shift or event day, Pro makes retention configurable and lets you export the evidence for the post-incident review.