Mini 16s

[sanscorp1]

I was afraid it wouldn't take long for my next question :) Previous issues were about the Outdoor camera (bullet).

This is about the indoor mini 16S camera (1080). I have been able to telnet into the camera and enable RTSP in the tuya_config.json file, the RTSP stream works.

I now want to apply the hosts file hack via custom.sh but the camera stays online. Below is the file I'm using now and the host file is in the root of the SD.

Is the custom.sh edited correctly and can I try something else?

#!/bin/sh
if [ ! -e /tmp/customrun ]; then
 echo custom > /tmp/customrun
 cp /mnt/mmc01/passwd /etc/passwd
 /mnt/mmc01/busybox telnetd
 /mnt/mmc01/busybox httpd -c /mnt/mmc01/httpd.conf -h /mnt/mmc01 -p 8080
 if [ -e /mnt/mmc01/ppsapp ]; then
  PPSID=$(ps | grep -v grep | grep ppsapp | awk '{print $1}')
  kill $PPSID
  /mnt/mmc01/set record_enable 0
  #/mnt/mmc01/set enable_event_record 1
  /mnt/mmc01/ppsapp &
  if [ -e /mnt/mmc01/hosts ]; then
   sleep 180
   cp /mnt/mmc01/hosts /etc
   ifconfig wlan0 down
   sleep 120
   ifconfig wlan0 up
  fi
 fi
fi

[guino]

@sanscorp1 since you likely don’t have a patched ppsapp you can try this instead:

#!/bin/sh
if [ ! -e /tmp/customrun ]; then
 echo custom > /tmp/customrun
 cp /mnt/mmc01/passwd /etc/passwd
 /mnt/mmc01/busybox telnetd
 /mnt/mmc01/busybox httpd -c /mnt/mmc01/httpd.conf -h /mnt/mmc01 -p 8080
 if [ -e /mnt/mmc01/ppsapp ]; then
  PPSID=$(ps | grep -v grep | grep ppsapp | awk '{print $1}')
  kill $PPSID
  /mnt/mmc01/set record_enable 0
  #/mnt/mmc01/set enable_event_record 1
  /mnt/mmc01/ppsapp &
 fi
 if [ -e /mnt/mmc01/hosts ]; then
  sleep 180
  cp /mnt/mmc01/hosts /etc
  ifconfig wlan0 down
  sleep 120
  ifconfig wlan0 up
 fi
fi

[sanscorp1]

"hosts" is succesfully copied to /etc/ (verified trough telnet)

WiFi does seem to go down after the sleep timer and comes up again. But the connection to Tuya servers is maintained. i.e. I can still open the camera stream trough the android app.

[guino]

@sanscorp1 you can try to increase the sleep 120 value between ifconfig commands to 180 - that is the time it waits with the wifi down so the tuya connection is ‘dropped’ , you can reduce the first sleep to reduce how long it waits to connect to the tuya servers initially (to get date/time).

I can probably devise a more ‘accurate’ method for this by checking the time and the connections - I will see if I can find the time to work on this.

[sanscorp1]

I increased the sleep timers and edited the hosts file but the connection to Tuya is still up.

I did add this to the hosts file: 127.0.0.1 aws3nat.tuyaeu.com aws4nat.tuyaeu.com

I test it trough the android app.

[guino]

@sanscorp1 If you want you can post a zip of your ppsapp and I can try to patch it for offline (would require you to have an accessible NTP server to set the time).

If you prefer to get the 'universal' offline method working I just have to find the time to re-work it by checking date/time and disconnections instead of just using 'sleep'.

[sanscorp1]

The hack isn't properly working on this indoor 1080 camera, the content of the device isn't copied to the SD card so I have no PPSAPP of this camera.

Working:

• Busybox / Telnet
• Custom.sh

Not working:

• Copy of the device internal storage to the SD card.
• Custom.sh offline patch (hosts)
• No PPSAPP available so there is nothing to patch.

Device info: {"devname":"Smart Home Camera","model":"Mini 16S","serialno":"1038088XX","softwareversion":"5.2.4","hardwareversion":"M16S_A2_V10_MIS","firmwareversion":"ppstrong-a3-tuya2_lsc-5.2.4.20211015","identity":"XXXX","authkey":"XXXX","deviceid":"XXXX","pid":"aaa","WiFi MAC":"XX:XX:XX:X3:17:f9","ETH MAC":"00:00:00:00:00:00"}

