Bump minimum NodeInfo send to 5 minutes

[thebentern]

What do we think about this change to combat some of the excessive chattiness of NodeInfo on larger meshes?

[github-actions]

🤖 Pull request artifacts

empty string

file	commit
firmware-2.3.1.b04beaa.zip	b04beaa

[andrekir]

considering the flood expire time of 10 minutes, 3 min is very reasonable. maybe could even bump it up to 5.

[garthvh]

Why not the whole 10?

[GUVWAF]

I don't think we should set it too high, it's a bit annoying for first-time users if you have to wait a while before a node shows up in your node list if you start up one after the first sent out its initial NodeInfo.

[thebentern]

Survey time? 😄
Thumbs up this comment for 3 minutes
Thumbs down this comment for 5 minutes

[andrekir]

I'm fine with either 3 or 5 minutes. no real preference.

firmware/src/mesh/MeshService.cpp

Lines 92 to 93 in 13cc1b0

	LOG_INFO("Heard a node on channel %d we don't know, sending NodeInfo and asking for a response.\n", mp->channel);
	nodeInfoModule->sendOurNodeInfo(mp->from, true, mp->channel);

something else we should consider is always sending NodeInfo to NODENUM_BROADCAST, instead of DMs.

[garthvh]

I'm fine with either 3 or 5 minutes. no real preference.

firmware/src/mesh/MeshService.cpp

Lines 92 to 93 in 13cc1b0

	LOG_INFO("Heard a node on channel %d we don't know, sending NodeInfo and asking for a response.\n", mp->channel);
	nodeInfoModule->sendOurNodeInfo(mp->from, true, mp->channel);

something else we should consider is always sending NodeInfo to NODENUM_BROADCAST, instead of DMs.

Yeah I fixed this the other day because it was making it seem like some nodes were on the wrong channel

[GUVWAF]

I'm also fine with either 3 or 5 min.

In the specific case Andre linked I think it makes sense to send the NodeInfo as DM, because we request a response from the unknown node, we don't want everyone to respond.

[andrekir]

In the specific case Andre linked I think it makes sense to send the NodeInfo as DM, because we request a response from the unknown node, we don't want everyone to respond.

for sure, we would send to NODENUM_BROADCAST and wantReplies false. unless we really need a response. otherwise as a DM we would only reply to one single node every 3-5 minutes.

[GUVWAF]

Yeah, makes sense to only set lastSentToMesh when it's a broadcast.

[thebentern]

Could we make NodeInfo DMs (or maybe they already are and I missed it) read promiscuously as long as we can decode? That way, if I send a DM to interrogate NodeInfo only for a specific destination node that I don't know yet, any observers still would also get the benefit of observing that (but not rebroadcasting).

[garthvh]

Could we make NodeInfo DMs (or maybe they already are and I missed it) read promiscuously as long as we can decode? That way, if I send a DM to interrogate NodeInfo only for a specific destination node that I don't know yet, any observers still would also get the benefit of observing that (but not rebroadcasting).

Yeah I was already able to decode them, I just was not expecting a dm

[andrekir]

Could we make NodeInfo DMs (or maybe they already are and I missed it) read promiscuously as long as we can decode?

I like that. we could finally use sniffReceived().

firmware/src/mesh/Router.cpp

Lines 282 to 289 in e27f029

	/**
	* Every (non duplicate) packet this node receives will be passed through this method. This allows subclasses to
	* update routing tables etc... based on what we overhear (even for messages not destined to our node)
	*/
	void Router::sniffReceived(const meshtastic_MeshPacket *p, const meshtastic_Routing *c)
	{
	// FIXME, update nodedb here for any packet that passes through us
	}