owntracks/ping/ping

[theorician]

Hi! Thanks for all your hard work.

Is there a way to disable the owntracks/ping/ping end to end test? It seems like this comes from the iOS app, and that's extra mobile data that I don't want to see being sent out uselessly. I've verified everything works, so I have no need for the end to end test.

[jpmens]

The ping test is something that's not used by our apps; rather it's something you can use to monitor Recorder availability.

Please do not confuse ping/ping with iOS' t:p type. The former can be used by monitoring software, the latter is something which we send out to indicate iOS has woken up the app. And, no, it cannot be disabled in our iOS app, but it shouldn't really be necessary: we send out very few of these pings.

[theorician]

Thanks for the fast reply!

Just for clarification, I've installed the Docker container and the iOS app. I think I'm confused as to where this comes from. I'm referring to the fake device that seems as though it's in the East End of London. Looking at the recorder live map it seems as though it updates every 30 seconds. The docker confirm this (from docker logs -f <owntracks container>):

* 12:24:00 owntracks/ping/ping                 t=  tid=pp loc=51.47879,-0.01068 [GB] 233-243 Greenwich High Rd, London SE10, UK (gcpuzg2)
* 12:24:31 owntracks/ping/ping                 t=  tid=pp loc=51.47879,-0.01068 [GB] 233-243 Greenwich High Rd, London SE10, UK (gcpuzg2)
* 12:25:01 owntracks/ping/ping                 t=  tid=pp loc=51.47879,-0.01068 [GB] 233-243 Greenwich High Rd, London SE10, UK (gcpuzg2)
* 12:25:31 owntracks/ping/ping                 t=  tid=pp loc=51.47879,-0.01068 [GB] 233-243 Greenwich High Rd, London SE10, UK (gcpuzg2)

If these only originate from the recorder and do a "local" round trip (i.e. only within the Docker container) then I can live with it, it doesn't bother me much. But if these get sent out from my iOS device every 30 seconds, well, in some countries, data is really expensive... ;) As far as I can see, these do come from my phone, as there's none when my phone is in airplane mode.

Sorry if I'm barking up the wrong tree!

[jpmens]

As soon as you said Docker and East End of London I realized where this is coming from; forgive me, please, for not having noticed earlier. This is, indeed, monitoring which was added to the Docker image in recorder-health.sh. What this basically does is it allows Docker to monitor the Recorder's availability in HEALTHCHECK.

So, the ping/ping is being used between Docker and the container running the Recorder and have absolutely no impact on mobile data.

And yes, in some countries mobile data is very expensive! One of the things we've worked hard on is to try and avoid gratuitious use of it. You say the ping/ping comes from your phone: this is not possible.

[theorician]

You say the ping/ping comes from your phone: this is not possible.

Fantastic. In that case all is well!

Thanks so much for all your help here and on the other tickets! I'll close this one now.

[joshproehl]

I've been wondering where ping/ping was coming from for a while now, happy to see this documentation!

I'd like to follow up on this to find out if there are plans to monitor via another method, or perhaps allow customization of the ping/ping user? Reason being that I'd really like to use the auto-zoom feature on the map, and since I'm not in London it makes the autozoom rather useless. :-) I'd prefer not to have anything other than my devices on the map, but locating ping/ping on the physical location of my server would be a possible alternative.

I'm happy to work on a PR if needed, I just didn't want to go the wrong direction.

[jpmens]

I don't think that has anything to do with ping/ping.

If you want to work on a PR which allows a flag to set autozoom & co, go for it. There one other open request which you might want to look at.

[joshproehl]

@jpmens I didn't mean to focus on the autozoom feature, sorry. (although autozoom on the map in my recorderd instance does seem to work in that it always zooms to include all my devices + london...)

I suppose this report may belong in the recorderd repo. The issue is that I don't want to have to filter ping/ping out of API results in downstream tools, or to have it show up on the map/list if using recorderd directly. (Especially if it is behaving differently when used in docker vs when used standalone)

If having a ping/ping user in London on all recorderd maps/API-results is not an intended feature I figured there are a couple of directions to look: 1) ping/ping is not a real user/device, and not be treated as such in recorder (logged, positioned, etc...) 2) docker should not create a ping/ping user with an arbitrary position in order to do a health check. 3) Other?

I just didn't want to go any particular direction with a PR without knowing which way to go. :-)

[jpmens]

Pardon the possibly stupid question: are you saying that you have positions of the ping/ping user on the map ~and in the Recorder's .rec files~? That should certainly not be happening. Recorder is typically being built with WITH_PING defined and that catches ping/ping and should make Recorder ignore that "user/device" combination. To the best of my knowledge, we compile Recorder for docker likewise.

Looking back up in the issue I now feel like a fool: it turns out I may have been misunderstanding all allong.

[jpmens]

Answering my own question: yes, you are saying that.

This is a bug, and I've marked this issue appropriately.

[joshproehl]

Ah, well that answers that question! :-) Sorry for not communicating the problem more clearly the first time!

It sounds like you're reproducing this issue successfully, but just in case: Yes. ping/ping shows up on the map and in the devices table.

If there's anything else I can do to help please don't hesitate to ask!

[jpmens]

Packages have been built, and our recorderd docker image updated.