InitialiseProtocol: reset device before handshake

[luk1337]

Heimdall fails to handshake with device on my Linux installation: Initialising protocol... ERROR: libusb error -7 whilst sending bulk transfer. Retrying... ERROR: libusb error -7 whilst sending bulk transfer. Retrying... ERROR: libusb error -7 whilst sending bulk transfer. Retrying... ERROR: libusb error -7 whilst sending bulk transfer. Retrying... ERROR: libusb error -7 whilst sending bulk transfer. Retrying... ERROR: libusb error -7 whilst sending bulk transfer. ERROR: Failed to send handshake! ERROR: Failed to receive handshake response. Result: -7 ERROR: Protocol initialisation failed!

However, with the same USB cable, port and device, Heimdall successfully handshake with the device on Windows via WinUSB. This indicates handling of USB devices of host (AMD X570) on Linux might lead to undesired results. Though, without further testing, the interference from userspace (Ubuntu 20.04, KDE) can not be ruled out.

Thus, this patch calls libusb_reset_device to ensure the USB port is in a clean state before we send the data.

Fixes issues with newer devices and hosts.

Signed-off-by: Jesse Chan jc@linux.com

[luk1337]

@Benjamin-Dobell ping

[jnahmias]

@luk1337 - I still get this error, even after applying this patch :(

$ sudo ./heimdall flash --recovery /usr/local/android/recovery.img --pit MyTablet.pit --verbose --resume --usb-log-level debug
[...]
Claiming interface...
[ 0.004584] [000037e5] libusb: debug [libusb_claim_interface] interface 1
Setting up interface...
[ 0.004603] [000037e5] libusb: debug [libusb_set_interface_alt_setting] interface 1 altsetting 0

Beginning session...
[ 0.004829] [000037e5] libusb: debug [libusb_alloc_transfer] transfer 0x5560f9332300
[ 0.004834] [000037e5] libusb: debug [libusb_submit_transfer] transfer 0x5560f9332300
[ 0.004837] [000037e5] libusb: debug [add_to_flying_list] arm timerfd for timeout in 3000ms (first in line)
[ 0.004842] [000037e5] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 1024
[ 0.004850] [000037e5] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 0.004854] [000037e5] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 3.004903] [000037e5] libusb: debug [handle_events] poll() returned 1
[ 3.004932] [000037e5] libusb: debug [handle_events] timerfd triggered
[ 3.004951] [000037e5] libusb: debug [libusb_cancel_transfer] transfer 0x5560f9332300
[ 3.008278] [000037e5] libusb: debug [disarm_timerfd]
[ 3.008293] [000037e5] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 3.008297] [000037e5] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 3.008302] [000037e5] libusb: debug [handle_events] poll() returned 1
[ 3.008307] [000037e5] libusb: debug [reap_for_handle] urb type=3 status=-2 transferred=0
[ 3.008311] [000037e5] libusb: debug [handle_bulk_completion] handling completion status -2 of bulk urb 1/1
[ 3.008314] [000037e5] libusb: debug [handle_bulk_completion] abnormal reap: urb status -2
[ 3.008316] [000037e5] libusb: debug [handle_bulk_completion] abnormal reap: last URB handled, reporting
[ 3.008320] [000037e5] libusb: debug [usbi_handle_transfer_cancellation] detected timeout cancellation
[ 3.008322] [000037e5] libusb: debug [disarm_timerfd]
[ 3.008327] [000037e5] libusb: debug [usbi_handle_transfer_completion] transfer 0x5560f9332300 has callback 0x7fa65668a2c0
[ 3.008334] [000037e5] libusb: debug [sync_transfer_cb] actual_length=0
[ 3.008342] [000037e5] libusb: debug [libusb_free_transfer] transfer 0x5560f9332300
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
[ 3.258485] [000037e5] libusb: debug [libusb_alloc_transfer] transfer 0x5560f932c990
[ 3.258505] [000037e5] libusb: debug [libusb_submit_transfer] transfer 0x5560f932c990
[ 3.258519] [000037e5] libusb: debug [add_to_flying_list] arm timerfd for timeout in 3000ms (first in line)
[ 3.258537] [000037e5] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 1024
[ 3.258569] [000037e5] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 3.258575] [000037e5] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 6.258583] [000037e5] libusb: debug [handle_events] poll() returned 1
[ 6.258609] [000037e5] libusb: debug [handle_events] timerfd triggered
[ 6.258623] [000037e5] libusb: debug [libusb_cancel_transfer] transfer 0x5560f932c990
[ 6.261961] [000037e5] libusb: debug [disarm_timerfd]
[ 6.261975] [000037e5] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 6.261979] [000037e5] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 6.261984] [000037e5] libusb: debug [handle_events] poll() returned 1
[ 6.261989] [000037e5] libusb: debug [reap_for_handle] urb type=3 status=-2 transferred=0
[ 6.261993] [000037e5] libusb: debug [handle_bulk_completion] handling completion status -2 of bulk urb 1/1
[ 6.261996] [000037e5] libusb: debug [handle_bulk_completion] abnormal reap: urb status -2
[ 6.261998] [000037e5] libusb: debug [handle_bulk_completion] abnormal reap: last URB handled, reporting
[ 6.262001] [000037e5] libusb: debug [usbi_handle_transfer_cancellation] detected timeout cancellation
[ 6.262004] [000037e5] libusb: debug [disarm_timerfd]
[ 6.262007] [000037e5] libusb: debug [usbi_handle_transfer_completion] transfer 0x5560f932c990 has callback 0x7fa65668a2c0
[ 6.262011] [000037e5] libusb: debug [sync_transfer_cb] actual_length=0
[ 6.262020] [000037e5] libusb: debug [libusb_free_transfer] transfer 0x5560f932c990
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
[ 6.762150] [000037e5] libusb: debug [libusb_alloc_transfer] transfer 0x5560f932ca70
[ 6.762174] [000037e5] libusb: debug [libusb_submit_transfer] transfer 0x5560f932ca70
[ 6.762188] [000037e5] libusb: debug [add_to_flying_list] arm timerfd for timeout in 3000ms (first in line)
[ 6.762206] [000037e5] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 1024
[ 6.762238] [000037e5] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 6.762243] [000037e5] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 9.762251] [000037e5] libusb: debug [handle_events] poll() returned 1
[ 9.762278] [000037e5] libusb: debug [handle_events] timerfd triggered
[ 9.762293] [000037e5] libusb: debug [libusb_cancel_transfer] transfer 0x5560f932ca70
[ 9.765654] [000037e5] libusb: debug [disarm_timerfd]
[ 9.765669] [000037e5] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 9.765673] [000037e5] libusb: debug [handle_events] poll() 3 fds with timeout in 60000ms
[ 9.765678] [000037e5] libusb: debug [handle_events] poll() returned 1
[ 9.765683] [000037e5] libusb: debug [reap_for_handle] urb type=3 status=-2 transferred=0
[ 9.765686] [000037e5] libusb: debug [handle_bulk_completion] handling completion status -2 of bulk urb 1/1
[ 9.765689] [000037e5] libusb: debug [handle_bulk_completion] abnormal reap: urb status -2
[ 9.765691] [000037e5] libusb: debug [handle_bulk_completion] abnormal reap: last URB handled, reporting
[ 9.765694] [000037e5] libusb: debug [usbi_handle_transfer_cancellation] detected timeout cancellation
[ 9.765697] [000037e5] libusb: debug [disarm_timerfd]
[ 9.765702] [000037e5] libusb: debug [usbi_handle_transfer_completion] transfer 0x5560f932ca70 has callback 0x7fa65668a2c0
[ 9.765709] [000037e5] libusb: debug [sync_transfer_cb] actual_length=0
[ 9.765717] [000037e5] libusb: debug [libusb_free_transfer] transfer 0x5560f932ca70
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
[ etc ... ]

