clariusdev / solum

APIs for OEMs to Create Standalone Applications
https://www.clarius.com
BSD 3-Clause "New" or "Revised" License
16 stars 10 forks source link

Solum does not connect when networkId is Optional.empty #25

Closed tbjoern closed 1 year ago

tbjoern commented 1 year ago

Describe the bug

When passing Optional.empty() as the networkId to solum.connect, the connection always times out.

Expected behavior

Solum connects to the probe using the default network when Optional.empty() is passed as networkId. It should behave the same way as solum.connect in version 10.1.1.

Environment:

julien-l commented 1 year ago

Hi the network id is mandatory when doing wifi auto-join, omit the network id only if manually connecting to the probe's wifi. Can you confirm:

  1. you are joining the probe's wifi manually (from the device's wifi settings) and not doing auto-join
  2. the probe's wifi is detected by your android device (I noticed some android devices have stopped detecting the probe's wifi since early February, still under investigation)
  3. can you reproduce with the example app in this repo?
tbjoern commented 1 year ago

Hi Julien,

our logic connects to the wifi through an ad-hoc network, similar to the clarius app. With 10.1.1 I was using connectivityManager.bindProcessToNetwork(network) to ensure that solum was connecting through the ad-hoc wifi network. That worked well. With 10.2.2 the connection attempt now times out when using the same setup and passing in Optional.empty() as networkId.

When I pass in the network id from the ad-hoc network it connects as expected.

I'll have a look at the example app and report back.

tbjoern commented 1 year ago

I tested with the example app, can connect with manual connection and no networkId. I guess connectivityManager.bindProcessToNetwork(network) stopped working for some reason?

julien-l commented 1 year ago

The new version of solum does the binding for you now, pass Network.getNetworkHandle() as the network id in the connect() function.

In solum 10.1.1, the network id was hardcoded to 0 internally, in solum 10.2.2 we added a public parameter to specify that network id and if omitted, it defaults to 0 to maintain the previous behaviour. I am not sure why your workflow fails now. Is it acceptable to omit the call to bindProcessToNetwork() in your workflow?

Edit: all versions of solum were attempting to do the binding for you by calling android_setsocknetwork(). In solum 10.1.1 and earlier, the network id was hardcoded to 0, solum 10.2.2 simply added a parameter to let you specify a network id when doing auto-join. If you pass an empty optional, then the network id will default to 0, thus retaining the previous behaviour. For this reason I am not sure why your workflow fails after the update. You can try to omit your call to bindProcessToNetwork(network) and instead, pass the value of network.getNetworkHandle() to solum's connect() function.

tbjoern commented 1 year ago

Yes, I opted to pass the network handle now, that works. Very strange that bindProcessToNetwork stopped working. Anyways, thanks for looking into it!