QR code of restored a lot of times device is not scanned

[VolodLytvynenko]

For reproduction use this seed phrase that belongs to account which has been restored lot of times on different devices: fossil mix then ocean garden bind torch season fire spider swim quarter

Steps:

1. Restore given above account on Device A
2. Generate sync QR on Device A
3. Scan sync QR on Device B
4. Observe the result

Actual result: QR code is not scanned.

https://user-images.githubusercontent.com/52490791/228206456-a7556eba-7545-4463-a1f4-183a32843241.mp4

Additional Information

• Status version: nightly
• Operating System: Android, iOS

Logs:

[Uploading Untitled document.txt…]()

[smohamedjavid]

Hi @Samyoul and @qfrank

We need your input on this issue.

I tried to reproduce the scenario and below are the logs from both Sender and Receiver.

SENDER

The account was recovered using the seed phrase in the issue description on an Android 13 Emulator running the debug app.

[Sat Apr 01 2023 23:30:27.786] INFO [status-im.native-module.core:276] - [native-module] Fetching Connection String {:fn :get-connection-string-for-bootstrapping-another-device, :config-json "{\"senderConfig\":{\"keyUID\":\"0x9a4072b136b1760a7b6475b29c8433d7b14fe01c227ccd3c17ef143bbfac95e9\",\"keystorePath\":\"\",\"password\":\"0x38301fb0b5fcf3aaa4b97c4771bb6c75546e313b4ce7057c51a8cc6a3ace9d7e\",\"deviceType\":\"android\"},\"serverConfig\":{\"timeout\":0}}"}
[Sat Apr 01 2023 23:30:28.461] INFO [status-im.signals.core:61] - local pairing signal received {:event {:type "connection-success", :action 2}}
[Sat Apr 01 2023 23:30:28.501] INFO [status-im.signals.core:61] - local pairing signal received {:event {:type "connection-success", :action 3}}
[Sat Apr 01 2023 23:30:28.509] INFO [status-im.signals.core:61] - local pairing signal received {:event {:type "connection-success", :action 4}}

NOTE: On the sender device, we are getting {:event {:type "connection-success", :action 4}} as soon as the QR is generated and displayed in the bottom sheet.

RECEIVER

Scanned the QR code on a Physical iOS device running the debug app.

[Sat Apr 01 2023 23:30:37.220] INFO [status-im.native-module.core:284] - [native-module] Sending Connection String {:fn :input-connection-string-for-bootstrapping, :config-json "{\"receiverConfig\":{\"kdfIterations\":3200,\"nodeConfig\":{\"ClusterConfig\":{\"Fleet\":\"status.prod\",\"DiscV5BootstrapNodes\":[\"enrtree://AOGECG2SPND25EEFMAJ5WF3KSGJNSGV356DSTL2YVLLZWIV6SAYBM@prod.nodes.status.im\"],\"WakuNodes\":[\"enrtree://AOGECG2SPND25EEFMAJ5WF3KSGJNSGV356DSTL2YVLLZWIV6SAYBM@prod.nodes.status.im\"],\"RendezvousNodes\":[],\"StaticNodes\":[],\"Enabled\":true,\"TrustedMailServers\":[],\"BootNodes\":[]},\"DataDir\":\"/ethereum/mainnet_rpc_dev\",\"LogLevel\":\"INFO\",\"WakuV2Config\":{\"Port\":0,\"AutoUpdate\":true,\"Nameserver\":\"1.1.1.1\",\"PeerExchange\":true,\"UDPPort\":0,\"Enabled\":true,\"Host\":\"0.0.0.0\",\"EnableDiscV5\":true,\"DiscoveryLimit\":20},\"Rendezvous\":false,\"LogEnabled\":true,\"BrowsersConfig\":{\"Enabled\":true},\"MailserversConfig\":{\"Enabled\":true},\"KeyStoreDir\":\"/keystore/\",\"RequireTopics\":{\"whisper\":{\"Min\":2,\"Max\":2}},\"WakuConfig\":{\"BloomFilterMode\":false,\"Enabled\":false,\"MinimumPoW\":0.000001,\"LightClient\":true},\"UpstreamConfig\":{\"Enabled\":true,\"URL\":\"https://eth-archival.gateway.pokt.network/v1/lb/3ef2018191814b7e1009b8d9\"},\"ListenAddr\":\":0\",\"PermissionsConfig\":{\"Enabled\":true},\"NetworkId\":1,\"MaxPeers\":20,\"Name\":\"StatusIM\",\"EnableNTPSync\":true,\"LogDir\":\"\",\"MaxPendingPeers\":20,\"NoDiscovery\":true,\"LocalNotificationsConfig\":{\"Enabled\":true},\"ShhextConfig\":{\"VerifyENSURL\":\"https://eth-archival.gateway.pokt.network/v1/lb/3ef2018191814b7e1009b8d9\",\"VerifyTransactionChainID\":1,\"BackupDisabledDataDir\":\"/\",\"InstallationID\":\"c85b3249-3d96-55b6-a0a5-9dd88183cd02\",\"DataSyncEnabled\":true,\"PFSEnabled\":true,\"MailServerConfirmations\":true,\"MaxMessageDeliveryAttempts\":6,\"VerifyTransactionURL\":\"https://eth-archival.gateway.pokt.network/v1/lb/3ef2018191814b7e1009b8d9\",\"VerifyENSContractAddress\":\"0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e\"},\"LogFile\":\"geth.log\",\"WalletConfig\":{\"Enabled\":true},\"StatusAccountsConfig\":{\"Enabled\":true}},\"settingCurrentNetwork\":\"mainnet_rpc\",\"deviceType\":\"ios\"}}", :connection-string "cs2:FpsyZ:BNr:21wHJfgeUjKxLGuduNCv4n5XvL9XiThwaE9psLNXSPgkM:CCB8BsXstEUNTzqexuS6jr5Pj96hWAbnSEpGMX8kx4sG"}
[Sat Apr 01 2023 23:31:52.470] INFO [status-im2.contexts.syncing.events:50] - Initiated local pairing {:response "{\"error\":\"dial tcp 10.0.2.16:34907: connect: operation timed out\"}", :event :syncing/input-connection-string-for-bootstrapping}
[Sat Apr 01 2023 23:31:52.520] INFO [status-im.signals.core:61] - local pairing signal received {:event {:type "connection-error", :error "dial tcp 10.0.2.16:34907: connect: operation timed out", :action 1}}

