Allow direct message paths when denyf * is set

[ZjMNZHgG5jMXw]

Problem

Flood messages cannot pass repeaters when region denyf * is set. Repeaters with this setting would not only deny forwarding channel messages and flood adverts, but also all messages which are used to negotiate and establish new paths for direct messages. In areas where all repeaters deny forwarding flood traffic, no direct message paths can be (re)established.

What changed

The repeater setting region denyf * now allows flood-forwarding

• REQ,
• RESPONSE,
• TXT_MSG,
• ACK,
• ANON_REQ,
• PATH,
• TRACE,
• MULTIPART,
• CONTROL,

and denies flood-forwarding

• GRP_TXT,
• GRP_DATA, and
• ADVERT.

The payload type CUSTOM won't be forwarded, this logic has not been touched by this patch.

Why

The mesh network should always allow and support direct messages. The intention of a repeater admin who chooses to set region denyf * is likely wanting to restrict message types which typically clog the network by being flooded, such as GRP_TXT, ADVERT, and, since equally potential, GRP_DATA. The intention of the admin is likely not to shutdown the network for direct messages which they could easier achieve by switching off the repeater. Setting region denyf * in the current implementation (without this patch) would leave repeaters in an unusable state for forwarding (flood and) direct messages.

Expected outcome

Repeaters with region denyf * set are usable for direct messages, including forwarding messages and establishing paths for direct messages by flood-forwarding all message types which are used for establishing direct message paths. The repeaters should stop forwarding channel traffic and flood adverts.

Compatibility

Repeaters modified by this patch are compatible with unmodified repeaters of all versions, since region denyf * only takes out channel messages and flood adverts. These messages are fire-and-forget for companions and repeaters. Also, repeaters may choose to drop messages at their discretion already today. For companions repeaters would appear as absent for channel messages and flood adverts.

Testing

This patch has been successfully tested on a Heltec v3 repeater with region denyf * and region allowf *. For the test, a nearby observer node was watching the traffic created by a companion and forwarded by the repeater.

[skyepn]

I agree that the mesh network should always allow and support direct messages at a minimum, but it may still be useful to have the ability to turn off direct message flood routing in the case of a bad actor or misbehaving software.

In many large meshes the main problem is too much group text traffic (bots, etc) between regions.
More fine grained flood control will be needed for different scenarios.

I would propose replacing denyf arg * with bitwise flags for functional groups/packet classes, something like:
ALL (would override any other flag)
TXT (direct messages)
GRP (group messages)
ADVERT
etc tbd

I don't have detailed knowledge of which packet types are required for what functionality, but being able to block flood for only certain classes of packets would be a big improvement, and grouping the packet types into functional classes would make administration much more intuitive.

[ZjMNZHgG5jMXw]

I don't have detailed knowledge of which packet types are required for what functionality, but being able to block flood for only certain classes of packets would be a big improvement, and grouping the packet types into functional classes would make administration much more intuitive.

I agree, this could be a good next step. 👍

[skyepn]

Slightly off topic but using * as the argument is creating a lot of confusion.
People don't expect * to mean "no region set" they assume it means "any region set". And then it's still confusing because it's not clear if it means any region set, or any region or no region.
denyf unset or similar would be a lot more intuitive.