While working on my new NPR firmware for RP2350, I ran into a topic that I honestly had not thought about for many years: ARP. Or, more precisely, how ARP behaves in a network that only pretends to be Ethernet.
In the rest of this article I would like to write down a number of notes and ideas that I gathered while studying the original firmware and implementing my own version. Hopefully putting these thoughts into words will help me organise them a bit better. And perhaps it might also help someone else understand a few of the less obvious details of how NPR works and how it sometimes very deliberately does not behave like a normal network.
The original NPR firmware by Guillaume F4HDK implements a clever trick that makes the whole NPR network behave as if it were one large Ethernet segment. When you first start using NPR, you do not really need to think much about routing, subnet boundaries or address resolution. Devices obtain an IP address, they can reach other hosts in the network and packets flow over the radio link as expected. Only when you start implementing your own modem firmware, or try to integrate NPR into a more general router-like architecture, do you notice that something unusual is happening in the firmware.
I am currently implementing NPR support in a new firmware running on RP2350 with FreeRTOS and lwIP. At first I experimented with PPP over USB because it is simple and hides most of the Ethernet details. More recently I switched to USB CDC-NCM, which exposes a real Ethernet interface to the host computer. Suddenly the modem started seeing ARP traffic, broadcast frames and all the details that come with Ethernet networking. Once that happens, you have to understand how the original design deals with addressing, and why it works the way it does.
How NPR Works Today
New Packet Radio is a TDMA system operating over a relatively narrow RF channel. It was never meant to replace the Internet or carry large amounts of continuous traffic. The design goal was to provide a practical packet radio link with reasonably high throughput while still operating within the constraints of amateur radio spectrum.
In such an environment every transmitted byte matters. Unlike a wired Ethernet network where broadcast traffic is almost free, in a TDMA radio system every frame consumes a portion of the shared airtime. Broadcast traffic is particularly problematic because it has to be delivered to every participant in the network. If the protocol allowed Ethernet broadcast frames to freely propagate across the radio channel, the link would quickly become saturated with ARP requests, DHCP messages and other background traffic.
I believe this is the main reason the NPR protocol avoids transporting broadcast frames across the radio link. The radio channel carries IPv4 packets encapsulated in NPR frames rather than full Ethernet frames. This design decision has several consequences.
First, ARP packets are not transported over the radio link. A host connected behind one NPR modem cannot directly send an ARP request to a host connected behind another modem.
Second, DHCP traffic cannot simply be broadcast across the radio network in the usual way. The master therefore participates in address allocation and distributes address ranges to slaves during the connection procedure.
This behaviour looks unusual compared to typical Ethernet networks, however it makes perfect sense in a radio system where airtime is scarce and broadcast traffic would quickly waste a large fraction of the available bandwidth.
The ARP proxy behaviour
The NPR slave modem monitors ARP requests arriving from its local Ethernet network. When it sees a request for an IP address that belongs to the NPR subnet but does not belong to the address range assigned to that slave, the modem replies to the ARP request itself.
The reply essentially says that the requested IP address is reachable through the modem’s own MAC address.
From the perspective of the host computer behind the modem the situation now looks completely normal. The host asked who owns a certain IP address and received a valid ARP response. The host therefore sends the Ethernet frame to the modem.
Inside the modem firmware the Ethernet header is removed and the IPv4 packet is forwarded over the radio link. The NPR master receives the packet and determines which slave actually owns the destination address. If the address belongs to another slave the packet is forwarded to that slave. If it belongs to the upstream network it is sent to the LAN side. The result is that multiple routed radio links behave like one large Ethernet segment.
This behaviour has a name: proxy ARP described in RFC 1027. Originaly, this was used by routers to answer ARP requests on behalf of hosts located in another network. NPR uses this idea, but with a different purpose. Instead of connecting two IP subnets it creates the illusion that the entire NPR infrastructure is a single Layer-2 network.
What actually happens on the wire
A simple example helps illustrate the mechanism. Consider two computers located behind two different NPR slaves.
| Host | IP Address | MAC Address | Connected to | IP range of the slave |
|---|---|---|---|---|
| A | 192.168.0.10/24 | AA:AA:AA:AA:AA:AA | Slave 1 | 192.168.0.10 – 192.168.0.20 |
| B | 192.168.0.50/24 | BB:BB:BB:BB:BB:BB | Slave 2 | 192.168.0.40 – 192.168.0.50 |
Both computers believe they are in subnet 192.168.0.0/24, so when computer A wants to communicate with computer B the following ARP request is broadcasted on the Ethernet interface of slave 1:
Who has 192.168.0.50? Tell 192.168.0.10.
Src MAC address: AA:AA:AA:AA:AA:AA
Dst MAC address: FF:FF:FF:FF:FF:FF (broadcast)Slave 1 receives the request, sees that the requested IP address is inside the NPR subnet but outside its own DHCP range, and answers the request itself:
192.168.0.50 is at 11:11:11:11:11:11
Src MAC address: 11:11:11:11:11:11
Dst MAC address: AA:AA:AA:AA:AA:AAComputer A now believes that host 192.168.0.50 is reachable through the host 11:11:11:11:11:11 and starts to send packets there.
Slave 1 immediately forwards the IPv4 packet to the master via radio. The master examines the destination address and knows that 192.168.0.50 belongs to slave 2. The packet is then forwarded to slave 2 and finally delivered to computer B.
From the point of view of the two computers it appears as if they are connected to the same Ethernet switch.
What happens without the ARP proxy
If the modem did not implement this behaviour the communication would fail immediately. Computer A would broadcast an ARP request asking who owns 192.168.0.50, slave 1 would ignore the request. And because ARP broadcast frames are not transported through the NPR radio network, slave 2 would never see the request and therefore could not answer it. Computer A would eventually give up and report that the destination host is unreachable.
This means that the ARP proxy behaviour is not just an implementation detail. It is a fundamental part of how the NPR network behaves.
Why this works well for the original modem
The original NPR firmware connects exactly two worlds. On one side there is Ethernet and on the other side there is the NPR radio link. There are no other network interfaces and therefore no ambiguity about how traffic should be handled.
Under these conditions the proxy ARP trick works quite well and user does not need to think about it. It allows the entire network to behave like one Ethernet segment without requiring routing tables or complex configuration. For small networks this is extremely convenient.
The moment you try to build a more general modem the situation becomes more complicated.
NPR inside a general packet router
This is where things start to get interesting. The moment we begin thinking about multiple network interfaces and several different RF links, each with its own addressing scheme and configuration, the situation becomes more complicated both in the firmware and for the user.
The firmware can no longer simply listen to every incoming ARP request, answer it and forward the resulting IPv4 traffic through the NPR radio link. It also becomes limiting that the original NPR design allocates addresses from a single subnet.
What happens if our modem has more than one Ethernet interface? This is not a theoretical example. The hardware I am currently developing already exposes Ethernet over USB using CDC-NCM and also has a separate Ethernet interface implemented using a W5500 controller. That means two independent Ethernet networks connected to the same modem.
What if we want each interface to use a different subnet? Or what if we want traffic from one Ethernet interface to be routed through NPR, while the other Ethernet interface should be routed to a completely different radio link?
In such a scenario the original behaviour becomes too simplistic. We may want ARP proxy behaviour only between the NPR radio link and one specific interface, while the rest of the device behaves like a normal router.
In other words ARP proxy is still needed, but it can no longer be tightly coupled to NPR itself. It has to be implemented in a more general way inside the networking stack.
ARP proxy in lwIP
Fortunately lwIP provides several extension points that make this possible. Ethernet frames arriving from a network interface are first delivered to the stack through the netif interface and then processed by the ARP layer implemented in etharp.c. Because the firmware controls the network interface drivers and the packet flow into the stack, it is possible to inspect ARP requests and decide whether the modem should answer them locally.
In practice this means the firmware can examine ARP requests arriving on a particular interface and check whether the requested IP address belongs to a network reachable through another interface. If the modem decides to act as a proxy, it simply generates an ARP reply using its own MAC address.
This mechanism is essentially the same trick used by the original NPR firmware, but implemented in a more generic form so that it can be applied selectively between different interfaces rather than being tied to a single radio link.
At the moment this is exactly the part of the system I am experimenting with. Implementing NPR support in a more general packet modem has already forced me to learn quite a bit more about lwIP internals and about ARP behaviour than I originally expected. Hopefully the explanation above makes the problem at least a little clearer.
A routed NPR architecture
Everything described so far follows directly from the original NPR architecture and from the behaviour of the existing STM32 firmware implementation.
But what if we approached the problem from a completely different direction and tried to eliminate ARP proxy entirely?
Instead of pretending that the entire NPR network is one Ethernet segment we could treat it as a routed network. In other words every slave modem becomes a small router and the radio network forms a routed backbone between them.
Imagine that all NPR nodes share a small internal service network used only for communication between NPR devices. For example we could use the network 10.255.255.0/28.
Each slave modem receives one address in this service network. At the same time each slave is assigned its own client subnet that will be used for devices connected behind that modem.
The result could look like this.
| Service LAN IP | Subnet for Clients | Usable Host Range | |
|---|---|---|---|
| Upstream router | 10.255.255.1/28 | ||
| NPR Master | 10.255.255.2/28 | ||
| Slave 1 | 10.255.255.3/28 | 192.168.10.0/27 | 192.168.10.1 – 192.168.10.30 |
| Slave 2 | 10.255.255.4/28 | 192.168.10.32/27 | 192.168.10.33 – 192.168.10.62 |
| Slave 3 | 10.255.255.5/28 | 192.168.10.64/27 | 192.168.10.65 – 192.168.10.94 |
| Slave 4 | 10.255.255.6/28 | 192.168.10.96/27 | 192.168.10.97 – 192.168.10.126 |
| Slave 5 | 10.255.255.7/28 | 192.168.10.128/27 | 192.168.10.129 – 192.168.10.158 |
| Slave 6 | 10.255.255.8/28 | 192.168.10.160/27 | 192.168.10.161 – 192.168.10.190 |
| Slave 7 | 10.255.255.9/28 | 192.168.10.192/27 | 192.168.10.193 – 192.168.10.222 |
The upstream router only needs one route pointing to the NPR master.
192.168.10.0/24 via 10.255.255.2In this architecture the master behaves like a router between the upstream network and the NPR backbone. Each slave behaves like a small router between the backbone and its local LAN.
ARP traffic remains strictly local to each subnet and ARP proxy is no longer needed.
Consequences of this design
This approach has several advantages.
The first one is architectural clarity. The network behaves like a normal routed IP network rather than pretending to be a single Ethernet segment. The networking stack inside the modem becomes simpler because it does not need to implement special ARP proxy behaviour.
The second advantage is isolation between sites. Hosts connected behind different slaves are now separated by routing boundaries. This makes it much easier to implement firewall rules, access control or other security policies. In the original design every host effectively shares the same Layer-2 domain.
Another interesting property is flexibility. Because each slave receives an entire CIDR subnet it can decide how to use that address space. It may expose the entire range on a single Ethernet interface via DHCP, or it may subdivide the range into smaller networks. One subnet could serve local Ethernet clients while another could be routed further through an additional RF link. In other words each slave becomes a small router rather than a simple bridge.
Of course this approach also introduces some drawbacks.
The biggest one is configuration complexity. The address space must be planned in advance and routing must be configured correctly on the master and on the upstream router. Unlike the current NPR model it is no longer possible for a completely uncoordinated client to simply connect and start using the network.
Someone must decide which address block belongs to which site and configure the routing accordingly.
The current NPR signalling protocol also assumes the legacy model where the master allocates a simple range of IP addresses from a single subnet. It does not contain a mechanism for allocating entire subnets dynamically.
That leads to an obvious question. Could the signalling protocol be extended so that a slave can request a subnet from the master?
Subnet allocation extension
One possible way to support this architecture would be to slightly extend the NPR signalling protocol.
After establishing a connection, the slave could send a request asking for a subnet of a certain size. Instead of requesting a number of individual addresses it would request a prefix length, for example /27 or /28.
The master would then allocate a subnet from its configured address pool and return the assigned network and prefix length in the response.
Internally the master would maintain a small table mapping slave identifiers to allocated subnets. When an IPv4 packet arrives the master simply checks which subnet contains the destination address and forwards the packet to the corresponding slave.
This mechanism could be implemented using additional signalling TLV fields without fundamentally changing the protocol. A slave that supports the extension would first attempt to request a subnet. If the master does not understand the request the slave would simply fall back to the legacy behaviour where individual IP ranges are assigned.
Such an extension would therefore remain backwards compatible with existing NPR deployments. The question is whether this additional complexity is actually worth it.
For small networks, the simplicity of the original design is extremely attractive. For larger installations or for modem firmware that behaves as a general packet router the routed architecture starts to look more appealing.
At this point I do not have a definitive answer. I am still experimenting with different approaches and trying to understand which one makes more sense in practice.
A small networking rabbit hole
I did not expect that implementing a new NPR modem would lead me to questions about subnetting and ARP behaviour.
The original NPR firmware solves the problem with a clever proxy ARP mechanism that keeps configuration extremely simple and allows the entire network to behave like one shared segment. Once NPR becomes just one interface among several, however, the routed model starts to look more attractive.
For now I am still experimenting and thinking about how far it makes sense to push NPR in this direction. The routed approach is interesting, but the simplicity of the original design is also hard to beat.
If nothing else, the whole exercise has been a pleasant weekend of reading RFCs, studying lwIP internals and thinking about networks. Pretty good weekend, I’d say…