suddenly "Lock" - Githubissues

wjcarpenter commented 2 months ago

Discussed in https://github.com/opencardev/crankshaft/discussions/678

^{Originally posted by **wjcarpenter** September 1, 2024} I started tinkering with CS about a month or so back. I fired it up and used my mouse to operate it while displaying over HDMI. Everything looked pretty cool and stable. I got a nice touchscreen, bolted my RPi 3B+ to it and repeated the experiment. It worked great, and the touchscreen stuff worked just dandy. I plugged in my phone (Pixel 6a) and up came AA. It behaved the way I expected. Time went by while I was waiting for additional mail order parts, 3D printing a case, and doing unrelated things. With everything in hand a couple days ago, I repeated my experiments, including plugging in my phone for the first time in a few weeks. CS reacted by throwing up the word "Lock" in the upper left corner and ignoring touches or mouse clicks on the screen. When I unplug my phone, CS goes back to its normal responsive self. Thinking I might have tweaked something the wrong way, I started over with a freshly downloaded image file. Same "Lock" symptoms. I also locally built the image and got the same "Lock" symptoms. I know the generic advice is to check my USB cable. I've tried about a half dozen different cables between my phone and CS, but I don't really think that's the problem. I'm just starting my spelunking in the source code, but I wonder if someone has already been down this path and figured it out. (I'm not providing any logs at the moment because I don't want to bother someone into spending time on this unless it's something they already have ideas about. I can provide them if desired.) My hypothesis at the moment is something changed in an Android monthly update, and now the handshaking between my phone and CS is getting something confused. Things definitely get as far as CS recording my phone info into the /tmp/android_device file.

MatthewOnTour commented 2 months ago

Same problem here.

das-nirmal commented 2 months ago

Facing the same problem (with both wired and wireless connection), when I used crankshaft today after a couple of weeks.

Also phone screen showed a message, something like installed app in Android auto does not work with wired connection...

DJFliX commented 2 months ago

Same! Pi 4, Galaxy Flip 6, AA-Wireless (but also doesn't work with a direct USB connection to the phone). Tried a clean install of crankshaft-ng without any additional changes with the same result. I'll try to see some logs as soon as I can find the time to take my pi within range of my home wifi to run some diagnostics over ssh.

Note: the Lock isn't necessarily a problem: this occurs during the "handshaking" process between Crankshaft and Android Auto on the phone. But the fact that it keeps showing and disappearing in a loop is an issue.

Edit2: I've bumped my Android Auto app version to 12.9.143734-release.daily but this didn't change a thing (unfortunately). Curious to see if a downgrade would would work. What version are y'all using?

pyditn2 commented 2 months ago

Same with Samsung Galaxy S24 Ultra/ RPi3B+. However the issue seems to only be affecting the video, audio comes through just fine.

wjcarpenter commented 2 months ago

audio comes through just fine.

I hadn't even thought to try that, but audio comes through for me, too. In fact, if I play a Youtube video on my phone, the audio from that comes through to the Crankshaft device.

Somewhere in my travels (but which I have now lost track of), I saw a reference to turning on "allow videos while driving". If I ever find that again, I'll try it since the AA projection is just some sort of video stream (I think).

wjcarpenter commented 2 months ago

 Curious to see if a downgrade would would work. What version are y'all using?

I'm was also on Android Auto app version to 12.9.143734-release.daily, but just now I took an upgrade to 12.9.143804-release.daily. No change for this problem.

Have you tried downgrading yet?

wjcarpenter commented 2 months ago

The logcat on my phone when trying to connect to Crankshaft includes this line:

09-17 11:29:36.463 18018 20271 W CAR.VALIDATOR: Package DENIED; Should not run on HU [2018 Crankshaft-NG Universal null] [com.honda.hondalink.connect]

I don't know what it means or what to do about it, but it seems like it's probably significant.

FWIW:

09-17 11:29:36.169 18018 20257 I CAR.GAL.GAL.LITE: Car requests protocol version 1.1
09-17 11:29:36.170 18018 20257 I CAR.GAL.GAL.LITE: Requested protocol version 1.1, negotiated protocol version 1.7 (STATUS_SUCCESS)

pyditn2 commented 2 months ago

I have disabled the Android Auto app on my phone and then deinstalled all updates. At the same time I also completely reinstalled crankshaft on the Pi. I dont know what exactly fixed it, but now everything is working fine again. AA App version: 12.7.643414-release

wjcarpenter commented 2 months ago

That encouraging!

AA App version: 12.7.643414-release

I wonder how you got to that version instead of one of the 12.9. versions that I have. I was in the beta program for AA, but leaving the beta program still left me with the 12.9. version I reported earlier. If I remove all updates for the AA app, it leaves me with something that identifies itself as a "stub" that can't connect to anything until you follow its prompt to update it. I figured that's something that Google changed when they made AA a hidden app a while back.

My phone is a Google Pixel 6a. What's yours?

wjcarpenter commented 2 months ago

Ho ho! I guess normal app activity is that it wouldn't update to an earlier version just because I left the beta program. I uninstalled updates to AA and then applied fresh updates, leaving me at 12.6.643244-release. When I plugged into Cranskshaft, it worked, at least as far as prompting me to set up, etc. Woo-hoo!

For others who had the same problem, what AA versions were you using?

wjcarpenter commented 2 months ago

FWIW, I reported this in the AA community help forum, but I don't know if that will get any attention.

dcolecpa commented 2 months ago

I uninstalled the Android Auto updates and it is working again too. I'm back to 12.6.643244 on Android Auto and so far so good.

wjcarpenter commented 2 months ago

@dcolecpa Were you on the app beta before you uninstalled the AA updates?

dcolecpa commented 2 months ago

No. I was on "2022-09-11-crankshaft-ng-66525ef-pi2.img".

wjcarpenter commented 2 months ago

@dcolecpa I meant the beta channel of the AA app on your phone, not Crankshaft.

dcolecpa commented 2 months ago

Sorry, I misunderstood. No I wasn't on beta for the Android Auto.

correctomundo79 commented 2 months ago

I had the same issue since about a week. Out of the blue, didn't change a thing that might have caused issues.

After removing the updates of the Android Auto app I'm also back on 12.6.643244 and now all is working fine again. It looks like something changed in the 12.9 version that crankshaft didn't like?

pree commented 2 months ago

Same for me, running crankshaft for years and it broke this week. Let's see if we can fix this somehow

flewber commented 2 months ago

Same here. Many-year user. Just broke recently. My AA version that broke it was 12.7.643414. At the time my girl still had 12.6.643254, and her phone still worked consistently.

Her phone has since updated to 12.8.643614 and no longer works either.

pree commented 2 months ago

Pressing "uninstall" in the play Store removed updates and that made it work again for now. Quick solution for now, but not for the long term

pree commented 2 months ago

The folks at Bluewave Stuidos (OpenAuto Pro) also seem to have this issue, as they stopped selling it and locked down the forum.

DJFliX commented 2 months ago

I figured that was the reason. I was actually considering purchasing a license if their forks of openauto/aasdk would have been more up to date than the public ones. But alas that was not the case.

I tried building opendsh to see if that would work for me. So far no luck (but this has to do with my unfamiliarity with the project as well as my lack of time since I became a dad).

For now I'm driving without only audio nav over bluetooth, but I hope I can retry opendsh and get a working build to try this time...

Geekyadz commented 2 months ago

Add me to the list of "latest AA not working for me".

Multiple phones: Pixel 7A Pixel 4A Motorola Moto G30

Found it wasn't working for my pixels; crankshaft would say it's connected but wouldn't go into android auto.

Motorola wasn't up to date at the time so it worked, then I updated AA on it and then had the same issues. Uninstalled updates and wanted to do the first time setup.

Uninstalled updates on my pixel 7A (this is my main phone) and it started working again like it's a new car, then said something about updates which I did and has been working since.

App details

wjcarpenter commented 1 month ago

My phone updated to 12.7.643414-release, and now Crankshaft is broken in this way again. Things still work with my factory AA headunit (via an AAwireless dongle).

@DJFliX You mentioned opendsh. I built and tried that. Same symptoms as for Crankshaft, which is not surprising since it uses the same openauto substrate AFAICT.

TheLastMillennial commented 1 month ago

I'm going to chime in and say I have the same issue. I had to downgrade to Android Auto 12.4.6. I'm running Android 11 on a Sony Xperia 5 II.

I'm willing to provide any logs and test any configurations. I loved this project for years and want to keep using it!

DJFliX commented 1 month ago

Good to know! I am still surprised by the lack of reports of AA being broken for Opendsh users on their Slack. But I suspect AA is a secondary feature for most Opendsh users whereas for Crankshaft close to 100% of users AA is the only thing they use crankshaft for.

I have downgraded to 12.6 but am experiencing frequent disconnects. Since I'm using AAWireless the reconencts do happen automatically but this does mean 20 second interruptions of music and nav which isnt great. I had never experienced this before...

On Tue, 24 Sept 2024, 21:08 WJCarpenter, @.***> wrote:

My phone updated to 12.7.643414-release, and now Crankshaft is broken in this way again. Things still work with my factory AA headunit (via an AAwireless dongle).

@DJFliX https://github.com/DJFliX You mentioned opendsh. I built and tried that. Same symptoms as for Crankshaft, which is not surprising since it uses the same openauto substrate AFAICT.

— Reply to this email directly, view it on GitHub https://github.com/opencardev/crankshaft/issues/680#issuecomment-2372109764, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ6DNJ2O7N6U54EUIP2HQLZYG2D3AVCNFSM6AAAAABOKJIW4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZSGEYDSNZWGQ . You are receiving this because you were mentioned.Message ID: @.***>

wjcarpenter commented 1 month ago

lack of reports of AA being broken for Opendsh users

It seems odd to me, too. I suspect there may be more to it than just the AA app version, like maybe some other dependent library or something that varies from phone to phone.

am experiencing frequent disconnects. Since I'm using AAWireless

For the last couple months (not sure how long) my factory AA headunit, which I also use with AAwireless, occasionally stalls with some message about losing bluetooth connectivity. It resumes after a few seconds. It's been rare enough that I just put up with it.

(Before I learned more about how AA works, I blamed a lot of things on the firmware inside my head unit. Now that I know about AA projection, it seems like almost every glitch has to be in the AA app on the phone.)

TheLastMillennial commented 1 month ago

I make a point to disable auto updates as much as possible. I also haven't changed any crankshaft settings in months. So there's only two things that could have changed on my phone to break things.

Updating Android auto (of course).
Google Services (like Google Play Services and Google Services Framework) since I can't prevent those from auto updating.

I only noticed crankshaft broke when I manually updated AA but it's possible changes in Google services play a role in the incompatibility.

younsj97 commented 1 month ago

I also have same issue

I used wireless Android auto using CS few months ago. And I tried to connect again yesterday, it didn't works. So i removed update of AA(12.8.xxx) and installed old version(12.4.xxx), now it works well.

wjcarpenter commented 1 month ago

[Update: Maybe a false alarm. Various reports of getting this pop-up going back to the early 17th century. Apparently nothing bad happens, and it's just some quirk of who-knows-what.]

I hope we find a real fix soon. When I was trying some things today with a downgraded AA app, I got this notification when I unplugged from the HU:

DJFliX commented 1 month ago

Yeah... at this point I'm not betting on a fix from openauto pro being open sourced to benefit other projects. So I'm also keeping an eye open for dedicated Android Auto HDMI dongles. These do seem a lot less common than the USB dongles unfortunately...

On Thu, 26 Sept 2024, 17:51 WJCarpenter, @.***> wrote:

I hope we find a real fix soon. When I was trying some things today with a downgraded AA app, I got this notification when I unplugged from the HU:

image.png (view on web) https://github.com/user-attachments/assets/a4b87971-1bda-49df-855b-64255bc5cc91

— Reply to this email directly, view it on GitHub https://github.com/opencardev/crankshaft/issues/680#issuecomment-2377346148, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ6DNM2Y2F25YGFZ233JSTZYQUOJAVCNFSM6AAAAABOKJIW4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZXGM2DMMJUHA . You are receiving this because you were mentioned.Message ID: @.***>

wjcarpenter commented 1 month ago

There was a response in the AA community support forum asking for more info about this problem. I'll be supplying my observations, but I encourage anybody else with these symptoms to also responds with the requested information items.

https://support.google.com/androidauto/thread/297405071/recent-aa-updates-break-crankshaft-ng-not-beta?msgid=298839883#

maklimcz commented 1 month ago

I confirm, latest Android Auto on phone breaks. I've uninstalled updates and then manually installed v 12.6.643224 in aurora store (in there provide version number without dots)

Contosos commented 1 month ago

Hi! I have the same problem. I was using Crnakshaft without any issue but since I have the latest version of AA I cannot connect to RPi with my phone. I've tried to downgrade my AA to 12.6.643204-release and now I can connect AA trought USB cable but it doesn't work with WiFi conection.

MatthewOnTour commented 1 month ago

The trick of uninstalling AA and updating it afterward is no longer working for me.

I'll need to update AA through a third party and disable auto-updates again.

AA version: 12.7.643414

sjdean commented 1 month ago

09-17 11:29:36.463 18018 20271 W CAR.VALIDATOR: Package DENIED; Should not run on HU [2018 Crankshaft-NG Universal null] [com.honda.hondalink.connect]

Just out of interest, do you have Honda Link installed on your phone? If you uninstall that, do you still get that message? I wonder if that message is just saying that Honda Link is not allowed to connect?

I'm running a Google Pixel 8 Pro and get the following in my OpenAuto log:

[2021-09-22 23:32:08.530913] [0xadefa340] [info]    [OpenAuto] [AndroidAutoEntity] version response, version: 1.7, status: 0
[2021-09-22 23:32:08.530942] [0xadefa340] [info]    [OpenAuto] [AndroidAutoEntity] Begin handshake.
[2021-09-22 23:32:08.541801] [0xae6fb340] [debug]   [AaSdk] Message from channel 0
[2021-09-22 23:32:08.541944] [0xadefa340] [info]    [OpenAuto] [AndroidAutoEntity] Handshake, size: 2347
[2021-09-22 23:32:08.554247] [0xadefa340] [info]    [OpenAuto] [AndroidAutoEntity] continue handshake.
[2021-09-22 23:32:08.569329] [0xaeefc340] [debug]   [AaSdk] Message from channel 0
[2021-09-22 23:32:08.569419] [0xae6fb340] [info]    [OpenAuto] [AndroidAutoEntity] Handshake, size: 51
[2021-09-22 23:32:08.569606] [0xae6fb340] [info]    [OpenAuto] [AndroidAutoEntity] Auth completed.
[2021-09-22 23:32:08.574106] [0xae6fb340] [debug]   [AaSdk] f1x.aasdk.proto.messages.AuthCompleteIndication - status: OK

I must get LogCat installed.

I would think that Google wouldn't have simply stopped supporting older protocols, or suddenly stopped supporting unknown headsets, so I'm wondering if we need to do something with changing the headset information:

head_unit_name: "Crankshaft-NG"
car_model: "Universal"
car_year: "2018"
car_serial: "20180301"
left_hand_drive_vehicle: true
headunit_manufacturer: "f1x"
headunit_model: "Crankshaft-NG Autoapp"
sw_build: "1"
sw_version: "1.0"
can_play_native_media_during_vr: false
hide_clock: false

Especially the head unit name, model, year, serial, head unit manufacturer and model.

wjcarpenter commented 1 month ago

@sjdean I think you are probably right about that "Package DENIED" message. Something about the HondaLink app must be quietly telling AA to only let it run on a Honda HU. Interestingly, the HondaLink app is not among the available apps in the AA "Customize launcher" panel, so it must also be quietly telling AA to show the HondaLink icon when it is connected to a Honda HU.

So, I think you are right that it's just an obscure permissions thing that we can't do anything about and that doesn't have much to do with the issue in this thread. Except it does indicate that the AA app knows the details of what HU it's connecting to, beyond just things like screen resolution, and that might have started to matter (as you suggested).

The info about the HU model, etc, is unfortunately hard-coded

void AndroidAutoEntity::onServiceDiscoveryRequest(const aasdk::proto::messages::ServiceDiscoveryRequest& request)
{
    OPENAUTO_LOG(info) << "[AndroidAutoEntity] Discovery request, device name: " << request.device_name()
                       << ", brand: " << request.device_brand();

    aasdk::proto::messages::ServiceDiscoveryResponse serviceDiscoveryResponse;
    serviceDiscoveryResponse.mutable_channels()->Reserve(256);
    serviceDiscoveryResponse.set_head_unit_name("Crankshaft-NG");
    serviceDiscoveryResponse.set_car_model("Universal");
    serviceDiscoveryResponse.set_car_year("2018");
    serviceDiscoveryResponse.set_car_serial("20180301");
    serviceDiscoveryResponse.set_left_hand_drive_vehicle(configuration_->getHandednessOfTrafficType() == configuration::HandednessOfTrafficType::LEFT_HAND_DRIVE);
    serviceDiscoveryResponse.set_headunit_manufacturer("f1x");
    serviceDiscoveryResponse.set_headunit_model("Crankshaft-NG Autoapp");
    serviceDiscoveryResponse.set_sw_build("1");
    serviceDiscoveryResponse.set_sw_version("1.0");
    serviceDiscoveryResponse.set_can_play_native_media_during_vr(false);
    serviceDiscoveryResponse.set_hide_clock(!configuration_->showClock());

    std::for_each(serviceList_.begin(), serviceList_.end(), std::bind(&IService::fillFeatures, std::placeholders::_1, std::ref(serviceDiscoveryResponse)));

    auto promise = aasdk::channel::SendPromise::defer(strand_);
    promise->then([]() {}, std::bind(&AndroidAutoEntity::onChannelError, this->shared_from_this(), std::placeholders::_1));
    controlServiceChannel_->sendServiceDiscoveryResponse(serviceDiscoveryResponse, std::move(promise));
    controlServiceChannel_->receive(this->shared_from_this());
}

Even more unfortunate is that it's part of the openauto app layer (`openauto/src/autoapp/Service/AndroidAutoEntity.cpp), which I have been unable to build locally. So, tricky to try some guesses at other HU identities.

Geekyadz commented 1 month ago

Just out of interest, do you have Honda Link installed on your phone? If you uninstall that, do you still get that message? I wonder if that message is just saying that Honda Link is not allowed to connect?

This is the same Google that killed many a thing (Google Music, Google Podcasts, Timely just to make a few things. Seems even their Wear OS app has also taken a hit recently as that's no longer needed for Pixel Watch 3). In other words it wouldn't surprise me if they have enabled something to break the connection to OpenAuto or crankshaft to ensure "security".

So, next question: what app are you using to get the logs?

I might have a little play myself

wjcarpenter commented 1 month ago

what app are you using to get the logs?

There are two kinds of logs. Crankshaft can produce some additional debug logging, and there is logcat on the phone side.

For CS, you can turn on debug logging via the settings screens. See the "CS Env" tab. Enable debug mode and run whatever you want. Come back to that settings tab and "Create Log", and it will drop "/boot/debug.zip" with all the logs. There are many logs and config files in that ZIP, but the one I have found most interesting is "openauto.log", which is also present in "/tmp/openauto.log". I get stuff off there via ssh and scp.
For the phone side, you want to enable developer settings in the AA app (similar to how you enable developer settings for Android overall). There is an AA dev setting to force debug logging, which goes to logcat (an in-memory ring buffer). There are probably apps for poking around logcat on the phone, but I find it easier to look at the contents on my PC. Enable USB debugging via Android developer settings, plug the phone into the PC via USB. The command "adb logcat" will dump the contents of logcat to standard output (and keeps going since tons of new things are written to it all the time). On Linux, I capture the contents to a file via "adb logcat | tee /some/file.txt". I break out of it when I see it's gotten to the current timestamps. Since logcat is catching logs from many things on your phone, there is a lot of boring junk in there.

Geekyadz commented 1 month ago

Thankyou. Might be time for me to dust off my Linux laptop and make sure adb is installed on it. Might not happen until next week though

wjcarpenter commented 1 month ago

it wouldn't surprise me if they have enabled something to break the connection to OpenAuto or crankshaft to ensure "security".

I think that's possible since (I assume) they get some revenue from the car/headunit makers for AA. There is plenty of documentation about how to do AA-compatible apps on the phone side, but I have yet to come across any public documentation for how to do the headunit side.

But IMHO it's just as likely that the breakage happened by accident. I don't know for sure, but I assume the aasdk library was created by reverse engineering, and some changed part of the handshaking might work fine with official partners and is somehow missed in aasdk.

At this point, no way to know for sure.

wjcarpenter commented 1 month ago

Lines of inquiry that I have in mind to do as time permits. If anyone else wants to jump on any of these, go for it!

Modify the head unit name and other details sent by openauto as part of the service discovery response. Since I can't build openauto locally, I'll modify the strings inside the binary of "autoapp" in a Crankshaft image. That will limit me to using the same string lengths as the current values, and of course any substitutions I do will be simple guesswork since I don't know what any working HU sends. [Update: No joy. I tried "Honda", "Desktop", and "DHU". No change in results.]
Poke around in the decompiled AA apk looking for clues. I'm not optimistic about this because (1) there is a LOT of code, and (2) many of the classes have been processed through some obfuscation tools that hamper decompilation. I'm mostly looking for strings that might hint at what HUs are acceptable, if that is even what's going on. [Update: Giving up after a fair amount of poking around. I didn't find anything interesting for this problem.]
Examining strings contained in the Desktop Head Unit emulator. Once again, just looking for clues.
Using wireshark to capture the handshake between my phone and DHU to compare that to what I see in the logs I've already captured.
See if I can get additional logging on either the phone or the Crankshaft side in the hopes of finding more clues.

DJFliX commented 1 month ago

@wjcarpenter how would one go around capturing the USB handshake between the DHU and the phone? My wife has a Sony XAV-AX8050 in her car so if I know how to capture data I might be able to provide some handshake data. I'm on a Samsung with Knox, so root unfortunately isn't really an option for me.

wjcarpenter commented 1 month ago

how would one go around capturing the USB handshake between the DHU and the phone

Well, I haven't completely figured that out yet, but I'm pretty sure it's possible. For capturing network traffic of various sorts, I use the popular Wireshark tool. It's usually for TCP/IP stuff, but it can also be used to capture USB traffic (I've never done that).

A secondary problem is that most or all of the AA conversation is encrypted with TLS/SSL. Wireshark also has techniques for decrypting that if you can arrange to get the keys. I have done that in the past with browser traffic, but I'm not sure at the moment how to grab the keys when the AA app is talking to DHU; it just seems pretty likely to be possible somehow. (As the saying goes, it's just software.)

A third problem is that most/all of the message exchanges use a low-level scheme called protocol buffers. Wireshark has some support for decoding protocol buffers, but protocol buffers are not self-describing on the wire. Since we're mainly looking for strings, maybe that's not such a big deal, and maybe the protocol buffer definitions in aasdk are close enough that they will help Wireshark decode most of what it sees.

Have I scared you off yet? :-)

wjcarpenter commented 1 month ago

I did some more experiments to narrow down the versions:

good: 12.6.643254-release
bad: 12.7.143404-release.daily beta
bad: 12.7.643404-release

(all later versions that I tried are also bad)

TowarzyszFatCat commented 1 month ago

Where I can download older versions? Is there any archive or I need to trust random sites

sjdean commented 1 month ago

Let me know if anyone can let me know how to obtain a wireshark trace of the communication for reverse engineering.

I am a programmer by trade, so want to get this sorted.

Looking through the logs, there are few possibilities that spring to mind.

Firstly, the Car Protocol. @wjcarpenter if you can get the logcat to find the Requested and negotiated protocol version and let us know if its any different to 1.7.

One suspicion is that 12.7 version of Android Auto defaults to protocol 1.7 and its possible CrankShaft/OpenAuto/AASDK is not properly saying hey, I only support Protocol 1.1.... We really could do with getting those protocols if possible.

The other possibility is that the there is problems with the certificate - perhaps it's been detected later on in communication and being regjected - it seems to be for a Kenwood headunit.

I'm getting an IO Exception when trying to read a frame:

2024-10-02 21:52:26.572 22751-1440  CAR.GAL.GAL.LITE        com...e.android.projection.gearhead  W  IO exception, dataReceived=true, isWireless=true
                                                                                                    java.net.SocketTimeoutException: Read timed out
                                                                                                        at java.net.SocketInputStream.socketRead0(Native Method)
                                                                                                        at java.net.SocketInputStream.socketRead(SocketInputStream.java:118)
                                                                                                        at java.net.SocketInputStream.read(SocketInputStream.java:173)
                                                                                                        at java.net.SocketInputStream.read(SocketInputStream.java:143)
                                                                                                        at gyl.run(SourceFile:110)

and I suspect it may be because:

Updated region groups: {CarRegionGroup{groupId=3, carDisplayId=CarDisplayId{displayId=0}, primaryRegionOfGroup=CarRegionId{regionId=8 carDisplayId=CarDisplayId{displayId=0}}}=[CarRegionId{regionId=8 carDisplayId=CarDisplayId{displayId=0}}, CarRegionId{regionId=7 carDisplayId=CarDisplayId{displayId=0}}], CarRegionGroup{groupId=1, carDisplayId=CarDisplayId{displayId=0}, primaryRegionOfGroup=CarRegionId{regionId=0 carDisplayId=CarDisplayId{displayId=0}}}=[CarRegionId{regionId=0 carDisplayId=CarDisplayId{displayId=0}}, CarRegionId{regionId=2131428382 carDisplayId=CarDisplayId{displayId=0}}, CarRegionId{regionId=2131428784 carDisplayId=CarDisplayId{displayId=0}}, CarRegionId{regionId=2131428782 carDisplayId=CarDisplayId{displayId=0}}]}

This happens when connecting via USB to my local test DHU, but this doesn't occur and effectively crashes CrankShaft.

I'll have a look from my end.

sjdean commented 1 month ago

I think this might be the solution:

void ControlServiceChannel::handleVersionResponse(const common::DataConstBuffer& payload, IControlServiceChannelEventHandler::Pointer eventHandler)
{
    const size_t elements = payload.size / sizeof(uint16_t);
    const uint16_t* versionResponse = reinterpret_cast<const uint16_t*>(payload.cdata);

    uint16_t majorCode = elements > 0 ? boost::endian::big_to_native(versionResponse[0]) : 0;
    uint16_t minorCode = elements > 1 ? boost::endian::big_to_native(versionResponse[1]) : 0;
    proto::enums::VersionResponseStatus::Enum status = elements > 2 ? static_cast<proto::enums::VersionResponseStatus::Enum>(versionResponse[2]) : proto::enums::VersionResponseStatus::MISMATCH;

    eventHandler->onVersionResponse(majorCode, minorCode, status);
}

It looks like this code doesn't do any negotation at all, and simply bounces back the protocol suggested by the phone.

This would be my guess and I'll try to make this happen later.

DJFliX commented 1 month ago

I've ordered a usb sniffer so we can confirm. But given the recent posts we might already have some avenues to investigate before we have to resort to USB captures... Let's see!

On Thu, 3 Oct 2024, 19:50 WJCarpenter, @.***> wrote:

how would one go around capturing the USB handshake between the DHU and the phone

Well, I haven't completely figured that out yet, but I'm pretty sure it's possible. For capturing network traffic of various sorts, I use the popular Wireshark https://www.wireshark.org/ tool. It's usually for TCP/IP stuff, but it can also be used to capture USB traffic https://wiki.wireshark.org/CaptureSetup/USB (I've never done that). A secondary problem is that most or all of the AA conversation is encrypted with TLS/SSL. Wireshark also has techniques for decrypting that if you can arrange to get the keys https://wiki.wireshark.org/TLS. I have done that in the past with browser traffic, but I'm not sure at the moment how to grab the keys when the AA app is talking to DHU; it just seems pretty likely to be possible somehow. (As the saying goes, it's just software.)

— Reply to this email directly, view it on GitHub https://github.com/opencardev/crankshaft/issues/680#issuecomment-2391990772, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ6DNJ52I6KUGRWCAQV4SLZZV7XPAVCNFSM6AAAAABOKJIW4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJRHE4TANZXGI . You are receiving this because you were mentioned.Message ID: @.***>

wjcarpenter commented 1 month ago

Where I can download older versions? Is there any archive or I need to trust random sites

APKmirror.com has a good reputation. FWIW. It's what I've been using. See above for the last good and first bad versions (for 64-bit arm8 variants; other architectures have slightly different numbering).

Requested and negotiated protocol version and let us know if its any different to 1.7.
...
I think this might be the solution:

I checked that a while back. It didn't change between the last good and first bad versions. I had high hopes, but I don't think that's it. I also got to that handleVersionResponse method as part of my high hopes, but I didn't pursue it once I saw that the negotiated protocol number hadn't changed.

That code is in the aasdk component. Have you looked to see if aasdk can be updated in autoapp without being able to actually build autoapp completely (which takes all day and eventually fails for me)? I was planning to add some additional logging in aasdk but didn't pursue it. In particular, it seems to only log the protobuf responses from the HU side and doesn't log what comes in from the phone side.

opencardev / crankshaft

suddenly "Lock" #680

Discussed in https://github.com/opencardev/crankshaft/discussions/678