XXXX=Removed identity, authkey and deviceid.

[guino]

@sanscorp1 they may have changed something about where the files are stored -- can you post the result from: http://admin:056565099@ip/proc/self/root/etc/init.d/S90PPStrong -- this should give us a clue at what may be different.

Also, if you don't mind post your initrun.sh file as well just to rule out any problems with that.

[sanscorp1]

I have to use: http://admin:admin@192.168.0.43:8090/proc/self/root/etc/init.d/S90PPStrong And get this response:

response.txt

Here's the initrun.sh: initrun.sh.txt

[guino]

@sanscorp1 can you try this: 1-make sure there's no 'home' directory in the SD card 2-update your initrun.sh to be this (I only added the mkdir line):

#!/bin/sh

# Copy app partition if not already done
if [ ! -e /mnt/mmc01/home ]; then 
 mkdir -p /opt/pps
 MTDNUM=`cat /proc/cmdline | sed 's/.*ppsAppParts=\([0-9]\).*/\1/'`
 mount -t cramfs /dev/mtdblock$MTDNUM /opt/pps
 tar xzf /opt/pps/app.tar.gz -C /mnt/mmc01/
fi

# Now flag the hack is done
echo done > /mnt/mmc01/hack

# Try to run custom.sh
while true; do
 if [ -e /mnt/mmc01/custom.sh ]; then
  /mnt/mmc01/custom.sh
 fi
 sleep 10
done

3-reboot the device and make sure to wait at least 3 minutes before removing the SD card, then check if the home directory was created (with ppsapp inside).

[sanscorp1]

Nope, did not work, waited 10 minutes.

[guino]

@sanscorp1 I am going to need you to execute these commands in telnet and show me the outputs:

mkdir -p /opt/pps
MTDNUM=`cat /proc/cmdline | sed 's/.*ppsAppParts=\([0-9]\).*/\1/'`; echo $MTDNUM
mount -t cramfs /dev/mtdblock$MTDNUM /opt/pps
ls -la /opt/pps/
tar xzf /opt/pps/app.tar.gz -C /mnt/mmc01/

Everything seems to be 'normal' but one of the above must be failing and I need to see 'why' as the above is basically the same as the firmware does -- chances are it's just something stupid like they renamed the app.tar.gz file to something else.

[sanscorp1]

It looks like the filename is indeed different. tar.gz is tar.xz

EDIT: tar xf /opt/pps/app.tar.xz -C /mnt/mmc01/ did seem to do something, the command is differrent for xz files.

The adjustment to the command resulted in a succesfull copy, here is the PPSAPP:

ppsapp.txt

[guino]

@sanscorp1 good job on providing accurate results -- yes it seems they modified the format of the compressed file on this version -- I will adjust the initrun.sh script accordingly. I'll take a look at your ppsapp and see if I can make an offline version for you, meanwhile I'm also working on a different universal offline option.

[sanscorp1]

Thank you!

I am willing to try another offline method if needed.

The PPSAPP has to be edited with an HEX editor right? Shame it's so hard to learn, I have two other cams (Lidl, Silvercrest) with undoubtebly a Linux based OS. Would be great to enable RTSP/ONVIF on those to.

Connecting is one thing, extracting the password a whole other thing.

[guino]

@sanscorp1 Please try this for a newer/improved universal offfline patch: 1-create a file on the SD card called offline.sh with these contents:

#!/bin/sh

# If no hosts file, leave
if [ ! -e /mnt/mmc01/hosts ]; then
 exit 0
fi 

# Wait for date to be corrected
while [ `date +%s` -lt 1645543474 ]; do
 date >> /tmp/offline.log
 sleep 1
done
# Wait for connection to be made
while [ `netstat -n | grep ':8883' | grep -c ESTABLISHED` -lt 1 ]; do
 echo "no conn" >> /tmp/offline.log
 sleep 1