[jnahmias]

nevermind, i did something silly. used the wrong arguments to heimdall. The following worked:

$ sudo /usr/local/android/Heimdall/build/bin/heimdall flash --RECOVERY /usr/local/android/recovery.img --VBMETA /usr/local/android/twrp-gts4lvwifi/vbmeta.img
Heimdall v1.4.2

Copyright (c) 2010-2017 Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
Claiming interface...
Setting up interface...

Initialising protocol...
Protocol initialisation successful.

Beginning session...

Some devices may take up to 2 minutes to respond.
Please be patient!

Session begun.

Downloading device's PIT file...
PIT file download successful.

Uploading RECOVERY
100%
RECOVERY upload successful

Uploading VBMETA
100%
VBMETA upload successful

Ending session...
Rebooting device...
Releasing device interface...

[Grimler91]

@luk1337 do you get the error when flashing a single partition, or only when flashing multiple partitions?

The other PR that fixes issues with newer devices also adds a libusb_reset_device() call, but in BridgeManager::EndSession, so I am curious if reseting in that function instead works for you as well.

[luk1337]

@Grimler91

$ /home/luk/Heimdall/bin/heimdall flash --BOOT boot.img 
Heimdall v1.4.2

Copyright (c) 2010-2017 Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
Claiming interface...
Setting up interface...

