5 MegaGixel 1/1.8" low light destroyer for $90-AVOID LONGSE JUNK

Well that sucks.
Hope prices when things are up and running will not go up like they did years back with the flooding of Thailand in 2004.
Western digital prices went up and up and very slowly down again.
 
Having bought the CantonK version of the S500 (KIP-500DR20H) and tested it in various locations currently occupied by Hikvision 2-series cameras I really liked the image quality and build quality and am going to give it a permanent home at the expense of one of my Hiks.
But before I do that, I thought it would be prudent to look a bit under the covers to see if there were any obvious risks, especially having read some of the posts and concerns and findings here:
https://www.ipcamtalk.com/showthrea...a-that-doesn-t-phone-home-to-China-random-IPs

So the first thing to do was to have a good look at the network traffic and see if it was doing anything I'd prefer it didn't.
And the result was - there appears to be absolutely zero strange traffic going out to the internet, the device looks clean.
I'm pleased and maybe a bit surprised at that.
Especially as there is a P2Pserver running and consuming a few CPU cycles:
Code:
Mem: 47604K used, 11948K free, 0K shrd, 0K buff, 19236K cached
CPU: 10.5% usr  0.5% sys  0.0% nic 88.8% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 5.66 5.75 5.71 1/113 1234
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
  849     1 root     S     163m279.8   0  9.7 /usr/AVServer
 1116     1 root     S     229m392.7   0  0.3 /boaServer/boa
 1114     1 root     S    88408147.8   0  0.3 /usr/freep2p_server
  854     1 root     S     128m219.9   0  0.2 /usr/SystemServer
 1118     1 root     S    36088 60.3   0  0.1 /usr/DeviceSearch
 1234  1230 root     R     1768  2.9   0  0.1 top
    3     2 root     SW       0  0.0   0  0.1 [ksoftirqd/0]
 1230   844 root     S     1784  2.9   0  0.0 -sh
  844     1 root     S     1780  2.9   0  0.0 telnetd
  841     1 root     S     1768  2.9   0  0.0 /bin/login
    1     0 root     S     1764  2.9   0  0.0 init
 1120     1 root     S     1268  2.1   0  0.0 /usr/WatchDog
  593     1 root     S <   1068  1.7   0  0.0 udevd --daemon
  670   593 root     S <   1068  1.7   0  0.0 udevd --daemon
  661   593 root     S <   1068  1.7   0  0.0 udevd --daemon
  845     1 root     S      848  1.4   0  0.0 /usr/Main
 1080     1 root     S      840  1.4   0  0.0 /usr/HWatchDog
  579     2 root     SWN      0  0.0   0  0.0 [jffs2_gcd_mtd2]
  249     2 root     SW       0  0.0   0  0.0 [kworker/0:1]
  161     2 root     DW       0  0.0   0  0.0 [kusbotg]
~ #

So next up was a good old vulnerability scan to see if there were any known vulnerabilities that might make the device into a foothold on the LAN. Not that the LAN is configured with inbound access, but that's not the only way the bad actors get around your network.
I gave the scanner root telnet access so it could have a good look around.
There were the expected dozen or so 'informational' findings - such as what OS is running, what type of web server etc.
The only finding above 'information' was a 'medium' one - yes, you've guessed it - telnet traffic including credentials are passed in plain text.
And that was all.
Quite comforting.

But there was one surprising finding - which nmap on my normal settings did not spot - there is a small set of ports which are set up presumably for debug purposes.
They chat away on various topics, a bit like the kernel msg log would do.

I know that doesn't make this camera a hardened appliance, but it does provide a degree of comfort that there is nothing major to worry about.
Time to have another look at Hikvision IP cameras to see if they've sorted that vulnerable 'dropbear' version yet ...
 
@alastairstevenson, I have the same camera and have been trying to get to play in Rpisurv. I cannot get stream 2 to play in either omxplayer or vlc, any hints to the proper string? Thanks.
 
Last edited by a moderator:
I'm not sure, as I haven't tried that.
But here is what ONVIF Device Manager thinks will work:
Main stream : rtsp://192.168.1.168:80/0
Sub stream : rtsp://192.168.1.168:80/1
And VLC seems happy with them:
VLC_1.jpgVLC_2.jpg
 
  • Like
Reactions: bob2701
I know that doesn't make this camera a hardened appliance, but it does provide a degree of comfort that there is nothing major to worry about.
Time to have another look at Hikvision IP cameras to see if they've sorted that vulnerable 'dropbear' version yet ...


Thanks for that! Great to know.

I must have missed it, what's the telnet root user/pass for these cam's
 
Thanks for that! Great to know.

I must have missed it, what's the telnet root user/pass for these cam's

