Publish wifi client address (until connection)

[jeffkowalski]

This is less likely an issue on these scenarios:

1. when the sotacat joins an existing home wifi network
2. when the sotacat creates its own access point (discoverable at 192.168.4.1), but not availing split networking on android (sigh)
3. when the sotacat joins a hotspot on apple devices, where it's discoverable as sotacat.local

The chief issue is

• when sotacat joins a hotspot on android devices, in order to provide split networking, but doesn't advertise it's client IP

There's no good way, currently, of determining the IP addr of the sotacat as it is presented on the hotspot. Therefore there's no reliable address to which to connect. Fortunately it does have a lifetime, so if observed in the serial logs while connected to PC, it could be a basis for subsequent connection, but that's really terrible.

Proposal here is to scroll the IP address of the SOTAcat on the VFOb display until a connection from client (e.g. webserver request) is made.

[brianmathews]

I have a Samsung Android phone and sotacat.local works on it. So is there some way to get other Android phones to do what the Samsung phones do? Are there 3rd party mDNS clients we could use?

Using the KX display would be cool if you know how to do that. But then you have to type in the address each time rather than having a shortcut that can be reused.

[jeffkowalski]

Two issues conflating here:

1. resolving name to ip addr
2. split networking

Yes, there are some ways to get android to resolve sotacat.local to the address of the sotacat when it's working in AP mode. But then, the android will direct all traffic there, and won't allow simultaneous split network access to the "outside" so that all the other functions of the sotacat page (like the spot list!) will silently fail.

Instead, we can connect the sotacat to the android-published hotspot - as a client of that hotspot. This allows the sotacat to communicate with the outside world just fine.
...If only we could figure out where the sotacat was from the point of view of the hotspot-serving device. It seems to hop around.

That's the central issue - when the sotacat connects to an android hotspot, how can the android user find the sotacat's client IP?

[brianmathews]

I think I have the solution, at least it works on my Samsung Android phone:

1. On the Android phone, go to the Google Play Store, and install the app called "Bonjour Browser" by "wellenvogel"
2. Start with a fresh firmware flash of the SOTACAT to factory settings. You can do this on https://sotamat.com/sotacat and use the Firmware button. This will completely erase all the settings including the WiFi SSID's and Passwords.
3. Reboot the SOTACAT (power off, then on)
4. With a factory default configuration, the SOTACAT will fail to find WiFi Client-1 and will fail to find WiFi Client-2. It will then time out and create its own WiFi Access Point (a WiFi hotspot), where the SSID is in the form "SOTACAT_xxxx" where "xxxx" is the serial number for the SOTACAT.
5. On the Android phone, go to Settings --> Wifi --> and connect to the SSID "SOTACAT_xxxx" with the default SOTACAT password of "12345678"
6. Once connected to the SOTACAT WiFi on the Android, run the "Bonjour Browser" app and locate the entry for "SOTAcat SOTAmat Service". Click on it to open your web browser to that URL (with the correct dynamically assigned IP address).
7. With the Android Web Browser open your should see the SOTACAT user interface. At the bottom of the screen click on the "Settings" button.
8. Follow the instructions to program the SOTACAT with the 3 WiFi settings:
   • Client 1: fill in the info for your home network (optional, and for testing how it will work in the field you might want to leave blank so that it does not connect to your home network)
   • Client 2: fill in the info for your Android phone's mobile Hotspot with a Network name and Password (for example "ham-hostspot" and "sotapota"). You can find your Android hotspot settings under Settings --> Connections --> Mobile Hotspot and Tethering --> Mobile Hotspot --> etc.
   • Server: leave as-is
   • click the "Save" button.
9. On the Android phone, configure your "mobile Hotspot" under Settings --> Connections --> Mobile Hotspot and Tethering --> Mobile Hotspot --> turn on and set your "Network Name" to the same setting as the Client-2 SSID (ex. "ham-hotspot") and the Client-2 "Password" (ex. "sotapota") you programmed into the SOTACAT. Turning on Mobile Hotspot mode on the Android will turn off your WiFi connection to the SOTACAT's "access point" mode.
10. Reboot (power off, then on) your SOTACAT. This time when it boots it should connect to your Android Phone's Mobile Hotspot using the Client-2 settings (unless it first connects to your Client-1 home network -- but your can force Client-1 to fail by walking out of range of your house or by setting Client-1 with the wrong password). So rather than the SOTACAT creating its own hotspot and having the Android phone connect to the SOTACAT, it should now be reversed and the SOTACAT should connect to your Android phone's hotspot.
11. Open the "Bonjour Browser" app on the Android phone and click on the entry for the "SOTAcat SOTAmat Service". This will open a web browser to the URL for the SOTACAT, and the URL will have the dynamically created IP address for the SOTACAT as connected to your cell phone's hotspot.

[brianmathews]

To make things easier on novice users, I updated the firmware with a WiFi Client-2 default SSID of "ham-hotspot" and Password of "sotapota" in commit 38a66f6. This allows Android users to avoid having to program the SOTACAT, and all they need to do is configure their Android hotspot settings to match the defaults.

[jeffkowalski]

This is good sleuthing, Brian. I will try it out. I prefer to have the phone hotspot on client 1 since that's the one I use most of the time in the field. At home, it's OK to wait the extra seconds to have it time out past that and find my home network on client 2. I would think that most folks wouldn't need to have it connect to home network, except for testing, or, like us few, for programming.

…

On Sun, Apr 21, 2024 at 4:00 PM Brian Mathews ***@***.***> wrote: To make things easier on novice users, I updated the firmware with a WiFi Client-2 default SSID of "ham-hotspot" and Password of "sotapota" in commit 38a66f6 <38a66f6>. This allows Android users to avoid having to program the SOTACAT, and all they need to do is configure their Android hotspot settings to match the defaults. — Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAN4MCNMLMIP533TUDGA7LY6RAINAVCNFSM6AAAAABGMSE4QCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRYGI2DAOJUGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[brianmathews]

Feel free to swap them. I just want a reasonable default so that people can skip having to connect to the ESP32 as a Server, and instead just set up their Android hotspot to advertise an SSID/Password that the SOTACAT is expecting by default. Saves a lot of steps that way.

[brianmathews]

Made the following changes in commit 51a9133

• Flipped the default mobile hotspot settings from Client-2 to Client-1.
• Now by default Client-2 is for the home network (optional).
• Updated the web page instructions for configuring the settings.
• Changed the "Save Settings" button to be a "Save and Reboot" so that you don't have to manually power down the SOTACAT when changing settings.

Just need you to test.

[brianmathews]

Made changes to the Setup and WiFi code in commits adde9a4 84b5da8 1b0b670

• Setup now starts two "tasks" (RTOS threads) that run in parallel:
  • One for the WiFi connection handling
  • One for Radio connection handling
• Setup blocks for a WiFi connection to be established, then blocks on the Radio connection task
• The WiFi code is a lot more sophisticated. The problem this solves is Android users who depend on a hotspot might first turn on the SOTACAT and then might turn on their Android hotspot later. To make sure the order doesn't matter we now:
  • Put the ESP32 into dual-networking mode where it is both an access point (AP mode) and a station client (STA mode) simultaneously.
  • Have the ESP32 boot into AP mode and dwell for a bit while initialization happens
  • Have the ESP32 continuously attempt to connect to SSID1 and SSID2 in order, with timeouts and idle time between attempts
  • Handle cases where a disconnect happens: the disconnect event puts the system back into hunting mode.
  • Whenever a connection is made, the other types of connections are stopped to save power.