Allow direct message paths when denyf * is set - alternative approach

[ekjf0943vc]

PR1810 #1810 deals with enabling DM when denyf* ist set. I would like to suggest an idea that should render the same result, but without messing with the implementation of denyf* itsself.

I suggest adding two new rules:

• allowg *
• denyg *
  for GRP_TXT, GRP_DATA, ADVERT respectively.

I can't implement it, but hope someone here can do this easily.

I would like to thank dt267 dt267/MeshCore-Low-Power-Firmware-For-Heltec-V3-V4#6 for the suggestion.

This would not break the implementation of denyf* while enabling the above mentioned protocols. I hope this suggestion has better chances then PR1810. This would also end the endless support question concerning PR1810 and how denyf* works in main vs. evo respectively.

[dt267]

I already have the code.

// RegionMap.h
#define REGION_DENY_FLOOD        0x01
#define REGION_DENY_DIRECT       0x02   // reserved for future
#define REGION_DENY_FLOOD_GROUP  0x04   // deny only GRP_TXT, GRP_DATA, ADVERT flood; allow direct message types

// MyMesh.cpp
bool MyMesh::filterRecvFloodPacket(mesh::Packet* pkt) {
  // just try to determine region for packet (apply later in allowPacketForward())
  if (pkt->getRouteType() == ROUTE_TYPE_TRANSPORT_FLOOD) {
    recv_pkt_region = region_map.findMatch(pkt, REGION_DENY_FLOOD);
  } else if (pkt->getRouteType() == ROUTE_TYPE_FLOOD) {
    bool is_group = (pkt->getPayloadType() == PAYLOAD_TYPE_GRP_TXT ||
                     pkt->getPayloadType() == PAYLOAD_TYPE_GRP_DATA ||
                     pkt->getPayloadType() == PAYLOAD_TYPE_ADVERT);
    uint8_t deny_mask = is_group ? (REGION_DENY_FLOOD | REGION_DENY_FLOOD_GROUP)
                                 : REGION_DENY_FLOOD;
    if (region_map.getWildcard().flags & deny_mask) {
      recv_pkt_region = NULL;
    } else {
      recv_pkt_region = &region_map.getWildcard();
    }
  } else {
    recv_pkt_region = NULL;
  }
  // do normal processing
  return false;
}

However, we need to modify the 'Manage Regions' section within the Repeater Admin interface to visualize the filter rules. The 'allowg/denyg' logic is just an example of an external rule set that the core team could implement to better address user operational requirements.

[ekjf0943vc]

I have tested this approach and can confirm that the technical implementation in itsself works as expected.