Blocking app-measurement.com breaks realtime-database connection during push notification processing

[kernel-sanders]

Issue

When processing a push notification, I am updating an entry in my realtime-database. During testing, this would work ~1/2 the time. Digging into the console logs, it appears as if react-native-firebase is trying to re-use an old TCP connection to firebase, and after some time (~5 to 10 minutes) that connection is stale and does not work. Instead of opening a new connection and completing the update to the database, it simply fails. I believe this is because the device is on a network with a Pi-Hole which sinkholes app-measurement.com and e.crashlytics.com. The react-native-firebase library attempts to connect to app-measurement.com for the analytics, but if it can't it does not continue with any other connections? I believe this is a bug. If the analytics connection fails, the database update should occur anyway. Whitelisting e.crashlytics.com resolves the issue.

AppDelegate.m

- (void)application:(UIApplication *)application didReceiveLocalNotification:(UILocalNotification *)notification {
  NSLog(@"Got Local Notification");
  [[RNFirebaseNotifications instance] didReceiveLocalNotification:notification];
}

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(nonnull NSDictionary *)userInfo
fetchCompletionHandler:(nonnull void (^)(UIBackgroundFetchResult))completionHandler{
  NSLog(@"Got Remote Notification");
  [[RNFirebaseNotifications instance] didReceiveRemoteNotification:userInfo fetchCompletionHandler:completionHandler];
}

- (void)application:(UIApplication *)application didRegisterUserNotificationSettings:(UIUserNotificationSettings *)notificationSettings {
  NSLog(@"Got User Notification");
  [[RNFirebaseMessaging instance] didRegisterUserNotificationSettings:notificationSettings];
}

Message handler code:

// Subscribe to push notifications for background notifications (priority 10 with alert)
firebase.notifications().onNotificationDisplayed((notification: Notification) => {
      console.log('onNotificationDisplayed');
      console.log(notification);
      firebase.database().ref(`/users/${currentUser.uid}`).update({ lastMessage: notification });
      firebase.database().ref(`/users/${currentUser.uid}/lastMessage`).update({ type: 'onNotificationDisplayed' });
      firebase.database().ref(`/users/${currentUser.uid}/lastMessage`).update({ timestamp: new Date() });
});

First push console logs (successful database update):

default	10:29:50.084513 -0400	appname	Got Remote Notification
default	10:29:50.084560 -0400	appname	Unknown aps key: content-available
default	10:29:50.338727 -0400	appname	TCP Conn 0x1c417e900 event 1. err: 0
default	10:29:50.338821 -0400	appname	TCP Conn 0x1c417e900 complete. fd: 8, err: 0
default	10:29:50.338861 -0400	appname	TCP Conn 0x1c417e900 starting SSL negotiation
default	10:29:50.432625 -0400	appname	TCP Conn 0x1c417e900 SSL Handshake DONE
default	10:29:50.699275 -0400	dasd	COMPLETED com.apple.pushLaunch.com.companyname.appname:97F734 <private>!

Second push console logs (no database update - URL redacted):

default	10:44:31.643363 -0400	appname	Got Remote Notification
default	10:44:31.643430 -0400	appname	Unknown aps key: content-available
default	10:44:31.643681 -0400	appname	[com.companyname.appname] Did deliver 1 notifications
error	10:44:31.914655 -0400	appname	nw_socket_get_input_frames recvmsg(fd 6, 1024 bytes) [57: Socket is not connected]
default	10:44:31.916060 -0400	appname	TCP Conn 0x1c417cf80 canceled
default	10:44:31.916820 -0400	appname	[12 s-usc1c-nss-211.firebaseio.com:443 stream, pid: 45453, traffic class: 200] cancelled
	[12.1 9C21CD12-026B-45CC-9091-D0A3A27FE0C3 10.42.5.54.49602<->35.201.97.85:443]
	Connected Path: satisfied (Path is satisfied), interface: en0, ipv4, dns
	Duration: 225.976s, DNS @0.000s took 0.275s, TCP @0.277s took 0.024s
	bytes in/out: 0/0, packets in/out: 0/0, rtt: 0.000s, retransmitted packets: 0, out-of-order packets: 0