Initialising protocol...
ERROR: Failed to send handshake!ERROR: Protocol initialisation failed!

Releasing device interface...

$ /home/luk/Heimdall/bin/heimdall flash --BOOT boot.img --DTBO dtbo.img 
Heimdall v1.4.2

Copyright (c) 2010-2017 Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
Claiming interface...
Setting up interface...

Initialising protocol...
ERROR: Failed to send handshake!ERROR: Protocol initialisation failed!

Releasing device interface...

I pulled the patch you linked but it doesn't work for my device ^^

[Grimler91]

Thanks for checking! I guess reset needs to go in both places then

[bbinet]

I had the same issue on device SM-A300FU, and I confirm that this patch fix the issue. Could it be merged to master ?

[mparker17]

I can confirm that this pull request fixes a connection problem for device SM-T720 (gts4lvwifi)

+1 to merging

[aktivkohle]

I can second that this pull request fixes a connection problem for device SM-T720.

So few lines in the commit but it fixes it. Some links to help you use the unmerged pull request in your clone of the repo :

https://stackoverflow.com/questions/40182366/how-to-list-all-pull-request-with-count-of-files-changed

https://stackoverflow.com/questions/14947789/github-clone-from-pull-request

This certainly fixed the immediate error message and handshake problem, but I've still not managed yet to get TWRP onto this tablet from linux, bunch of other problems beyond what this pull request fixes.

[TheAirBlow]

@Benjamin-Dobell seams to be inactive here. Very sad.

[TheAirBlow]

No updates since 2017.

[Grimler91]

This apparently causes issues on some devices, on degaswifi (SM-T230) it prevents successful handshake. Maybe only devices using odin protocol v3 and newer needs this. @mparker17 and @aktivkohle reported that issue happens on SM-T720 though, and that device seem to use the same protocol version as degaswifi (v0).

So, don't know how to properly deal with this. Maybe heimdall need to detect which distro it is running on and only do libusb_reset() on ubuntu (that would be very annoying).

Protocol version that the device is compatible with can (it seems) be seen in the pit header, with heimdall 1.4.2 it is Unknown 7, so for example:

$ heimdall print-pit --file dream2lte.pit
Heimdall v1.4.2

Copyright (c) 2010-2017 Benjamin Dobell, Glass Echidna
https://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
https://www.glassechidna.com.au/donate/

Entry Count: 30
Unknown 1: 1598902083
Unknown 2: 844251476
Unknown 3: 21324
Unknown 4: 14153
Unknown 5: 12852
Unknown 6: 48
Unknown 7: 4
Unknown 8: 0

