Can the veraplus be UNBRICKED?

Yes! Exactly that.

You were looking at your interfaces from inside a fully-booted Vera. But when Vera is in recovery or update mode, the Vera “overlay” isn’t “up” yet; the machine is in a bare-bones, almost factory-reset condition.

It first boots OpenWRT, sets up the main WAN address per DHCP, then adds a hardcoded ‘backup’ address (192.168.1.1) to a virtual interface (eth0.1), to which you should be able connect if there are problems, and the Vera customization scripts are supposed to take it from there – which won’t happen if your network’s default gateway uses the same IP as the ‘backup’ address.

I suppose if I still had a laptop with an ethernet port, I could have used a crossover ethernet cable (or two regular cables and a hub/switch), forced my laptop to use 192.168.1.2/255, and connected to the Vera; I would probably have been able to SSH into it at that point via that ‘backup’ 192.168.1.1 address. But Vera still wouldn’t have been able to get outside the local network (which at that point would only be my laptop and Vera), so it would not have helped to get Vera back online.

In this situation, one either has to reconfigure their entire network to use a different subnet, or reconfigure the default gateway to use some other address than 192.168.1.1… or take the approach I did, which seems like the easier path: just force Vera to drop the “backup” interface via ‘ifconfig eth0.1 down’. Of course, that will only work from the serial console (3V3 FTDI + 3x wires connected to J1,2&4), not from an ethernet-connected session (which would be connected to 192.168.1.1, so killing eth0.1 would end the SSH session).

In retrospect, it might not even have been necessary to add a default route; the WAN interface is getting that from DHCP, so the route is probably already there. Just stopping the backup interface from stealing all the outbound traffic might be sufficient. Next time I brick my VeraPlus, I’ll test that hypothesis :joy:

Good luck with your resurrection attempt!

im glad @kapstaad that the method worked for you. I have also tried whit several baud rates to work, i suppose dependieng on the firmware actually instaled on the unit it can change.
My problem was similar for the ip config. So i suponse the units lost connection and if you can make it accesible to the internet it will countinue with the update process.

That certainly seems to have been the case for me. Again: a big THANK YOU for your post!

I’ve finally connected to my VeraSecure via USB TTY and with the baud rate at 57600, putty it’s showing various activity.

[  249.812000] led off GPIO_LED_ZIGBEE
[  249.964000]
[  249.964000] led off GPIO_LED_LPRF
[  250.084000]
[  250.084000] led off GPIO_LED_SERVICE
[  250.204000]
[  250.204000] led off GPIO_LED_3G
[  250.884000] led blink GPIO_LED_WIFI
[  251.028000] led blink GPIO_LED_BLUETOOTH
[  257.876000]
[  257.876000] led off GPIO_LED_ZIGBEE
[  259.872000]
[  259.872000] led off GPIO_LED_SERVICE
[  259.924000]
[  259.924000] led off GPIO_LED_LPRF
[  261.128000]
[  261.128000] led off GPIO_LED_ZIGBEE
[  261.248000]
[  261.248000] led off GPIO_LED_LPRF
[  261.368000]
[  261.368000] led off GPIO_LED_SERVICE
[  261.488000]
[  261.488000] led off GPIO_LED_3G
[  268.896000]
[  268.896000] led off GPIO_LED_ZIGBEE
[  270.896000]
[  270.896000] led off GPIO_LED_SERVICE
[  270.960000]
[  270.960000] led off GPIO_LED_LPRF
[  272.152000]
[  272.152000] led off GPIO_LED_ZIGBEE
[  272.272000]
[  272.272000] led off GPIO_LED_LPRF
[  272.392000]
[  272.392000] led off GPIO_LED_SERVICE
[  272.508000]
[  272.508000] led off GPIO_LED_3G
[  279.952000]
[  279.952000] led off GPIO_LED_ZIGBEE
[  281.980000]
[  281.980000] led off GPIO_LED_SERVICE
[  282.036000]
[  282.036000] led off GPIO_LED_LPRF
[  283.216000]
[  283.216000] led off GPIO_LED_ZIGBEE
[  283.336000]
[  283.336000] led off GPIO_LED_LPRF
[  283.456000]

