[Bug]: CLIENT_MUTE never sends NodeInfo packets

[0x5c]

Category

Other

Hardware

Other

Firmware Version

2.5.14.f2ee0df and 2.5.18.89ebafc

Description

When set to CLIENT_MUTE, my node never sends a nodeinfo packet. Whereas it reliably sends one within minutes of being set to CLIENT, and at every nodeInfoBroadcastSecs.

Tested on a Heltec Capsule Sensor v3, with nodeInfoBroadcastSecs: 3600 (and also default), both left to its own for hours and with attempts at getting an early nodeinfo broadcast by having it forget a nearby active node.

Relevant log output

[garthvh]

https://meshtastic.org/blog/choosing-the-right-device-role/#client-mute

[0x5c]

Isn't NodeInfo something the node should be able to originate itself? To be clear, I am talking of the NodeInfo packet that allow that node to have others know it exist, not rebroadcasted NodeInfo messages.

As far as the docs say, it seems that the behaviour of not originating NodeInfo message is supposed to be specific to CLIENT_HIDDEN and REPEATER.

[GUVWAF]

There is only one place in the code where CLIENT_MUTE is used (except for its definition) and that's at the place it decides to rebroadcast: https://github.com/search?q=repo%3Ameshtastic%2Ffirmware%20CLIENT_MUTE&type=code
The setting doesn't affect NodeInfo broadcasts.

Are you sure you have other settings, like channel key and name, unchanged? Does normal messaging work?

[0x5c]

There is only one place in the code where CLIENT_MUTE is used (except for its definition) and that's at the place it decides to rebroadcast: https://github.com/search?q=repo%3Ameshtastic%2Ffirmware%20CLIENT_MUTE&type=code

Yeah I searched the code and couldn't see anything that could potentially have been relevant, glad to know I wasn't just lot there

Are you sure you have other settings, like channel key and name, unchanged? Does normal messaging work?

The LoRa/etc settings weren't knowingly changed, and from comparing the settings of a different -perfectly working- node it seems they were indeed not changed.
Other than the lack of NodeInfo broadcast, most things work normally; default unchanged ch0 LongFast messages, traceroutes, receiving other node's NodeInfo messages.
Some things don't work, like power/environment telemetry broadcast, and sending DMs (that might be a key issue?), and of course the NodeInfo broadcasts

I have done a full factory-reset of the node, and it has not affected the persistence of the issue

Edit: normal power/environment telemetry works, I had misread the delay value

[0x5c]

@thebentern What makes this not a bug?

[0x5c]

I did look closer after sending that, there's 6 very small plated holes on a side of the PCB, they're sized small enough I might be able to jam small wires in there and get a good enough connection. If that works that should be safe enough.

I don't have another capsule sensor to attempt to reproduce this with, but I'll try a Heltec v3 later.

[GUVWAF]

You can also set up an Rsyslog server and set its address in network.rsyslog_server if that's easier.

[GUVWAF]

Removing the client_mute from the NodeDB of another node I own, and waiting multiple times the NodeInfo broadcast delay for it to appear in the node list. Each testing run lasted 3+ hours, and ended without the other node knowing the identity of the client_mute.

By the way, using the iOS app, for example, sometimes I have to disconnect and reconnect the Bluetooth connection before NodeInfos are updated in the list.

[0x5c]

Ok I got to the header, and wires do fit in there. There's however no output. Is there a config I should be enabling to get something to show up on those data lines? And to get the actual debug logs, do I need a specific CLI flag or just a serial terminal?

By the way, using the iOS app, for example, sometimes I have to disconnect and reconnect the Bluetooth connection before NodeInfos are updated in the list.

That was accounted for on both the MUTE node (only interaction is CLI over bluetooth: full reconnect all the time) and the normal one (wifi in app, frequent reconnections)

[GUVWAF]

Is there a config I should be enabling to get something to show up on those data lines?

No, by default it's enabled and you should see it on a serial monitor using baud 115200, or the CLI command --noproto. At least that's how it works for other boards, I don't know if the pins you're using is for the regular Serial output of the Capsule.

BTW, my T-Beam on CLIENT_MUTE also sends NodeInfo on its configured 3-hour interval:
10832 [NodeInfo] Send our nodeinfo to mesh (wantReplies=0).

[SimbimChimbetov]

I had similar problems with two Nodes (Rak4631) not sending their Node info when I Changed the Rebroadcast Mode to "Core Portnums"
When I switched back to "All" or "Local Only" it started Rebroadcasting its Node info regularly.

[0x5c]

What firmware version(s)? And did you have nodes of that model successfully broadcast their NodeInfo in "Core Portnums" mode?

[SimbimChimbetov]

Fw 2.5.15 on two nodes, both same issue.
I have one node with 2.5.18 as a Router, I can test it later.

[SimbimChimbetov]

So all three Nodes,
as soon as I switch to Core Portnums only, they stop broadcasting node info. Tested in ROUTER and CLIENT mode.
I'm managing the nodes via Remote on Android App 2.5.16