usbmuxd, branch lograw A socket daemon to multiplex connections from and to iOS devices Add usbmuxd_log_buffer helper for easier debugging of binary payloads 2014-07-26T15:32:27+00:00 Martin Szulecki 2014-07-26T15:32:27+00:00 06a26dbc0c9fc7e96d211481bc6dd2944d7aeb36 






client: Fix crash that occured when receiving client command from old client
2014-05-27T10:54:48+00:00

Martin Szulecki

2014-05-27T10:54:48+00:00

aede4d06c49a8446e8011ab569c765a4f4ba32e7












Fix detection of new "-V" version argument
2014-05-27T10:52:17+00:00

Martin Szulecki

2014-05-27T10:52:17+00:00

002e964e37ee45da88375b2938a8b302904a3c95












Fix connection abort if device buffer is full
2014-05-06T23:46:33+00:00

Peter Wu

2014-04-19T22:56:37+00:00

1a57e4ad05fae295f2892e1aeae462cbaaded9a3

When trying to upload a IPSW filesystem to an iPad, the process would
randomly stop somewhere at 3% or 10%. It is possible that the receive
buffer of the iPad is full. To prevent erroring out because size ==
conn->sendable == 0, skip reading from the client.

There is a similar case where the clients is ready to accept data, but
the device has no data to send. Apply a similar fix there.

Hopefully the device is fast enough to reply in the next main loop
iteration, otherwise the CPU usage of usbmux will spike because the
client socket is ready while there is no data to process...





When trying to upload a IPSW filesystem to an iPad, the process would
randomly stop somewhere at 3% or 10%. It is possible that the receive
buffer of the iPad is full. To prevent erroring out because size ==
conn->sendable == 0, skip reading from the client.

There is a similar case where the clients is ready to accept data, but
the device has no data to send. Apply a similar fix there.

Hopefully the device is fast enough to reply in the next main loop
iteration, otherwise the CPU usage of usbmux will spike because the
client socket is ready while there is no data to process...







utils: Add missing plist_read_from_filename() helper
2014-05-06T09:56:29+00:00

Nikias Bassen

2014-05-06T09:56:29+00:00

b27e6ffe7233123fc99a26723443705595e925de












preflight: Unset preflight callback data when no longer needed to prevent segfault
2014-04-16T15:47:58+00:00

Nikias Bassen

2014-04-16T15:47:58+00:00

c24463ee5f4ebd3cabb279c2a37e35b1777f4dd9












Add "--version" option to print version number and exit, useful for bug reports
2014-03-27T09:23:22+00:00

Martin Szulecki

2014-03-27T09:23:22+00:00

c92b4f59aba053a3df1ae67c49403122650ad996












Update command usage output to match best practice and other tools
2014-03-27T09:22:46+00:00

Martin Szulecki

2014-03-27T09:22:46+00:00

249ab2aee2c9692895d0adb676e22c592ea457a2












usb-linux: massive read perf improvement with 3 parallel transfers
2014-03-24T16:01:30+00:00

Mikkel Kamstrup Erlandsen

2014-03-20T09:01:53+00:00

8ba560fdd177f107c5a0cf667d4e4ab3b0c59f4a

By maintaining 3 parallel usb trasfers when reading we get 2-3x more
throughput when reading. Without this the usb port is mostly just idling.
I get 23mb/s on my system compared to a clean Apple stack that gives me
17mb/s.

3 was chosen because it is simple to hard code, gives very good performance,
and have very little impact on out resource consumption.





By maintaining 3 parallel usb trasfers when reading we get 2-3x more
throughput when reading. Without this the usb port is mostly just idling.
I get 23mb/s on my system compared to a clean Apple stack that gives me
17mb/s.

3 was chosen because it is simple to hard code, gives very good performance,
and have very little impact on out resource consumption.







usb-linux: add some explanatory comments to usb-linux.c
2014-03-24T16:01:30+00:00

Mikkel Kamstrup Erlandsen

2014-03-19T20:28:29+00:00

d06ea10f14a806f2770507cd179b62c0d4eda6a2