CH R0 misbehaving after upgrade to 5.4.5

ritz

n3wb
Aug 10, 2020
2
1
timbuktu
Hi, I have a Chinese R0 2032-I, which served me well for ~5 years. For various reasons, over the past 5 years, I had its web interface exposed to the Internet. In the last month or so I figured that I could not log on anymore (was getting message "password incorrect", although it was my usual password that I was trying). Thought camera got hacked and decided to upgrade it. Original fw=5.2.3 build 141024.

I used @alastairstevenson brickfixV2 tool and went straight up to 5.4.5. The upgraded camera worked for about 10-15 mins (I had re-configured pretty much everything again). I then left home happy. When I used tinycam Pro on Android to check the stream remotely, the camera was offline. Long story short, I figured out that the camera was continuously rebooting. I tried all possible 'acrobatics' that I could find in this forum and went from downgrading to upgrading all over again. I finally got to the web GUI of a 5.4.5 f/w again. After full reconfiguration (now armed with access to the serial console and the camera fully disassembled), I realise that something odd is going on with the camera: it works OK while I'm browsing the web config menus, but as soon as a client (tinycam pro, browser, etc.) logs off the camera goes into a 'bad state' and starts rebooting continuously. When this happens I see the following message in the console:

Code:
[08-13 12:47:46][pid:839][STRM_ANLS][ERROR]Client close fd break
Unix bus detect one process  exit.Please check
detected id 1 ;davici: id = 1, netprocess: id =2

It turns out that I do not have to re-flash the f/w to make the camera work again. A normal reboot won't fix the problem, but I can get access to the web interface eventually after connecting the camera with an ethernet wire to a laptop (laptop eth interface pre-configured to 192.0.0.128, no TFTP servers running) and then take that wire out and plug the camera into my regular network (192.168.0.0/24). At next reboot the camera is back up again.

I have managed to capture some logs in case anyone could help. Does the above sound puzzling, or familiar to anyone? Could it be a f/w issue, a h/w issue, a network+f/w issue?
 
Does the above sound puzzling, or familiar to anyone?
Puzzling and not familiar.
Firmware 5.4.5 is solid as a rule.

davinci (the main app) has aborted, and the daemon_fsp_app program that launched it notices that and triggers a reboot.
The log may show why davinci aborted, especially if you add dbg=8 to the end of the bootargs variable in the bootloader.

As a longshot, you could try installing 5.4.41 which is newer that 5.4.5

It turns out that I do not have to re-flash the f/w to make the camera work again. A normal reboot won't fix the problem, but I can get access to the web interface eventually after connecting the camera with an ethernet wire to a laptop (laptop eth interface pre-configured to 192.0.0.128, no TFTP servers running) and then take that wire out and plug the camera into my regular network (192.168.0.0/24). At next reboot the camera is back up again.
That is a bit odd too.
Maybe wire the camera with a different ethernet cable to a different switch port and power it differently to see if anything changes.
 
That is a bit odd too.
Maybe wire the camera with a different ethernet cable to a different switch port and power it differently to see if anything changes.

Something not right with the 2032 and IPv6. I noticed an ERROR about ARPING in the console when switching eth cable from private lan (straight to a dev laptop 192.0.0.128) back to the home lan switch. This makes the camera "auto-repair itself" and provide me with a web gui in the next reboot. I have a Synology 214play on the home switch. NAS is IPv6 enabled and emits Route Advertisements. Never had an issue with any other device (few are dual stack at home, including the OpenWRT main router). Changed settings on the camera to use DHCPv6 (not running one on home network) as opposed to RA and have not experienced this issue since.

The issue seems to be systematic, if anyone wanted to debug further.

I have enabled SSH (to look at console messages), removed camera from public Internet, and all seems solid again.

Thanks everyone for the very valuable info in this forum.
 
  • Like
Reactions: alastairstevenson