done
# Block internet access to tuya servers
cp /mnt/mmc01/hosts /etc
echo "blocked hosts" >> /tmp/offline.log
# Wait for connection to be dropped
while [ `netstat -n | grep -v 127.0.0.1 | grep -v ':23' | grep -c ESTABLISHED` -gt 0 ]; do
 # For each non-telnet established IP
 for ip in `netstat -n 2>&1 | grep -v 127.0.0.1 | grep -v :23 | grep ESTABLISHED | awk '{print $5}' | awk -F: '{print $1}'`; do
  echo "checking $ip" >> /tmp/offline.log
  if [ "`route -n | grep -c $ip`" == "0" ]; then
   route add -net $ip netmask 255.255.255.255 gw 127.0.0.1
   echo "blocked $ip" >> /tmp/offline.log
  fi
 done 
 # Bring down wifi
 ifconfig wlan0 down
 # Brief wait
 sleep 1
done
# Restore wifi connection
ifconfig wlan0 up

2-Modify your custom.sh file so it looks like this (I removed the offline commands and added a call to the new script):

!/bin/sh
if [ ! -e /tmp/customrun ]; then
 echo custom > /tmp/customrun
 cp /mnt/mmc01/passwd /etc/passwd
 /mnt/mmc01/busybox telnetd
 /mnt/mmc01/busybox httpd -c /mnt/mmc01/httpd.conf -h /mnt/mmc01 -p 8080
 if [ -e /mnt/mmc01/ppsapp ]; then
  PPSID=$(ps | grep -v grep | grep ppsapp | awk '{print $1}')
  kill $PPSID
  /mnt/mmc01/set record_enable 0
  #/mnt/mmc01/set enable_event_record 1
  /mnt/mmc01/ppsapp &
 fi
 /mnt/mmc01/offline.sh
fi

I tested the above with my own device and seems to work well -- the device will boot up and should be unaccessible for a couple of minutes (while it drops connections) then it should be off the tuya cloud (which you can verify by running netstat -n on telnet). Please notice the app may still show the device 'online' if you're in the same local network because the app scans the local network for devices (but it will likely still not work with the app).

Please give that a try and let me know.

[sanscorp1]

Netstat results in this:

The highlighted rule is connecting to amazon? ec2-3-120-92-134.eu-central-1.compute.amazonaws.com

adguard also shows a query: Time now is 13:33

[guino]

@sanscorp1 thanks for trying the offline script -- can you provide the output of these two telnet commands: 1-cat /tmp/offline.log 2-route -n PS if I can't figure out the issue with the offline script quickly I'll try to make an offline patch for you.

[sanscorp1]

The difference in our timezone makes it a slow proces, but I'm in no rush.

IF it can be done without much effort, the offline ppsapp is welcome, otherwise it would be more benefitial to others to continue with the universal offline.sh patch

[guino]

@sanscorp1 you can try this offline patch: ppsapp-offline.zip please use these steps: https://github.com/guino/ppsapp-rtsp/issues/1#issue-759079080

Also these may be useful: jpeg address: 0305ba4 play address: 03069a8

[sanscorp1]

I followed all the steps from step 1 to assure a "stock hack" and the camera is stuck in a boot loop with the patched PPSAPP.

I also played with offline.sh and hosts but whatever I try, I can still connect trough the app (even outside the local network) and I still see activity in AdGuard to tuya servers.

[guino]

@sanscorp1 I did not expect you to have boot loop issues with the patch.

Can you try it again with the original ppsapp (no patching) in the root of the SD card to see if it boot loops ?

I don't know if you saw this request in regards to the 'universal' offline script: https://github.com/guino/Merkury1080P/issues/23#issuecomment-1049213196

[sanscorp1]

Forgot about that.

Summary PPSAPP:

• PPSAPP offline causes a bootloop every 1,5 minute, even when redoing all the steps on an empty SD card.
• Original PPSAPP in the root of the SD also caused a bootloop.
• Copied the working outdoor cam SD to the Indoor cam SD and placed the correct PPSAPP in root, this also causes a bootloop. Removing the PPSAPP from root SD alltogether and the camera boots fine.

Summary offline.sh hack: Waited 5 minutes after boot.

Netstat -n:

Route -n:

AdGuard shows these DNS requests:

I can still connect trough the LSC (Tuya like) app on mobile internet (not connected to WiFi or VPN).

[guino]

@sanscorp1 it sounds like the issue is that killing ppsapp and starting it again is causing a the boot loop (unrelated to the patch I made). There’s a way around it (Dan’s changes) to boot the parched ppsapp directly but it seems an excessive measure just for offline mode.

Can you post the output of cat /tmp/offline.log with the offline script? If you don’t have one it may not be setup correctly in which case please post a zip of your offline.sh and custom.sh file so I can review it.

[sanscorp1]

