[Bug]: TAK Server still advertises 0.0.0.0:4242:tcp endpoint after 2.7.14 fix for directed GeoChat routing

[kd2var]

Contact Details

farpoint16@aol.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.14 (29321034) F-Droid using with ATAK version 5.6.0.18 (f4cee7b9) and ATAK plugin 1.1.42 (52cc9e1c)

Affected Android version

16

Affected phone model

Samsung Galaxy A15 5G

Affected node model

Heltec v3

Affected node firmware version

2.7.26

Steps to reproduce the bug

1. Install Meshtastic Android app version 2.7.14 (29321034) from F-Droid.
2. Connect a Meshtastic node and enable the built-in TAK Server.
3. Import the Meshtastic TAK Server data package into ATAK.
4. Connect ATAK 5.6.0.18 using the Meshtastic TAK Plugin.
5. Open a Meshtastic contact in ATAK and view Contact Details.
6. Observe that the contact endpoint is still displayed as 0.0.0.0:4242:tcp instead of *:-1:stcp.

Actual behavior

ATAK receives Meshtastic contacts and PLI/location updates, but the contact endpoint remains:

0.0.0.0:4242:tcp

The expected endpoint after the TAK server fix (#5661) is:

*:-1:stcp

Because the endpoint remains incorrect, directed TAK-Talk/GeoChat messages do not route back through the Meshtastic mesh.

Expected behavior

The Meshtastic TAK Server should advertise the contact endpoint as:

*:-1:stcp

ATAK should use this endpoint so directed TAK-Talk/GeoChat messages are routed back through the Meshtastic mesh instead of attempting to connect directly to 0.0.0.0:4242:tcp.

PLI/location updates should continue to work, and directed messages should be delivered through the mesh.

Screenshots/Screen recordings

Relevant log output

Additional information

Additional information:

The fix referenced in #5661 appears to be included in the 2.7.14 release notes:

fix(takserver): emit *:-1:stcp contact endpoint so directed TAK-Talk/GeoChat routes over the mesh by @thebentern in #5661

However, after installing Meshtastic Android 2.7.14 (29321034) from F-Droid, the generated ATAK contact endpoint is still:

0.0.0.0:4242:tcp

I re-exported and re-imported the Meshtastic TAK Server data package and also manually recreated the ATAK server connection. The behavior did not change.

The Meshtastic TAK Server is enabled and ATAK is receiving nodes/PLI correctly. The issue appears limited to the advertised contact endpoint used for directed TAK-Talk/GeoChat routing.

Attached:

• Screenshot of ATAK contact details showing 0.0.0.0:4242:tcp endpoint
• Screenshot of fix(takserver): emit *:-1:stcp contact endpoint so directed TAK-Talk/GeoChat routes over the mesh #5661 change showing the expected *:-1:stcp endpoint change

[kd2var]

Additional testing:

The same behavior was reproduced on two separate Android devices:

• Samsung Android phone
• Revvl Android tablet

Both devices showed the same TAK contact endpoint:

0.0.0.0:4242:tcp

instead of the expected:

*:-1:stcp

Both were running:

• Meshtastic Android 2.7.14 (29321034) F-Droid
• Meshtastic TAK Plugin 1.1.42
• ATAK 5.6.0.18

[jamesarich]

Triage note: this app's embedded TAK server already emits *:-1:stcp for the CoT contact endpoint (fix #5661 — TAKDefaults.DEFAULT_TAK_ENDPOINT), so app-generated contacts should carry the corrected endpoint.

Your repro path is the Meshtastic TAK Plugin 1.1.42 + the node firmware's built-in TAK server. In that flow the CoT shown to ATAK is generated by the plugin/firmware from TAKPackets, not by this app's TAK server — a separate codebase.

Could you confirm whether 0.0.0.0:4242:tcp appears for contacts generated by this app's TAK server, or only via the plugin/firmware path? That determines whether this stays here or should move to the plugin/firmware repo.

[kd2var]

Update on testing:
I performed additional testing to determine whether the incorrect endpoint is coming from the Android integrated TAK server or the ATAK plugin path.
I unloaded the Meshtastic ATAK plugin and restarted ATAK.

The integrated TAK server was still enabled and running.

With the plugin unloaded, I do not see any Meshtastic CoT contacts appearing in ATAK.

With the plugin loaded:

Meshtastic contacts appear normally.
The contact endpoint is still generated as:
0.0.0.0:4242:tcp

I also tested changing the Meshtastic node role:

CLIENT role: same behavior
TAK role: same behavior when using the plugin

This leads me to believe the Meshtastic ATAK plugin is the component generating/injecting the Meshtastic CoT contacts, and the integrated TAK server may only be providing the TAK transport/server functionality rather than generating Meshtastic CoT itself.

My question is: Is the expected behavior that the integrated TAK server alone should generate Meshtastic CoT contacts, or is the ATAK plugin still required to convert Meshtastic node data into CoT?
If the plugin is still responsible for generating Meshtastic CoT, then it appears the incorrect endpoint (0.0.0.0:4242:tcp) is likely coming from the plugin/firmware path rather than the Android TAK server fix.

[kd2var]

I have another question regarding the intended function of the integrated TAK server.

Is the goal of the integrated TAK server to act primarily as a transport layer for ATAK CoT traffic using Meshtastic nodes configured with the TAK role, or is it intended to function similarly to the ATAK plugin by translating normal Meshtastic contacts into CoT events for display in ATAK?

My use case for ATAK is as a situational awareness hub with multiple data sources feeding into one map. One of the capabilities I was using the plugin for was visualizing Meshtastic nodes in my area as ATAK contacts and, if needed, communicating with them through ATAK.

Based on my testing, with the plugin unloaded I do not see Meshtastic contacts in ATAK even though the integrated TAK server is running. This makes me wonder if the new TAK server architecture is intended to separate TAK transport from Meshtastic node visualization.

If the integrated TAK server is not intended to provide the same functionality as the plugin for displaying Meshtastic nodes, I would like to understand that so I can adjust my setup and expectations accordingly.

[jamesarich]

Thanks for the follow-up testing — that was exactly the right experiment, and your conclusion is correct on both counts. Here's what we found tracing it through the code.

The endpoint is never carried over the mesh

This is the part that reframes the bug. As of the shared TAKPacket-SDK, the contact endpoint is stripped on parse and re-synthesized on rebuild:

• Parse: CotXmlParser normalizes both 0.0.0.0:4242:tcp and *:-1:stcp to empty, so the endpoint never crosses LoRa.
• Rebuild: CotXmlBuilder re-emits *:-1:stcp whenever the field is empty — the TAK "reply via this server" form. That is what makes ATAK route directed GeoChat and TAK-Talk (<marti>) back down the server connection. 0.0.0.0:4242:tcp points ATAK at a direct connection that doesn't exist on a mesh-relayed contact, so directed messages silently never reach the mesh.

So 0.0.0.0:4242:tcp in your ATAK is a property of whichever component rebuilt the CoT XML for display — in your repro, Meshtastic TAK Plugin 1.1.42, which predates the SDK. It is not a stale value propagating from your node or from this app.

The fix path isn't a one-line patch in the plugin: any component that adopts takpacket-sdk inherits the correct endpoint for free, across all five language bindings (Kotlin, Swift, Python, TypeScript, C#). That SDK is the new direction for TAK conversion generally — it exists so the app, the plugin, Apple, and the firmware tooling all share one tested CoT ↔ TAKPacketV2 implementation instead of each maintaining their own.

Your architectural read is right, and it's a real gap

Is the expected behavior that the integrated TAK server alone should generate Meshtastic CoT contacts, or is the ATAK plugin still required?

Today, the plugin is still required for that, and you diagnosed why correctly. The in-app TAK server subscribes only to ATAK_PLUGIN (port 72) and ATAK_PLUGIN_V2 (port 78) traffic. Every CoT it hands to ATAK originates from a TAKPacket already on the mesh. Nothing subscribes to the node database, so regular Meshtastic nodes are not surfaced as ATAK contacts. With the plugin unloaded, seeing no Meshtastic contacts is current expected behavior — not a misconfiguration on your end.

The intent is for the in-app server to replace the plugin, so this is a gap rather than a deliberate split of responsibilities. The converters for it already exist in the codebase (Position.toCoTMessage() / User.toCoTMessage() in CoTConversion.kt) — they're simply not wired to the NodeDB yet. Note the SDK doesn't close this one for us: it converts CoT XML ↔ TAKPacketV2, and a Meshtastic NodeInfo isn't a CoT event, so the synthesis is app-side work.

Disposition

• Endpoint bug: belongs with the plugin, and is resolved there by adopting takpacket-sdk rather than by a local patch.
• NodeDB → CoT contacts: we'll track as a separate feature issue on this repo once the questions above are settled.

Leaving this open until @garthvh and @thebentern weigh in.

[jamesarich]

Follow-up: I checked how Meshtastic-Apple handles this, and it narrows the question above considerably — Apple already ships mesh-to-CoT synthesis, so this is an Android gap specifically, not an undecided design question.

What Apple does today

TAKMeshtasticBridge.swift implements the capability you're asking for:

	Apple's behavior
Gating	Opt-in. takServerMeshToCot, defaults to off. Settings toggle: "Mesh to CoT Converter — Bridge Meshtastic positions, nodes, waypoints, and messages to TAK/CoT format"
Node filter	Nodes with user info, lastHeard within the last 2 hours, and a valid non-zero position. Your own connected node is excluded
Scope	Broader than nodes alone — mesh positions, text messages, and waypoints all become CoT
Cadence	Full node replay whenever a TAK client connects, plus incremental broadcasts as positions / messages / waypoints arrive

Their per-node CoT (createCoTFromNode) emits uid MESHTASTIC-<nodenum-hex>, callsign "SHORT - Long Name", team Green, role Team Member, a 15-minute stale, and remarks carrying battery, voltage, channel utilization, RSSI, and SNR.

That is a close match for your use case: Meshtastic nodes on the ATAK map as contacts, opt-in so users who only want TAK transport aren't opted into a map full of mesh nodes.

What this means for Android

The capability is missing on Android, and you'd still need the plugin for it today. But it's now a port of a shipped, field-tested feature rather than a design question — which makes it a much more tractable piece of work.

Worth noting: this synthesis path deliberately does not go through takpacket-sdk. Synthesized node CoT travels app → ATAK only and never crosses the mesh, so there's nothing to compress or wire-optimize. The SDK stays responsible for CoT ↔ TAKPacketV2 on the mesh path; node visualization is purely local. So the two workstreams are independent.

Revised question

@garthvh @thebentern — replacing the three open questions in my comment above, since Apple has effectively answered them:

1. Should Android match Apple's behavior and defaults as-is (opt-in, 2-hour / position-bearing filter, replay-on-connect, same uid and callsign format)? My inclination is yes — two platforms behaving identically against the same mesh is worth more than re-tuning the parameters independently.
2. Anything learned in the field that Android should change rather than copy? The 2-hour window and the full replay on every client connect are the two I'd most want a second opinion on before duplicating them.

@kd2var — thanks again for the careful testing. It turned what looked like a misfiled endpoint bug into a well-scoped platform gap.

[kd2var]

Just my 2 cents there are a lot of people that I know that use the Meshtastic/ATAK integration in the same way I do. Being able to see all Meshtastic nodes in ATAK was expected behavior if you left the node role as client and installed the plugin. I think a toggle would be a compromise. If someone wants it to be a TAK only data picture they can toggle all nodes off and if someone has a similar use case to mine they can toggle all nodes on. One other thing now that I have my node role set to TAK I am trying to set my team color and role but when I save it the node reboots and when it reconnects the color and team are not saved it says unspecified again.

[jamesarich]

Did some digging - looks like providing nodes, waypoints, etc is a gap in the Android implementation - following up with new issue referencing Apple for spec and waiting on upstream confirmation.

[jamesarich]

One other thing now that I have my node role set to TAK I am trying to set my team color and role but when I save it the node reboots and when it reconnects the color and team are not saved it says unspecified again.

this sounds like a different issue entirely, if you could write that up and include details/logs there - that would be helpful.

[jamesarich]

@niccellular booping you here as well, in case you have any insight

[kd2var]

I agree that matching the Apple implementation makes the most sense. The opt-in toggle is a good compromise because it allows users who only want TAK transport to keep the map clean, while users who use ATAK as a situational awareness hub can enable mesh-to-CoT.
The filters Apple is using also seem reasonable. The only area I would consider adjusting is the stale time. For mobile/handheld nodes, the 2-hour window makes sense, but fixed infrastructure nodes (solar roof nodes, repeaters, etc.) may intentionally broadcast less frequently to conserve power. For example, a solar node configured to send position every 3-4 hours would disappear from ATAK even though it is functioning normally.
It may be worth considering either:
a longer stale timeout for infrastructure-type nodes, or
a configurable stale time in the mesh-to-CoT settings.
Otherwise, I think matching Apple’s behavior across platforms is the right approach.

[niccellular]

@niccellular booping you here as well, in case you have any insight

sorry i've been MIA, still moving.