Closed whmoorejr closed 3 weeks ago
ckrey
commented
3 months ago kCFGetAddrInfoFailureKey=8 means the hostname you were trying to connect to couldn't be resolved.
Did you change your hostname? Any chance you accidentally edited the hostname in Settings?
ckrey
commented
3 months ago The log shows only the 30 seconds before you loaded the new config. When you uninstall the app, all logs are deleted too.
ckrey
commented
3 months ago Is it possible you accidentally loaded the same config on two devices? If two devices have the same MQTT clientID, the MQTT broker kicks them out
whmoorejr
commented
3 months ago I'm about 99% sure I didn't use the same config for another device. Sorry... copied the log in the wrong direction.... looking at the log more recently... this is all I see....
2024-03-28T17:42:13.043Z [LocationManager] set monitoring=-1
2024-03-28T17:42:39.439Z [Connection] idle
2024-03-28T17:43:22.551Z [OwnTracksAppDelegate] applicationWillResignActive
2024-03-28T17:43:22.557Z [OwnTracksAppDelegate] applicationDidEnterBackground
2024-03-28T17:43:22.558Z [Connection] disconnect
2024-03-28T17:43:22.558Z [Connection] state closing (4)
2024-03-28T17:43:22.558Z [Connection] connection closed MQTT eventCode: (2) (null)
2024-03-28T17:43:22.558Z [Connection] state closed (5)
2024-03-28T17:43:22.558Z [Connection] state starting (0)
2024-03-28T17:43:50.314Z [Connection] idle
2024-03-28T17:43:52.592Z [OwnTracksAppDelegate] applicationDidBecomeActive
2024-03-28T17:43:52.592Z [Connection] connectToLast
2024-03-28T17:43:52.592Z [Connection] state connecting (1)
2024-03-28T17:43:52.602Z [LocationManager] startBackgroundTimer
2024-03-28T17:43:52.713Z [Connection] connected MQTT eventCode: (0) (null)
2024-03-28T17:43:52.713Z [Connection] connected sessionPresent 0
2024-03-28T17:43:52.713Z [Connection] state connected (3)
2024-03-28T17:43:55.623Z [OwnTracksAppDelegate] connectionOff
2024-03-28T17:43:55.623Z [Connection] disconnect
2024-03-28T17:43:55.623Z [Connection] state closing (4)
2024-03-28T17:43:55.624Z [Connection] connection closed MQTT eventCode: (2) (null)
2024-03-28T17:43:55.624Z [Connection] state closed (5)
2024-03-28T17:43:55.624Z [Connection] state starting (0)
2024-03-28T17:43:55.631Z [LocationManager] set monitoring=-1
2024-03-28T17:43:55.633Z [LocationManager] set monitoring=-1
2024-03-28T17:43:55.636Z [LocationManager] set monitoring=-1
2024-03-28T17:43:55.646Z [OwnTracksAppDelegate] reconnect
2024-03-28T17:43:55.646Z [Connection] disconnect
2024-03-28T17:43:55.646Z [Connection] state closing (4)
2024-03-28T17:43:55.647Z [Connection] connection closed MQTT eventCode: (2) (null)
2024-03-28T17:43:55.647Z [Connection] state closed (5)
2024-03-28T17:43:55.647Z [Connection] state starting (0)
2024-03-28T17:43:55.650Z [Connection] cisa-myphone connectTo: cisa:<passwd>@MYDNS:8883 v3 MQTT TLS (55) c0 / owntracks/cisa/myphone {"_type":"lwt","tst":1711647836} q2 r0 as cisa-myphone 0 (null)
2024-03-28T17:43:55.650Z [Connection] state connecting (1)
2024-03-28T17:43:55.710Z [Connection] connected MQTT eventCode: (0) (null)
2024-03-28T17:43:55.710Z [Connection] connected sessionPresent 0
2024-03-28T17:43:55.710Z [Connection] state connected (3)Nothing jumps out at me... but I don't know what I'm looking for either.
ckrey
commented
3 months ago pls use triple back ticks ``` for code formatting :-)
ckrey
commented
3 months ago The log shows a successful connection state connected (3)
whmoorejr
commented
3 months ago So this device will publish its location without any issue... but for whatever reason, it's not receiving anything. Any troubleshooting ideas?
ckrey
commented
3 months ago I assume you are using the device in a "quicksetup" environment (you did not tell us). Do you see the location publishes of the device on the server? Do you see the location publishes of the other devices on the server?
whmoorejr
commented
3 months ago As an experiment, I just published a new card via MQTT Explorer owntracks/cisa/myphone/info This populated the contact card for the TID CS device on three other devices that I have on me. The CS device still only shows "CS" .
whmoorejr
commented
3 months ago Yes, this was a "quicksetup" setup. I do see location published of the device on the server along with all the other devices. And, all the other devices can all see each other and are getting updates without issue. Even the older iPhone6 devices are playing nicely. This is onle of three iphone13 s in my setup... but the only one that is acting this way.
whmoorejr
commented
3 months ago The only OS difference... the CS device is running iOS 17.4.1 Everything else is 17.3.1 or older, down to 12.5.7
whmoorejr
commented
3 months ago A 2nd device (TID: vm) has also stopped receiving updates. (also an iPhone 13... but this one is running iOS17.3.1) I was running with a theory that something in 17.4 messed up something or something on the first one with the issue was because of a management setting (it's a work phone with some interesting restrictions).
To summarize, I have 2 devices that the app doesn't populate (as if they aren't subscribed to anything). But both phones publish just fine.
I've tried re-booting devices, re-installing the app, rebooting the raspberry pi. I havn't made any progress in troubleshooting this.
On the log, the negative looking stuff I see is:
2024-04-03T13:37:18.630Z [Connection] connected MQTT eventCode: (0) (null)
2024-04-03T13:37:18.630Z [Connection] connected sessionPresent 0
2024-04-03T13:37:18.630Z [Connection] state connected (3)
2024-04-03T13:37:18.630Z [Connection] subscribe owntracks/+/+ qos=2
2024-04-03T13:37:18.630Z [Connection] subscription mid=8
2024-04-03T13:37:18.630Z [Connection] subscribe owntracks/+/+/event qos=2
2024-04-03T13:37:18.630Z [Connection] subscription mid=9
2024-04-03T13:37:18.631Z [Connection] subscribe owntracks/+/+/info qos=2
2024-04-03T13:37:18.631Z [Connection] subscription mid=10
2024-04-03T13:37:18.631Z [Connection] subscribe owntracks/cisa/myphone/cmd qos=2
2024-04-03T13:37:18.631Z [Connection] subscription mid=11
2024-04-03T13:37:18.642Z [Connection] subAckReceived mid=8 rc=(
2
) up=(null)
2024-04-03T13:37:18.650Z [Connection] subAckReceived mid=9 rc=(
2
) up=(null)
2024-04-03T13:37:18.650Z [Connection] subAckReceived mid=10 rc=(
2
) up=(null)
2024-04-03T13:37:18.650Z [Connection] subAckReceived mid=11 rc=(
2
) up=(null)
2024-04-03T13:37:25.416Z [Connection] idle
2024-04-03T13:37:38.236Z [OwnTracksAppDelegate] connectionOff
2024-04-03T13:37:38.236Z [Connection] disconnect
2024-04-03T13:37:38.236Z [Connection] state closing (4)
2024-04-03T13:37:38.237Z [Connection] connection closed MQTT eventCode: (2) (null)I also see this between the connections... but I don't know what the error codes corespond with:
2024-04-03T13:36:22.554Z [Connection] state connecting (1)
2024-04-03T13:36:22.611Z [Connection] connection refused MQTT eventCode: (1) Error Domain=MQTT Code=5 "MQTTReasonCode: 5" UserInfo={NSLocalizedDescription=MQTTReasonCode: 5}
2024-04-03T13:36:22.611Z [Connection] error.code 5, error Error Domain=MQTT Code=5 "MQTTReasonCode: 5" UserInfo={NSLocalizedDescription=MQTTReasonCode: 5}
2024-04-03T13:36:22.612Z [Connection] set reconnectTimer 2.000000
2024-04-03T13:36:22.612Z [Connection] state error (2)
2024-04-03T13:36:22.613Z [Connection] connection closed MQTT eventCode: (2) (null)
2024-04-03T13:36:22.613Z [Connection] state closed (5)```
jpmens
commented
3 months ago You appear to be playing around a bit too much… ;-) MQTT reason code 5 means your user ID and password do not correspond to what the broker is expecting. I assume that you have modified the configuration.yml file on the server have reinstalled with bootstrap, but still have an old configuration on your phone. Please make sure that after running bootstrap you absolutely re-download the configuration onto your phones
whmoorejr
commented
3 months ago I double checked the configuration.yaml file.... as far as I can tell, it's all correct... Here is the "Friend" section:
# a single user has more than one device.
friends:
- { tid: "BM", username: "bill", devicename: "myphone" }
- { tid: "CS", username: "cisa", devicename: "myphone" }
- { tid: "IS", username: "indigo", devicename: "myphone" }
- { tid: "VM", username: "vikki", devicename: "myphone" }
- { tid: "HM", username: "harper", devicename: "myphone" }
- { tid: "WM", username: "william", devicename: "myphone" }
- { tid: "AH", username: "anna", devicename: "myphone" }
- { tid: "MH", username: "mikey", devicename: "myphone" }
- { tid: "RH", username: "rylee", devicename: "myphone" }
# - { tid: "BX", username: "bexley", devicename: "myphone" }
# - { tid: "D1", username: "quinn", devicename: "myphone" }
# - { tid: "D2", username: "sophia", devicename: "myphone" }
# ---- advanced options belowI commented out the ones that don't have a device assigned yet.
Then I ran bootstrap. After that, I checked the password file on the devices that I was having an issue with.... they havn't changed since the first time I did the quick setup.
On one of the trouble devices (tid: "CS" , I logged onto the local owntracks page https://mydns.com/owntracks and logged in with cisa and the password from the cisa.pass file.
And the device is back to where I started. From the status info -> settings page, everything looks correct. The "Friends" list is still empty.
Typically, on any other of the devices I'm using, once the device starts connecting, the friends list auto-populates with the TID and card info (name & picture). <-- expected behavior.
ckrey
commented
3 months ago it may help if you send us the mosquitto log file /var/log/mosquitto/mosquitto.log to support@owntracks.org (you may filter for cisa-myphone).
whmoorejr
commented
3 months ago Probably a dumb question... I'm trying to get the log off of the raspberry pi so I can email it. I tried using Cyber Duck to download the file to my mac (Permission Denied) Figuring that it was probably because of the location of the file, I made a copy of it in terminal to my home directory. Tried downloading the copy with cyber duck again... (Permission Denied).
Figured out how to do it from terminal. (Permission Denied)
sudo scp williammoore@192.168.1.86:/home/williammoore/mosquitto.log .
and tried this with same (Permission Denied) results)
sudo scp williammoore@192.168.1.86:/var/log/mosquitto/mosquitto.log .
jpmens
commented
3 months ago On the Raspi:
sudo cp /var/log/mosquitto/mosquitto.log mos.log
sudo chown whmoorejr mos.log
chmod 644 mos.logthen the copy (mos.log) belongs to you and you can scp it out.
whmoorejr
commented
2 months ago That worked perfectly.... I'm saving that to my rasperry pi cheet sheet to reference later.
I emailed the full log.
There was one oddity that I noticed, but not sure how to track it down.... there was a repetative ping in the log from "Indigo-MQTT". This was a user from my previous owntracks/mosquitto broker setup. I'm trying to isolate that now. I should still have "Indigo" in the log, one of the devices is "indigo-myphone". (The phone assigned to my home automation server). My home automation system logs in as "_lr". So I don't think I have anything outside of the raspberry pi that is still using the "Indigo-MQTT" user. I just shut down the MQTT plugin on my home automation server, will wait an hour or so and re examine the log to see if it's still there.
ckrey
commented
2 months ago Thank you for the log. I don't think the indigo-mqtt user does any harm.
But there is something strange for the users vikki, anna, and cisa e.g.:
1712236322: Outgoing messages are being dropped for client anna-myphone.Something went wrong during the process so far. mosquitto and those 3 clients are out of sync.
To cleanup the mosquitto queues please do these 3 steps:
sudo systemctl stop mosquitto
sudo /var/lib/mosquitto/mosquitto.db
sudo systemctl start mosquittoThe second command... I think it's missing something? sudo rm maybe?
sudo /var/lib/mosquitto/mosquitto.db
Thought I should ask before I arbitrarily delete something.
jpmens
commented
2 months ago remove is correct, @whmoorejr, so
sudo rm /var/lib/mosquitto/mosquitto.dbFingers crossed... looks like that is fixing it.
One note: I noticed that as different devices were reporting, the friends list started building on the cisa phone. :-)
The other phones, the data wasn't updating. :-(
My first thought was "crap, now all the other devices are getting weird." Simple switch from MQTT -> HTTP (to clear the data from the phone) then -> MQTT and now all my devices (at least the ones that are currently in my reach) are populating with the correct information again.
Luckily, I had a folder with all the cards in .json format and all the regions in .json format.... so a couple minutes publishing that and it's pretty much all built back to where it was.
I have one device (tid: CS) that 1st stoppped updating. None of the friend data was updating. If I published a location, that worked (populated the other devices with updated CS device location.
I've completely uninstalled / reinstalled the software from the device to start from scratch. Logged onto the local https://mydns/owntracks and opened the config file from that page (which loaded correctly).
The device still shows nothing from the other devices. Now, the other devices aren't even visable on the "Friends" tab. I've done a side-by-side comparison with another device to tripple check that all the settings are correct.
I'm not sure what to look for in the log file to troubleshoot this. Maybe you can see something in it? Below is I think everything from when I last opened the config file to current...