cat /tmp/offline.log doesn't excist, here are the files:

custom.sh.txt offline.sh.txt

[guino]

@sanscorp1 And you still have a hosts file in the SD card?

[sanscorp1]

Yes, I did edit it to include some more hosts and a better overview:

hosts.txt

[guino]

@sanscorp1 can you try adding & to the offline.sh line in custom.sh, like this: /mnt/mmc01/offline.sh &

We should have at least seen some data in /tmp/offline.log but you're saying it is not there so it is like the script isn't even running.

Please make sure the hosts file is NOT called 'hosts.txt' in the SD card.

[sanscorp1]

none of the files have the extention .txt on the SD :) It is necessery for upload to GitHub only.

Still no offline.log in TMP.

But when trying to run the SH scripts I get:

[guino]

@sanscorp1 looks like you found the issue but it makes no sense -- I have the same script on my device and it is working so maybe they have some support commands missing on your device.

Can you execute this on telnet and post responses: 1-if [ ! -e /mnt/mmc01/hosts ]; then echo no file; fi 2-if [ -e /mnt/mmc01/hosts ]; then echo fileok; fi

Depending on the results we may be able to make small adjustments to fix it but I'm more worried about the more complex commands in the rest of the script.

[sanscorp1]

What about simplifying it more?

after editing offline.sh (removing bogus characters, I think because of Windows Notepad) I get this:

IF copying hostst to ETC is enough to block internet, maybe I should go with the simple version. Sleep timer, copy hosts, restart WiFi.

I can use my NTP server for the time.

1-if [ ! -e /mnt/mmc01/hosts ]; then echo no file; fi 2-if [ -e /mnt/mmc01/hosts ]; then echo fileok; fi

results in:

[guino]

@sanscorp1 the tcp6/udp6 messages are not a problem -- I am interested in seeing the offline.log file now that you 'fixed' character issues with the file.

The issue I found during my testing is that the ppsapp seems to have some 'hard coded' IP addresses instead of relying on DNS to find the server IPs to connect onto so using the hosts file alone may not do the trick.

The offline script I built basically goes thru the current connections on the device (anything that is not telnet or local) and creates a route to nowhere so the connections are blocked -- all that while making sure the wifi connection is down so that any existing connections are dropped.

The offline.log file should have details on what it is doing, so that should be very informative on what works or not.

To prevent windows/character issues, please download/unzip and use this file (straight from my device): offline.zip

[sanscorp1]

This is working now. I don't know what went wrong yet but I'll compare the files.

I think the lesson would be to use Notepad++ instead of Windows Notepad...

Output of cat /tmp/offline.log

[guino]

@sanscorp1 as long as it works offline and you have RTSP/ONVIF working that's what matters (so you don't have to patch ppsapp and deal with the boot loop issue).

I should have just made the file available for download to start instead of copy/pasting it, sorry.

[guino]

@sanscorp1 by the way: you CAN use the address I provided for snap/mjpeg and play.cgi without patching too, not sure if those are features you want but just thought I'd let you know.

[sanscorp1]

RTSP is the main feature I'm using. Now testing on the other two indoor camera's.

The only thing left to do is disable SD card recording, even tough /mnt/mmc01/set record_enable 0 is uncommented it still records.

I will try to adjust tuya_config.json accordingly.

[sanscorp1]

I've been using the offline hack for two days now and the camera's are still working.

I do notice frequent connection interruptions. Could this be because of the RDP protocol and high CPU usage?

Is there a(n easy) way to utilize the TCP protocol? Or is there a secondary stream availablen in 720P? That would also be sufficient for mobile applications.

I will add a stock camera to observe it's behaviour as well.

[guino]

@sanscorp1 these cameras are known to high cpu , disconnection and even rebooting due to UDP based RTSP streaming. The client used can choose to use TCP instead of UDP which greatly improves stability of the stream and reduces cpu load.

On VLC you can start it like this:

vlc --rtsp-tcp rtsp://ip:8554

OR you can go into VLC settings and selecting RTP over RTSP (TCP) : in 'Simple' mode click 'Tools > Preferences > Input / Codecs and select 'RTP over RTSP (TCP)' at the bottom, them click 'Save'. In 'Advanced' mode click 'Tools > Preferences > Input / Codecs > Demuxers > RTP/RTSP and select 'RTP over RTSP (TCP)' then click 'Save'.

