Capture last Physical IP ?

[n9yty]

Is it possible to capture and show the last connected "Physical IP" for nodes? On the ZeroTier hosted controller this remains in the list but on ztnet once they disconnect it goes to "Unknown".

[sinamics]

Yes, its possible. We could store the last known IP in Database.

[n9yty]

Similar to my other request on the status update, it would be great if this could be implemented whenever you are working on the project. It is not a functional problem so there is no urgency, although it would be nice to have it.

[sinamics]

@n9yty If you get time, could you test docker build main-1bc117a ?
https://github.com/sinamics/ztnet/releases/tag/untagged-ff10065626c8e6d9fd88

Important: Do not test in production, use a test environment.

[n9yty]

I get a 404 error using that link

I tried to take the repo and build a new docker image, but I get this:

--------------------
  79 |     # https://nextjs.org/docs/advanced-features/output-file-tracing
  80 |     COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
  81 | >>> COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
  82 |     COPY --from=builder --chown=nextjs:nodejs /app/prisma ./prisma
  83 |     COPY --from=builder --chown=nextjs:nodejs /app/init-db.sh ./init-db.sh
--------------------
ERROR: failed to solve: failed to compute cache key: failed to calculate checksum of ref 10ecf2de-7e4a-4864-a0b8-e8b0aa401b56::2v6vvxilrnh5d1909chm78bu1: "/app/.next/static": not found

I am not at all familiar with the nextjs stuff to debug it. But I tried...

I found that I could change the build output to "plain" and found another error:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

Trying to build it on a limited cloud compute node so that is likely the problem.

Added some swap and added this environment variable to the build phase:

NODE_OPTIONS="--max-old-space-size=1024

It builds now, will work on testing. Whew. :)

[n9yty]

Quick test results... Since I have a dual path to all nodes, I connected to one and had it leave the ztnet network. It still shows as having a DIRECT connection in the ztnet GUI after quite a while. I saw recent changes about a 5-minute checking interval but it has been considerably longer. I will test more, if you have anything specific to test let me know.

Of course right when I hit send, I clicked on the OPTIONS box and it caused the page to update. The node status went to RELAYED, the IP remains in the display. Also a few other nodes are now also showing the same thing as RELAYED while on the zerotier network status page they show offline.

Thinking there may be some weird cross network routing going on, since both run through a LAN gateway, I took the node off both zerotier networks and now it shows offline in ztnet and the IP address field is "Unknown".

[sinamics]

Thank you for the feedback.

I connected to one and had it leave the ztnet network. It still shows as having a DIRECT connection in the ztnet GUI after quite a while.

When you disconnect a node, it takes about 20 minutes for it to disappear from the ZeroTier controller's listpeers. This delay is just how ZeroTier works, I'm not sure why it takes so long.

I will test more, if you have anything specific to test let me know.

I just wanted to test the physical IP and the background worker keeping the "lastseen" correct even if user is offline.
But as you pointed out, there is a bug in the physical ip, will look into that.

Of course right when I hit send, I clicked on the OPTIONS box and it caused the page to update. The node status went to RELAYED, the IP remains in the display. Also a few other nodes are now also showing the same thing as RELAYED while on the zerotier network status page they show offline.

Will look into that.

[sinamics]

When a node is online with active peers, it appears as online across all networks in ztnet controller, without distinction. This is markedly different in ZeroTier Central, which effectively differentiates each node online status between networks, likely through backend mechanisms such as pinging or sophisticated status tracking systems.

Ztnet relies on zerotier-cli listpeers to ascertain online connectivity, this is lacking a network-level peer capability.

So until we have a smarter way of determine online status, there will be discrepancies between ZeroTier Central and Ztnet.

Others has asked the same without answer:
https://discuss.zerotier.com/t/listing-peers-per-network/17601

[n9yty]

Thanks for that clarification, and I suspected as much. I don’t see it as a problem worth spending the time to try to resolve as much as I was just reporting it as an observation.I appreciate the time  you invested to research it.On Mar 11, 2024, at 9:06 AM, Bernt Christian Egeland ***@***.***> wrote: When a node is online with active peers, it appears as online across all networks in ztnet controller, without distinction. This is markedly different in ZeroTier Central, which effectively differentiates each node online status between networks, likely through backend mechanisms such as pinging or sophisticated status tracking systems. Ztnet relies on zerotier-cli listpeers to ascertain online connectivity, this is lacking a network-level peer capability. So until we have a smarter way of determine online status, there will be discrepancies between ZeroTier Central and Ztnet. Others has asked the same without answer: https://discuss.zerotier.com/t/listing-peers-per-network/17601 —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[n9yty]

By the way, this seems to be working great! Thanks for handling it so quickly!! I am on a github clone/self-built release, so if this isn't released yet it is only a matter of time. :)