Support & setup guide

Getting started

1. Install MobiObs from Google Play or the App Store (coming soon), and open it. The collectors start automatically.
2. Connect the device to a network that your equipment can reach. This could be the same VLAN or a routed network. Avoid guest Wi-Fi with client isolation (see Troubleshooting).
3. Open the Network screen to see the device's addresses and the URL for each collector.
4. Configure a sender using the examples below, then watch the Overview or Logs screen.
5. Optional: open the web UI on a laptop at http://192.168.1.20:8080 (or https://192.168.1.20:8443). Scan the QR code shown in the app, or enter the token it displays.

Permissions

Android

• Notifications (Android 13 and later). Allow this when asked. The always-on collector runs as a foreground service, and Android requires it to show a persistent notification. Without the permission, background collection cannot be shown or kept running reliably.
• Battery optimisation exemption. For long captures, go to Settings → Background collection in MobiObs and allow it to ignore battery optimisation, or set the app's battery usage to Unrestricted in Android settings. Some manufacturers add their own task killers. If Android stops the collector anyway, MobiObs shows a red banner with a Restart button.
• Location / nearby Wi-Fi devices (optional). Requested only if you tap Show Wi-Fi details on the Network screen. Android needs it before it will reveal the SSID and BSSID. MobiObs never reads your location.
• Camera (optional). Requested only when you scan another device's pairing QR code.

iOS and iPadOS

• Local Network. Allow this when iOS asks. It is needed to receive traffic, serve the web UI and find peers. If you declined, go to Settings → Privacy & Security → Local Network and turn on MobiObs.
• Foreground only. iOS suspends apps in the background, so keep MobiObs open during a capture. Setting Auto-Lock to Never while you work helps.

Configuring senders

Point each device at the MobiObs address and the non-default port. Syntax varies between software versions, so check your platform's documentation if a command is rejected.

The vendor guides go further for Cisco, Juniper, Aruba, Fortinet, MikroTik and Linux, including SNMPv3, verification commands and how to remove the configuration afterwards.

Linux: rsyslog

/etc/rsyslog.d/90-mobiobs.conf

# RFC 5424 over UDP
*.* action(type="omfwd" target="192.168.1.20" port="5514" protocol="udp"
           template="RSYSLOG_SyslogProtocol23Format")
# or TCP (reliable for bursts):  *.* @@192.168.1.20:5514

Then run sudo systemctl restart rsyslog. To send a quick test from any Linux host: logger -n 192.168.1.20 -P 5514 -d "hello from $(hostname)".

Cisco IOS / IOS XE

Syslog and SNMP traps

logging host 192.168.1.20 transport udp port 5514
logging trap informational
logging source-interface Vlan10
!
snmp-server community public RO
snmp-server enable traps
snmp-server host 192.168.1.20 version 2c public udp-port 1162

Flexible NetFlow (v9)

flow exporter MOBIOBS
 destination 192.168.1.20
 transport udp 2055
 export-protocol netflow-v9
!
flow monitor MOBIOBS-MON
 exporter MOBIOBS
 record netflow ipv4 original-input
!
interface GigabitEthernet0/1
 ip flow monitor MOBIOBS-MON input

Juniper Junos

Syslog, SNMP traps and sFlow

set system syslog host 192.168.1.20 any info
set system syslog host 192.168.1.20 port 5514
set system syslog host 192.168.1.20 structured-data
set snmp trap-group public version v2
set snmp trap-group public destination-port 1162
set snmp trap-group public targets 192.168.1.20
set protocols sflow collector 192.168.1.20 udp-port 6343
set protocols sflow sample-rate ingress 1024
set protocols sflow interfaces ge-0/0/0

On Junos, the trap-group name is used as the SNMP community (public in this example).

Fortinet FortiGate (FortiOS 7.x)

Syslog (RFC 5424 or CEF)

config log syslogd setting
    set status enable
    set server "192.168.1.20"
    set port 5514
    set mode udp
    set format rfc5424
end

NetFlow (FortiOS 7.4 and later)

config system netflow
    config collectors
        edit 1
            set collector-ip "192.168.1.20"
            set collector-port 2055
        next
    end
end
config system interface
    edit "port1"
        set netflow-sampler both
    next
end

For CEF, use set format cef instead. On FortiOS 7.2 and earlier, set collector-ip and collector-port directly under config system netflow.

Other flow exporters and SNMP trap senders

Software exporters and a test trap

# softflowd (NetFlow v9 from a Linux interface)
softflowd -i eth0 -v 9 -n 192.168.1.20:2055

# host sFlow agent (/etc/hsflowd.conf)
sflow { collector { ip = 192.168.1.20 udpport = 6343 } }

# net-snmp: send a test linkDown trap
snmptrap -v 2c -c public 192.168.1.20:1162 '' 1.3.6.1.6.3.1.1.5.3

On other platforms, look for a flow exporter or collector destination with a configurable UDP port, and a trap host or trap receiver entry with a port option.

Windows Event Logs with NXLog

Install NXLog Community Edition on the Windows host and add the following to C:\Program Files\nxlog\conf\nxlog.conf:

nxlog.conf (excerpt)

<Extension _syslog>
    Module      xm_syslog
</Extension>

<Extension _json>
    Module      xm_json
</Extension>

<Input eventlog>
    Module      im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id="0">
                <Select Path="Application">*</Select>
                <Select Path="System">*</Select>
                <Select Path="Security">*</Select>
            </Query>
        </QueryList>
    </QueryXML>
</Input>

<Output mobiobs_udp>
    Module      om_udp
    Host        192.168.1.20
    Port        5514
    Exec        $Message = to_json(); to_syslog_ietf();
</Output>

<Route r1>
    Path        eventlog => mobiobs_udp
</Route>

Restart the NXLog service. Events appear under Windows Events with event ID, channel, provider, computer and all EventData fields. For bursts, use om_tcp to port 5514 instead. Snare format (to_syslog_snare()) and plain to_syslog_bsd() text are also recognised. NXLog must run as a service with Event Log read rights to collect the Security channel, and the default LocalSystem account has them.

Troubleshooting

If a sender does not appear, work through this list in order:

• Can the sender route to the device? Check that the equipment has a route to the MobiObs address shown on the Network screen. Ping it from the equipment if you can.
• Client isolation on Wi-Fi. Guest and venue SSIDs often block traffic between clients. Move the device to a staff or management SSID, or use a wired connection.
• Firewalls and NAT. An ACL, firewall policy or NAT boundary between the sender and the device can drop UDP silently. Allow the collector ports from the sender's source address.
• Correct ports. Mobile devices cannot listen on 514 or 162, so check that the sender uses 5514, 2055, 6343 or 1162 (or the ports you configured).
• Collector running. On Overview, the Collectors card shows how many listeners are up. A listener that failed to start, for example because another app holds the port, is shown as stopped with its error.
• Check the Sources page. Every sender that has reached the device is listed with its IP, kinds and last-seen time. If the source is listed but you can't see its data, clear the search and severity filters.
• SNMP community or v3 credentials. Traps that fail the community check or v3 authentication are still shown, flagged, rather than dropped. Look for them on the SNMP Traps page.
• Test the path. From a second MobiObs device, use Sender to send test syslog, flows or traps to the first. If they arrive, the network path works and the problem is in the equipment's configuration.

Contact support

Email support@mobiobs.com. It helps to include:

• your device, operating system version and the MobiObs version (shown in Settings);
• the sending equipment and its configuration lines, with secrets removed;
• what the Sources and Overview screens show.

Please don't send exported telemetry unless we ask for it, and remove any personal data first. For Team licences and seat changes, email sales@mobiobs.com.