MQTT status changes many times per second (offline/online) when RTSP server is activated (0.4.1.e)

[Sigfrodr]

Describe the bug
MQTT "status" changes many times per second (offline/online) when RTSP server is activated (0.4.1.e)

To Reproduce
Steps to reproduce the behaviour:

1. Activate MQTT
2. Activate RTSP

Expected behaviour
"status" must be consistent

Set Up Details (please complete the following information):

• Firmware Version: 0.4.1e
• Device: YI DOME1080P

[waleed-alharthi]

I have the same camera. Just flashed the same version (0.4.1.e).
Enabled RTSP (Both), sound, paging file and MQTT during initial setup.
Disabled cloud and recording.
All cameras go into boot loop the second day. Not sure if it's related. I have the same issue on any version.

[alienatedsec]

@waleed-alharthi a one of those functions must keep breaking a service and results in boot looping. I'll have a look

[Sigfrodr]

I have the same camera. Just flashed the same version (0.4.1.e). Enabled RTSP (Both), sound, paging file and MQTT during initial setup. Disabled cloud and recording. All cameras go into boot loop the second day. Not sure if it's related. I have the same issue on any version.

I confirm the bootloop on the 2nd day too.

[waleed-alharthi]

@waleed-alharthi a one of those functions must keep breaking a service and results in boot looping. I'll have a look

I forgot to enable MQTT on one of the cameras on version (0.4.1.c I think). It's the only camera up and running for weeks.

[waleed-alharthi]

I've flashed one and kept MQTT off yesterday. It still went into boot loop today. I'll try something else.

I get this a lot in wd_rtsp.log

2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:07 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:09 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...
2023-11-22 01:22:08 - Starting RTSP watchdog...

This is hackerror.txt (apparently it's normal)
Your baseline 0.4.1e (rootfs and home partitions) is incorrect, Ignore if you are using a pre-release version. Please refer to https://github.com/alienatedsec/yi-hack-v5/discussions/267

[Minims]

Same here after upgrading an outdoor 9CUS from 0.4.1.d to 0.4.1.e

[Minims]

I can confirm the issue is still present on 0.4.1f
(I know this bug has not been addressed in 0.4.1f)

[alienatedsec]

I also noticed the same and need to work on this at some point.

[alienatedsec]

@roleoroleo do you experience the same?

[roleoroleo]

There are several possibilities.
I need some more information.
Please, open a mqtt client (MQTT-Explorer for example) and check if the broker receives messages from the cam in the status topic.
Especially, check if the status changes online-offline-online...

Then, connect to the cam with a ssh session, kill mqttv4 and restart it manually.
Read the output and check if the cam has a stable connection with the broker.

[roleoroleo]

The problem is 2 mqttv4 processes running.
But I don't know who starts the 2nd process.

[alienatedsec]

@roleoroleo wd_rtsp seems to restart the mgttv4 a lot

[roleoroleo]

Maybe, but the syntax of the check seems to be ok.

[alienatedsec]

Found the issue and this is wd_rtsp.sh caused by this change 29f8cdb

When wd_rtsp.sh is executed, it does not see mqttv4 and launches it. After 30 seconds, the above kicks another mqttv4 process.

My question is - are these 30 seconds needed @fidesachates ?

[roleoroleo]

If it's necessary, we could start wd_rtsp.sh with the same delay.

[fidesachates]

Well it's interesting... as I noted in my PR, I added it because the mqtt was failing to start for me due to this error:

Can't open mqueue /ipc_dispatch_1. Error: No such file or directory

which I had attributed to the previous command at the time of that commit, ipc_multiplexer to not have fully started. However, immediately after my commit, this commit was added which removed it so now I don't know if it's needed. Feel free to roll it back and I can always resubmit a pr if needed.

bd032dd#diff-255ce4d35bec53378a47c9c7a0488aa2944e89d216f4a9ee8f428e109d47744dL227-L228

[Minims]

It seems working great in 0.4.1h

status is ok
I can change the led status / switch status with success.

I needed to remove retain message on camera settings to make it work.
The command is retain in that case et it’s not a normal behavior. Only state need to be retain. Maybe cmd and state needs to be split in differents topic later.

[alienatedsec]

Which retain message? @Minims

[Minims]

Set this to 0 by default

https://github.com/alienatedsec/yi-hack-v5/blob/master/src/static/static/home/yi-hack-v5/etc/mqtt_advertise.conf#L42

[alienatedsec]

This is fixed in the latest pre-release - please raise another issue if needed