Unfortunately the screen keeps on updating with log information to allow me to see anything very easily, plus it will reboot every now and then - but I’ve typed in ifconfig -a and that only lists 4 interfaces (eth0, gre0, gretap0, lo)

eth0      Link encap:Ethernet  HWaddr 78:94:B4:F7:85:AC
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:1281 (1.2 KiB)
          Interrupt:3

gre0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-D0-33-00-00-00-00-00-00-00-00
          NOARP  MTU:1476  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

gretap0   Link encap:Ethernet  HWaddr 00:00:00:00:00:00
          BROADCAST MULTICAST  MTU:1476  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          LOOPBACK  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

None of which have an IP address assigned, so I’m guessing my issue is that I can’t get an IP?

If i type reboot I can see it cycle through everything again, but it still does not pick up an IP address, but it does report some interesting things, see extracts below… e.g.

STANDALONE_LOAD_ADDR is 0xa1200000
..
******************************************
    Uboot StandAlone Entry
******************************************


Please choose the operation:
   2: Load system code then write to Flash via TFTP.
   3: Boot system code via Flash (default).
   4: Entr boot command line interface.
   9: Load Boot Loader code then write to Flash via TFTP.                                                                                                                                                                                  0

******************************************
    Uboot StandAlone Entry
******************************************
Flash Sector Number : 522.

***************************************************
    Sercomm Boot Version 3.00.1

***************************************************
Entering Firmware : Everything is OK.

=================================================
Check image validation:
Image1 Header Magic Number --> OK
Image2 Header Magic Number --> Failed
Image1 Header Checksum --> OK
Image1 Data Checksum --> .........................OK

Image1: OK Image2: Broken
..Done!

=================================================
..kernel addr :0xbc140000

flash base: 0xbc000000, kernel addr :0xbc140000, bootloader size: 0x80000, config size 0x80000, fac size : 0x40000
..Erasing NAND Flash...
.Writing to NAND Flash...
done

3: System Boot system code via Flash.
## Booting image at bc140000 ...
   Image Name:   OpenWrt Linux-3.10.14
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    1580859 Bytes =  1.5 MB
   Load Address: 82001000
   Entry Point:  82001000
.........................   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 82001000) ...
## Giving linux memsize in MB, 256

Starting kernel ...

Also after doing a quick search in the file system,

root@MiOS_5510000:/ ls
1                  lib                proc               sys
bin                mios               rom                tmp
dev                mios_constants.sh  root               usr
etc                mnt                sbin               var
foo                overlay            storage            www

where under storage, I found this…

root@MiOS_5510000:/storage# ls -l
drwxr-xr-x    2 root     root             0 Jun 17  2018 cmh-backup
drwxr-xr-x    5 root     root             0 Jun 17  2018 cmh-firmware

cmh-backup was empty, but in cmh-firmware, i can see the following

drwxr-xr-x    2 root     root             0 May 22  2018 1.7.3062
drwxr-xr-x    2 root     root             0 Jun 17  2018 1.7.3535
drwxr-xr-x    2 root     root             0 Jan  1 00:00 1.7.3832
-rw-r--r--    1 root     root           156 May 22  2018 error.log
-rw-r--r--    1 root     root           162 Jun 17  2018 latest_firmware.conf

Within the error.log, it seems to only say…

2018-05-22_15:12:38 - ERROR: Failed to copy MiOS Squashfs MD5SUM into jffs2 partition
2018-05-22_15:12:38 - ERROR: Mismatched md5sum of new Firmware Script

Other than the above, I can’t see anything specific to what the cause might be - any ideas ?..

Hi all

Anyone have any thoughts on what to do, no IP, but I could plug in a usb stick if that helps ?

Hi everyone. I had Vera edge in a cyclic reboot. I saw the forum section and decided to try to connect via UART TTL. After connecting, the console appeared with a constant reboot. After the tenth attempt, I managed to insert the command “reboot config” into the console line and the magic happened, the web interface loaded. And the controller was factory-configured.