Robert Nagy

> @rnagy Which operating system are you observing the problem? In this case I am using OpenBSD but I've tested `res_search` on linux and the behavior is the same.

The following code can be used to test easily outside of heimdal. Just do `echo "nameserver 233.233.233.233" > /etc/resolv.conf` and then run the code: ``` #include #include #include #include #include...

The system resolvers will retry all the nameservers listed in resolv.conf. So if you have more than one unreachable server listed there, the wait time will double.

I think if errno == ETIMEDOUT we should break out from the loop because that means that the system resolver tried all of the nameservers listed in resolv.conf and everything...

``` --- resolve.c.orig Mon Jul 13 21:43:28 2020 +++ resolve.c Mon Jul 13 22:17:40 2020 @@ -564,6 +564,12 @@ size = resolve_search(handle, domain, rr_class, rr_type, reply, len); + if (errno...

Well retrying on the application level is not a problem if you actually have available resolvers, but in this case the system resolver tells you that you do not, so...

Anything i can do to help maybe? :)

> @rnagy your output looks a bit mixed up, could you maybe dump stderr and stdout separately? sure thing. attached. [debug_stdout.txt](https://github.com/libimobiledevice/idevicerestore/files/6610029/debug_stdout.txt) [debug_stderr.txt](https://github.com/libimobiledevice/idevicerestore/files/6610030/debug_stderr.txt)

> src/tss.c new debug logs attached ``` root@ubuntu:/media/ubuntu/180C558E0C556830# idevicerestore --erase --latest Found device in Recovery mode Identified device as j293ap, MacBookPro17,1 The following firmwares are currently being signed for MacBookPro17,1:...

Goes further this time, new logs attached. ``` Found device in Recovery mode Identified device as j293ap, MacBookPro17,1 The following firmwares are currently being signed for MacBookPro17,1: [1] 11.4 (build...