[Feature Request]: Do not reply to any broadcast packets with want_response

[RCGV1]

Platform

other

Description

This should not be a supported feature. Nodes should not be able to ask for a response on a broadcast packet as this can cause tons of traffic. Want response should only be allowed on directed messages.
@GUVWAF

[b8b8]

What about when you are deliberately sending a ping like when double tapping the button on screenless node to send your position and want a response?

[RCGV1]

This should not be allowed. That position packet should be sent without a want response.

[b8b8]

But the purpose of sending that position packet is to have a response. It's to ping the network with your position and receive everyone else's back.

[niccellular]

can we keep this for portnums 72 and 257? I use this feature in the ATAK Plugin

[Xaositek]

I will say I'm not in favor of this change as it limits the overall discovery of a mesh in a meaningful way.

If it's deemed to be the only way then I would say shrink the minimum Node Info Broadcast to something like an hour or 90 minutes, including having that setting in the apps. Currently set at three hours is far too infrequent when looking at removing this.

[b8b8]

There are more uses for Meshtastic than just hyper dense cities on the coast. If "traffic" is a constant issue in these places like SFO or NYC a faster preset solves this. There are so many people there already that the lower link-budget isnt an issue.

Perhaps the default preset in the USA should just be short_turbo so we can stop removing important features.

[RCGV1]

Sample code

    if (p->want_ack && p->to == NODENUM_BROADCAST && !IS_ONE_OF(p->decoded.portnum,meshtastic_PortNum_ATAK_PLUGIN,meshtastic_PortNum_ATAK_FORWARDER,meshtastic_PortNum_TRACEROUTE_APP)) {
        LOG_WARN("Broadcast packet requested ACK, ignoring!");
        p->want_ack = false; // Can't ACK broadcast packets
    }

[korbinianbauer]

Sample code [...]

Wait, are we talking about want_ack or want_response now?

About broadcasts with want_ack:

Current firmware should already refuse to send broadcasts with want_ack=true. I'm not sure how the broadcasts with want_ack=true from the ATAK plugin even work (?) Does it somehow circumvent this? @niccellular

firmware/src/mesh/Router.cpp

Lines 326 to 328 in 8fe98db

	// Never set the want_ack flag on broadcast packets sent over the air.
	if (isBroadcast(p->to))
	p->want_ack = false;

In case we still receive such a packet, the logic for deciding whether to respond with an ACK is fairly complicated, maybe that needs to be reviewed. But as I read it, the firmware already doesn't reply to broadcasts with want_ack=true.

firmware/src/mesh/ReliableRouter.cpp

