The Network Held: Three Days of Spam in the Carinthian MeshCore Network

The most important thing first: the network held. For three days the Carinthian MeshCore network was flooded with spam and fake nodes, and it kept running. I see this as a test I would never have ordered and that the network passed anyway. Here I tell what happened, from my point of view as one of the operators.

Just before eight on Tuesday evening

It started on 10 November at 19:37. Messages showed up in the Carinthian MeshCore network that no human can type that fast: on the public channel and on four hashtag channels, at peak 19 per minute, so one every three seconds. By 00:35 there were 471 messages from nine fixed device names.

Then it went quiet. Through the night and the morning the network ran as if nothing had happened.

On Wednesday at 17:12 it started again, this time with a trick. The device name changed after every single message. In a good two hours, until 19:16, 377 messages arrived under 261 different names, from only seven base names, with 116 to 163 new names per hour. Anyone who wants to hide something like that will not get far with a block list.

It was not just one person who noticed. The whole network noticed. Anyone who had the public channel open saw the messages scrolling by.

All times in the text are CET, the chart below is in UTC. The numbers come from the packets of the public map and are calculated, not measured on air.

What a Repeater sees, and what it does not

Why is something like this hard to defend against? Because a MeshCore Repeater knows almost nothing.

A channel message is encrypted. The Repeater sees the packet header, the path so far and a hash of the channel. It does not see the content, the name or the sender. It forwards the packet like any other.

This forwarding is called Flood: every Repeater within hearing range repeats the packet, its neighbors repeat it again, until it has arrived everywhere. That makes a network without fixed routes robust. It also makes it vulnerable. With the radio parameters of CarinthiaMesh (SF8, 62.5 kHz, CR8), a packet of around 109 bytes takes about one second of airtime per forward, and each of those costs air for everyone in range.

How much was it really?

A normal day in the network looks like this: on average around 180 Flood packets per hour. At the peak of the first wave (night of 11 November, 00:00 to 01:00) there were 390, of which 243 from the sender, so 62 percent. At the peak of the second wave (11 November, 18:00 to 19:00) there were 348, of which 200 or 57 percent.

The load on the Repeaters roughly doubled, and the network took it in stride: normal channel traffic carried on, all six Observers stayed active, and the network remained usable. As a stress test, that was a good sign.

Something else stood out in the paths of the second wave. No Observer heard a packet with fewer than two Hops. In 40 percent of the paths the same Repeater appeared twice, for the rest of the traffic it is 13 percent. And the first Hops were spread evenly over many Repeaters all over Carinthia. That looks like pre-filled, forged paths. An operator in the group saw it the same way: the sender writes a few pseudo-Hops into the header to confuse. For locating the sender, these paths are worthless.

An evening in the group

While the second wave was running, what always happens in such moments played out in the Kärnten Funkt MeshCore group: first anger, then ideas, then work.

The anger was real. One person said that as long as this goes on, there is no point even thinking about exercises. Another suggested switching off the Repeaters across the whole country so the sender loses interest.

Then it got concrete, and the group cleared up a few things every newcomer should know:

• Blocking in your own client only tidies up your own display. The packets keep running through the network and eat airtime. And because the name keeps changing, there is nothing to filter on.
• You cannot block the sender. You can only cut off the points through which the sender gets in. But then everyone else is locked out too.
• Switching off does not mean powering down. What is meant is turning off forwarding (set repeat off). The Repeater stays reachable, it just no longer carries anything through the network. This was also briefly clarified so that everyone does the same thing.

Then people acted. First, forwarding was switched off at an entry point in the Spittal area. Then I switched it off on the Dobratsch, the hub between southern and western Carinthia and the rest, and last it went off on the Koralpe in the east, so that the flood would not spill over the Lavanttal branch into the rest of Austria. One operator took his Repeater off the network for the whole night. Shortly after the switch-off it was quiet, whether that was chance or effect, we do not know. And it did not stay quiet: later in the evening operators reported that it had started again. That phase is not included in the numbers of this article.

