Can't establish a network connection when Watch is tethered to a Phone over Bluetooth

Hey Everyone,

The problem I am encountering is related to making an outgoing network connection via HTTPS over a Bluetooth connection between a watch app and a phone connecting via LTE to the cell network.

The code running on the watch creates an HTTPS connection easily when the watch is connected directly to Wifi, however, as soon as Wifi drops and a Bluetooth connection to a phone takes over, the connection cannot be established.

From what I have read in the docs, it looks like we have to treat the Bluetooth connection as an HTTP proxy that will tunnel the HTTPS connection to our target server. Is this correct, or is there another way to establish a network connection across the Bluetooth tether? I’m using the MbedTLS library for the network connection and it doesn’t directly support using a proxy, so that’s why I am asking.



If your app wants to receive/send http/https data packets when the watch is paired with mobile phone, you can check web proxy.
Here you will find the guideline-

Thanks, yeah, I did find that tutorial. Samsung support confirms that when tethered to a phone using Bluetooth, one has to use a web proxy (which is provided by the Wearable tethering app on the phone).

In I found this Note: “To handle HTTP and HTTPS requests in a proxy environment, get the proxy address using the Connection Manager and then set the proxy address using the Connection Profile API (in mobile and wearable applications). For libcurl, you can use the CURLOPT_PROXY option.”

So, based on this, it sounded like I needed to create a connection profile for bluetooth tether (ETHERNET type), then set the proxy in the profile before using it to connect to the network. This sounded a lot easier than writing the proxy code myself, so that’s what I tried. There does not seem to be a tutorial about creating new connection profiles, but this one provides sample code to access the default profile, so it will serve as a good starting point:

After grabbing the default profile and checking its properties, I realized that when tethered to a phone over BT using the Galaxy Wearable app on the phone, the default profile automatically switches to this connection and provides a web proxy. In either case, with a proxied profile in hand, it turns out you still need to use a library that supports HTTP proxies or write your own code to send the HTTP CONNECT message and then allow the proxy tunnel to provide the socket for writing.

On a side note, a workaround is to establish a Wifi hotspot on the phone, and connect to the closed Wifi network of the phone from the watch. This allows the web traffic from the watch to use the cellular connection of the phone for Internet. It unfortunately uses more power than Bluetooth, but it will work without any extra coding on the app.

Without knowing much about mbed TLS, it sounds as if that is sitting in the SSL/TLS layer which wouldn’t be responsible for managing a proxy connection.

If that’s the case then you’d have to handle your proxy connection higher up in the stack. If you’re hand-rolling something higher up in the stack proxy connections are not that difficult to implement.

I think the only difference between a regular connection and a proxy connection is that you pass in the url of the proxy server and pass in your target URL in the header of your request. For a little bit more work you can add basic authentication for proxy servers but the proxy that your watch is using does not require authentication.

I had similar problems and after a lot of testing and consulting different experts, the best solution was the one they told you before, connecting it through a closed Wi-Fi network. porno gratis Or what is the same, that the watch is connected to the phone through bluetooth and then share the data network or wifi with it, in this way you can be safe against possible external threats and you can do all kinds of tests to check if it really works. porno gratis The proxy is another possible solution, but from my point of view it is more complicated and less economical.

In this particular case, the embedded AWS IoT MQTT SDK is using the TLS layer to provide the basic socket, so I needed to add the proxy code at the lower layer, which I did. Not too much code to implement, as you mention. Just had to pass the proxy host and port down from the Tizen profile through AWS IoT SDK to the underlying TLS layer, write an HTTP CONNECT message to the proxy, read the 2xx response from the proxy to indicate a tunnel has been established, then pass the socket back to AWS. About 70 lines of code at the lowest level.

It is a bit more complicated, but the BT connection saves on battery and the watch will automatically prefer that connection to Wifi if it can establish it. It’s also a bit less complicated for end users as they do not have to create Wifi hotspots and maintain them on their phones. Now that I have it working, it is actually very slick and seamless, as it uses the mechanisms created by the Wearable app on the phone.

The only thing that made this more complicated for me was that I was not using one of the higher level HTTP client libraries that often support proxies themselves without depending on the lower layer protocols (example: Curl).

1 Like