SIGSEGV from unexpected lockdown result in lockdownd_get_value() about libimobiledevice

[FunkyM]

Yes, restrictions apply to WiFi based communication but I think this is simply because idevice_id does not use "lockdownd_client_new_with_handshake()" and thus does not use a secure session. Many requests are only possible by using a secure session over WiFi. Are you following up on the netmux branch or have something custom brewing?

In regard to the issue, I'd expect the code to return LOCKDOWN_E_GET_VALUE_PROHIBITED.

However, due to the need for refactoring the error logic in general, as it affects all lockdown requests (and there is more than just GetProhibited possibly being returned), I'll just pushed an "else clause" fix for now which returns LOCKDOWN_E_UNKNOWN_ERROR.
Proper error handling support yet to come.

Thanks for reporting.

[aburgh]

Are you following up on the netmux branch or have something custom brewing?

Neither, I stumbled across it by accident. On OS X, if I plug in a device and launch iTunes so that AppleMobileDeviceHelper is running, idevice_id reports both the wifi and USB connections:

$ idevice_id -l
10b76ea3344247e647222a568cf42dfea903a985
d6b5b2912aba2b607bd8a4fe91570e8726268743
10b76ea3344247e647222a568cf42dfea903a985

Since specifying the UDID to commands doesn't distinguish between wifi and USB, I was getting the wifi device in some cases during some other testing. I don't normally have iTunes running, so it's not a big deal for me, but the bug looked worth reporting. Thanks for the fix.

[FunkyM]

Thanks for clarification, yes that's (almost) how the netmux branch is supposed to list WiFi devices, too.