All Repeaters went back into operation afterwards. Anyone who switches off at the entry point takes away everyone else's way into the network, that is the price. The plan that came out of this trade-off is in the wiki: wiki.carinthiamesh.com/flood-abwehr (detecting loops, Hop limit, duty cycle, emergency switch, finding the sender).

Detectives with limits

In parallel, operators began to narrow down the sender. Two teamed up. One logged every packet with all metadata from the evening on and offered the data to everyone who wanted to do their own analyses with it. Others thought about direction finding with an SDR and a directional antenna for 869 MHz.

Then came the question whether you can read a distance from the received strength. The group's answer: not reliably. The signal-to-noise ratio also depends on local noise, the received power (RSSI) would be the better value. One operator measured a Repeater at 18 kilometers stronger than one at 8 kilometers on one day, both with clear line of sight. Others reported Repeaters that you cannot hear despite a short distance because a hill is in the way, and paths in which Repeaters appeared that actually should not be able to hear each other. That fits what we already suspect: the path was probably forged. Triangulating, the conclusion went, is harder than expected.

So we do not know who it is.

The third night: lettering on the map

Then Thursday came, and with it a surprise that had nothing to do with messages. In the night of 12 November, 190 new nodes suddenly appeared on the map, whose positions together formed lettering north of Carinthia.

The facts: from 01:39 to 02:06, about 27 minutes, 356 Advert packets arrived, up to 24 per minute, under 190 different names. 90 names appeared with a single Advert, the rest with two to five. The packets ran as normal Floods across all Repeaters, on average 124 bytes long, and five Observers heard them. After that, nothing more came.

The damage: the map is falsified until the nodes drop out after seven days. Radio traffic was hardly harmed, 356 packets in half an hour are manageable for the network. Whether the same sender is behind it as in the message floods is open.

Did the sender break the rules?

In the group someone asked whether the sender had broken any rules. To answer that, you have to know what applies in our band in the first place.

MeshCore runs in Europe in the 869 MHz band, a band for devices with short range (Short Range Devices). You may use it without a license, but not without conditions. For this, Austria refers in the Austrian Frequency Use Ordinance 2013 (FNV 2013) to EU decision 2006/771/EC on short range devices. For the range 869.4 to 869.65 MHz it says there: at most 500 mW transmit power (ERP, effective radiated power) and either techniques for frequency access and interference mitigation or a duty cycle of at most 10 percent. The ordinance lists such requirements in the column "conditions of use".

The duty cycle is the share of time in which a single device actually transmits, measured over a continuous hour. 10 percent of an hour is 360 seconds of airtime. With our radio parameters and about one second per packet, that is roughly 360 packets per hour and device.

What that means in practice:

• What counts is the total over the hour, not the speed. Anyone who transmits very fast for a short time and then pauses for a long time can stay within the limit.
• The limit applies to every transmitting device individually, including Repeaters. Forwarded packets also count as airtime.
• The limit regulates airtime, not content. Spam can be within the limit and still be annoying.
• Only those who exceed the 10 percent violate the conditions of use of the band. Below that it is unwelcome, but not a rule violation.

Now the calculation. We calculate with the packets our Observers heard and 1.0 to 1.17 seconds of airtime per packet. The limit is 10 percent per hour, so 360 seconds. As the sender we assume a single device. We suspect that really only one was behind it, but we cannot prove it.

• Wave 1: in the peak hour 243 packets, about 243 seconds of airtime, so about 6.8 percent.
• Wave 2: in the peak hour 200 packets, about 200 seconds, so about 5.6 percent.
• The Adverts of the third night: 356 packets in 27 minutes, about 404 to 416 seconds, so about 11 percent of the hour, in the worst ten minutes even around 37 percent airtime.

This is an estimate, not a measurement: packets that no Observer heard are missing, so the real airtime can be higher. If several devices transmitted, each individual one was below that. The two message floods thus stayed under the 10 percent. The Adverts were above it, if a single device sent them.

My conclusion: the Repeater network has to build its resilience itself. An authority will hardly help with that, unless it becomes a question of frequency use.

Who reads along, and who accuses

Several operators had the feeling that the sender is reading along in the Telegram group. Nobody can prove that, and in an open group you cannot exclude anyone anyway.

