Jump to content

Aaron407

Members
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. I come bearing closure I discovered that the one camera becoming stable was actually due to iSpy, for some reason, falling back to the low resolution secondary stream. Putting it back to the main stream had it full of disconnections again. I was able to do a reset of the GUI parameters on the one camera, which removed the odd overlaid numbers from the side of the screen. Putting both cameras with their main streams into iSpy again, though, worked terribly as they were both continually dropping out. So, I installed the demo version of Blue Iris. It recognized the cameras right away, connected, and never lost them. That software is a piece of beauty, so I paid the $60CAD for a license. Free iSpy vs. Blue Iris - I guess I got what I paid for. Anyway, things seem to be working well now, and I might even add a few cameras now that I have a solid monitoring solution. Thanks for all of the help throughout this fight of mine. I should have switched to Blue Iris months ago and saved myself a lot of headaches.
  2. Well, I updated the firmware, but it didn't seem to make any difference. Then I changed the h.264 profile to "high", and, strangely, it has become very stable. So, I updated the other identical camera with the same firmware, and it has now fallen apart. Constant disconnects in iSpy, and it has a bunch of numbers on the left side of the screen (see attachment). Reflashing and rebooting haven't helped. I guess I got what I paid for with these cameras.
  3. After a lot more digging, I'm starting to think that the program and the web interface don't actually use a typical http stream address for accessing the camera stream. I've dug through wireshark for more hours than I'd like to admit, and I can see the connection happening, but it's passing numerous other parameters through rather than requesting from a specifically formatted address. I have monitored wireshark while using the CMS software, the web interface, and with the manufacturer's android app, and it appears that they use javascript to effectively log into the camera and pull the stream rather than a full http address. I'm not sure where to go from here other than garbaging the cameras and going with something more stable. What really bothers me is that I can see the stable streams in CMS, the web applet, and the android app while the RTSP stream is falling apart and resulting in disconnects in iSpy. Maybe I should bail on iSpy and go with another monitoring platform. Does anyone have any suggested alternatives?
  4. Well, I tried using URL snooper with a direct connection, but it didn't find anything. I then used wireshark and managed to get a couple of captures when launching the CMS monitoring program. Unfortunately, I'm not sure how to interpret the data as the packet information doesn't contain cleanly formatted data. As such, I'm also not sure how much sensitive data might be buried in the capture. So, rather than post it publicly, is there anyone who would be so kind as to sift through a couple of my captures and see if there's anything usable? I can see when communication starts between the two devices, and see frames that might be useful, but don't know how to interpret it. If anyone is interested, please let me know through PM and I'll send you links to the two capture files. Thanks in advance for any help!
  5. Sorry for the delay in responding. I used wireshark and captured a lot of packets between the camera and the capture computer when running the CMS software. I dug through every packet and found that some seemed to include parameter data for a stream or interface, but they were not in a URL format and seemed to be completely unformatted. Unfortunately, I'm not sure exactly how to strip out personal information from the .pcap file, so I'm hesitant to post it publicly (that, and it's about 100 MB in size right now). This problem ended up costing me. At 12:40am on June 26th, we had a brief power outage. The CMS software shows that the camera disconnected and reconnected 30 seconds later, presumably through the HTTP stream. However, iSpy didn't reconnect, and later that day someone stole an off-road vehicle out of our shed. The camera obviously hadn't reconnected to be able to catch them on video, so I'm pretty much SOL and seriously disappointed by our loss. It was a dune buggy that my young kids and I had used extensively to explore our new 80 acre land parcel over the last couple of years, and I had put about 60 hours into restoring it. Sad day, although they got to meet a police officer. Anyway, I'm going to try connecting a camera directly to a computer's ethernet port and see if I can capture anything more with wireshark and URL snooper. I'm going to scan right from camera startup as well to see if it might be broadcasting anything that could provide any clues. I need to figure this out, or we will continue to feel uneasy living away from neighbors who now can't keep a watchful eye on our place.
  6. I ran wireshark when starting up the CMS software, and sifted through the raw packet data for all packets between the computer and IP camera, in both directions. I found some of what appeared to be smaller negotiation packets which included parameter data, but they didn't include any actual URLs. I'm not familiar with multicast, but, if it might not be tied to the same two addresses, I definitely might have missed something. If I can figure out how to export the log with any unnecessary data stripped out, I'll definitely post it. Thanks for sticking with me on this, I appreciate it.
  7. Sorry, one question regarding Nmap and the script. It looks like the script only applies to RTSP streams. I can access those, whereas I'm trying to find the HTTP stream being used by the CMS software (which I know is an HTTP address as it is using the media port rather than the RTSP one). Is there anything similar for HTTP media URLs? I took a quick look through the scripts on the webpage, but didn't see one that would fit.
  8. Yeah, it's on the same machine as the CMS capture software. There is also an option in URL Snooper for it to look beyond the computer (I believe "promiscuous" is the term they use), but I haven't needed it.
  9. Thanks, I'll definitely look into that. In terms of Wireshark, I have used it in the past for other applications, but I didn't dive in too deep. Since the URL Snooper application uses the same backend (winpcap), I figured that it would find the same results, but maybe I'm wrong. I'll have more digging to do anyway.
  10. Thanks for the responses guys. The camera does have a label as noted below, but it hasn't really helped me to track anything down. SGB Model: SG-5036?8 2.0MP SONY CMOS IP CAMERA SYSTEM: NTSC POWER: DC12V MADE IN TAIWAN Beyond that, the only other labeling on the camera is a sticker with the default local IP address, and a “logo” of sorts stating “IR COLOR CCD CAMERA DIGITAL”. All settings for the camera seem to have to be made through the CMS software, but I haven't been able to find a firmware version for the camera itself. I would assume from the "SGB" ahead of the model number that it would be considered the manufacturer, but I haven't been able to find an associated website. iSpy also doesn't have SGB listed as a make. As for the ip address post, thanks, but I do indeed have that side covered, and it's just finding the http stream URL that is causing me grief.
  11. Thanks! I was very optimistic about that application, but, unfortunately, it ended up not helping. I can see every full URL request from iSpy, but it doesn't show anything in terms of requests from the other programs. Any other ideas?
  12. Thanks for the offer to help. That's the thing, I know the IP address and the port with certainty. The CMS software can scan IP addresses, and sees the correct one with the correct port, and connects to it without issue. I can enter that same IP address and port number into vMEyeSuper HD, and it connects beautifully as well. I just need to know what complete URL either the app or the CMS software are using to access the stream since none of the typical ones that I've tried in iSpy are working. Any other ideas? I'm open to trying pretty much anything to track this down.
  13. Hi everybody, I'm a new member to the board, mostly because I can't seem to figure out URL formatting for accessing my cameras. I picked up a cheap chinese IP camera (I know, first mistake...) with virtually no documentation. They came with a link to the standard CMS software, which I can use to access the stream without any issue. The stream is stable and uses the standard media port (8086 in my case). I can also find the stream using the Android vmEyeSuper HD app, with a strong and stable stream with the same local IP and port number. They work even when RTSP is disabled in the camera. The problem is that I can't get iSpy to access through that port, presumably due to not knowing how to format the url. I have tried all of the generic formats for http, but nothing wants to connect. I can connect via RTSP and ONVIF, but I have found that there are many stream disconnections and poor FPS, while the stream in the CMS application stays strong at the same time, presumably with HTTP access. What I'm trying to determine is what URL either CMS or vmEyeSuper HD are actually using for accessing the camera. I have dug into it through wireshark, but that only shows the IP address and port for the request, but not the full call address. Can anyone suggest how to determine this URL? I've been banging my head against the wall for days trying to figure it out, but haven't had any luck. Any help would be greatly appreciated!
×