The receiver is getting a connection-error signal with the error dial tcp 10.0.2.16:34907: connect: operation timed out. But, both devices are connected to the same WiFi network.

[Samyoul]

Hey @smohamedjavid thank you for the ping on this.

[Sat Apr 01 2023 23:30:27.786] INFO [status-im.native-module.core:276] - [native-module] Fetching Connection String {:fn :get-connection-string-for-bootstrapping-another-device, :config-json "{\"senderConfig\":{\"keyUID\":\"0x9a4072b136b1760a7b6475b29c8433d7b14fe01c227ccd3c17ef143bbfac95e9\",\"keystorePath\":\"\",\"password\":\"0x38301fb0b5fcf3aaa4b97c4771bb6c75546e313b4ce7057c51a8cc6a3ace9d7e\",\"deviceType\":\"android\"},\"serverConfig\":{\"timeout\":0}}"}
[Sat Apr 01 2023 23:30:28.461] INFO [status-im.signals.core:61] - local pairing signal received {:event {:type "connection-success", :action 2}}
[Sat Apr 01 2023 23:30:28.501] INFO [status-im.signals.core:61] - local pairing signal received {:event {:type "connection-success", :action 3}}
[Sat Apr 01 2023 23:30:28.509] INFO [status-im.signals.core:61] - local pairing signal received {:event {:type "connection-success", :action 4}}

NOTE: On the sender device, we are getting {:event {:type "connection-success", :action 4}} as soon as the QR is generated and displayed in the bottom sheet.

Ah, this is interesting and this is a bug. But it shouldn't be causing a connection issue. I will write a fix for this, it is simple to fix this particular issue. Thank you for spotting and reporting this.

---

The other issue, the real problem maybe more difficult to resolve. It will require some additional diagnosis. We need to check if both devices truly are on the same network.

IP address 10.0.2.16 is a valid private network address, but the emulator may be listening on a different network to the network the client device is making requests to.

I can write a diagnostic tool for debugging the network id. If this is the same, then we can try some simpler listening and requesting. But this will need specific tooling to be embedded into the app, which isn't a problem to implement, just will take a few hours to write.

[qfrank]

As far as I know, the network system of the Android emulator is different from that of the iOS emulator by default. When the app is running on the iOS emulator and listening on port e.g. 8080(we use random port for local pair,8080 is just an example), we can communicate with it using the telnet command on the local machine (such as a Mac) to connect to port 8080. However, when the app is running on the Android emulator and listening on port 8080, we cannot communicate with it directly using telnet on the Android emulator. We need to use "adb tcp forward" to expose port 8080 on the Android emulator to the local machine. The network system of an Android physical device is more similar to that of the iOS emulator, unlike the Android emulator. I guess this issue reported only exist when android simulator used as server? @smohamedjavid @VladimrLitvinenko

[qfrank]

if this is the case ( we used android simulator as server for local pairing test) , i suggest not fix it since it depends on how android emulator network works, and this issue won't/shouldn't exist for real android device. Or @Samyoul do you have better solution?

[smohamedjavid]

Yes @qfrank, The network system of Android Emulators is indeed different. We need to use adb tcp forward to expose port 8080. I did use them during the test to see the logs https://github.com/status-im/status-mobile/issues/15512#issuecomment-1493395214. Got no luck.

I checked now with a nightly build (generated locally and run on a physical android device) and tried to sign in on an iOS device by scanning the sync QR code. It paired successfully.

