This works like a charm … though I don’t seem to be getting the ACK packets. Any way to get access to those as well?
hmm - that’s a good point. ack packets (and all of the routing control packets) are still in the ‘old’ system (pre portnum). The clean answer (and not super hard) is that they should be moved to be just Data packets like everything else. But I was reluctant to make that change because it would require all nodes to upgrade.
Anyone have opinions on this? I’m now kinda thinking that this project is young enough to say “we should just declare 1.2.0 and all nodes on a mesh must be either running something older than 1.2.0 or younger than 1.2.0 - no mixing (because 1.2.0 will change the wire representation slightly)”
This change would be invisible to python api consumers (because I don’t think any of the projects I’ve heard about are ‘sniffing’ ack packets). The android app could in theory be made to work with <1.2.0 builds - but we could also just snapshot an old version and tell people they have to use that if they don’t want to upgrade their nodes.
1 Like
The usage stats are on a hockey stick trajectory. Changes now will be cheaper than changes later. Having access to ACK and the other mesh routing packets would make the Store and Forward plugin that I’m working on just that much more reliable.
1 Like
Where is encryption applied?
Is the contents of data encrypted, and if so, is there value in having ACK packets traverse/be relayed by nodes not having the encryption key for the channel?
Conversely, is there danger in permitting ACK packets from being spoofed, blocked, or altered by nodes not having the encryption key for the channel?
1 Like
From what I’ve seen, the mesh packets are routed by all devices within reach with the same channel configuration, regardless of encryption key.
1 Like
Ack & routing packets etc are outside of the encryption envelope for this reason (so nodes on the same freq could route for even channels they don’t have keys for).
But if we made this change I’d do it along with the (in my WIP branch) multichannel support. In that case we could specify that the routing control messages always go on the “control” channel. Which would normally be a well-known key, but if someone is concerned about fairness or attacks on that channel they could use a different key and it would become private.
4 Likes
(moving to a new thread for visibility)
HI ya’ll,
So we are considering making 1.2 a not backwards compatible release. This would allow us to cleanup the code a bit, and it makes the multichannel feature easier to implement. Anyone have serious objections? The relevant ‘user level’ effects of this choice (if we did it):
-
The ‘normal’ android app release would detect if you any device on your mesh is running an older (<1.2) release and tell you you must upgrade that firmware (using the app). This upgrade process would work all the way back to the 1.0 release, so in the case of folks buying “preinstalled” meshtastic devices they would be prompted to do this upgrade.
-
Users of the python API probably wouldn’t have to change anything (other than updating the python lib with pip3 upgrade.
-
Users of the android api (@paulmandal) probably wouldn’t have to change anything (other than updating the android app)
-
People who have installed ‘remote’ nodes that are hard to physically reach to upgrade would have to stay on 1.1.48 until they can upgrade that node. To support these (small) number of users, we’d archive the 1.1.48 version of the android app as an APK on github.
-
This would probably be the last protocol breaking change for at least the year. Possibly longer - protobufs usually provide us easy backwards compatibility.
-
This would probably occur in next weeks release.
Thoughts?
6 Likes
As noted, it’s much easier to change things earlier as opposed to later, and the project is very young. Break it early, break it often! 
As long as the protocol is changing, may as well add in some of the other tweaks that have been floated: Location options - #5 by geeksville
Is now a good time to implement a version field somewhere within the 4 bytes of the packet header flags?
4 Likes
A switch to 1.2.0 would be a good opportunity for destructive refactoring.
Completely agree about saving 2 bytes for the location options.
That’s 0.2 seconds of airtime on the Long Slow setting. Another way of thinking of it, if there are 10 nodes on the mesh, those 2 bytes will be 1.1% of the total capacity of the selected frequency for the entire mesh network. That adds up quick.
7 Likes
ok - I’ll start this refactoring in a new branch - I’ll post a link here once it is ready. I’ll do it as part of the multi-channel support.
For the first couple of releases we might make minor tweaks if I missed anything.
3 Likes
I see packets that are discarded because a node has repeated it and we’ve already seen that packet id.
Could the refactoring also provide access to those packets along with who forwarded it and not just the original from? Pretty please 
1 Like
Any chance of adding super long range/very slow to the Android app
1 Like
Please add the option to increase hop_limit. Thanks
4 Likes
hop limit can already be increased (just no UI in the android app for it)
1 Like
hmm - I think it is already in there, but I’ll check.
2 Likes
Thanks geeksville really want to set a longer range record for a successfully transmitted message.
(Meaning the 160db link budget setting)
https://github.com/mc-hamster/Meshtastic-device/blob/master/docs/radio-settings.md
A switch to 1.2.0 would be a good opportunity for destructive refactoring.
Indeed. It could be a good to introduce other potentially breaking changes on the feature roadmap if feasible. Better to break once, right?
2 Likes
Now feels like a good time to do this. It will only get harder for new users.
Currently ‘permanent’ routers seem few and far between, and most people using them seem to still be in the test and improvement stage of development and use.
From what I’ve read the people that wanted to leave a long term node in remote places did not manage to stand up a network that was ready to meet local needs.
@luandro, this could be a deep impact on your setup in the savannah in Brazil. I just want to make sure that you are aware of this change once it will be implemented. Be careful on your risky expeditions!
2 Likes
Really appreciate the heads up @drewsed! But it’s no problem. I just reveiced word today that they’re taking down all the nodes we’ve setup because of lightning storms. So we’ll have to reboot the network on a next visit anyways.
And as @Spor7biker said, we’re still not at a point of meeting local needs. Hopefully next time!
Great job everyone! Looking forward to testing this new version.
3 Likes