push notifications not working on android

[James.S]

On Wed Mar 13th when the phones were receiving push notifications for around 70 minutes. I did a packet capture from NVR to compare when phones are receiving push alerts vs. not receiving. This was also the day FB was down.

When push alerts were working and being received by all 3 phones while I created motion. I did a network packet capture on NVR for around 4 minutes, NVR did not connect at all to firebase fcm addresses at 172.217.X.X or 216.58.X.X. when push alerts were working. Unusual because about 10 other packet captures I did from NVR while making motion at camera and push alerts not being received at phones all show two way communication with either 172.217.X.X or 216.58.X.X. But those 2 address in also give that TLSv1.2 error message I wrote about in a prior post when they connect in bound into my NVR.

During packet capture while push were working the NVR did communicate 2 way with Google at 64.233.177.95 their Port 443 for TLSv1.2 connected to various of my NVR ports. The 4108-HS NVR was also was communicating with 74.125.196.108 Port 465 when Gmail enabled. Seems both those Google addresses appear in NVR packet capture when Gmail is enabled. That IP 64.233.177.95 looks like related to Gmail or could be a multipurpose address to Google and did create TLSv1.2 connections to my NVR with better success than the firebase servers do. Or possibly the motion alert info is making it to GCM or firebase through the 64.233.177.95 address.

Also tried to do a router log capture when alerts were working. Only captured the last few minutes of push alerts working at router log to see what IP's phones and other cameras were connecting to before push alerts stopped working. Had time to create motion on 1 camera a few times before phone alerts stopped working and noticed in the router log that the cameras IP address connected once directly out to Firebase IP at 172.217.14.106 each time I created the motion. So when phone alerts were working the camera did connect out to firebase address itself but the NVR did not, unless NVR did through Gmail related TLSv1.2 IP. The other cameras might also connect out to Firebase individually with motion however did not have time to test the other cameras. I only have mobile app connected to NVR via P2P not to any individual camera.

The 3 phones were receiving push alerts except 1 older phone stopped receiving alerts a few minutes before the other 2. The older phone that stopped receiving alerts a first, the router log shows it connected to fewer IP addresses, one being FCM IP 172.217.14.106 and a some IP addresses starting with 13 and starting with 18 seen in router log. The two other phones that still received alerts a few minutes longer connected to more IP addresses including 64.233.177.95, and 74.125.X.X 172.217.X.X and about 8 more different IP addresses each.

The phone that stopped receiving alerts first I had just changed push notification type from live view, to video, then saved on app and after that there was no more alerts from it. Do not know if changing app setting caused it to stop receiving motion alerts before other phones or not.

Now that alerts are not getting to phones again, and Gmail is enabled on NVR. Did some more packet capture on NVR a few minutes while making motion at camera shows that NVR connects to firebase fcm 216.58.193.202 and with Gmail enabled also connects to 64.233.177.95 but not with 74.125.196.108. Every time there is a connection made from firebase IP into my NVR IP it gives that message mentioned in a earlier post while trying to create a TLSv1.2 connection, Alert(Level: Fatal, Description: Inappropriate Fallback).

Just to note that 74.125.196.108 Google address when seen in NVR packet capture logs causes the Inappropriate Fallback message as well but the 74.125.196.108 IP address is not showing on this capture log from when push alerts are not working.

Just thought I would mention the observations in case the missing notifications are not caused by the app itself. Picture below shows some addresses for the firebase cloud messaging service seen in a packets from NVR.

It may be that Google services are routed by a domain name used like googleapis.1.google.com rather than routed to a static IP address, depending on what app is connecting to Google services dynamically routed to any different IP address Google wants to use to get it there.

[img]firebaseAdresses.jpg[/img]

Thank you very much for your in-depth details on this! I have sent this information to our R&D and Engineering team. I am sure they will make great use of it. if you ever find anything more in your research please let me know I will gladly Forward the information.

[jack7]

...Also tried to do a router log capture when alerts were working. Only captured the last few minutes of push alerts working at router log to see what IP's phones and other cameras were connecting to before push alerts stopped working. Had time to create motion on 1 camera a few times before phone alerts stopped working and noticed in the router log that the cameras IP address connected once directly out to Firebase IP at 172.217.14.106 each time I created the motion. So when phone alerts were working the camera did connect out to firebase address itself but the NVR did not, unless NVR did through Gmail related TLSv1.2 IP. The other cameras might also connect out to Firebase individually with motion however did not have time to test the other cameras. I only have mobile app connected to NVR via P2P not to any individual camera...

Have you tried adding one of your network attached NVR cameras to your phone with camera Push Notifications enabled, in addition to the NVR? Even if NVR push is not working, you might receive camera notifications directly from the camera. The test might help in analysing the problem or providing some temporary notifications. I don't use a NVR so I haven't tested it. Push notifications work for my cameras.

[Systemuser]

Hello, and thank you James.s sorry I was not able to reply to here earlier.

Thanks for the suggestion Jack7. I have tried a couple times and adding an extra camera in addition to the NVR to send notifications to see if they are received at phone has not worked for me, but I may try it some more later through port forwarding when I get a chance and update here if it does.

I did read that when a server tries to make a connection for the TLSv1.2 handshake and either side gives that Alert (Level: Fatal, Description: Inappropriate Fallback) error message that there is no data transferred the connection is terminated and any reply would only be to tell other host connection was terminated.
https://tools.ietf.org/html/rfc5246#section-7.2.2