Definitely comforting news! Now they should make the firmware a bit more stable in terms of image control among other things. Every time I fine tune something in the image settings things get out of control where too much over processing applied so I am mostly running at default settings
 
Hi all!
ive been following this thread now for a number of months as I've been wanting to upgrade one of my cameras. So, I finally made the plunge and bought a S500 from Longse.
When it arrive I connected it up and all seemed good... For a while.
When darkness came, I noticed that the ired LEDs just flash on and off, roughly at a mark / space of about 1 second. The image would still be there but erratics due to the switching lighting levels.

After further investigation, I discovered if I powered up the camera in the dark and it hasn't been powered up for a while, the LEDs will stay on for a short period (<30 secs) before cycling again. If I then turn off the power and put it back on, the LEDs start to cycle straight away, before the camera has had time to boot. The camera is on its own 6A PSU.

There is nothing close and bright to reflect the ired straight back to force the ldr to switch off the LEDs.

I'm guessing that the fault lies with the ired LED board? As I see the effect even when the camera hasn't had time to boot up. I'm also guessing a power related issue for two reasons, if the camera is cold, then the LEDs work fine. Once the problem starts, the problem stays until the camera has been powered down for a short while. Also, the camera does get quite warm with the LEDs on!

Any thoughts...?

Thanks


Rice
 
I'm guessing that the fault lies with the ired LED board? As I see the effect even when the camera hasn't had time to boot up. I'm also guessing a power related issue for two reasons, if the camera is cold, then the LEDs work fine. Once the problem starts, the problem stays until the camera has been powered down for a short while. Also, the camera does get quite warm with the LEDs on!
That's not good - it sounds like the camera has a hardware fault.
And you've figured that it seems to be temperature related.
Let us know how Longse react to the problem.
 
I have IR switching on/off when I use ircut mode set to Video Auto, if I use LDR Auto, it's not an issue. I am not even sure what's the purpose of Video Auto mode. What is your ircut filter time set to?
 
Last edited by a moderator:
I have IR switching on/off when I use ircut mode set to Video Auto, if I use LDR Auto, it's not an issue. I am not even sure what's the purpose of Video Auto mode. What is your ircut filter time set to?

Thanks for the reply. I've tried both Video Auto and LDR Auto, it doesn't make any difference to the LEDs cycling.
The default value for the icut filter was set to 3. I've tried this setting with different values and it makes no difference.
Looks as though once the cycling begins, the only way to cure it (for a very short while!) is to either power down the camera for a few minutes are have enough light so the LEDs are naturally switched off for a while.

Again, it is looking towards some heating issue with the LED control board :sad2:
I've emailed Eddy at Longse so see what he comes back with...


Rice
 
I'm not sure, as I haven't tried that.
But here is what ONVIF Device Manager thinks will work:
Main stream : rtsp://192.168.1.168:80/0
Sub stream : rtsp://192.168.1.168:80/1
And VLC seems happy with them:
View attachment 10168View attachment 10169

Thanks @alastairstevenson, played fine in vlc with both port 80 or 554 but no video in omxplayer. It sees the port but does not connect. I'll keep playing.

Update... I must have been in a dead zone last night when I tried this. (Me being dead)

Works great with either :80/1 or :554/1 but must add user name and password. Thanks @alastairstevenson,
 
Last edited by a moderator:
Credentials always help ... good to know they are on the ball with security ...
Well done for getting there.
I actually find that a glass or 3 of vino rosso makes things work so much better. Until you come to review what you've done the next day and can't figure it out at all.
 
The camera just arrived. I had problems finding it in my network at 192.168.1.168, with the installation disc I finally found the camera at 192.168.1.222.
I hooked the cam up to my Synology with the Synology Surveillance Station and it was surprisingly easy to setup, so I can confirm the S500 works with a Synology NAS.

Attached are two screenshots of the S500 on the Synology Surveillance Station.
One is live view (black and white) and one is playbak (color). The JPG compression makes the black and white image ugly, in real life it is beautiful. :D

Synology Longse Live.JPGSynology Longse Playback.JPG
 
Good to know that it works with Synology. Frankly in this view, you are not showing true potential of the sensor in this cam :)
 
  • Like
Reactions: Maurice Sundermann
I was about to buy some of these to test on my synology. I take it you used the onvif profile?

Interested to see if you get fully functionality of Surveillance Station using it this way?
 
Yes I took the ONVIF profile, check the attached image. It's just that simple to set it up.
And yes, you can get the full functionality from the SSS. :)

Translation*: Apparaatinstellingen = device settings, Naam = name, Poort = port, Merk = brand, Gebruikersnaam = username, Wachtwoord = password.

Synology Longse Settings.JPG
 
Last edited by a moderator:
  • Like
Reactions: Danfozzy85