One point matters to me here: accusations, direct or indirect, have no place in the mesh or in the group. Anyone can give themselves any device name. A name says nothing about the person behind it.

In the public channel it happened anyway during the second wave. There people speculated about who is behind the messages, and a group of radio amateurs from Carinthia was accused across the board, based on a device behind which, going by the name, a radio amateur might stand. Who is really behind it and whether he has anything to do with the flood, nobody can say.

Later, hints came up again in the group, here too without evidence. My impression is that they come from the same voice.

I consider it possible that this is exactly the goal. A flood that sets operators against each other does more harm than one that only costs airtime.

And in a real emergency?

The question asked loudest in the group after the flood is the most uncomfortable one. An operator pointed out that MeshCore is more a network for the population than for emergency responders. If the mobile network fails, the fear goes, the number of messages jumps suddenly, and the network is under load, without any ill intent at all.

From 13 to 15 November the disaster protection exercise Combined Success runs in Carinthia, which the state of Carinthia and the Austrian Armed Forces have held since 2009. As far as I know, it plays through an earthquake this time, and radio amateurs relay reports on 2 m and 70 cm. MeshCore is not planned in it so far. I asked the people involved and suggested considering it in the future.

For me this means: we should practice in the network how to transmit in an emergency, with defined channels and clear agreements. One suggestion from the group: take the wide Scopes (*, Europe, Austria) off the Repeaters and work only locally. I would apply that as soon as something shows up again. Implementing it in a coordinated way on all Repeaters is the real work, and that is exactly what we should practice, instead of learning it in an emergency.

The test and what it showed

I see these three days as a test, and it turned out well. The network took the flood, fake nodes and forged paths in stride, the rest of the traffic carried on. At least as important as the technology was what happened among us mesh people: we coordinated quickly, without anyone having to give orders. At the end of these days one of us noted that people stick together and work together. There is little to add to that. With us mesh people, everyone who has a device joins in, whether in a club or privately, and that is the real defense. Technology alone would have helped little here.

The test also showed what we should work on: a uniform minimum defense on all Repeaters, a practiced procedure for emergencies and more Observers that share data.

And in the middle of the excitement, on Thursday noon, a question came from the group that sounded completely different: what do people think of a Repeater near Feldkirchen, with direct line of sight to the Magdalensberg and up to Ossiach? I answered: good idea, and asked whether there is already a site for it or only the idea so far, and what hardware would be needed.

The network keeps growing.

What you can take away

Procedure in case of an attack in six steps

1. Document the situation with counts, without message content.
2. Inform operators and change nothing for the time being.
3. Uniform minimum defense on all Repeaters.
4. Switch off the entry point for a limited time (set repeat off), if necessary.
5. Narrow down the source, talk to people instead of pillorying them.
6. Document afterwards.

What works, what does not

• A private channel protects the content, but not against the flood.
• A Scope sorts, but does not protect, because the code can be calculated from the region name.
• Paths and received strengths are only a hint for locating, not a trail, especially not with forged headers.
• Only measures that limit the amount and reach of Floods are effective. In an emergency that is the temporary switch-off of forwarding at the entry point, at the price that everyone else stays out there.

Appeal

• Do not read other names as grounds for suspicion, and do not accuse anyone anywhere without evidence.
• The network belongs to nobody alone. It lives on agreements within the community, for example when naming devices. Those who take part keep to them and do not present the network as their own.
• Configure Repeaters uniformly and keep the firmware version visible.
• Run your own Observers and share data: anyone who logs packets can later prove what happened.
• Those who keep to transmit power and duty cycle act within the rules, and yet a network can suffer. That is why agreements are needed.

73, Michi OE8YML

---

Transparency note

I wrote and checked this article with the support of AI (Claude, Anthropic), based on my analyses and the observations from the operator group. All numbers are calculated from the packets of the public map (map.carinthiamesh.com), not measured on air, the airtimes are estimates under the stated assumptions. The article contains no message contents, no keys and no positions of private persons. Who is behind the messages and the fake nodes is unknown. The two header images are AI-generated and serve only as illustration. Corrections and additions are welcome at [email protected].