default	10:44:31.921393 -0400	appname	TIC Enabling TLS [11:0x1c4360540]
default	10:44:31.921525 -0400	appname	TIC TCP Conn Start [11:0x1c4360540]
default	10:44:31.921972 -0400	appname	Task <09C17321-38DB-417C-8E2B-5768DF7E15B0>.<1> setting up Connection 11
default	10:44:31.922181 -0400	appname	[14 app-measurement.com:443 stream, pid: 45453, url: https://app-measurement.com/config/app/1:XXXXXXXX:ios:XXXXXXXXXX?platform=ios&app_instance_id=XXXXXXXXXXXXXXXXXX, tls] start
default	10:44:31.970071 -0400	appname	TIC TCP Conn Event [11:0x1c4360540]: 3
error	10:44:31.970126 -0400	appname	TIC TCP Conn Failed [11:0x1c4360540]: 1:61 Err(61)
default	10:44:31.970180 -0400	appname	TIC TCP Conn Cancel [11:0x1c4360540]
error	10:44:31.970439 -0400	appname	Task <09C17321-38DB-417C-8E2B-5768DF7E15B0>.<1> HTTP load failed (error code: -1004 [1:61])
default	10:44:31.970591 -0400	appname	[14 app-measurement.com:443 stream, pid: 45453, url: https://app-measurement.com/config/app/1:XXXXXXXXX:ios:XXXXXXXXXXXX?platform=ios&app_instance_id=XXXXXXXXXXXXXXXXXX, tls] cancelled. Events:
default	10:44:31.970682 -0400	appname	0.000s [14 1218D1F1-C727-4CA6-AB5D-A9242D8939C0 app-measurement.com:443 resolver] path:start
default	10:44:31.970742 -0400	appname	0.000s [14 1218D1F1-C727-4CA6-AB5D-A9242D8939C0 app-measurement.com:443 resolver] path:satisfied
default	10:44:31.970820 -0400	appname	0.000s [14 1218D1F1-C727-4CA6-AB5D-A9242D8939C0 app-measurement.com:443 resolver] resolver:start_dns
default	10:44:31.970873 -0400	appname	0.036s [14 1218D1F1-C727-4CA6-AB5D-A9242D8939C0 app-measurement.com:443 resolver] resolver:receive_dns
error	10:44:31.970981 -0400	appname	Task <09C17321-38DB-417C-8E2B-5768DF7E15B0>.<1> finished with error - code: -1004
default	10:44:31.971021 -0400	appname	0.037s [14.1 AC9AE0D8-8A86-46EE-B65C-1723D8BA10DE 10.42.5.54:56308->10.42.5.8:443 channel-flow] path:start
default	10:44:31.971183 -0400	appname	0.038s [14.1 AC9AE0D8-8A86-46EE-B65C-1723D8BA10DE 10.42.5.54:56308->10.42.5.8:443 channel-flow] path:satisfied
default	10:44:31.971359 -0400	appname	0.039s [14.1 AC9AE0D8-8A86-46EE-B65C-1723D8BA10DE 10.42.5.54:56308->10.42.5.8:443 channel-flow] flow:start_nexus
default	10:44:31.971399 -0400	appname	0.039s [14.1 AC9AE0D8-8A86-46EE-B65C-1723D8BA10DE 10.42.5.54:56308->10.42.5.8:443 channel-flow] flow:receive_nexus
default	10:44:31.971643 -0400	appname	0.043s [14.1 AC9AE0D8-8A86-46EE-B65C-1723D8BA10DE 10.42.5.54:56308->10.42.5.8:443 channel-flow] flow:start_connect
default	10:44:31.971678 -0400	appname	0.047s [14.1 AC9AE0D8-8A86-46EE-B65C-1723D8BA10DE 10.42.5.54:56308->10.42.5.8:443 channel-flow] flow:failed_connect Error Domain=kNWErrorDomainPOSIX Code=61 "Connection refused" UserInfo={NSDescription=Connection refused}
default	10:44:31.971733 -0400	appname	0.047s [14 1218D1F1-C727-4CA6-AB5D-A9242D8939C0 app-measurement.com:443 resolver] resolver:children_failed
default	10:44:31.971767 -0400	appname	0.048s [14] path:cancel
default	10:44:32.052176 -0400	dasd	COMPLETED com.apple.pushLaunch.com.companyname.appname:4C6488 <private>!

Environment

1. Application Target Platform:

    iOS
   

2. Development Operating System:

    macOS High Sierra, 10.13.6
   

3. Build Tools:

    Xcode 9.4.1 (9F2000)
   

4. React Native version:

    0.54.2
   

5. React Native Firebase Version:

    4.3.8
   

6. Firebase Module:

    database/messaging
   

7. Are you using typescript?

    no
   

[Salakar]

My initial looking through the iOS SDK code indicates that app-mesaurement.com is also used for network reachability testing:

https://github.com/firebase/firebase-ios-sdk/blob/master/GoogleUtilities/Network/GULNetwork.m#L248
and
https://github.com/firebase/firebase-ios-sdk/blob/master/GoogleUtilities/Network/GULNetworkConstants.m#L24

, which is why other services like database are failing most likely - I think. 🙈

cc @wilhuff & @paulb777 from the firebase/firebase-ios-sdk GitHub repo - any thoughts on this issue?

[wilhuff]

Preliminarily I'd consider this a bug in your filter configuration in Pi-hole. There's a major difference between third-party non-consensual ad-serving/tracking, and first-party app analytics/crash reporting that happens to be implemented with Firebase.

Our disposition is not to fight against ad blockers or otherwise hostile networks. We don't use them, we don't test them, etc. We're not opposed to making our software work better in their presence, but this is not a priority for us--there's only so many hours in the day.

If you're interested in making this better, pull requests are welcome.

[bobobo1618]

@wilhuff as someone who actively blocks traffic like this on-device, I'd be interested in making this work. Would you accept a PR that simply changes the host to connectivitycheck.gstatic.com or captive.apple.com? That seems like a simple way to solve both issues.

[Salakar]

I'm gonna close this issue as it's not related to this library, we only consume the official Firebase SDKs, any changes would need making there.

Feel free to continue discussing though.

[wilhuff]

@bobobo1618 that's not really my call. @paulb777 what's your take?

If this is going to get anything past spitballing I'd suggest moving this discussion to an issue/PR in the firebase-ios-sdk repo.

[paulb777]

@bobobo1618 At first glance, I suspect we would accept such a PR. However, we'd need to do a bit more investigation and get a few more reviewers/approvers.

Please create an issue or PR at https://github.com/firebase/firebase-ios-sdk with details about the issue and why the proposed hosts would address it along with any trade-offs between the two.

[bobobo1618]

Thanks @paulb777, I created firebase/firebase-ios-sdk#2254.