LonTalk over IP (IP-852): Setup and Troubleshooting

Putting LonWorks on an IP network sounds like the easy part. The protocol doesn’t change, and Ethernet is already in the building.

Then a device stops forwarding and nothing in the LonWorks tooling explains why.

ISO/IEC 14908-4 doesn’t rewrite LonTalk into a different application protocol. It transports LonTalk packets over IP using a mechanism it calls CNP/IP. But that mechanism brings its own state — send lists that have to be symmetric, sequence numbers that have to stay ordered, and a clock dependency that can cause a device to stop forwarding if it can’t establish that its clock is still within the permitted margin. That last one is the reason this article exists.

The standard calls devices doing this CNP/IP devices. Vendors call it IP-852.

Why UDP

The protocol already does end-to-end acknowledgement at its transport layer. Adding another reliable transport underneath would duplicate that work and slow it down.

So UDP, chosen for efficiency and for multicast support. The IP layer sends no acknowledgements and never retransmits a dropped packet — if something goes missing, the LonWorks transport layer already knows how to handle it.

What the IP layer must do instead is narrower: keep packets in order, throw away duplicates, and discard anything that arrived too late to be useful.

Ports. Four registrations exist with IANA: 1628/tcp, 1628/udp, 1629/tcp and 1629/udp. The standard’s wording is that a device should use one of them — not all four. So don’t assume a deployment needs every one open. Find out which port and transport your devices are actually configured for, and open that. In practice most CNP/IP traffic is UDP, since that’s what the data exchange uses.

The common header

Every CNP/IP message carries a fixed header, and every message in a bunched datagram carries its own:

Packet bunching is mandatory. Several messages can ride in one UDP datagram, each with its own header, and every device must support receiving them. Because each header carries its own size, they can be pulled apart individually.

Vendor extension is handled cleanly: a vendor packet extending a standard function reuses that function’s Packet Type and sets a non-zero Vendor Code. A vendor packet with no standard equivalent uses a type in the 0x80–0xFF range.

Ordering and duplicates

Each sender keeps a session ID and a 32-bit sequence number per destination. The receiver tracks the last sequence it forwarded.

• In sequence → forward
• Ahead of sequence → hold in escrow, wait for the gap to fill
• Escrow expires → give up and move on. Bounded by the channel timeout, which is capped at 1,5 s
• At or below the last forwarded sequence → discard as duplicate

Session IDs are normative, and the trigger is specific. Every node keeps a session ID chosen at random. If a node reboots, resets, or otherwise forgets the sequence numbers it was using, it sends its next messages to each destination with a new session ID — also random, with the constraint that it must not match the one in use before the event.

On the receiving side, a message arriving with a different session ID than the previous message from that source is assumed to be in sequence, and the receiver stores the new session ID and sequence number pair for ordering everything that follows. That’s how a rebooted device gets accepted immediately instead of being ignored until its counter catches up.

The channel timeout is a channel-global parameter. Every device holds it and every device holds the same value. It isn’t tuned per device.

The NTP trap

This is the part that surprises people, and it’s worth reading twice.

Stale packet detection works by timestamping every packet and comparing on arrival. For that comparison to mean anything, every device on the IP channel needs a synchronised clock. The standard names the mechanism: SNTP, per RFC 2030. That implies an SNTP time server somewhere on the IP network, and devices configured with its address.

The timestamp format needs care, because two different formats are in play.

The RFC 1305 timestamp is a 32-bit integer of seconds plus a 32-bit integer of picoseconds. The standard rejects it for this purpose, and says why: no contiguous range of bits in that format has both the resolution and the arithmetic properties needed. So CNP/IP defines its own timestamp — 32 bits of milliseconds, aligned with current SNTP time. A 32-bit millisecond counter wraps every 49,7 days.

One detail worth having: the timestamp is always zero for configuration packets. It’s only meaningful on data packets.

Now the consequence. The standard’s wording is careful, and worth getting exactly right:

A device may continue forwarding packets only as long as it can be reasonably sure its clock hasn’t drifted outside the margin of error against the rest of the channel. That’s the restrictive clause. It can meet it if it knows its own clock drift rate. And if it has no way of estimating that margin, the standard says it need not forward packets onto the IP channel at all.

So the final step is permissive rather than mandatory — the standard doesn’t say “shall stop.” But the practical outcome is the same: a device that loses its time reference and can’t bound its own drift is entitled to stop forwarding, and implementations do.

Which means a LonWorks-over-IP installation carries a real dependency on a time server, and most commissioning checklists never mention it. Somebody decommissions an NTP server, and weeks later a building control network goes quiet for reasons nobody connects to that change.

A note on precision, since it explains why this isn’t as fragile as it sounds. Whatever resolution the time format allows, practical precision comes down to timer interrupts, typically 10 ms or 16 ms. The CNP/IP timestamp is in milliseconds and the low three or four bits carry no useful value, so rounding or truncating isn’t an issue. And the smallest receive transaction timer in LonWorks is 128 ms, so small differences between two timestamps aren’t relevant anyway. The mechanism needs devices roughly in sync, not precisely.

Two practical notes:

Stale detection can be disabled. On a single flat Ethernet segment with no routers in the path, that’s a defensible choice — packets can’t be delayed enough to matter. On anything routed, leave it on and provide the time server.

The SNTP server address is a device parameter, sitting alongside the IP gateway address, subnet mask, and configuration server address. It belongs in the same commissioning record as those.

Send lists, and why they must be symmetric

Each device holds a send list: the unicast and multicast IP addresses and ports it forwards to.

That list is configured, not discovered. And it has to be symmetric.

