Digipeating refers to making use of an old feature of AX.25 which includes one or more “VIA” callsigns within the header.

APRS makes extensive use of digipeating- actually using it as a kind of multicast, unlike how it works in connected mode.

In connected-mode packet, while it can occasionally be useful in specific situations, digipeating is generally discouraged. This is for three reasons:

1. it is less efficient in terms of airtime
2. it is less reliable in terms of robustness
3. it is generally not even needed - there are other means to achieve the same end result which are more efficient and reliable.

The reason for both the efficiency and reliability issues are related. It is less efficient because with digipeating, in an example with three stations in a chain, station X needs to orchestrate retries between station Y (which X can hear) and station Z (which station X cannot hear). It is less reliable because, with digipeating, if any part of the chain breaks down and causes retries, every station needs to be involved in recovering, which introduces far more opportunities for further failure and collapse of the session than if each individual link in the chain were modeled as its own independent connection.

The simplest version of the “other means” is as follows.

Instead of digipeating, i.e. X connecting to Z via Y, we connect from X to Y, and then X tells Y to connect to Z. The nodes together pass the user or application which requested the session a binary-transparent link between the two distant systems.

A concrete example:

GB7RDG exchanges mail with GB7CIP. They cannot hear each other. In fact, one is on 40m and one is on 70cm. GB7WEM has a modem on each band. GB7RDG connects to GB7WEM, and tells GB7WEM to connect to GB7CIP. GB7RDG's linbpq mail then talks transparently to GB7CIP's fbb bbq.

More complex schemes exist, for example, NET/ROM. This glosses over the need to establish two connections explicitly, at the expense of an additional per-packet overhead of some bytes, plus the need to tolerate nodes broadcasts. It also provides an aliasing system, such that a distant system can advertise an alias for itself or its applications, and asking a NET/ROM-aware node within its “horizon” to connect to one of these aliases automatically establishes the underlying L2 sessions, if required, and joins them to each other.

Regardless of how X connects to Z, the result is a binary-transparent two way pipe through which you can shove bytes either way until the connection is closed. The pipe has exactly the same characteristics as a connection between two nodes which can hear each other directly - the origin and destination software at each end of the pipe is immaterial.

None of this is a new concept- indeed this is primarily how multi-hop connected-mode traffic is passed in practice in 2024.