Skip to content

Firewall ufw

Jump to bottom
Daniel Heinen edited this page May 9, 2026 · 1 revision

Firewall (ufw)

If you run ankerctl on a Linux host with ufw (or any stateful firewall) configured to deny incoming traffic by default, the printer's UDP replies for LAN discovery and PPPP sessions can be silently dropped. This page explains why and which rules you need.

TL;DR

sudo ufw allow in proto udp to any port 32108
sudo ufw allow in proto tcp to any port 4470

Why this matters

The PPPP protocol uses UDP and is asymmetric:

  1. ankerctl broadcasts a LanSearch packet to 255.255.255.255:32108 to find printers.
  2. The printer answers with a PunchPkt to the local source port of that broadcast.
  3. After the handshake, the printer sends session data to the same local port.

The catch: by default Python's socket.socket() without an explicit bind() lets the OS pick an ephemeral local port at the moment of the first sendto. That port is unpredictable and changes on every restart. Two consequences when ufw is active:

  • Stateful rules do not cover broadcasts. Conntrack does not track outbound broadcasts, so the printer's reply is not auto-allowed as "related" — it hits the default-deny rule and is dropped.
  • Static allow port rules cannot match a moving target. A rule like allow in proto udp to any port 32108 only fires when the printer's reply is addressed to port 32108. With ephemeral local ports it never matches.

The fix (since v1.10.9 + issue #77)

ankerctl now bind()s the LAN sockets to a fixed local port before the first sendto:

Socket Created by Local bind Remote target
LAN session open_lan UDP 32108 <printer-ip>:32108
LAN discovery open_broadcast UDP 32108 255.255.255.255:32108
WAN / cloud open_wan (ephemeral, intentional) <cloud-relay>:32100

With predictable local ports, one static ufw rule covers all LAN traffic. The WAN socket stays ephemeral so it does not collide with the LAN socket on the same host (cloud responses transit NAT, which tracks the connection regardless of local port).

For the full design notes see documentation/issue77_code_fix.md.

Required rules

LAN mode (the common case)

sudo ufw allow in proto udp to any port 32108

Covers both LAN discovery (broadcast) and the LAN session (printer replies). One rule, both sockets.

Web UI / slicer access

If you want to reach the web UI or the slicer upload endpoint from another machine, allow the TCP port the web server is bound to (default 4470):

sudo ufw allow in proto tcp to any port 4470

If you changed FLASK_PORT, substitute the correct port.

WAN / cloud mode (rarely needed)

The cloud relay socket (open_wan) is ephemeral on purpose — see the table above. Cloud responses transit NAT, which tracks the connection regardless of local port, so no extra rule is normally required.

Only add the rule below if you have confirmed your environment needs it:

sudo ufw allow in proto udp to any port 32100   # only if needed for WAN mode

Restrict to a specific subnet (recommended)

If your printer is on a known LAN subnet, narrow the rule to that subnet for defense in depth:

sudo ufw allow from 192.168.1.0/24 proto udp to any port 32108
sudo ufw allow from 192.168.1.0/24 proto tcp to any port 4470

Verifying

After enabling the rules:

sudo ufw status numbered
./ankerctl.py pppp lan-search

Expected: the printer is listed within ~5 seconds with its DUID, IP, signal quality, and firmware version. Without the fix or without the rule, discovery hangs at "Connecting" and times out.

Other firewalls

firewalld (RHEL / Fedora)

sudo firewall-cmd --permanent --add-port=32108/udp
sudo firewall-cmd --permanent --add-port=4470/tcp
sudo firewall-cmd --reload

iptables (raw)

sudo iptables -A INPUT -p udp --dport 32108 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 4470 -j ACCEPT

Persist with iptables-save / netfilter-persistent per your distro.

Docker

When network_mode: host is used (the default for the bundled docker-compose.yaml), the host firewall applies — Docker does not insert NAT rules. Use the same ufw / firewalld rules as for a bare-metal install.

If you run ankerctl in bridge mode, PPPP discovery cannot work at all — see Docker for why.

Common error messages

RuntimeError: PPPP local port 32108 already in use

A second ankerctl instance (or another tool listening on 32108) is holding the port. Stop it first:

sudo lsof -i :32108
sudo ss -ulnp | grep 32108

Kill the conflicting process or pick a different printer index for the second instance.

LAN search returns nothing, no error

Most likely causes:

  1. Firewall rule missing — apply the rule above.
  2. Different subnet / VLAN — broadcasts do not cross routers. Put ankerctl on the same L2 segment as the printer.
  3. Wi-Fi client isolation — some access points block client-to-client traffic. Disable AP isolation (sometimes called "Guest Network").
  4. Printer in sleep mode — wake it via the touchscreen.

Camera stream disconnects after exactly 5 seconds

Stall detection — the video service drops the stream when no frame arrives for 5 seconds. Cause is almost always upstream (firewall, network glitch). Check ufw status again and verify packet capture with tcpdump -i any port 32108.

Background reading

ankerctl Wiki

Links

Clone this wiki locally