Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RTSP stopped working once I block the internet access of the camera #234

Closed
cchenga opened this issue Jan 27, 2021 · 29 comments
Closed

RTSP stopped working once I block the internet access of the camera #234

cchenga opened this issue Jan 27, 2021 · 29 comments
Labels

Comments

@cchenga
Copy link

cchenga commented Jan 27, 2021

Hello roleoreleo,

RTSP server is working fine with internet access. However it stopped working once I blocked the internet access of the camera and restart it.
Is that expected behavior?
Version is 0.2.2, upgraded recently.
I remembered it worked without internet access in one of the previous version. (maybe I am wrong)
Could you please confirm that?

Thanks

@roleoroleo
Copy link
Owner

This is an unresolved issue.
When you block the traffic internally, shutting down the processes, it works but if you block the connection through a firewall, the cam stops working (probably a memory leak).
I don't know why, it depends on the yi programs.
roleoroleo/yi-hack-MStar#149

@Catfriend1
Copy link
Contributor

Hi,

I was successful to block outgoing connections until the early days of using Yi-Hack Allwinner. Never had problems with the cam after that. There seems to be a hard-coded requirement by the cam I've discovered by trial and error: It demands access to Google DNS.

My cam works on the local network with these rules in the firewall:
image

Regards,
Catfriend1

@cchenga
Copy link
Author

cchenga commented Feb 4, 2021

Thanks @Catfriend1 , it seems a good solution. But my problem is, my router doesn't allow me to add an exception to the black list. If I use white list, I need to add rules for each device in this subnet. Any suggestions?
my

@Catfriend1
Copy link
Contributor

Catfriend1 commented Feb 4, 2021

@cchenga Hmm maybe letting everything pass but block http/https traffic ports 443, 80 entirely? I don't remember if there was another port which the yi cloud api used. to be sure, run e.g. wireshark when booting the cam with full internet access.

@colethegamer123
Copy link

I have the same problem. Finally my whole network works in local, except the cameras what is my biggest risk and concern lets say. It would be good to do that somehow if I block Internet access with one button it works properly after.

If someone has idea what to do just tell me , im using Xiaomi Ax3600 Router.

Thank you guys :)

@roleoroleo roleoroleo pinned this issue Feb 9, 2021
@pomtom44
Copy link

pomtom44 commented Mar 3, 2021

Im having the same issue
I have logged my firewall and can see the camera trying to communicate DNS to 8.8.8.8 as well as 161.117.69.207
Does anyone know what that second IP address is?

@pomtom44
Copy link

pomtom44 commented Mar 4, 2021

Edit: Nope back to same problem as shown below (Fifo Full)
Doing more testing to see if i can figure it out

Original:
Can confirm allowing just 53 to 8.8.8.8 fixes the problem

On a side note which I dont see mentioned in this thread or the one linked before
when debugging my camera, i could see this error when I started a RTSP stream without allowing 8.8.8.8 though

ALSA lib pcm.c:8683:(pcm_write_snoop_fifo) Fifo full!

It would spam that in the logs, until i reboot the camera, then it would be fine again till I tried to connect to rtsp where it would start back up

@pomtom44
Copy link

pomtom44 commented Mar 4, 2021

Update:
For me it wasnt a network issue, (that i can see)
I have blocked all network access again for the camera, and set the following config
Disabled Cloud ON
Record without cloud off
RTSP ON
RTSP Auidio OFF
ONVIF OFF

SSH ON (Defualt I believe)
HTTPD ON
Everything else off

I cant see any traffic on my firewall any more from the camera
and my RTSP seems stable

@roleoroleo
Copy link
Owner

ALSA lib pcm.c:8683:(pcm_write_snoop_fifo) Fifo full!

This error depends on a patch I made to add audio to the stream.
Should not be a problem.

@Arkady23
Copy link

Arkady23 commented Mar 7, 2021

Good day, roleoreleo!
I asked Andy2301 to make such a simple but high-quality RTSP. There is rarely a suitable RTSP-server for old and new Yi-cameras.... I've read about the unsolvable difficulties that arise with direct flow. You can ask him to make such an RTPS so that he closes questions about any camera.
andy2301/test1#1 (comment)

@ivanfor
Copy link

ivanfor commented Mar 11, 2021

Hi.
I can fully reproduce the behaviour described in this issue.
As a further analysis, I've run wireshark and seen that DNS query to 8.8.8.8 comes from /etc/resolv.conf

root@yi1080:~# cat /etc/resolv.conf
nameserver 192.168.1.1
nameserver 8.8.8.8
nameserver 8.208.8.243
nameserver 47.89.253.148
nameserver 47.74.247.115

It's querying for api.eu.xiaoyi.com. I have my own LAN DNS (192.168.1.1) and have set api.eu.xiaoyi.com to resolve to 127.0.0.1 and the RTSP server starts normally even with no internet access at all.
We can conclude that it's only needed to get an IP address for api.eu.xiaoyi.com (no matter what IP or DNS).

@roleoroleo : maybe an entry to /etc/hosts would work for everyone

@Arkady23
Copy link

@ivanfor
No, you can't. Request to api.eu.xiaoyi.com, as well as other Chinese addresses requests the "dispatch" module.