Found some technical info that may be useful regarding why the main Firebase or googleapis servers at 172.217.x.x and 216.58.x.x cause an Alert error message when trying to make an incoming TLS connection to my NVR. But the day that FB was down and something was going on with internet, my NVR packet capture shows it did not communicate with those normal address at all and firebase routed connection to and from my NVR through 64.233.177.95 instead.

I did find one website named threatcrowd .org that shows extensive reverse DNS information for any IP address you search there. Their reverse DNS shows firebase and googleapis accessible through the 64... address as well.

Found some pages below that might explain why my NVR was able to accept successful inbound TLSv1.2 connections from one Google server at 64.233.177.95. but not the ones at 172.217.x.x and 216.58.x.x. Most likely the 64... IP that worked for me is probably going through a different Google cloud server with no SSL Policy set so it would use a compatible policy by default. For how strict they want to be making TLSv1.2 connections they have a compatible, modern and restricted policies.

Google's SSL policy concepts are configurable by people that have a Google cloud account with them. Three TLS modes compatible, modern, and restricted. And the details for which type of encryption methods each accepts.
https://cloud.google.com/load-balancing ... s-concepts

My NVR and camera certificate are using sha256RSA and I am not sure of any other details about weather it uses any TLS_ECDHE_ECDSA. The dates are good on them as I used the create your own certificate option built in.

A link from the page above led to this information on Known Issues in Using SSL Policies. At the bottom of the web page below it says, Known issues, Load balancers that have no SSL Policy set presently allow four cipher suites to be used that are not usable when an SSL Policy is enabled. These cipher suites are:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
Google is deprecating support for these cipher suites. Over time they will no longer be supported with any load balancers.
https://cloud.google.com/load-balancing ... olicies#KI

If Amcrest has a gcloud account then it sounds like Amcrest might be able to set the SSL policy to what ever they want when the firebase or googleapis main servers try to connect out to individual servers running their application like on my NVR.

Not sure if this same error could be causing failure to receive phone push notification for other people but looks like could be contributing to it in my case. If only in my case then something would be wrong with my NVR, my network, my certificate or ISP or I could have a malware or something else on my network causing a problem with the connection.

Below are some pictures, first of TLS v1.2 failure message from inside a packet, from the main fcm or googleapis addresses that has the Alert message, Alert 21 and 0x0303. And a picture of an inbound connection not working with TLSv1.2 from a 216.58.x.x address. Also a picture of a successful TLSv1.2 inbound connection by the 64... address. In the picture the wireshark packet capture results from NVR are sorted by Protocol so they appear to be happening all in a row but they are actually mixed in with thousands of other connections NVR makes in a few minutes.

Alert error message type Alert 21 and 0x0303

TLS12Alert0x0303.jpg (15.25 KiB) Viewed 1369 times

TLS v1.2 not working from 216.58.x.x or 172.217.x.x

TLS12FailsSortByProtol.jpg (73.54 KiB) Viewed 1369 times

TLS v1.2 works when coming from 64.233.177.95 Notice the one address toward the bottom to/from 74.125.196.108 which I think is Gmail is also giving the alert message when these packets were captured. Which might be why it opened the 64.233.177.95 address as a second resort for Gmail.

TLS12worksSortByProto.jpg (109.2 KiB) Viewed 1369 times

Later the next day when alerts were (not) working to phone again NVR was connecting with either 216.58.x.x or 172.217.x.x and in log again giving the TLSv1.2 alert error. Packet capture log also showed 64.233.177.95 being used possibly related to Gmail in the log however the 216.58.x.x or 172.217.x.x addresses terminated the connection with firebase cloud messanging with the Alert error so it did not try to go through 64.233.177.95.

[Emahunter]

...We are having a hard time replicating the issue 100% within our office...

Does your office have any indication of what works and what doesn't? Notifications have always worked for me and still do. If a working scenario description would help you, let me know what info you would like to have.

I also have the same issue.

[brusters99]

I just started receiving push notifications clear out of the blue tonight. I have checked several of my cameras and the push notifications are being sent out from my NVR. My notifications had stopped around January 28th. I don't know if something has changed with a server at Amcrest or somewhere else along the routing. I just wanted to let everyone know who has had the same problem, that mine seems to be working. I just hope its not temporary like others have reported on this thread.

[brusters99]

One more thing. I just checked the Amcrest View Pro app on my Pixel 3, Android Ver 9 and checked the notification settings. All notifications are turned OFF. That seems very strange, but somehow the notifications are coming through.

[brusters99]

It's been a little less than three hours since I last posted that the push notifications were working again. Well, now they are not. Very frustrating!

[haw1144]

yeah mine briefly started working again this morning, and now stopped again.

[Systemuser]

Push notifications are working with their app update released March 29 2019, that updates it to Version 4.2.002

Newer phone had automatically installed the update to the app by itself so it did not show the update option when viewing this app in the play store.

On my older phones this app in Google Play store showed an update option to manually update the 2 older phones I had probably turned off automatic updates on.

On all 3 phones after it updates the app, just had to open the app on the phone and go to push notification configuration, to re enable the notifications how you want and click floppy disk icon to save. All 3 phones working over 12 hours now is a good sign.

Can also check app version from the app menu, under help - about, updated app version has build date 20190329

[cgeddis]

My notifications began working yesterday around 1:30pm EST. So far still working.