Oh, one other thing, my camera did not reboot itself after the process was indicated as being complete. I unplugged the camera and powered it back on. I read in another thread that this happened to them as well. (even though the instructions indicate it will reboot itself.)
R6 Camera upgraded to 5.5, now ONVIF problems
- Thread starter rprade
- Start date
Oh, one other thing, my camera did not reboot itself after the process was indicated as being complete. I unplugged the camera and powered it back on. I read in another thread that this happened to them as well. (even though the instructions indicate it will reboot itself.)
Ok, one additional update. I was able to successfully reload/re-flash a freshly downloaded R6 5.4.5 on top of the "fake" 5.4.5 without issues in both the browser, and in the IVMS4200 client. (I know that the "fake" 5.4.5 was real with just a modified header to make the camera think it was 5.5.0, but I like knowing there wasn't anything else accidentally messed up in that non-official firmware file.)
I also did another wireshark test on the camera after a fresh 5.4.5 was installed, and it still was trying to reach 192.168.1.128 from a 192.168.1.64 IP.
I also did another wireshark test on the camera after a fresh 5.4.5 was installed, and it still was trying to reach 192.168.1.128 from a 192.168.1.64 IP.
alastairstevenson
Staff member
I will get it pulled down and try later this evening. I would prefer to have it off of my network when trying since there are 13 other Hikvision cameras. I am learning Wireshark now.So, did it work? I am on pins and needles here
Ahh, I gotcha, sounds good. The wireshark application is pretty easy. I had it installed on my laptop, and used a USB Ethernet dongle that I manually set to 192.168.1.128. I then connect it and the camera to a spare switch I had and made sure nothing else was connected. (This ins't necessary, but it helps in reducing the clutter that wireshark will see on the line you are monitoring). I then plugged the camera in, and watched the packet info from wireshark. What becomes pretty clear is when you see requests / responses about 192.168.1.128 from 192.168.1.64, etc. (I would say pay attention to the .128 and .64, maybe it might be something other than 192.168.1.x. )
When you see what you want/expect, you can stop wireshark, power off the camera, and start the TFTP server (after you set your ip address to whatever wireshark indicates the camera is asking for) and power the camera back on. It should only take a few seconds for the tftp process to begin, and it maybe took 1 - 2 minutes for the tftp program to show that it was all complete. I then closed the tftp program, and disconnected the power from the camera and plugged it back in to have it boot up.
Good luck, and let us know how it all goes, I am sure this thread will help others if they want to get off of 5.5.0 on R6 (and other revisions if they create their own fake 5.5.0 using a 5.4.5 firmware.)
Using Wireshark I am only seeing activity at the IP addresses assigned to the camera. The 2442 has been reset, it is only seen as 192.168.1.64 and the 2142 is at 192.168.2.114 which is its current address on my local network. There are a couple of IGMPv3 reports, a bunch of MDNS queries and a single UDP to 239.255.255.250. Nothing looking for 192.0.0.128 or 192.162.1.128.
This makes me feel like I am making some sort of rookie mistake, but I haven't a clue what it is.
This makes me feel like I am making some sort of rookie mistake, but I haven't a clue what it is.
First question, is it just the computer and the camera plugged into the switch, and the adapter on the computer is set to 192.168.1.128? When you started wireshark, did you select the adapter that has the 192.168.1.128 IP address assigned? I attached a picture of the first wireshark I did, when I had the computer setup as 192.0.0.128. See the line 5 and 6, this is what you should see where the camera is asking if anybody on the network knows of 192.168.1.128. This is how I realized that the camera was using 192.168.1.64 and not 192.0.0.64.
Well what I would try is to set the computer to 192.168.1.128 start the tftp process and power on the camera. If it works you will see status updates in the tftp window a second or two after you plug in the camera.
Well what I would try is to set the computer to 192.168.1.128 start the tftp process and power on the camera. If it works you will see status updates in the tftp window a second or two after you plug in the camera.
Attachments
Only 1 NIC on the computer and it is the only device connected to the switch. I first had it set to 192.0.0.128 then tried 192.168.1.128, both with Wireshark looking at that adapter. I never saw the requests.
OK, Here is an odd one. Today I decided to take a fresh look. I used a 12V power supply and a standard switch instead of a POE switch. I connected the camera to the switch, then applied 12V to it. As it booted, it was found by TFTP and the software was updated (downgraded to 5.4.5) and ONVIF is working again.
I cannot understand why it didn't work with the POE switch. I wonder if the POE switch doesn't negotiate a connection quick enough to catch the bootloader. At least I can reflash them now, but I will have to pull each one down to power it separately.
I cannot understand why it didn't work with the POE switch. I wonder if the POE switch doesn't negotiate a connection quick enough to catch the bootloader. At least I can reflash them now, but I will have to pull each one down to power it separately.
Last edited:
alastairstevenson
Staff member
That has the ring of plausibility.
This type of problem caused problems with network booting of the Raspberry Pi 3. The switch (not PoE) the bootcode was developed and tested on was quite quick to establish a connection and pass traffic. Other switches that users had were in some cases slower, so some probe packets were not passed by the switch and the network boot timed out.
Well done for getting there and sharing, others may have the same problem.
Out of interest - what's the brand/model of POE switch?
Ubiquiti US-8-150W.
I am going to try another low end (unmanaged) POE switch and see if it makes any difference. I have some other ideas to try. I will post back if I can sort this further.
I am glad you were able to get it working! I didn't even think about the POE aspect, as I used a dumb switch and the 12v power. (After it was all done, I plugged it back into my POE.)
Awesome that you got it working. Did it use the 192.168.1.128/64 IPS or the 192.0.0.x IPs?
The one camera I tried was a 2142 and it found the TFTP server at 192.0.0.128.
I haven't been able to get it to work with my dumb TP-Link POE switch. To save dismounting 13 more cameras I am going to pick up a POE injector tomorrow and see if I can use that with a dumb switch. That way I can apply power after making the Ethernet connection to the switch. If that works, I can do it all at my main switch one at a time, saving dismount/remount
Hopefully this will help others.
I used the Hikvision TFTP server and the fake 5.5 firmware binary. I got all 14 rolled back to 5.4.5 170124 and they are all working again.
I initially tried to do them over the network and that failed, sort of expected. I tried with a Ubiquiti US-8-150W POE switch, a Ubiquiti US-8-60W and a TP-Link unmanaged POE switch. The TFTP program never saw the cameras and Wireshark never saw the cameras request for 192.0.0.128. My thinking is that the switches did not negotiate a connection fast enough for the TFTP server to see the bootloader request for 192.0.0.128.
With a dumb switch and a 12V power supply and the camera on my bench, it worked immediately. I connected the Windows 7 machine running TFTP to the switch, connected the camera to the switch, then applied 12V from the power supply to the camera.
The problem with this is 10 of the 14 cameras are mounted up high and outside and two of them are mounted high inside the house, meaning that I would have to pull them down one by one, reflashing the camera, installing them and aiming them again if needed. That is a lot of work.
I went to Microcenter and picked up a TP-Link POE injector, connected it to a dumb switch (a crossover cable would also work) and connected the TFTP server to the switch. I powered the injector, started TFTP and plugged the first cameras cable into the injector. TFTP started immediately and uploaded the firmware in about a minute. The next 13 all worked the same and I had them all done in less than 30 minutes. Then I used the SADP tool to reactivate them and set them for DHCP. I had originally set them for static IPs in 2016, but now that I have all UBNT equipment, I used DHCP reservations to set their addresses. Then I used the batch config tool to reflash them with a downloaded 5.4.5 just to make sure the binary was correct.
I used the TFTP program posted above by alastairstevenson and the fake 5.5 firmware from a post linked above.
I want to thank all for the help here and I hope this will help others in the same boat.
I used the Hikvision TFTP server and the fake 5.5 firmware binary. I got all 14 rolled back to 5.4.5 170124 and they are all working again.
I initially tried to do them over the network and that failed, sort of expected. I tried with a Ubiquiti US-8-150W POE switch, a Ubiquiti US-8-60W and a TP-Link unmanaged POE switch. The TFTP program never saw the cameras and Wireshark never saw the cameras request for 192.0.0.128. My thinking is that the switches did not negotiate a connection fast enough for the TFTP server to see the bootloader request for 192.0.0.128.
With a dumb switch and a 12V power supply and the camera on my bench, it worked immediately. I connected the Windows 7 machine running TFTP to the switch, connected the camera to the switch, then applied 12V from the power supply to the camera.
The problem with this is 10 of the 14 cameras are mounted up high and outside and two of them are mounted high inside the house, meaning that I would have to pull them down one by one, reflashing the camera, installing them and aiming them again if needed. That is a lot of work.
I went to Microcenter and picked up a TP-Link POE injector, connected it to a dumb switch (a crossover cable would also work) and connected the TFTP server to the switch. I powered the injector, started TFTP and plugged the first cameras cable into the injector. TFTP started immediately and uploaded the firmware in about a minute. The next 13 all worked the same and I had them all done in less than 30 minutes. Then I used the SADP tool to reactivate them and set them for DHCP. I had originally set them for static IPs in 2016, but now that I have all UBNT equipment, I used DHCP reservations to set their addresses. Then I used the batch config tool to reflash them with a downloaded 5.4.5 just to make sure the binary was correct.
I used the TFTP program posted above by alastairstevenson and the fake 5.5 firmware from a post linked above.
I want to thank all for the help here and I hope this will help others in the same boat.
alastairstevenson
Staff member
That is a brilliant result. Well done!
That's a pretty neat solution to the problem of timing and physical accessibility.
In effect - you are providing a remote power supply that becomes available at the same time as the ethernet connection.
I have a question : did you try having the PoE injector unpowered, with all cables connected, then applying the power?
To my mind this would more closely follow the on-the-bench scenario of being wired up then powered on via external 12v.
That's pretty likely. Thanks for sharing.
I tried it and it didn't work. I'm thinking it takes a few seconds for the switch to start up, but the POE is there immediately. The timing is critical. I found that he camera negotiates with TFTP almost immediately and the camera doesn't see it in that very narrow window, it continues with a normal boot. I'm guessing that one could SSH into the camera and possibly change the timing, but that is well above my pay grade.
I will file this procedure away, but it seems unlikely I will be going beyond 5.4.5 on these cameras unless Vivotek fixes their software (unlikely) or Hikvision corrects whatever they broke on ONVIF with 5.5 (very unlikely). I really have no idea who is really at fault.