Wireless investigations - page 5 - General Discussion and Assistance - CHDK Forum
supplierdeeply

Wireless investigations

  • 55 Replies
  • 15240 Views
*

Offline ahull

  • *****
  • 634
Re: Wireless investigations
« Reply #40 on: 24 / December / 2013, 04:44:20 »
Advertisements
I converted the above to a standalone script, to avoid conflicts with USB and PTP/IP. This allows the camera to connect to an AP and respond to ping while in record mode.

Still haven't gotten PTP/IP working.

edit:
Adding
evproc('SelectFunc_Create')
evproc('RegPTPIPCmd')
evproc('ConnectPtpIPService',0)
causes the camera to listen on the PTP/IP port, but I haven't been able to establish a connection.

Running nmap on the camera in this state crashed it.

This looks very promising.  :D

Now I need to try similar tricks on the SD430, but I am unsure of the status of the patches for VxWorks. What all will I/we need to patch and/or figure out to reach a similar level of functionality?

*

Offline srsa_4c

  • ******
  • 4005
Re: Wireless investigations
« Reply #41 on: 24 / December / 2013, 07:26:37 »
Now I need to try similar tricks on the SD430, but I am unsure of the status of the patches for VxWorks. What all will I/we need to patch and/or figure out to reach a similar level of functionality?
You can choose between my and reyalp's patches. The latter doesn't contain the modified stubs_entry.S files for Vx cameras, you can find those in mine.
When you finished patching, you only need to add
#define CAM_CONSOLE_LOG_ENABLED 1
to platform_camera.h and recompile. reyalp's method works with stock CHDKPTP, mine requires the patched one.

*

Offline reyalp

  • ******
  • 12108
Re: Wireless investigations
« Reply #42 on: 24 / December / 2013, 15:12:58 »
Now I need to try similar tricks on the SD430, but I am unsure of the status of the patches for VxWorks. What all will I/we need to patch and/or figure out to reach a similar level of functionality?
Note that many of the specific eventprocs I used probably don't all exist in SD430, but you can probably find strings prompting for SSID etc. On elph130, there seem to be several different systems that do this.

If you want to be able to run the commands without PTP (which is probably required to get PTP/IP working) you will need to use my patch.

I didn't include the stubs the auto-generated files in my patches, but if you rebuild with primary bin they should be regenerated. I haven't tested my last patch on vxworks, but it should probably work.

Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 12108
Re: Wireless investigations
« Reply #43 on: 26 / December / 2013, 17:43:25 »
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.
Don't forget what the H stands for.


Re: Wireless investigations
« Reply #44 on: 26 / December / 2013, 18:00:22 »
Any idea if this is going to be manufacturer dependent?   Santa brought both Transend & a Toshiba card this year.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 12108
Re: Wireless investigations
« Reply #45 on: 26 / December / 2013, 18:54:30 »
Any idea if this is going to be manufacturer dependent?   Santa brought both Transend & a Toshiba card this year.
All of the above only refers to cameras with an actual wireless NIC built in. Except for the old sd430 that ahull has, I would expect them to be very similar.

Wireless SD cards are a completely different topic. They have their own CPU on board, and do not provide a wireless network interface to the camera firmware. The firmware on non-wireless cams does not include a networks stack or PTP/IP.

eyefi uses some special files to control the card (http://chdk.setepontos.com/index.php?topic=6753.0 ), but this doesn't let you send packets over the network from the camera. I have no idea if other cards use the same or similar interface. Since it's not standard or well documented, I would guess not, but it's possible some have copied it to some extent.
 
People have hacked the transcend cards: http://hackaday.com/2013/09/19/advanced-transcend-wifi-sd-hacking-custom-kernels-x-and-firefox/
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 12108
Re: Wireless investigations
« Reply #46 on: 27 / December / 2013, 01:08:55 »
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
Looking at this more, startCameraServiceProvide sets all CDcvry_StartServiceProvide parameters to 0. The third (R2) would be expected to contain the GUID sub_FF17ABE4 looks for, so the eventproc case must not expect it to be filled in. The call to sub_FF17ABE4 is skipped if 0x655C+0x18  is non-zero. The only place I see this set is from sub_FF17901C which looks like it's called form the factory mode network eventprocs.

calling sub_FF17ABE4 after join_network sets 0x655C+0x18, but CDcvry_StartServiceProvide still fails, now producing a log message.
Code: [Select]
== EPILOG SHOW ==
== index r:00000000 w:00000001
== total r:00000000 w:00000001 max: 00000155
==      level:00000006 group:0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
000.013s950m:01:   ****:PhySw:[CDcvry] StartServiceProvide Failed
 
== EPILOG SHOW END ==
Don't forget what the H stands for.

Re: Wireless investigations
« Reply #47 on: 27 / December / 2013, 21:42:39 »
Hi all,

Attached shows two Ixus 240 when inter-connected by Wi-fi

H_H

continued # 48
« Last Edit: 27 / December / 2013, 21:46:10 by Hardware_Hacker »


Re: Wireless investigations
« Reply #48 on: 27 / December / 2013, 21:49:18 »
Continued from #47

Compile Errors-3268 when appling patch.

H_H

Continued to # 49
« Last Edit: 27 / December / 2013, 21:57:45 by Hardware_Hacker »

Re: Wireless investigations
« Reply #49 on: 27 / December / 2013, 21:57:06 »
Continued from #48

Trunk-3268 - ixus140 vs ixus 240 - funcs_by_name-csv - Compared

Am I doing some thing wrong ??? or should I have also applied a previous patch.

The Ixus 140 and Sd430 are only included so as to find any "Errors"

I have also changed or am also testing some other stuff such as the mode-maps.

H_H
« Last Edit: 27 / December / 2013, 21:59:12 by Hardware_Hacker »

 

Related Topics