config: LAN TCP direct to Heltec V4, meshcomod v1.16.0.4.
(this was working w/ direct USB-serial connection to meshcore 1.16; but haven't built a custom meshcore 1.16 wifi firmware yet to see if this is a meshcomod-specifc problem)
Hopefully this log is helpful; I don't see how to correlate the outgoing message to the responses just from the logging.
2026-06-20 23:31:03 outbound message to #dummy, "testing 123".
2026-06-20 23:31:05 ack (or looks to be, from packet analyzer)
2026-06-20 23:31:06 ack (or looks to be, from packet analyzer)
[debug_2026-06-20_193114.json](https://github.com/user-attachments/files/29168945/debug_2026-06-20_193114.json)
config: LAN TCP direct to Heltec V4, meshcomod v1.16.0.4.
(this was working w/ direct USB-serial connection to meshcore 1.16; but haven't built a custom meshcore 1.16 wifi firmware yet to see if this is a meshcomod-specifc problem)
Hopefully this log is helpful; I don't see how to correlate the outgoing message to the responses just from the logging.
* `2026-06-20 23:31:03` outbound message to `#dummy`, "testing 123".
* `2026-06-20 23:31:05` ack (or looks to be, from packet analyzer)
* `2026-06-20 23:31:06` ack (or looks to be, from packet analyzer)
<!-- github-sync-id:4708793292 -->
Hmmm that leads me to be far more suspicious of the firmware not implementing acks correctly than RemoteTerm. I'll take a look.
Hmmm that leads me to be far more suspicious of the firmware not implementing acks correctly than RemoteTerm. I'll take a look.
<!-- github-comment-id:4760457140 -->
Looks like a false alarm. meshcomod HEAD (63e5c6) works. The HEAD commit is a garbage data fix, so that would track.
Looks like a false alarm. meshcomod HEAD (63e5c6) works. The HEAD commit is a garbage data fix, so that would track.
<!-- github-comment-id:4760493118 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
debug_2026-06-20_193114.json
config: LAN TCP direct to Heltec V4, meshcomod v1.16.0.4.
(this was working w/ direct USB-serial connection to meshcore 1.16; but haven't built a custom meshcore 1.16 wifi firmware yet to see if this is a meshcomod-specifc problem)
Hopefully this log is helpful; I don't see how to correlate the outgoing message to the responses just from the logging.
2026-06-20 23:31:03outbound message to#dummy, "testing 123".2026-06-20 23:31:05ack (or looks to be, from packet analyzer)2026-06-20 23:31:06ack (or looks to be, from packet analyzer)Do you ever see ack checkmarks for any message at all?
Before switching to TCP/meshcomod, yes.
After, none for anything.
Hmmm that leads me to be far more suspicious of the firmware not implementing acks correctly than RemoteTerm. I'll take a look.
I'm also suspicious of meshcomod; will try building their latest HEAD, and then try building meshcore.
Looks like a false alarm. meshcomod HEAD (63e5c6) works. The HEAD commit is a garbage data fix, so that would track.
Woot!