Reconnect wifiandheadunit

[Ioniq3]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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