or with Heimdall 2.0.0 from my repo

$ heimdall print-pit --file dream2lte.pit 
Heimdall v2.0.0

Copyright (c) 2010-2017 Benjamin Dobell, Glass Echidna
https://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
https://www.glassechidna.com.au/donate/

--- PIT Header ---
Entry Count: 30
Unknown string: COM_TAR2
CPU/bootloader tag: LSI7420
Protocol version: 0x0004

[TheAirBlow]

@Grimler91, Maybe only devices using odin protocol v3 and newer needs this. Nah, in 2021 when Thor was Hreidmar, I used my main phone for testing (turned out to be a bad idea) It connected successfully, and afaik Galaxy A20s is Odin v3. Arch Linux, not ubuntu. And I think at the time I was on Windows, so it's something other than that.

[davux]

@Grimler91, thanks for continuing the work on Heimdall. Is there an issue tracker?

Using your repo, I have the same problem as described in this discussion.

~$ ./heimdall flash --recovery $IMG
Heimdall v2.0.2

Copyright (c) 2010-2017 Benjamin Dobell, Glass Echidna
https://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
https://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
Claiming interface...
Initialising protocol...
ERROR: Failed to send handshake!
ERROR: Protocol initialisation failed!

Releasing device interface...

Any idea what might cause this?

[Grimler91]

@davux sorry, missed your message here. What device is this for?

I have set up a mailing list for the sourcehut repo here: https://lists.sr.ht/~grimler/Heimdall-devel, so discussion/bug reports can be sent to ~grimler/Heimdall-devel@lists.sr.ht

[TheAirBlow]

@Grimler91 https://forum.xda-developers.com/t/official-samsung-odin-v4-1-2-1-dc05e3ea-for-linux.4453423/, imo Heimdall lost it's purpose.

[Grimler91]

@TheAirBlow there's plenty of reasons why one could prefer a tool like heimdall over odin on Linux, including:

• It is doubtful if it is legal to use or spread, considering it is most likely leaked from repair shops
• It is closed source (and leaked), can not package it for distros
• It is closed source, can not really solve bugs or make other improvements
• I guess the version you posted is for amd64, can't use that (well, maybe with qemu) on arm{,64} and other architectures

[TheAirBlow]

@TheAirBlow there's plenty of reasons why one could prefer a tool like heimdall over odin on Linux, including:

• It is doubtful if it is legal to use or spread, considering it is most likely leaked from repair shops
• It is closed source (and leaked), can not package it for distros
• It is closed source, can not really solve bugs or make other improvements
• I guess the version you posted is for amd64, can't use that (well, maybe with qemu) on arm{,64} and other architectures

Well, the first one can be simply ignorer as Odin for Windows is around for a lot of time now and Samsung didn't take any legal action. I do agree with others though, but if you just want to flash on an everyday use computer you can do it.

[TheAirBlow]

@Grimler91 also, it you have a testing device for Thor I may resume development, not promising but it can happen

[Grimler91]

@Grimler91 also, it you have a testing device for Thor I may resume development, not promising but it can happen

Your docs are already very helpful, I have plenty of things to catch up with and try to implement in heimdall from there :)

The newest device I have access to at the moment is a galaxy tab s6 lite. Do you have a good test to see if it supports the updated Thor protocol/software? (Reported protocol from the device is 0x03, so not one of the most recent versions)

[TheAirBlow]

@Grimler91 also, it you have a testing device for Thor I may resume development, not promising but it can happen

Your docs are already very helpful, I have plenty of things to catch up with and try to implement in heimdall from there :)

The newest device I have access to at the moment is a galaxy tab s6 lite. Do you have a good test to see if it supports the updated Thor protocol/software? (Reported protocol from the device is 0x03, so not one of the most recent versions)

