Brain dump / progress (or not) report.
Using variations of the attached script, I can reliably start the network, connect to an AP, and obtain a DHCP IP. I can also make the camera listen on the PTP/IP port (15740). However, when I attempt to connect it returns code 5 (Init_Fail, subcode 1) from the Init_Command_request and closes the connection (names from
http://www.gphoto.org/doc/ptpip.php) This is the same thing that happens when you try to connect from a computer that wasn't registered in the UI, or try to connect when something else already has a connection, or try to connect when the camera is listing available computers.
Possibly related to this, I have not found a way to trigger the UPnP stuff. netstat in drysh shows there is nothing listening on the related ports. I think that startCameraServiceProvide is supposed to do this, but it always returns 1, where the other eventprocs return 0 on success. ComDiscovery does the network setup and calls the same underlying function (FF17A248 CDcvry_StartServiceProvide), and also fails. I think the failure is related to sub_FF17ABE4
sub_FF17ABE4 looks at two variables:
0x13DB84 appears to be an array of pointers, which if I connect through the normal camera UI contains the GUID of my PC.
0x655C is a byte which appears to hold the number of entries in the array.
These are empty when using my eventproc script. These variables are referenced in quite a few places that I haven't really been able to untangle. The only place I could find where stuff gets added to the array is sub_FF179E28, but it's not really clear to me how this gets called.
Since there are eventprocs that make the camera listen on PTP/IP, it seems like everything needed to actually get a connection should be there, but I don't see any obvious things to call. ComDiscovery looks like it is intended to be the whole sequence.
I tried posting messages to ComWireless (as described in
http://chdk.setepontos.com/index.php?topic=10724.msg106270#msg106270 ) but this generally seems to just cause crashes. The event procs seem to be mostly a separate system. The only ComWireless message observed using the eventproc script is 0x108 (which appears to be related to connection being made), and 0x10c which may be related to one of the drysh network commands. In all cases the "state" variable remains 1.
Some things I haven't found
1) What task(s) are responsible for the UPnP stuff. dmEventLoop looks like it might be involved.
2) Where the code that actually generates the Init_Fail response is, and more generally, which code handles the socket communication for PTP/IP. sub_FF2ED118 looks like it might be related.
It feels like I'm really close to getting this to work, but the final bit is proving elusive. Since I can now start the network reliably, I've started thinking about alternative approaches, using our own socket code. A few ideas:
1) write a very simple socket interface that can be accessed from Lua to connect / read / write. The scheduling of Lua inside the kbd task makes this somewhat annoying and means we can't easily recycle LuaSocket (
http://w3.impa.br/~diego/software/luasocket/). We also don't get to re-use all the client code, and live view, remote capture etc would not be available. Still, this would be useful as a standalone feature even if we get full PTP working.
2) Write a custom PTP/IP driver that just implements the parts necessary for the CHDK protocol, and implements the same interface that the existing ptp.c expects. This would mean writing a fair bit of annoying code, but shouldn't be hugely difficult.
3) Write our own network protocol to support the same features available in the PTP interface. This could potentially be a lot more efficient and flexible (we could get rid of all the polling nonsense for live view and remote capture), but would be more work and require more client code.
Attachment is my current test script plus a representative log.
A side note, PTP/IP support is now in the wireshark development release (1.11.2) on
http://www.wireshark.org/download.html so you no longer need to use a nightly to dissect PTP/IP traffic.
