I am trying to use Fiddler 4.6.1.4 to determine the format of http control strings for an IP camera.
I need to be able to exercise various camera functions from its application which runs within a browser after entering its IP address.
The application will only run completely correct in IE. When using any other browser, only part of its functionality is available and excludes functions I need to test.
The problem is, I have been able to successfully use Fiddler with Firefox or Opera for this purpose but not IE. I am running Windows 7 and have tried IE11, IE10 and now regressed to IE9 and all have the same problem. When the IP address is entered and the application starts to load, Fiddler captures all of the resulting traffic but when the application is done loading, the app controls will operate the camera but none are captured by Fiddler. This does work correctly, with apparently the identical internet proxy settings, with, e.g., Opera (but with only the limited camera functions noted). With any of these browsers, Fiddler does appear to automatically set the proxy settings as expected but only with IE does it not respond to commands sent.
I have tried everything I can find on the net and in your troubleshooting guidelines to no avail. Please suggest how I can resolve this issue.
9 Answers, 1 is accepted
The most likely explanation is that the camera site in question uses an ActiveX control when running inside IE, and that ActiveX control either doesn't properly respect the system proxy, or (more likely) does not use HTTP/HTTPS to control the camera, instead using straight TCP/IP or UDP packets.
If you enable ActiveX Filtering in IE (on the Tools menu), this will cause IE not to load the ActiveX control and should allow you to verify that this is what's happening.
Regards,
Eric Lawrence
Telerik
Rank 1
Eric,
Thanks very much for your reply!
However, turning on ActiveX Filtering in IE made no difference.
I should mention again the following:
-- The IP camera is directly connected to the router that serves my PC. Thus, there is no "camera site" per-se. The camera itself serves its own application, as is common with such cameras.
-- The only other way I have to gain full camera control is via a standalone application called CMS. However, its commands are also ignored by Fiddler.
-- The camera controls are, indeed, http commands. For example, to start a pan one can send:
http://192.168.1.10/command=ptz_req&req=start¶m=directionright&channel=1&stream=0
The portion staring with command=... is displayed in Fiddler TextView. 192.168.1.10 is listed under host and /dvrcmd under URL.
-- Firefox and Opera also operate the camera (but with reduced functionality) and work correctly with Fiddler with no particular extra configuration required, except the proxy settings imposed automatically by Fiddler.
I hope this additional info will help diagnose the problem.
Thanks again,
Ron
Can you send me a capture (File > Save All Sessions, Help > Send Feedback and attach the .SAZ file)?
Without using an ActiveX control, there's no way for requests to bypass the proxy inside Internet Explorer.
Regards,
Eric Lawrence
Telerik
Rank 1
Eric,
Here is the .saz file.
But one question: If the problem was that the application was using ActiveX controls, why would Opera and Firefox running the same application work correctly with Fiddler?
Ron
Correction -- Looks like a .saz file is not an allowed file type for attachment. How can I get that file to you?
You can send me a capture by clicking (File > Save All Sessions) then clicking (Help > Send Feedback) and attach the .SAZ file) to the email in question.
Most applications that use an ActiveX control also have a more-limited functionality fallback that does not require the control.
Regards,
Eric Lawrence
Telerik
Rank 1
Hi Eric,
I sent you the file by replying to the email from clientservice@telerik.com -- I hope that you received it.
Some additional info:
To verify that the camera app uses ActiveX controls, I enabled prompts for ActiveX in IE. Running the app does indeed prompt for ActiveX controls. However, when I used Process Explorer to see what controls it may use, there are no .ocx files in the associated tab.
I noticed RapportGP.dll and Rapport Util.dll in the Process Explorer info. Turning off Trusteer Rapport and stopping any Rapport processes made no difference to that listing or to Fiddler operation.
If the use of ActiveX controls prevents me from using Fiddler to determine how to control this camera, then I sure hope you have a suggestion for another method to determine that. Being able to write the needed Python code to control all functions of this camera seems to depend on figuring this out....
Ron
Unfortunately, no, I don't receive emails to that account. If you click Help > Send Feedback, it creates a new email to fiddler @ telerik{dot}com, which I do receive.
Most ActiveX controls are no longer stored as .OCX files; they're instead simply .DLL files.
There are some complicated hacks you could try to collect the traffic with Fiddler, but if the URL to the camera isn't HTTPS, the easiest thing you could do is use Wireshark or Microsoft Network Monitor to collect the low-level TCP/IP traffic. If the traffic is HTTP (but simply bypassing the proxy) Fiddler can import that (File > Import > Packet Capture). If the traffic isn't HTTP, you can examine it directly using Wireshark or NetMon.
Regards,
Eric Lawrence
Telerik
Rank 1
Eric,
I sent you the file to the email address you provided.
Makes sense that the ActiveX controls are .DLLs -- that's what I do see in Process Explorer.
Importing a collected Wireshark file to Fiddler did not turn up anything useful.
Tried to use Netmon but it seems quite opaque to me -- I think the demo is not effectively enabled for my purpose.
If the traffic is not HTTP, as it appears, I have not found a way to configure Wireshark to make sense of the traffic of interest. That is, I see loads of transmissions to/from the camera URL but suspect that is all due to updating the image and statusing. I don't understand how to use filters to isolate just commands from the IE host app to the camera and from that see the kind of command detail I need to write a sketch to emulate such commands.
Meanwhile, using an NVR program, I have been able to verify that the camera does respond properly to ONVIF controls. Perhaps I will have to go back to trying to make it work by that programatically more complex route.
Thanks,
Ron
Thanks for the capture; I'll have a look and mail you back. If you have a PCAP file, I can take a look at that as well.
Regards,
Eric Lawrence
Telerik