I don't know for some reason, it didn't work yesterday for me when I used the nightly build, and we can confirm the Android Emulators are causing issues on pairing due to the network system.

From the video attachment (in the issue description), it seems the sender is on iOS, and the receiver is on Android. I tried that scenario too. I recovered the account using the seed phrase in the issue description. Tried to sync/pair. It works as expected.

Thanks, @Samyoul @qfrank for the quick response.

@VladimrLitvinenko Can you help us check again with the latest nightly builds?

[Samyoul]

I agree @qfrank, and in this case this is not only a wontfix but a "shouldn't fix" 😂.

@smohamedjavid if you have the tools already to find the network SSID then I don't need to add anything right now. Although when this goes in to full production I wonder if having embedded network detection would be useful to show to the user. Something like:

Device (client) could not connect to counterpart (server), please check devices are on the same network.
This device is currently on network `some network SSID`

Have a small bit of text always showing network SSID of the server on server device.

This could be a pain though because we'd need to write network drivers for each device type, including the three desktop types. It is doable, I've got code working for Linux and Darwin. We'd just need to check the application OS and switch based this value.

The pain would come if the same os implementation uses different commands to get the network SSID.

But I'm pleased this isn't a blocker right now.

Edit: maybe I spoke too soon.

[VolodLytvynenko]

@VladimrLitvinenko Can you help us check again with the latest nightly builds? @Samyoul just a moment

if this is the case ( we used android simulator as server for local pairing test) , i suggest not fix it since it depends on how android emulator network works, and this issue won't/shouldn't exist for real android device. Or @Samyoul do you have better solution?

Hi @qfrank For reproducing this issue I used real devices.

• Huawei p20 light, android 9;
• iPhone 11 Pro max, IOS 16.

I used the case when android performed to generate the QR code and IOS scenes. And the case when IOS generates then Android scans. In both cases, this issue reproduced

[VolodLytvynenko]

@VladimrLitvinenko Can you help us check again with the latest nightly builds?

Hi @smohamedjavid . Yes, just a moment

[Samyoul]

@VladimrLitvinenko Can you help us check again with the latest nightly builds? @Samyoul just a moment

if this is the case ( we used android simulator as server for local pairing test) , i suggest not fix it since it depends on how android emulator network works, and this issue won't/shouldn't exist for real android device. Or @Samyoul do you have better solution?

Hi @qfrank For reproducing this issue I used real devices.

• Huawei p20 light, android 9;
• iPhone 11 Pro max, IOS 16.

I used the case when android performed to generate the QR code and IOS scenes. And the case when IOS generates then Android scans. In both cases, this issue reproduced

Do you use the ios emulator with a real android device? Or are you using 2 real devices for test?

So you are using no emulators in the tests you have issues with?

[qfrank]

@VladimrLitvinenko Can you help us check again with the latest nightly builds? @Samyoul just a moment

if this is the case ( we used android simulator as server for local pairing test) , i suggest not fix it since it depends on how android emulator network works, and this issue won't/shouldn't exist for real android device. Or @Samyoul do you have better solution?

Hi @qfrank For reproducing this issue I used real devices.

• Huawei p20 light, android 9;
• iPhone 11 Pro max, IOS 16.

I used the case when android performed to generate the QR code and IOS scenes. And the case when IOS generates then Android scans. In both cases, this issue reproduced

are these 2 devices in the same network? did they connect the same WIFI? can you check the network setting to see what's the IP for each devices? thank you @VladimrLitvinenko

[VolodLytvynenko]

@Samyoul @qfrank @smohamedjavid just checked it on the latest nightly. It is not reproducible anymore!

[VolodLytvynenko]

Do you use the ios emulator with a real android device? Or are you using 2 real devices for test?

So you are using no emulators in the tests you have issues with?

@Samyoul I used 2 real devices when reported this issue. For now, it is not reproducible anymore when real devices are used

[smohamedjavid]

@smohamedjavid if you have the tools already to find the network SSID then I don't need to add anything right now. Although when this goes in to full production I wonder if having embedded network detection would be useful to show to the user. Something like:

Device (client) could not connect to counterpart (server), please check devices are on the same network.
This device is currently on network `some network SSID`

Have a small bit of text always showing network SSID of the server on server device.

This could be a pain though because we'd need to write network drivers for each device type, including the three desktop types. It is doable, I've got code working for Linux and Darwin. We'd just need to check the application OS and switch based this value.

The pain would come if the same os implementation uses different commands to get the network SSID.

@Samyoul We have an existing library (https://github.com/react-native-netinfo/react-native-netinfo) which we use to listen for a network state change. It that can be used to fetch network details but fetching network SSID on iOS need at least one permission and Android requires the user to accept the location permission (https://github.com/react-native-netinfo/react-native-netinfo#type-is-wifi) which might potentially create unhappy flows (For a user who is entering the sign-in flow If we ask the location permission, and the user denies it. The SSID would be an empty string). Maybe for now, we will place a generic text like Make sure both devices are connected to the same network below the QR scanner (Receiver) and below the QR code (Sender).