Systemuser wrote: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.