It runs, so I can't imagine it being corrupted. If it were corrupted, it'd be highly unlikely that the program would execute.
I'm also on my 2nd HikVision TFTP. So I kinda tried that already
Help reverting or fixing a 5.3.0 firmware update
- Thread starter tastle
- Start date
I'm also on my 2nd HikVision TFTP. So I kinda tried that already
Here's my current plan for tonight:
- I'm going to repeat my steps, and I might try running TFTP as "administrator". (I think this is set by default, but my head is so frayed, I'm at least going to double-check.) If that doesn't work...
- I'm not going to use my Asus RT-N56U as the middle component between the camera and my computer. Instead, I'm going to use my Cisco SG200-26P (non-PoE port). If that doesn't work...
- I'm going to try to use a cross-over cable between the Camera and the computer. If that doesn't work...
- I'm going to try a different computer.
As for the firmware to use (switching to optimistic mode), do you guys think it'd be better to go with the one provided to me from the seller I bought the camera from, or one of the ones I was given in a link above? I'm leaning towards the one the seller provided.
Thanks again to everyone for all of your help. I'm learning a lot, and I have a feeling that I've either hit a wall, need to start eliminating unknown points of failure, or going to kick myself for missing something stupidly obvious.
whoslooking
IPCT Contributor
I wouldn't waste your time with the crossover cable that is so hit and miss,
As to the firmware I would use my one from the link@alastairstevenson posted but I'm biased as it's mine lol
As to the firmware I would use my one from the link@alastairstevenson posted but I'm biased as it's mine lol
Last edited by a moderator:
haha, thanks for making me laugh.
/sigh, busy weekend.
I'm starting to wonder if it's not working because the camera's terminating the open port very quickly. Does that make any sense?
I'd appreciate any thoughts.
Edit: I re-read some other posts and the above seems to be expected. I assume it should "wait and hold" the IP if it receives a response from my computer?
I've tried:
The only thing I have let to try is a different computer than my Alienware m14x.
I'm starting to wonder if it's not working because the camera's terminating the open port very quickly. Does that make any sense?
Code:
C:\WINDOWS\System32>ping -t 192.0.0.64
Pinging 192.0.0.64 with 32 bytes of data:
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.64: bytes=32 time=1150ms TTL=255
Reply from 192.0.0.64: bytes=32 time<1ms TTL=255
Reply from 192.0.0.64: bytes=32 time<1ms TTL=255
Request timed out.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.64: bytes=32 time=1290ms TTL=255
Reply from 192.0.0.64: bytes=32 time<1ms TTL=255
Reply from 192.0.0.64: bytes=32 time<1ms TTL=255
Request timed out.
Reply from 192.0.0.128: Destination host unreachable.
Reply from 192.0.0.128: Destination host unreachable.Edit: I re-read some other posts and the above seems to be expected. I assume it should "wait and hold" the IP if it receives a response from my computer?
I've tried:
- Running the application from C:
- Running the application as Administrator.
- I've tried using my Cisco switch instead of my Asus router. Then I tried my switch without the Asus router, and then I tried a crossover cable. (Yea, I know it shouldn't work, but I'm running out of ideas.)
The only thing I have let to try is a different computer than my Alienware m14x.
Last edited by a moderator:
alastairstevenson
Staff member
It's normal that there are only a couple of ping responses to 192.0.0.64 if the camera does not succeed in the handshake with the TFTP server. The test of the TFTP server takes only milliseconds.
Your network captures have shown that the TFTP server is not responding to the UDP probe packet sent by the camera.
You have tested with the Windows firewall turned off - though have you checked that the inbound rule for 'tftpserv.exe' is 'allow' for UDP (Advanced settings)?
Do you have any of the more sophisticated anti-virus active that provides a form of 'network access protection' that would inhibit the UDP packet such as Symantec Endpoint Security?
Your network captures have shown that the TFTP server is not responding to the UDP probe packet sent by the camera.
You have tested with the Windows firewall turned off - though have you checked that the inbound rule for 'tftpserv.exe' is 'allow' for UDP (Advanced settings)?
Do you have any of the more sophisticated anti-virus active that provides a form of 'network access protection' that would inhibit the UDP packet such as Symantec Endpoint Security?
whoslooking
IPCT Contributor
Try another pc or try safe mode, seem to be your only other option. It's a simple app but you have definitely have some thing blocking it from running normally.
- I added a special rule for TFTP incoming to allow everything.
- I disabled my puny Windows Defender. It doesn't really have network access protection.
No dice. But thanks for the tips. It was worth a try.
Yea, you're right. I need to prioritize this work during the day where I can get a hold of someone else's computer. Preferably XP, since I recall (before I switched it to debian) XP on my old Dell 710m was the only thing able to root my android. Of course I had to be stupid and do this while I have a dozen things on the go
WOAH boys and girls, we got life!
I got to thinking about how wonky Windows firewalls were, and when alastairstevenson mentioned the inbound firewall rules, I decided to press 't' a few times to see what was in there. Sure enough, windows set a bunch of rules on tftpserv. Then I remembered in the past that even if you shut off your firewall, and those rules exist, they still seem to get applied. So I deleted them all, started up again and set new rules.
The connection was made!
I'm so excited. I'm going to restart and see where that gets me.
I got to thinking about how wonky Windows firewalls were, and when alastairstevenson mentioned the inbound firewall rules, I decided to press 't' a few times to see what was in there. Sure enough, windows set a bunch of rules on tftpserv. Then I remembered in the past that even if you shut off your firewall, and those rules exist, they still seem to get applied. So I deleted them all, started up again and set new rules.
The connection was made!
I'm so excited. I'm going to restart and see where that gets me.
Attachments
Last edited by a moderator:
I'd like to thank each of you for getting me this far. I think you're doing this for free, so it's very much appreciated.
I might need to start another thread though. I can see my camera in SADP (Software Version V4.0.8build 150401) but I'm not having any success changing the settings. (Trying to set DHCP.) I'm always getting the "Failed to modify the settings.ID:001" I thought I was using the firmware that whoslooking provided, but I might have used the Chinese one instead. I know the other camera had version 5.2.5 firmware.
Also the HTTP port is grayed out. /hmmmm
What should I do next?
Should I try to load the other firmware?
I might need to start another thread though. I can see my camera in SADP (Software Version V4.0.8build 150401) but I'm not having any success changing the settings. (Trying to set DHCP.) I'm always getting the "Failed to modify the settings.ID:001" I thought I was using the firmware that whoslooking provided, but I might have used the Chinese one instead. I know the other camera had version 5.2.5 firmware.
Also the HTTP port is grayed out. /hmmmm
What should I do next?
Should I try to load the other firmware?
Last edited by a moderator:
Sounds like a failed firmware upgrade. You will not be able to change the settings in SADP while it is in the MIN system.
Use the firmware available in this thread.
http://www.ipcamtalk.com/showthread.php/4036-Custom-Firmware-Downgrader-5-3-0-Chinese-to-5-2-5-English
Cheers
Use the firmware available in this thread.
http://www.ipcamtalk.com/showthread.php/4036-Custom-Firmware-Downgrader-5-3-0-Chinese-to-5-2-5-English
Cheers
alastairstevenson
Staff member
Well done!
Interesting that the firewall is still active when disabled. Most odd. Unless it was the 'public' mode of it.
Now your troubles really start as you puzzle over the multiple choices and consequences of the many firmware versions ...
Interesting that the firewall is still active when disabled. Most odd. Unless it was the 'public' mode of it.
Now your troubles really start as you puzzle over the multiple choices and consequences of the many firmware versions ...
whoslooking
IPCT Contributor
1st how old is the camera roughly (when you broght it)?
Where did you buy the camera?
Can you see the sticker on the camera if so what is written on it.
Where did you buy the camera?
Can you see the sticker on the camera if so what is written on it.
No dice. Once I started seeing how the camera wasn't reacting to SADP, I tried to repeat the process but use the other firmware. No luck. I run ping while plugging in the camera and it doesn't respond at all. It's like it's not running on that IP (192.0.0.64).
I bought it a month ago. I picked it up off of ebay. Chinese model of course, well reviewed seller. On the bottom there is a sticker.
Attachments
Nothing wrong with the camera or the firmware... but from someone not reading the forums for advice before trying to upgrade. Grass is not greener from newer firmware. Sad, the Chinese have a regional firmware for their area, and we bought into it. Call nellys and buy something else. Lesson learned. Don't upgrade.
whoslooking
IPCT Contributor
A silly mistake that load of people have made with lessons to be learned.
Use this firmware to fix your camera with 5.2.5
https://www.dropbox.com/s/3hy72q4oss...rader.rar?dl=0
And Enjoy your Camera in Multi Language.
Use this firmware to fix your camera with 5.2.5
https://www.dropbox.com/s/3hy72q4oss...rader.rar?dl=0
And Enjoy your Camera in Multi Language.
Something I don't understand is if I don't see TFTP and the camera connect when trying the other firmware linked a few comments above, I can't see how a different firmware would change anything since it's just the payload. Of course I'm not in the "boot loop" situation now (and again, I really thank you for your help), but I'm not sure how to get the software on if I can't find a way to get it on. I got a PM earlier and I'm going to read that thread to see if it jogs the neuron that isn't firing in my head at the moment.
alastairstevenson
Staff member
This is the 'Min system mode' that a camera will go into when the kernel boots but cannot initialise the environment properly for the main application. We've seen this on newer (ie 2Q2015) cameras with older firmware (eg 5.2.0) that can't control the updated DSP. But the end result is usually still seen by SADP.
Though I don't pretend to know much detail about this - I managed to fully erase the flash in my test camera before I got a chance to explore this new aspect. I should have another in a couple of weeks - I have a friend visiting China with a shopping list.
Also what I don't have any info on, which might have a bearing on this specific problem, is when on the 5.3.0 firmware the camera bootloader is changed, if at all, to use the different default IP address of 192.168.1.64, which is mentioned in the 5.3.0 Release Notes as the new default. Does installing the firmware change this, or is it something programmed into the bootloader of newer cameras during manufacture?
Maybe someone knows and can comment.
Perhaps a quick network capture of the camera at power-on with the Hik TFTP server running in the usual way would shed some light on what if anything could be a next step.