print-pit fails on Samsung Galaxy W (samsung-i8150): ERROR Protocol initialisation failed

[onny]

Hey,
trying to use heimdall for an older Samsung device (samsung-i8150) somehow fails:

heimdall print-pit
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: Protocol initialisation failed!

Releasing device interface...

I'll look if I could find some workarounds :)

Best regards
Jonas

[Grimler91]

Are you running heimdall as root? (see #403)

Stupid question but have to ask: have you tried reseting/restarting the phone? I know that an error like this happens if you try to run several heimdall commands in a row without reseting the phone in between

[onny]

Hey thank you for the tipps. I tried with root and also as normal user. Restarting/resetting the phone several times did not help :(

[Grimler91]

Try capturing debug logs: heimdall print-pit --usb-log-level debug, and the libusb traffic with for example wireshark, and (if you have the possibility) the libusb traffic when flashing stock android with odin. Heimdall just mimics odin, so we need libusb traffic logs from odin to see how Heimdall is suppose to work with this device

[onny]

Try capturing debug logs: heimdall print-pit --usb-log-level debug, and the libusb traffic with for example wireshark, and (if you have the possibility) the libusb traffic when flashing stock android with odin. Heimdall just mimics odin, so we need libusb traffic logs from odin to see how Heimdall is suppose to work with this device

Cool I'll try this! Unfortunately I didn't have luck with Odin on Windows 10 nor Windows 7. Installing the Samsung USB drivers is quite unstable and Odin is unable to establish an connection :/

[Grimler91]

I didn't have luck with Odin on Windows 10 nor Windows 7

When flashing stock android? In "proper" windows or a virtual box? (I have never gotten it to work in a virtual box)

If it does not work with odin on windows either, then maybe your usb cable is bad?

[onny]

@Grimler91 I used your Heimdall fork and run it debugging option:

$ heimdall print-pit --usb-log-level debug
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/

Initialising connection...
Detecting device...
[timestamp] [threadID] facility level [function call] <message>
--------------------------------------------------------------------------------
[ 6.788668] [00006436] libusb: debug [libusb_get_device_list]  
[ 6.788690] [00006436] libusb: debug [discovered_devs_append] need to increase capacity
[ 6.788697] [00006436] libusb: debug [libusb_get_device_descriptor]  
[ 6.788703] [00006436] libusb: debug [libusb_get_device_descriptor]  
[ 6.788708] [00006436] libusb: debug [libusb_get_device_descriptor]  
[ 6.788714] [00006436] libusb: debug [libusb_get_device_descriptor]  
[ 6.788718] [00006436] libusb: debug [libusb_get_device_descriptor]  
[ 6.788725] [00006436] libusb: debug [libusb_open] open 1.100
[ 6.788752] [00006436] libusb: debug [usbi_add_event_source] add fd 7 events 4
[ 6.788758] [00006436] libusb: debug [libusb_get_device_descriptor]  
[ 6.788762] [00006436] libusb: debug [libusb_get_config_descriptor] index 0
Claiming interface...
[ 6.788775] [00006436] libusb: debug [libusb_claim_interface] interface 1
Setting up interface...
[ 6.788803] [00006436] libusb: debug [libusb_set_interface_alt_setting] interface 1 altsetting 0

Initialising protocol...
[ 6.791324] [00006436] libusb: debug [libusb_reset_device]  
[ 6.943760] [00006436] libusb: debug [libusb_alloc_transfer] transfer 0x1d43b18
[ 6.943783] [00006436] libusb: debug [libusb_submit_transfer] transfer 0x1d43b18
[ 6.943789] [00006436] libusb: debug [add_to_flying_list] arm timer for timeout in 1000ms (first in line)
[ 6.943806] [00006436] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 4
[ 6.943829] [00006436] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 6.943852] [00006436] libusb: debug [handle_events] event sources modified, reallocating event data
[ 6.943873] [00006436] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
[ 6.943974] [00006436] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 6.943992] [00006436] libusb: debug [reap_for_handle] urb type=3 status=0 transferred=4
[ 6.944007] [00006436] libusb: debug [handle_bulk_completion] handling completion status 0 of bulk urb 1/1
[ 6.944011] [00006436] libusb: debug [handle_bulk_completion] all URBs in transfer reaped --> complete!
[ 6.944018] [00006436] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer
[ 6.944035] [00006436] libusb: debug [usbi_handle_transfer_completion] transfer 0x1d43b18 has callback 0x7ff5bb601e20
[ 6.944047] [00006436] libusb: debug [sync_transfer_cb] actual_length=4
[ 6.944064] [00006436] libusb: debug [libusb_free_transfer] transfer 0x1d43b18
[ 6.944081] [00006436] libusb: debug [libusb_alloc_transfer] transfer 0x1d26c98
[ 6.944091] [00006436] libusb: debug [libusb_submit_transfer] transfer 0x1d26c98
[ 6.944102] [00006436] libusb: debug [add_to_flying_list] arm timer for timeout in 1000ms (first in line)
[ 6.944134] [00006436] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 7
[ 6.944167] [00006436] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 6.944174] [00006436] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
[ 7.944124] [00006436] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 7.944158] [00006436] libusb: debug [libusb_cancel_transfer] transfer 0x1d26c98
[ 7.947251] [00006436] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer
[ 7.947265] [00006436] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 7.947279] [00006436] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
[ 7.947286] [00006436] libusb: debug [usbi_wait_for_events] poll() returned 1
[ 7.947295] [00006436] libusb: debug [reap_for_handle] urb type=3 status=-2 transferred=0
[ 7.947303] [00006436] libusb: debug [handle_bulk_completion] handling completion status -2 of bulk urb 1/1
[ 7.947309] [00006436] libusb: debug [handle_bulk_completion] abnormal reap: urb status -2
[ 7.947314] [00006436] libusb: debug [handle_bulk_completion] abnormal reap: last URB handled, reporting
[ 7.947321] [00006436] libusb: debug [usbi_handle_transfer_cancellation] detected timeout cancellation
[ 7.947329] [00006436] libusb: debug [arm_timer_for_next_timeout] no timeouts, disarming timer
[ 7.947335] [00006436] libusb: debug [usbi_handle_transfer_completion] transfer 0x1d26c98 has callback 0x7ff5bb601e20
[ 7.947343] [00006436] libusb: debug [sync_transfer_cb] actual_length=0
[ 7.947350] [00006436] libusb: debug [libusb_free_transfer] transfer 0x1d26c98
ERROR: Protocol initialisation failed!