@roleoroleo
Copy link
Owner

@roleoroleo : maybe an entry to /etc/hosts would work for everyone

Many people use cloud services.
I only need to add it when the cloud is disabled.

@Catfriend1
Copy link
Contributor

Catfriend1 commented Mar 16, 2021

Do we have any chance to create this file?

echo "127.0.0.1 api.eu.xiaoyi.com" > "/home/yi-hack/etc/hosts"
mount --bind "/home/yi-hack/etc/hosts" "/etc/hosts"
# mount: mounting /home/yi-hack/etc/hosts on /etc/hosts failed: No such file or directory

/tmp/log.txt reveals which address the camera likes to connect to / resolve.

rmm.c(main-1815) ----wifi connected goto venc and aenc----
[./dispatch][3/16/4:49:31:522]: dispatch.c(check_wifi_connect-1599) signal_quality(46)[./cloud][3/16/4:49:31:649]: cloud.c(sys_init-5275) open share mem ok
[./cloud][3/16/4:49:31:810]: cloud.c(yi_sync_time-5145) cmd = /home/app/cloudAPI -c 136 -url http://api.eu.xiaoyi.com/v2/ipc/sync_time 
[./cloud][3/16/4:49:31:872]: cloud.c(yi_sync_time-5152) req_info=http://api.eu.xiaoyi.com/v2/ipc/sync_time?hmac=BIke7GBrJXU6Qe4XXXUkYNp8%3D&seq=9
curl_easy_perform() failed: {"curl_code":7} Couldn't connect to server

@roleoroleo
Copy link
Owner

/etc/hosts doesn't exist.
mount --bind doesn't work if the file doesn't exist.
Add this file means rewrite the whole partition.
It's not a good idea.

@Catfriend1
Copy link
Contributor

HOSTALIASES env var does not work, too :-/

@roleoroleo
Copy link
Owner

Did you try to export it before running rmm? In system.sh

@Catfriend1
Copy link
Contributor

I tried to export it on she and then start udhcpd and then using wget to test. (did not work)
does rmm respect the var?

@roleoroleo
Copy link
Owner

The only solution is to bind the whole folder.

mkdir /tmp/etc
cp -R /etc/* /tmp/etc
mount --bind /tmp/etc /etc
echo "127.0.0.1    api.eu.xiaoyi.com" > /etc/hosts

@Catfriend1
Copy link
Contributor

@roleoroleo Thought about this, too. Would you accept it when someone makes a PR like this? I fear in my stomach that could cause weird behaviour when mounting/unmounting or upgrading!?

@Arkady23
Copy link

The only solution is to bind the whole folder.

mkdir /tmp/etc
cp -R /etc/* /tmp/etc
mount --bind /tmp/etc /etc
echo "127.0.0.1    api.eu.xiaoyi.com" > /etc/hosts
	if [ -f "$sd/record/tmp.mp4.tmp" ]; then
		killall dispatch
	fi

@roleoroleo
Copy link
Owner

I will test this solution.

@roleoroleo
Copy link
Owner

roleoroleo commented Mar 21, 2021

	if [ -f "$sd/record/tmp.mp4.tmp" ]; then
		killall dispatch
	fi

@Arkady23
Why do you need to kill dispatch?

@Arkady23
Copy link

Arkady23 commented Mar 21, 2021

DIspatch constantly sends your network information with passwords to China. I don't like it. The camera was created for espionage purposes. It would be great if you completely remove this software.

I do this on my CN17 camera. The camera works without dispatch. But for the CN17 camera, there is currently no working RTSP at all. I'm at my end system.sh so added:

if [[ $(get_config DISABLE_CLOUD) == "yes" ]] ; then
  if [[ $(get_config REC_WITHOUT_CLOUD) == "yes" ]] ; then
	if [ -d "/tmp/sd" ]; then
		sd="/tmp/sd"
	else
		sd="/home/hd1"
	fi
	sleep 20
	i=0
	while [ $i -lt 30 ] ; do
		if [ -f "$sd/record/tmp.mp4.tmp" ]; then
			killall dispatch
			killall cloudAPI
			killall p2p_tnp
			killall cloud
			i=30
		fi
		sleep 5
		i=$(( $i + 1 ))
	done
  fi
fi

Adjusted the delay. In one camera sleep 5, in the other sleep 8.

@Catfriend1
Copy link
Contributor

@Arkady23 Interesting. Do you have any proof like wireshark traces or so , just out of my interest? I'm also trying to live "privacy conscious".

@Arkady23
Copy link

@Catfriend1 Yes, I saw it in wireshark. The SSID and password were forwarded there. Why would they do that?!

@roleoroleo
Copy link
Owner

If I remeber correctly, if dispatch is not running, rmm doesn't start.
So, we can't comment dispatch in the init script.
And kill it after some seconds, could be too late for our privacy.

@Arkady23
Copy link

The situation with "RTSP stopped working once I block internet access of the camera" reminds me how web.whatsapp.com stopped working once I block internet access of the smartphone. And this does not happen with telegram.

Copy link

github-actions bot commented Apr 8, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the Stale label Apr 8, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants