Why an Android device can’t receive syslog on port 514

Why 514 does not work

Ports 0 to 1023 are privileged on Linux, which Android is built on. Binding a socket to one of them needs the CAP_NET_BIND_SERVICE capability (or root), and the kernel setting net.ipv4.ip_unprivileged_port_start, which is 1024 by default, marks where the unprivileged range starts. Android runs each app as its own unprivileged Linux user without that capability, so an app that tries to listen on udp/514 gets a permission error, however the app is written.

That is why every MobiObs collector listens above 1024. iOS has no such rule, but MobiObs uses the same defaults on every platform, including iPhone, iPad and desktop, so one sender configuration works whichever device is collecting. You can change each port in Settings; on Android a port below 1024 fails to open.

Which ports to use

Only syslog and traps have to move. Syslog over TLS, NetFlow and sFlow already use ports above 1024. IPFIX exporters that default to the registered IPFIX port 4739 need to be pointed at 2055, where MobiObs decodes NetFlow and IPFIX side by side.

Changing the port on the sender

Almost every network operating system lets you set the syslog and trap destination port. The setting is usually next to the server address, sometimes as host:port. Some examples, with the MobiObs device at 10.20.4.9:

Cisco IOS XE, Juniper Junos and MikroTik RouterOS

! Cisco IOS XE
logging host 10.20.4.9 transport udp port 5514
snmp-server host 10.20.4.9 version 2c MOBIOBS-RO udp-port 1162

# Juniper Junos
set system syslog host 10.20.4.9 port 5514

# MikroTik RouterOS
/system logging action add name=mobiobs target=remote remote=10.20.4.9 remote-port=5514

The vendor guides give the full configuration, including where to set the port in web interfaces such as Cisco Meraki, UniFi, pfSense and OPNsense and Synology DSM, and on VMware ESXi, where the port is part of the log host URL.

Senders with a fixed port

A few senders cannot change the destination port at all. MikroTik RouterOS, for example, sends SNMP traps only to udp/162. There are three ways around it, in order of preference.

1. Destination NAT on a router or firewall in the path. Translate traffic from the sender to udp/514 (or 162) into 10.20.4.9 on udp/5514 (or 1162). The original source address is kept, so MobiObs files the messages under the real sender. Most firewalls call this a port forward or a destination NAT rule.

2. A NAT rule on a Linux host. If a Linux machine is on the path, or you can point the sender at it, the kernel can rewrite the destination. The sender is configured to send to the Linux host on 514; the host forwards each packet to MobiObs.

Linux: forward udp/514 to MobiObs on udp/5514 (nftables)

sudo sysctl -w net.ipv4.ip_forward=1
sudo nft add table ip mobiobs
sudo nft add chain ip mobiobs prerouting '{ type nat hook prerouting priority dstnat; }'
sudo nft add rule ip mobiobs prerouting udp dport 514 dnat to 10.20.4.9:5514
sudo nft add rule ip mobiobs prerouting udp dport 162 dnat to 10.20.4.9:1162

Linux: the same with iptables

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -p udp --dport 514 -j DNAT --to-destination 10.20.4.9:5514
sudo iptables -t nat -A PREROUTING -p udp --dport 162 -j DNAT --to-destination 10.20.4.9:1162

Destination NAT keeps the sender’s source address, and because syslog and traps are one-way UDP, no return path is needed. If the Linux host also filters forwarded traffic, allow the forwarded UDP in its forward chain. Remove the rules afterwards with sudo nft delete table ip mobiobs, or by repeating the iptables lines with -D instead of -A.

3. A relay daemon. rsyslog listening on udp/514 can forward to udp/5514, and snmptrapd can forward traps to udp:10.20.4.9:1162. A relay is easy to set up on a laptop, but MobiObs then sees the relay as the source address (syslog messages keep their own hostname field). The Linux guide has both configurations.

Verify it works

1. On the MobiObs device, open the Network screen and note the collector URLs, for example udp://10.20.4.9:5514.
2. From a Linux or macOS host on the same network as the sender, send a test message straight to the device: logger -n 10.20.4.9 -P 5514 -d "port test". It should appear in Logs within a second.
3. If you use a NAT rule or a relay, send the same test to the relay on port 514 (logger -n <relay> -P 514 -d "relay test") and check that it arrives in Logs.
4. Configure the real sender, then check Sources: it lists every address that has reached the device, with the kinds of data and the last-seen time.

Troubleshooting

• Nothing arrives, not even the logger test. The path is blocked before the sender is involved. Guest Wi-Fi with client isolation is the most common cause; use a staff SSID, a management VLAN or a USB-C Ethernet adapter.
• The test arrives but the sender’s messages do not. The sender is probably still using 514 or 162. Check the port in its configuration, and that it sends from an interface with a route to the device.
• Traps arrive flagged. The port is right but the community string or SNMPv3 credentials do not match. See the SNMP trap receiver guide.
• Flows arrive but show no data. NetFlow v9 and IPFIX need a template first; lower the template timeout on the exporter. See the NetFlow collector guide.
• Everything stops after a while on an iPhone or iPad. iOS suspends background apps; keep MobiObs in the foreground.

The support checklist covers the remaining cases.