Releasing device interface...
[ 7.947389] [00006436] libusb: debug [libusb_release_interface] interface 1

[ 7.947428] [00006436] libusb: debug [libusb_close]  
[ 7.947437] [00006436] libusb: debug [usbi_remove_event_source] remove fd 7
[ 7.947451] [00006436] libusb: debug [libusb_exit]  
[ 7.947458] [00006436] libusb: debug [libusb_exit] destroying default context
[ 7.947464] [00006436] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
[ 7.947470] [00006436] libusb: debug [handle_events] event sources modified, reallocating event data
[ 7.947479] [00006436] libusb: debug [usbi_wait_for_events] poll() 2 fds with timeout in 0ms
[ 7.947486] [00006436] libusb: debug [usbi_wait_for_events] poll() returned 0
[ 7.947492] [00006436] libusb: debug [libusb_unref_device] destroy device 2.3
[ 7.947498] [00006436] libusb: debug [libusb_unref_device] destroy device 2.2
[ 7.947505] [00006436] libusb: debug [libusb_unref_device] destroy device 2.1
[ 7.947511] [00006436] libusb: debug [libusb_unref_device] destroy device 1.7
[ 7.947518] [00006436] libusb: debug [libusb_unref_device] destroy device 1.100
[ 7.947524] [00006436] libusb: debug [libusb_unref_device] destroy device 1.2
[ 7.947530] [00006436] libusb: debug [libusb_unref_device] destroy device 1.1
[ 7.947536] [00006436] libusb: debug [libusb_unref_device] destroy device 4.1
[ 7.947543] [00006436] libusb: debug [libusb_unref_device] destroy device 3.1
[ 7.947549] [00006436] libusb: debug [usbi_remove_event_source] remove fd 6
[ 7.947562] [00006436] libusb: debug [usbi_remove_event_source] remove fd 5
[ 7.947585] [0000643a] libusb: debug [linux_udev_event_thread_main] udev event thread exiting

I captured this session with usbmon and tshark: https://onny.project-insanity.org/files/heimdall_linux.cap

Will try to do the same on the Windows 7 VM :) Maybe I also should prepare Windows 7 on a physical machine ...

[onny]

DRAFT:

Using the latest heimdall 1.4.2 of your fork:

heimdall flash --RECOVERY recovery.img

Here's the capture file.

Using Odin Multi Downloader 4.43 on Windows 7 (KVM):

Here's the capture file.

Files:

• recovery.img
• recovery.tar.md5
• Ancora.ops
• Odin Multi Downloader v4.43.exe

I really would like to look into the capture files but I haven't worked with them nor Heimdall yet so it might be a bit more complicated.

[Grimler91]

Seems something went wrong when you pasted the capture file link, could you send it again?

[Grimler91]

Your heimdall capture shows that the phone does not even respond to the first message sent, so will be interesting to see how different the "Odin Multi Downloader 4.43" protocol is

[onny]

Hey thanks for the feedback. I have some issues capturing traffic on Windows but will try again tomorrow :)

[Grimler91]

Going through some of the old issues it seems some galaxy phones, like the Galaxy Y (and so perhaps the Galaxy W) use a different flashing protocol, see #335 (comment).

Still interesting to see the differences in how it is flashed if you can capture the usb traffic, but adding support for it is probably quite a lot of work

[onny]

I finally was able to capture the Win 7 usb traffic ;) Here's the Odin Multi Downlaoder flashing session capture: https://onny.project-insanity.org/files/samsungw/odin_flash_recovery.cap

[Grimler91]

Thanks! Some quick observations: the bootloader seem to be based on qcom's little kernel, and it claims that it is a MSM7230 device (not MSM8255T). I guess samsung did not bother s/7230/8225/..