Lines 97 to 165 in 8fe98db

	void ReliableRouter::sniffReceived(const meshtastic_MeshPacket *p, const meshtastic_Routing *c)
	{
	if (isToUs(p)) { // ignore ack/nak/want_ack packets that are not address to us (we only handle 0 hop reliability)
	if (!MeshModule::currentReply) {
	if (p->want_ack) {
	if (p->which_payload_variant == meshtastic_MeshPacket_decoded_tag) {
	/* A response may be set to want_ack for retransmissions, but we don't need to ACK a response if it received
	an implicit ACK already. If we received it directly or via NextHopRouter, only ACK with a hop limit of 0 to
	make sure the other side stops retransmitting. */
	if (shouldSuccessAckWithWantAck(p)) {
	// If this packet should always be ACKed reliably with want_ack back to the original sender, make sure we
	// do that unconditionally.
	sendAckNak(meshtastic_Routing_Error_NONE, getFrom(p), p->id, p->channel,
	routingModule->getHopLimitForResponse(p->hop_start, p->hop_limit), true);
	} else if (!p->decoded.request_id && !p->decoded.reply_id) {
	// If it's not an ACK or a reply, send an ACK.
	sendAckNak(meshtastic_Routing_Error_NONE, getFrom(p), p->id, p->channel,
	routingModule->getHopLimitForResponse(p->hop_start, p->hop_limit));
	} else if ((p->hop_start > 0 && p->hop_start == p->hop_limit) || p->next_hop != NO_NEXT_HOP_PREFERENCE) {
	// If we received the packet directly from the original sender, send a 0-hop ACK since the original sender
	// won't overhear any implicit ACKs. If we received the packet via NextHopRouter, also send a 0-hop ACK to
	// stop the immediate relayer's retransmissions.
	sendAckNak(meshtastic_Routing_Error_NONE, getFrom(p), p->id, p->channel, 0);
	}
	} else if (p->which_payload_variant == meshtastic_MeshPacket_encrypted_tag && p->channel == 0 &&
	(nodeDB->getMeshNode(p->from) == nullptr || nodeDB->getMeshNode(p->from)->user.public_key.size == 0)) {
	LOG_INFO("PKI packet from unknown node, send PKI_UNKNOWN_PUBKEY");
	sendAckNak(meshtastic_Routing_Error_PKI_UNKNOWN_PUBKEY, getFrom(p), p->id, channels.getPrimaryIndex(),
	routingModule->getHopLimitForResponse(p->hop_start, p->hop_limit));
	} else {
	// Send a 'NO_CHANNEL' error on the primary channel if want_ack packet destined for us cannot be decoded
	sendAckNak(meshtastic_Routing_Error_NO_CHANNEL, getFrom(p), p->id, channels.getPrimaryIndex(),
	routingModule->getHopLimitForResponse(p->hop_start, p->hop_limit));
	}
	} else if (p->next_hop == nodeDB->getLastByteOfNodeNum(getNodeNum()) && p->hop_limit > 0) {
	// No wantAck, but we need to ACK with hop limit of 0 if we were the next hop to stop their retransmissions
	sendAckNak(meshtastic_Routing_Error_NONE, getFrom(p), p->id, p->channel, 0);
	}
	} else {
	LOG_DEBUG("Another module replied to this message, no need for 2nd ack");
	}
	if (p->which_payload_variant == meshtastic_MeshPacket_decoded_tag && c &&
	c->error_reason == meshtastic_Routing_Error_PKI_UNKNOWN_PUBKEY) {
	if (owner.public_key.size == 32) {
	LOG_INFO("PKI decrypt failure, send a NodeInfo");
	nodeInfoModule->sendOurNodeInfo(p->from, false, p->channel, true);
	}
	}
	// We consider an ack to be either a !routing packet with a request ID or a routing packet with !error
	PacketId ackId = ((c && c->error_reason == meshtastic_Routing_Error_NONE) || !c) ? p->decoded.request_id : 0;
	// A nak is a routing packt that has an error code
	PacketId nakId = (c && c->error_reason != meshtastic_Routing_Error_NONE) ? p->decoded.request_id : 0;
	// We intentionally don't check wasSeenRecently, because it is harmless to delete non existent retransmission records
	if (ackId || nakId) {
	LOG_DEBUG("Received a %s for 0x%x, stopping retransmissions", ackId ? "ACK" : "NAK", ackId);
	if (ackId) {
	stopRetransmission(p->to, ackId);
	} else {
	stopRetransmission(p->to, nakId);
	}
	}
	}
	// handle the packet as normal
	isBroadcast(p->to) ? FloodingRouter::sniffReceived(p, c) : NextHopRouter::sniffReceived(p, c);
	}

-> Therefore, the Feature Request as per title ("Do not reply to any broadcast packets with want ack") is already fulfilled, IMO.

@RCGV1 Can you elaborate what's missing?

About broadcasts with want_response:

Some features rely on it, e.g.:

• Initial node discovery when joining a mesh works by sending our own NodeInfo to broadcast with want_response = True, so the nodes around respond with their NodeInfo
• "deliberately sending a ping like when double tapping the button on screenless node to send your position and want a response" does the same thing, but with position packets instead.

Yes, that does cause a lot of traffic, but for a reasonable cause. Especially for initial discovery, I can't think of a good alternative. The cooldown periods for responding to these should make sure it doesn't overload the mesh constantly, no matter how often this is requested.

---

Perhaps the default preset in the USA should just be short_turbo so we can stop removing important features.

Not just in the US.

I'd advocate for having the fastest available preset as the default. Either ShortFast everywhere for consistency/compatibility across regional borders, or ShortFast/ShortTurbo depending on regional laws for maximum resistance to congestion.

If someone really needs increased range/penetration, doing so by using more airtime might as well come at the cost of moving to a different mesh.

IMO that's more reasonable than having to move to a different, incompatible preset because the default preset is unusable due to congestion.

Meshtastic has grown too large for SF11 as a default, and the combination of many nodes, a feature-richness that causes a lot of traffic and a slow default preset is a strategic weakness compared to other LoRa Mesh Projects.

But that's probably not an option before 3.0

[GUVWAF]

Wait, are we talking about want_ack or want_response now?

It seems indeed this issue is about want_response, not want_ack.

I agree that it is of good use in some cases. Maybe we can disallow it for specific portnums, but we should be careful.

[RCGV1]

Sorry I meant want response. I don't believe that want response broadcast packets should be sent at all.

[korbinianbauer]

So what do you say about the listed use cases for it?

[RCGV1]

Nodes should decide when to reply to a unknown nodes node info without a want response. In large meshes these sorts of packets create tons of traffic. I think that want response packets should only be used as directed packets.

[korbinianbauer]

Nodes should decide when to reply to a unknown nodes node info without a want response.

If we just change the flag to false and an arbitrary number of nodes respond anyways, what problem did we solve?

Nodes already decide whether they should respond based on when they sent their NodeInfo last time afaik.

I think that want response packets should only be used as directed packets.

So how does a new Node discover other nodes when joining?