I have checked Thor's (not to be confused with mine, this is Samsung's) source code, and it doesn't use the Thor handshake and just does everything Heimdall can in the exact same way (packets are the same)

The only thing it can do other than flashing with regular Odin protocol is the one that is for very old phones, I don't remember how it's called exactly.

[Grimler91]

The only thing it can do other than flashing with regular Odin protocol is the one that is for very old phones, I don't remember how it's called exactly.

You mean it supports both odin mode and the older "Multi Downloader" type of flash, for Galaxy W/Y/whatever devices?

[felurx]

I've got the same problem as described in the original message and in #517 on Manjaro (Arch) with my S21+ (SM-G996B/DS). I tried building Heimdall with the branch from this PR, which resulted in print-pit working once after booting into Odin mode, but a similar error when running the command a second time.

You can find the outputs of sudo heimdall print-pit --verbose --no-reboot --usb-log-level debug in the attached files. The ones beginning with original are with the heimdall distributed with Arch, pr478 with the heimdall I built from this PR. _1 is the first run after a fresh boot into Odin mode, _2 the second run right after. I also attached a picture of the screen with Odin mode open, maybe it helps with something, I dunno. (The pink rectangles are from me, I don't know if any of those IDs are PII or something.) I booted into Odin mode by holding Vol+ and Vol- while plugging in an USB cable.

Photo of phone in Odin mode original_1.txt original_2.txt pr478_1.txt pr478_2.txt

If there's anything I can try out or do to help, I'd be happy to! Also, huge thank you to everyone who did work on Heimdall so far.

[Grimler91]

@felurx did you run the same command, with --no-reboot, everytime?

Commands after using --no-reboot need to use the --resume flag, see this part of heimdall --help:

Note: --no-reboot causes the device to remain in download mode after the action is completed. If you wish to perform another action whilst remaining in download mode, then the following action must specify the --resume flag.

[felurx]

@Grimler91 Ah, thanks, I somehow managed to completely miss that! (I think I didn't even read --help, just skimmed the README, sorry about that...)

Just like last time, I ran sudo heimdall print-pit --verbose --no-reboot --usb-log-level debug and it worked fine. Then right after that, I ran sudo ./heimdall print-pit --verbose --no-reboot --resume --usb-log-level debug. That resulted in the same libusb error -7 whilst sending bulk transfer. Retrying... errors as some of the other runs.

Here's the full output (of just the second command with --resume): with_pr478_2_with_resume.txt

[Grimler91]

@felurx so seems something is wrong with --no-reboot/--resume for your device.

What are you trying to achieve? If print-pit works then flashing probably works as well, as long as --no-reboot/--resume is not used.

You can also try the updated heimdall sources here: https://git.sr.ht/~grimler/Heimdall, it has some of the various PRs in this repo merged and might work better.

To actually fix the --no-reboot/--resume issue we would need to sniff usb traffic from odin when it successfully does (the equivalent of) --no-reboot/--resume with this device, and compare what heimdall does differently

[anarcat]

You can also try the updated heimdall sources here: https://git.sr.ht/~grimler/Heimdall, it has some of the various PRs in this repo merged and might work better.

i am trying to flash a Samsung Galaxy S5e wifi here and it's also failing with that source code, compiled fresh out of today's git:

anarcat@angela:Heimdall$ ./bin/heimdall download-pit --output foo.pit
Heimdall v2.0.2

Copyright (c) 2010-2017 Benjamin Dobell, Glass Echidna
https://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
https://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
Claiming interface...
Initialising protocol...
ERROR: Failed to send handshake!
ERROR: Protocol initialisation failed!

Releasing device interface...

anarcat@angela:Heimdall[1]$ git log | head -1
commit 02b577ec774f2ce66bcb4cf96cf15d8d3d4c7720 (HEAD -> master, tag: v2.0.2, origin/master, origin/HEAD)

am i doing something wrong?

also, how do people create the famous .pit files? I can't seem to find those online, and guides such as LineageOS or /e/ all assume you run windows and the Odin crap...

[JonnyTech]

Seems like you may have sent a second command in the same session. Either reboot the phone after each heimdall command or use the --resume argument (not always reliable though).

[anarcat]

well at this point i did manage to flash ... something, but i also somehow managed to do it the wrong way and totally hosed the tablet. it's now showing this funky screen on boot:

i tried a lot of things from here, loading a new vbmeta from lineage, from TWRP, same with recovery, nothing seems to work. communication with the tablet is flaky over Heimdall, it frequently fails halfway with errors similar to those described here.

[luk1337]

@anarcat you forgot to unlock bootloader...?

[anarcat]

@anarcat you forgot to unlock bootloader...?

i did not, OEM lock is OFF, the thing is just hosed.

[anarcat]

i think my main problem here is it's not very clear how one is supposed to use heimdall in the first place. in the frontend, there's talk about having Heimdall packages, but on the commandline you pass arbitrary files as --RECOVERY and so on... i've tried my way around this but it feels like a minefield and, well, i think stepped on a mine.

my last hope is that locking the bootloader is somehow going to do a factory reset that's going to reset the normal recovery and firmware so that i get something working, but it would sure be nice to have some documented way of flashing tablets (my case is the Samsung Galaxy Tab S5e aka gts4lvwifi aka SM-T720...

otherwise i'm back to square one, minus all my data, apps and configuration. and that's the good scenario where the device is usable at all...

it looks like @Grimler91 is the new upstream, is there a forum somewhere where users can get (self?) support on this stuff? i suspect the LOS people will not be happy to see people trying to explicitly not follow their documentation (ie. not using windows...) but surely us linux folks could hang out somewhere better than an append-only log that pretends to be a pull request? :)

[josephmturner]

On a OEM-unlocked SMT500, I ran ./bin/heimdall print-pit --verbose --no-reboot using the master branch from @Grimler91's fork on SourceHut (commit 7c18391). I tried several USB cables and ports. Output:

Heimdall v2.0.2

Copyright (c) 2010-2017 Benjamin Dobell, Glass Echidna
https://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
https://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
      Manufacturer: "Samsung"
           Product: "SM6150"

            length: 18
      device class: 2
               S/N: 0
           VID:PID: 04E8:685D
         bcdDevice: 021B
   iMan:iProd:iSer: 1:2:0
          nb confs: 1

interface[0].altsetting[0]: num endpoints = 1
   Class.SubClass.Protocol: 02.02.01
       endpoint[0].address: 82
           max packet size: 0010
          polling interval: 09

interface[1].altsetting[0]: num endpoints = 2
   Class.SubClass.Protocol: 0A.00.00
       endpoint[0].address: 01
           max packet size: 0200
          polling interval: 00
       endpoint[1].address: 81
           max packet size: 0200
          polling interval: 00
Claiming interface...
Initialising protocol...
Linux distro ID: debian
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer. Retrying...
ERROR: libusb error -7 whilst sending bulk transfer.
ERROR: Failed to send handshake!
ERROR: Failed to receive handshake response. Result: -7
ERROR: Protocol initialisation failed!

Releasing device interface...

Advice greatly appreciated! Thank you!!

[fluxsilence]

Confirming same issue on Galaxy Tab S5e (gts4lv) on Manjaro (Arch), Heimdall 1.4.2-7.

[PanAeon]

This fix worked for me for Galaxy A31, nixos

[thatnerdjosh]

@Benjamin-Dobell - Any reason this isn't merged in if it fixes the issue?

[franciscoreinolds]

I can confirm that this pull request fixes a connection problem for device SM-T720 (gts4lvwifi)

+1 to merging

For whatever it's worth, I tried this yesterday on a Ubuntu 22.04 laptop and for this exact model, and it did not work for me. My laptop, however, only has usb-c ports, no usb-a, I'm not sure whether that is a factor, but thought I'd share for visibility.