I recommend you test it with VLC then compare with whatever you’re using and see if you can find tcp options for it. It should be possible to use ffmpeg on a machine to stream from the device over TCP and have it stream to other devices with different options (tcp or udp).

[sanscorp1]

OK I'm running into trouble with one indoor camera. I saw some errors concerning a non excistant tcp6 and raw folder but I googled the problem.

I'm now trying to figure out what's going wrong.

[guino]

@sanscorp1 you can safely ignore the tcp6, udp6 and raw6 errors -- they just mean the device doesn't have support for ip6. The offline script should work normally despite those messages.

[sanscorp1]

I figured that by reading about the error while I googled the problem :)

I'm trying again with the files you provided (hosts and offline.sh) I stripped the custom.sh to this:

custom.sh.txt

The strange thing is it works without problems on 1 camera (same firmware etc.) and doesn't on the other.

[guino]

@sanscorp1 you probably have some windows character issue on the file. You should copy the files from the one that works to be sure. If they’re the same type of camera you can probably swap chips and see if the problem stays with the device or with the chip.

[sanscorp1]

I did learn myself to use Notepad++ for the files. After some tinkering it did work again.

I will create a copy of the SD card for the other two indoor cams and test again.

[sanscorp1]

The three indoor camera's are working this way for now.

When I remove the ifconfig wlan0 down/up as a test, there are no blocked hosts in /tmp/offline.log When executing wifi down and up (while ifconfig wlan0 down, sleep 60, ifconfig wlan0 up) the camera reboots WiFi every 60 seconds.

netstat results in:

It seems the script is not terminated, If I repeat all the steps in offline.sh the last command is repeated over and over.

[guino]

@sanscorp1 so if your three cameras are working what is it that's showing no blocked hosts ? a 4th camera (not mentioned) ?

Where did you get 'sleep 60' from ? this newest offline script should loop every second with ifconfig wlan0 down to make sure the ppsapp won't restart it while we're blocking connections.

If you're having issues with the offline script not terminating on some device, just modify the /tmp/offline.log (5 occurances) in offline.sh to be /mnt/mmc01/offline.log then let it boot up and run for a few minutes (i.e. 5), power off the device and post a copy of your offline.log (which will be on the SD card) so I can review.

[sanscorp1]

I now have 3 indoor, 1 outdoor and 1 doorbel.

Because it is an universal offline hack I tried it on all devices.

I changed sleep 1 to sleep 60 in between inconfig wlan0 up and ifconfig wlan0 up, I will change it back.

I will continue with the doorbell and outdoor camera.

[sanscorp1]

Well, I just killed the doorbell.. Cannot connect or reconnect (Tuya app) after reset anymore. EDIT: "Revived" it after following the correct steps to fix the env file.

Now followed the hack for the doorbell (https://github.com/guino/BazzDoorbell/issues/13) to the letter and it's still online.

I'll be leaving the doorbell stock I guess :) The outdoor camera is also still online after the offline.sh hack.

[guino]

@sanscorp1 if youŕe running the offline.sh and it isn´t working send me a copy of the offline.log and I can review. Glad you 'revived' your device though.

[sanscorp1]

The joy was short lived, I tried the hacked env file again according to the manual and now I can't access the camera nor make connection with (or add it to) the Tuya app.

Do I only need the files in TazzDoorbell MMC from this repo or does this hack not work for the camera's where the debug is still active?

I purchased a second doorbell this afternoon to try it again.

We are shifting the subject here by the way... Sorry for jumping arround, I find it hard to structure my findings whilst working on 3 different camera's (universal hack).

Now another problem has occurred (doorbell not working) and perhaps it is better to split the topics?

[guino]

@sanscorp1 like I said before: I highly doubt the boot settings would 'damage' the device permanently -- if you modify it wrong enough you may cause the device to not boot but it should be reversible using the original cmdline using the troubleshooting steps in https://github.com/guino/BazzDoorbell/issues/2

You should be following the instructions from https://github.com/guino/BazzDoorbell/issues/13 to root the doorbell if it is on 2.x firmware or the steps from https://github.com/guino/Merkury1080P#conclusion if your device is running 4.x or 5.x firmware.

Yes I would recommend opening a separate issue for us to discuss the problems on a different device (one issue per device type/problem is the ideal).

[sanscorp1]

I have version 4.0.7 and followed the wrong steps and will open a new issue.