If A has B in its send list but B doesn’t have A, traffic flows one way. Since acknowledged LonWorks service needs the reply to get back, the transaction fails — but the outbound packets are visibly arriving, so the fault looks like the destination device is broken.

Asymmetric send lists are a common configuration error on these channels. Check both directions before suspecting hardware.

What a channel definition holds

A complete channel definition is logically a list of every device on the channel. Per device:

• Multicast support, yes or no — it’s optional, so the flag is required
• TCP support, yes or no — also optional
• Device type: router, node, proxy
• Router type: repeater, learning, configured
• The “wants all broadcasts” flag
• A text name for identification
• Channel timeout — global to the channel, same for every device
• Unicast IP address and listening port
• Multicast address and port pairs it listens on
• Up to three unique device IDs: router near side or node, router far side, and an auxiliary one for configuration
• Domain length and ID, subnet, and node address for each domain
• Group membership, for nodes
• Routing table, for routers

Note that the tunnel is addressing-agnostic. It doesn’t require any particular LonWorks addressing scheme — unique device ID, domain, subnet, node and group all pass through.

Configuration: three ways

Manual. No configuration server. Every channel parameter, send list entry, and device parameter typed in by hand. There is no standard method — the standard lists configuration files, terminal, telnet, FTP and HTTP as vendor options. Workable for a handful of devices, unmanageable beyond that.

DHCP or BOOTP. For getting an IP address without prior configuration. A compliant device that wants this shall implement a DHCP client and may implement BOOTP. Note the asymmetry — DHCP is the required one.

Configuration server. The plug-and-play path. It distributes channel definitions and send lists, and maintains the channel definition automatically by detecting devices coming on and going off line. The channel list describes the network as a whole; the send list is potentially unique per device.

Two rules worth knowing about configuration servers:

• Devices that use one must interoperate with devices that don’t. You can mix.
• A configuration server needn’t support every interaction in the specification. Channel Routing packets specifically need not be supported.

Devices send a registration message to the configuration server on power up, on reset, and whenever their channel definition parameters change. That’s the mechanism keeping the channel list current. If the server is unreachable at boot, the device may keep operating on its previous channel definition and send list until it can obtain an updated one.

Segmentation

The CNP/IP specification works to a maximum of 548 bytes of payload per UDP packet. This is the specification’s working limit — it isn’t an inherent property of UDP, which permits considerably larger datagrams. It comes from the classic safe-payload figure for IPv4, and the standard treats it as the ceiling it will rely on.

Some configuration structures — channel membership and routing lists in particular — exceed it. Those get carried as segment packets, each carrying:

• A segment ID
• A valid bit
• A final bit marking the last segment
• A datetime recording when that data structure became valid

The datetime is the clever part. Compare it across segments of the same transfer — a mismatch tells you the underlying data changed partway through, so what you assembled is a mix of two versions and should be discarded.

Messages using segmentation need not be bunched with other packets.

Security

Optional, and stronger than the native LonWorks scheme.

Set the security bit in the header and the sender appends a shared secret to the packet, runs MD5 over the whole thing, and puts the resulting 128-bit digest in the header. The receiver zeroes the digest field, recomputes with its own copy of the secret, and compares.

The standard’s requirement for the shared secret is that it must at minimum represent a value containing 128 degrees of freedom — its phrase, not a conventional cryptographic one. In practice it means 128 bits of entropy. The examples given are a 16-byte array of free bits, or a 22-byte string where each byte carries 6 usable bits.

What this does and doesn’t give you:

• Does: tamper detection. A modified packet fails the digest comparison.
• Doesn’t: confidentiality. Contents remain open to inspection, and the standard says so plainly.

Don’t read this as modern cryptographic authentication. It’s a keyed digest with no replay protection of its own, MD5 is long past being considered collision-resistant, and the construction is not HMAC. Treat it as protection against corruption and casual interference on a network you already control — not as a security boundary.

The secret must never cross the network in the clear, and devices must provide a secure manual method for setting and updating it.

Troubleshooting order

1. Both ports open? 1628 and 1629, both protocols.
2. Send lists symmetric? Check both directions, not just the one that looks broken.
3. Time server reachable? If stale detection is on and a device lost its reference, it stops forwarding by design.
4. Configuration server reachable at boot? Devices register on power up and reset.
5. Channel timeout consistent? It’s global. Every device should hold the same value.
6. Session IDs changing unexpectedly? That means devices are rebooting.

FAQ

What ports does LonWorks over IP use? Four registrations exist with IANA — 1628/tcp, 1628/udp, 1629/tcp and 1629/udp — and a device should use one of them. Check which one your devices are configured for rather than opening all four.

Why did my LonWorks IP device stop forwarding packets? Check the time server first. A device may keep forwarding only while it can be reasonably sure its clock hasn’t drifted out of range with the rest of the channel, and if it can’t estimate that margin the standard permits it to stop.

Do I need a configuration server? No — manual configuration and mixed channels are both supported. But every parameter has to be entered by hand, and devices won’t self-register, so it stops scaling quickly.

What’s the maximum packet size? The specification works to 548 bytes of UDP payload. That’s a CNP/IP limit, not a UDP one. Larger structures use the segment packet mechanism.

Is LonTalk over IP encrypted? No. The optional security provides tamper detection via an MD5 digest over a shared secret. Contents stay readable, and it shouldn’t be relied on as a security boundary.

Does putting LonWorks on IP change the protocol? No. LonTalk packets are transported over IP rather than rewritten into a different application protocol. Devices are still addressed by domain, subnet, node, group or unique device ID, and the transport layer still does the acknowledging.

Why is traffic only flowing one way? Almost certainly an asymmetric send list. Both devices need each other listed.