Reconnect wifiandheadunit #50

Ioniq3 · 2024-02-11T09:51:28Z

With these modifications, the device receives:

If the initial connection between the head unit and the dongle/phone fails due to a timeout or similar issue, the code now retries the entire process after 30 seconds if the channel is not established. This should be sufficient for the majority of head units.

If the Wi-Fi connection between the dongle and the phone is interrupted and not recovered, for example, if you leave the car for a shorter period than the time needed for the car to power off the dongle, the process will attempt to reconnect every 30 seconds to restore communication when you return to the car.

After some tests, it was found that it works better without the "Connect to USB after phone connection is available" e511b7c commit, so please conduct your own tests accordingly.

It's no longer necessary to use an external program as in the previous pull request.

nisargjhaveri · 2024-02-11T12:06:09Z

aa_wireless_dongle/package/aawg/src/proxyHandler.cpp

+        .tv_sec = 30
+    };
+
+   if (setsockopt(server_sock, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv))) {


Curious: If we're using select before accept, how does setting this help or make a difference?

accept is a unlimited time blocking function as it read information while select can manage a timeout because select only detect that the is information but not read it

nisargjhaveri · 2024-02-11T12:07:01Z

aa_wireless_dongle/package/aawg/src/usb.cpp

@@ -77,6 +77,9 @@ void UsbManager::disableGadget() {
    disableGadget(accessoryGadgetName);

    Logger::instance()->info("USB Manager: Disabled all USB gadgets\n");
+
+    enableGadget(defaultGadgetName);


Why is this required? We generally want to keep usb disabled until we have the phone connection ready to work around headunit timeouts.

it depends of the head unit makes the timeout, in my case, in hyundai, i need to have the usb connect (and disabled and enable) or it will never try again if you enabled after "large" time disabled. In this particular headunit works better without the "Connect to USB after phone connection is available" e511b7c commit ; but maybe it this not general behavior buy I don't have other cars to test.

In my own personalization I managed/test this commit controlled by a enviroment variable with this code:

if (const char* env_p = std::getenv("HEADUNIT_FIRST")) { UsbManager::instance().enableDefaultAndWaitForAccessroy(); }

Maybe its easier if file is present in /boot partition, as this can be edited from the pc prior to install the sdcard...

touch /boot/HEADUNIT_FIRST

Yes, it's another way.
So thanks you for your ideas on personalization, I get some of them and add to /etc/init.d/S93aawgd the following lines in my branch personalization:

xx=$(ls /var/lib/bluetooth/ | awk -F':' '{print $4$5$6 }' | tr [[:upper:]] [[:lower:]] | tr -d '\n') export ADAPTER_ALIAS=AndroidAuto_$xx export AAWG_WIFI_SSID=AndroidAuto_$xx export AAWG_WIFI_PASSWORD=1234567890 export HEADUNIT_FIRST=1

before start-stop-daemon -S -b -q -m -p "$PIDFILE" -x "/usr/bin/$DAEMON"

We can have an env file in /boot or somewhere else and source it if that works. We should ideally have a nicer ini config file, but for now env variables might be easier to get started with.

nisargjhaveri · 2024-02-11T12:17:30Z

aa_wireless_dongle/package/aawg/src/proxyHandler.cpp

+       break;
+      }
+    }
+
    if ((m_tcp_fd = accept(server_sock, &client_address, &client_addresslen)) < 0) {


Don't we need to set send and recieve timeouts to the client connection socket so that it closes when the phone goes away after connection?

this break happens when there is data to read before timeout occurs, going out the while to the accept function

nisargjhaveri · 2024-02-11T12:19:16Z

aa_wireless_dongle/package/aawg/src/proxyHandler.cpp

@@ -138,13 +161,17 @@ void AAWProxy::handleClient(int server_sock) {
    usb_tcp.join();
    tcp_usb.join();

+    should_exit = true;


Does this help in any way? We've already joined both the threads by now.

Yes, I was no sure about this variable to control the threads in this moment is necessary to inform or no, you better knows the behavior

nisargjhaveri · 2024-02-11T14:16:16Z

Thanks @Ioniq3 for the PR! I'll try out this soon.

For the first time connection issue, do we really need to restart the TCP server as well? We can maybe just disconnect and retry the bluetooth connection sequence. This way we can still catch connections coming in the few seconds the TCP server will be down for a few seconds with this change.

Ioniq3 · 2024-02-11T19:42:27Z

Thanks @Ioniq3 for the PR! I'll try out this soon.

For the first time connection issue, do we really need to restart the TCP server as well? We can maybe just disconnect and retry the bluetooth connection sequence. This way we can still catch connections coming in the few seconds the TCP server will be down for a few seconds with this change.

Sure, but as I said in my headunit works better without the "Connect to USB after phone connection is available" commit, apart from this you are right that can coincide in time the restart and the connection, if you see another way please go ahead, I don't have experience with c++ development.

nisargjhaveri · 2024-02-17T03:32:51Z

Seems like we're trying to multiple things in this PR.

Thanks for pointing out that in some cases the old flow to connect where we wait for the usb to connect first works better. To support both the flows let's add a configuration option and select which flow to take for initial connection.

Once we have that in, we can work on reconnect if the initial connection fails. I believe both the flows would have slightly different approach to reconnect in the initial connection flow.

Another is, reconnecting when the TCP fails after the Android Auto is connected and started. Fixing this won't have major differences in both the flows and can be done now. We can maybe restrict this PR only to this, and work on the first two parts separately.

Let me know what you think. Really appreciate everyone's effort on this. :)

Ioniq3 · 2024-02-17T20:56:24Z

Thanks Nisarg.

It's a good idea, I have just divided in three branches:

select_mode_operation
reconnect-firstconnection
reconnect-wifiandheadunit // with only the TCP reconnection

nisargjhaveri · 2024-02-21T20:11:36Z

I tried this out, doesn't seem to work very well for me. The connection seems to be closed/killed soon after the usb is connected.

Also, when you said that your headunit works better without "Connect to USB after phone connection is available", is that with these changes? Or even on main, without the reconnection changes it works better without that commit? What happens if it waits for phone connection?

Ioniq3 · 2024-02-21T21:26:12Z

No, i remove all about the first connection (now in the reconnect-firstconnection branch) to divided in three branches as you suggess, only remains the reconnection after tcp stop receiving from phone in this branch

nisargjhaveri · 2024-02-22T03:00:28Z

No, i remove all about the first connection (now in the reconnect-firstconnection branch) to divided in three branches as you suggess, only remains the reconnection after tcp stop receiving from phone in this branch

Yes, I understand that. Thanks a lot for separating the PRs.

The question is, if we don't merge this PR. Does #56 add any value? What is the issue you face with your headunit in current main?

Ioniq3 · 2024-02-22T07:51:13Z

I don't know if it is a special case or not. When I open the car with the key the usb automatically power on, starting the raspberry pi, but the headunit is turn off until i sit and turn on the contact. In the actual behavior if you make some other things like sit down my daughter and some other thing the phone connect to the rpi meanwhile and how the headunit is turn off when i turn on it doesn't work and i have to reboot the rpi (or the usb gadget and aawgd) to make it works. But in the behavior of the usb connection before I don't have that problem and the connection only start when i turn on the headunit independently of the time the rpi was uptime.

nisargjhaveri · 2024-03-03T19:02:01Z

As I mentioned, the current version doesn't seem to work well. It causes the TCP connection to fail just after it connects, if at all for me. Any ideas why this would happen?

Also, #72 makes further chances to initial connection. If it works, there should be lesser need to retry initial connection.

For disconnection after connection is established, this or similar change wouldn't help much either. Even if we successfully detect tcp disconnection, the usb thread would still keep waiting forever. We need to find a way to interrupt that as well.

Ioniq3 · 2024-03-03T20:11:30Z

Yes, I solved the two problems by a hard way restarting usb_gadget and aawgd signaling a external program when I get a problem on usb or tcp disconnection, but this is not the best and ortodoxal way, it is only a black box workaround. I prefer than people with more knowledge, of course than me, continue make investigations to get the issues and the best way to restart tcp and usb by means of the exact situation to improve.

If you want to close the PR I don't have any problem on it.

nisargjhaveri · 2024-03-23T20:31:16Z

See #90, which might help along with couple of other recent changes. Closing this PR for now.

Ioniq3 added 3 commits February 11, 2024 01:10

timeouts added

6aac0ef

enable default after new loop

1ce70ae

close new sock of select

de9a2d5

nisargjhaveri reviewed Feb 11, 2024

View reviewed changes

extract fot other new branch

2d3a93c

Update proxyHandler.cpp

8374562

Merge branch 'nisargjhaveri:main' into reconnect-wifiandheadunit

09d66d2

admiralspeedy mentioned this pull request Mar 3, 2024

Restart gadget on TCP failure (disconnect) or hostapd disconnect #26

Closed

remove should_exit

3715306

hkfuertes mentioned this pull request Mar 14, 2024

Some personalization from /boot #81

Closed

Merge branch 'nisargjhaveri:main' into reconnect-wifiandheadunit

0bb1a7e

nisargjhaveri closed this Mar 23, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Reconnect wifiandheadunit #50

Reconnect wifiandheadunit #50

Ioniq3 commented Feb 11, 2024

nisargjhaveri Feb 11, 2024

Ioniq3 Feb 11, 2024

nisargjhaveri Feb 11, 2024

Ioniq3 Feb 11, 2024

hkfuertes Feb 13, 2024

Ioniq3 Feb 13, 2024 •

edited

Loading

nisargjhaveri Feb 17, 2024

nisargjhaveri Feb 11, 2024

Ioniq3 Feb 11, 2024

nisargjhaveri Feb 11, 2024

Ioniq3 Feb 11, 2024

nisargjhaveri commented Feb 11, 2024

Ioniq3 commented Feb 11, 2024

nisargjhaveri commented Feb 17, 2024

Ioniq3 commented Feb 17, 2024

nisargjhaveri commented Feb 21, 2024

Ioniq3 commented Feb 21, 2024 •

edited

Loading

nisargjhaveri commented Feb 22, 2024

Ioniq3 commented Feb 22, 2024

nisargjhaveri commented Mar 3, 2024

Ioniq3 commented Mar 3, 2024 •

edited

Loading

nisargjhaveri commented Mar 23, 2024

Reconnect wifiandheadunit #50

Reconnect wifiandheadunit #50

Conversation

Ioniq3 commented Feb 11, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ioniq3 Feb 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nisargjhaveri commented Feb 11, 2024

Ioniq3 commented Feb 11, 2024

nisargjhaveri commented Feb 17, 2024

Ioniq3 commented Feb 17, 2024

nisargjhaveri commented Feb 21, 2024

Ioniq3 commented Feb 21, 2024 • edited Loading

nisargjhaveri commented Feb 22, 2024

Ioniq3 commented Feb 22, 2024

nisargjhaveri commented Mar 3, 2024

Ioniq3 commented Mar 3, 2024 • edited Loading

nisargjhaveri commented Mar 23, 2024

Ioniq3 Feb 13, 2024 •

edited

Loading

Ioniq3 commented Feb 21, 2024 •

edited

Loading

Ioniq3 commented Mar 3, 2024 •

edited

Loading