[Bug]: Setting LoRa Advanced max hops not saved to node

[shalberd]

Contact Details

sven.thoms@gmail.com

Checklist

• I am able to reproduce the bug with the latest version.

• I have updated to the latest Alpha firmware, and am able to reproduce the bug. Many issues are fixed quickly in alpha before the general beta release.

• I made sure that there are no existing OPEN or CLOSED issues which I could contribute my information to.

• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.

• This issue contains only one bug.

• I have read and understood the Contribution Guidelines.

• I agree to follow this project's Code of Conduct

• I actually read this list, and should be taken seriously.

Affected app version

2.7.13

Affected Android version

Android 16

Affected phone model

Samsung A54

Affected node model

RAK 4631

Affected node firmware version

2.7.15

Steps to reproduce the bug

• Go to Settings - LoRa - Advanced
• Select a new max hops number from the dropdown list, save button
• Write a new message

Actual behavior

• Check message via Text_Message_App filter category in Debug panel
• Observe that old, previous LoRa max hops setting is still set for field hop_start / hop_limit

Expected behavior

The bug was not present in App 2.7.10, probably not even in 2.7.11.
We have many users reporting the same, inadvertently sending messages with too-low or too-high hop_start / hop_limit because the setting LoRa - Advanced - max hops does not apply on the node.

• Check composed message via Text_Message_App in Debug panel
• new LoRa max hops number setting should be set for field hop_start / hop_limit

Workaround: only when I save and unsave any other field from the LoRa page than max hops, e.g. TX Enabled, is LoRa max hops finally saved to the node and used in new messages.

Screenshots/Screen recordings

No response

Relevant log output

Additional information

No response

[b8b8]

Even though i dont think its related, have you tried the newest firmware? You checked the box that you tried the latest alpha but also wrote 2.7.15 firmware.

[shalberd]

Yes, this happens with Android App 2.7.13 and both on firmware 2.7.15 as well as 2.7.19

Write a message with a given max hops 4. hop_limit and hop_start are set at 4

Change max hops to 3, save, delivery confirmed (to node)

write a new message

hop_limit and hop_start remain at 4, not 3

It is only when a change any other field on the settings page LoRa in the App, like TX enabled, that the dropdown value
for max hops really is applied. Not good, because max hops is such a central setting.

[ujade]

I stepped through with a debugger to make sure the settings get properly sent to the radio a bunch of times and I've been unable to reproduce this error on a T1000-E, but this might be a difference in hardware/app variant.

After you send the new hop limit settings, if you go to Debug panel and filter by ADMIN_APP, does the packet updating the settings contain the proper hop_limit?

[shalberd]

Hi @ujade thank you for your reply.

model: RAK 4631, Firmware 2.7.15 and also 2.7.19, same error

So, I set max hops from 4 to new 5 in the Android app settings:

Delivery confirmed, meaning saved to node:

node id is correct, and yes, the new setting hop_limit 5 and hop_start 5 in the packet data; in the decoded payload updating the packet to my node. However, in the non-decoded payload (mesh packet header?) it says hop_limit=4, hop_start=4!

When I then send out a new composed message, hop_limit and hop_start stays at the previous number 4:

This stays the same when I compose a message 8 minutes later, so it is not an issue with delay in node initialization either.

I noticed that if I update another field, like tx_enabled, to false, then the content of the Admin App packet is different after save:

Now, the Mesh Packet header (not the payload) shows hop_start=5 and hop_limit=5. So now, header AND decoded payload show the correct number for hop_start and hop_limit. And decoded payload shows tx_enabled=false.

Could it be that the cause of the error is a difference between MeshPacketHeader and payload data?

[prokrypt]

I noticed that if I update another field, like tx_enabled, to false, then the content of the Admin App packet is different after save:

could it be a reboot that applies the hops setting?

[shalberd]

Yes, after a reboot, just changing the loRa maxHop setting applies to newly-composed message.

Still ... why is the content of the PacketHeader and payload sent to node different (AdminApp) different for hop_limit and hop_start when I a) change that setting only and b) why is the admin app header updated with the correct value when I edit / change an additonal setting like TX enabled? What role does the AdminApp MeshPacket Header content play in terms of hop_limit and hop_start and its impact on Text_Message_App?

In any case, a reboot should not be necessary and has not been necessary in firmware 2.7.15 before Android App 2.7.13.
I went from Android App 2.7.10 to 2.7.13, others, too, and that is when the problems started.

[shalberd]

could it be a reboot that applies the hops setting?

yes. You sparked my curiosity. I hooked up my node via USB serial and did a config change to LoRa max hops via Web GUI
client.meshtastic.org

After I did that

the node rebooted by itself.

So, is a reboot in fact required for LoRa max hops / hop_start to effectively change? Was that always the case? Why does the app not trigger a reboot?

Side note: I don't think that in previous versions of firmware, e.g. 2.6.11, a reboot of the node was required.

Use case: We have a lot of users, in order to be responsible Mesh citizens, sometimes for a few messages set their max hops limit to 6, then, soon after, set it to 3 or 5 again. Currently, they are not aware that, if they change the max hops sertting on Android, they'd need to manually reboot the node.

[ujade]

The firmware does not mark hop_limit as a setting that requires a reboot. So this does seem like an issue of the app not updating the local app config once those settings are applied, thus maybe not sending the correct packet header info, rather than a firmware issue. When the device reboots and is reconnected to, a getConfig request gets sent to your meshtastic device which returns its config and updates the app's local config. I'm wondering if that's why a reboot fixes it for you.

This is just speculative as I don't know the app & firmware codebases nor packet flow too well yet.

[prokrypt]

I assume the next step is to see if a reconnect will apply the new hops setting...