Ok. Yesterday I flashed the 18.06.2 stable build via the Netgear webinterface. Then I just added my wifi credentials and added the driver based vlan in the network config.
I will reset the device in the evening. Is more needed than a 'firstboot' command over the CLI?
I will report back the default network config and the output of 'swconfig dev switch0 show'. Thanks in advance!
Edit: I see there is the 18.06.4 available. I will flash this tonight!
firstboot is OK
I updated to the latest stable (18.06.4). What's really strange: I can't perform a firstboot from the CLI! It says it will do all the stuff but it doesn't reboot from itself.
root@OpenWrt:~# firstboot
This will erase all settings and remove any installed packages. Are you sure? [N/y]
y
/dev/mtdblock14 is mounted as /overlay, only erasing files
After it I can reboot the device and perform a factory reset with Luci. Strange!
And here are the default settings on the device:
BusyBox v1.28.4 () built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt 18.06.4, r7808-ef686b7292
-----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:~# cat /etc/config/network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd09:910b:372e::/48'
config interface 'lan'
option type 'bridge'
option ifname 'eth0'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
root@OpenWrt:~#
'swconfig dev switch0 show'
Global attributes:
enable_vlan: 1
enable_mirror_rx: 0
enable_mirror_tx: 0
mirror_monitor_port: 0
mirror_source_port: 0
linkdown: ???
Port 0:
mib: Port 0 MIB counters
RxBroad : 2
RxPause : 0
RxMulti : 17
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
Rx64Byte : 139
Rx128Byte : 632
Rx256Byte : 33
Rx512Byte : 6
Rx1024Byte : 21
Rx1518Byte : 10
RxMaxByte : 56
RxTooLong : 0
RxGoodByte : 188958
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
TxBroad : 142
TxPause : 0
TxMulti : 666
TxUnderRun : 0
Tx64Byte : 0
Tx128Byte : 1468
Tx256Byte : 146
Tx512Byte : 17
Tx1024Byte : 118
Tx1518Byte : 40
TxMaxByte : 0
TxOverSize : 0
TxByte : 300703
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
TxSingleCol : 0
TxExcDefer : 0
TxDefer : 0
TxLateCol : 0
pvid: 0
link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
Port 1:
mib: Port 1 MIB counters
RxBroad : 0
RxPause : 0
RxMulti : 0
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
Rx64Byte : 0
Rx128Byte : 0
Rx256Byte : 0
Rx512Byte : 0
Rx1024Byte : 0
Rx1518Byte : 0
RxMaxByte : 0
RxTooLong : 0
RxGoodByte : 0
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
TxBroad : 0
TxPause : 0
TxMulti : 0
TxUnderRun : 0
Tx64Byte : 0
Tx128Byte : 0
Tx256Byte : 0
Tx512Byte : 0
Tx1024Byte : 0
Tx1518Byte : 0
TxMaxByte : 0
TxOverSize : 0
TxByte : 0
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
TxSingleCol : 0
TxExcDefer : 0
TxDefer : 0
TxLateCol : 0
pvid: 1
link: port:1 link:down
Port 2:
mib: Port 2 MIB counters
RxBroad : 0
RxPause : 0
RxMulti : 0
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
Rx64Byte : 0
Rx128Byte : 0
Rx256Byte : 0
Rx512Byte : 0
Rx1024Byte : 0
Rx1518Byte : 0
RxMaxByte : 0
RxTooLong : 0
RxGoodByte : 0
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
TxBroad : 0
TxPause : 0
TxMulti : 0
TxUnderRun : 0
Tx64Byte : 0
Tx128Byte : 0
Tx256Byte : 0
Tx512Byte : 0
Tx1024Byte : 0
Tx1518Byte : 0
TxMaxByte : 0
TxOverSize : 0
TxByte : 0
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
TxSingleCol : 0
TxExcDefer : 0
TxDefer : 0
TxLateCol : 0
pvid: 1
link: port:2 link:down
Port 3:
mib: Port 3 MIB counters
RxBroad : 0
RxPause : 0
RxMulti : 0
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
Rx64Byte : 0
Rx128Byte : 0
Rx256Byte : 0
Rx512Byte : 0
Rx1024Byte : 0
Rx1518Byte : 0
RxMaxByte : 0
RxTooLong : 0
RxGoodByte : 0
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
TxBroad : 0
TxPause : 0
TxMulti : 0
TxUnderRun : 0
Tx64Byte : 0
Tx128Byte : 0
Tx256Byte : 0
Tx512Byte : 0
Tx1024Byte : 0
Tx1518Byte : 0
TxMaxByte : 0
TxOverSize : 0
TxByte : 0
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
TxSingleCol : 0
TxExcDefer : 0
TxDefer : 0
TxLateCol : 0
pvid: 1
link: port:3 link:down
Port 4:
mib: Port 4 MIB counters
RxBroad : 142
RxPause : 0
RxMulti : 666
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
Rx64Byte : 278
Rx128Byte : 1195
Rx256Byte : 142
Rx512Byte : 17
Rx1024Byte : 118
Rx1518Byte : 40
RxMaxByte : 0
RxTooLong : 0
RxGoodByte : 293611
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
TxBroad : 2
TxPause : 0
TxMulti : 17
TxUnderRun : 0
Tx64Byte : 139
Tx128Byte : 637
Tx256Byte : 28
Tx512Byte : 8
Tx1024Byte : 21
Tx1518Byte : 66
TxMaxByte : 0
TxOverSize : 0
TxByte : 186754
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
TxSingleCol : 0
TxExcDefer : 0
TxDefer : 0
TxLateCol : 0
pvid: 1
link: port:4 link:up speed:1000baseT full-duplex txflow rxflow auto
Port 5:
mib: Port 5 MIB counters
RxBroad : 0
RxPause : 0
RxMulti : 0
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
Rx64Byte : 0
Rx128Byte : 0
Rx256Byte : 0
Rx512Byte : 0
Rx1024Byte : 0
Rx1518Byte : 0
RxMaxByte : 0
RxTooLong : 0
RxGoodByte : 0
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
TxBroad : 0
TxPause : 0
TxMulti : 0
TxUnderRun : 0
Tx64Byte : 0
Tx128Byte : 0
Tx256Byte : 0
Tx512Byte : 0
Tx1024Byte : 0
Tx1518Byte : 0
TxMaxByte : 0
TxOverSize : 0
TxByte : 0
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
TxSingleCol : 0
TxExcDefer : 0
TxDefer : 0
TxLateCol : 0
pvid: 2
link: port:5 link:down
VLAN 1:
vid: 1
ports: 0t 1 2 3 4
VLAN 2:
vid: 2
ports: 0t 5
~
Fails on all non-JFFS2 overlays, which includes NAND/UBIFS
@jeff the workaround in the described bug report seems not to work for me. Is there a way to perform a firstboot manually?
I tried a mount_root before I ran firstboot. It didn't reboot by itself.
I think the most robust is to boot into failsafe, don't mount the overlay and then re-init the volume, truncating it with double check this first!!
root@OpenWrt:/# ubinfo /dev/ubi0_1
Volume ID: 1 (on ubi0)
Type: dynamic
Alignment: 1
Size: 953 LEBs (121008128 bytes, 115.4 MiB)
State: OK
Name: rootfs_data
Character device major/minor: 252:2
Once you're sure of the proper volume
ubiupdatevol /dev/ubi0_1 -t
root@OpenWrt:/# ubiupdatevol --help
ubiupdatevol version 2.0.2 - a tool to write data to UBI volumes.
Usage: ubiupdatevol <UBI volume node file name> [-t] [-s <size>] [-h] [-V] [--truncate]
[--size=<size>] [--help] [--version] <image file>
Example 1: ubiupdatevol /dev/ubi0_1 fs.img - write file "fs.img" to UBI volume /dev/ubi0_1
Example 2: ubiupdatevol /dev/ubi0_1 -t - wipe out UBI volume /dev/ubi0_1
-t, --truncate truncate volume (wipe it out)
-s, --size=<bytes> bytes to read from input
--skip=<bytes> leading bytes to skip from input
-h, --help print help message
-V, --version print program version
Thank you! I think it's better for me to wait for tomorrow and try it with a fresh mind. Before I have to figure out which button I can use as failsafe-button and how to perform the boot into failsafe mode.
Something like this may work
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd09:910b:372e::/48'
config interface 'lan'
option type 'bridge'
option ifname 'eth0'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option ifname 'eth0.7'
option proto 'pppoe'
option password 'mypw'
option username 'xxx@t-online.de'
option ipv6 'auto'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option vid '1'
option ports '0 1 2 3 4'
config switch_vlan
option device 'switch0'
option vlan '7'
option vid '7'
option ports '0t 1t 2t 3t 4t'
Actually it looks like port 4 is in use. But we can use all if that is wrong.
Thanks @Pilot6. I will try it today. Something for my understanding:
Normally the CPU-port on the switch should always be tagged, shall it? In every OpenWRT router I have there is the CPU port of the switch always tagged even if the physical lan ports are untagged.
Someone also owns the EX6150v2?
Not always. The default vlan 1 config for my NBG6617 is with port 0 untagged. That means that all traffic by default goes to vlan 1 no matter is it tagged or not. It is hardcoded in dts.
You may be correct for the case when eth0 is used for both lan and wan. Change it fo 0t.
And when I am using vlans, it is still untagged on vlan 1.
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option vid '1'
option ports '0 2 3 4'
config switch_vlan
option device 'switch0'
option vlan '2'
option vid '2'
option ports '0t 1 5'
Thank you all for your advices! I will report back today.
Can someone explain why the factory reset performed over Luci seems to work and firstboot over the CLI doesn't?
I'm guessing that it's the mounted vs. not-mounted branch in jffs2reset (yes, JFFS2 tools running against UBIFS). https://git.openwrt.org/?p=project/fstools.git;a=tree overlay_delete() is in libsftools/overlay.c
Thanks for pointing out! I was just wondering why my try to factory reset in Luci seems to work. I can see the LEDs of the router are blinking and the device is rebooting by itself. I would expect a password and old configs in the webinterface if the factory reset isn't working but it looks like a fresh install.
Are you still advice to do a factory reset with the failsafe method or can I just trust the webinterface. Just asking for timesavings!
PS: You guys are great, so helpful and fast answers! Thanks a lot!
I don't trust something named jffs2reset with UBIFS, especially what I have seen of it so far. If I really need a "factory reset" on a NAND-based device I'll either manually "reformat" the overlay, or, more likely, reflash the device.
Very seldom do I need a full, factory reset -- if I need to revert a file or two that is auto-generated, I delete the file, then reboot.
Should a reflash with the CLI sufficient? I think I can do this way more faster (and more safe) than wiping some partitions. 
Reflash using sysupgrade, as long as you specify -n, should work as well.
There are good reasons to prefer ubiupdatevol (which sysupgrade typically eventually calls) over writing a raw image with NAND, such as a U-Boot flash would do.
Is ubiupdatevol /dev/<right_ubi_device> /tmp/netgear_ex6150v2-squashfs-sysupgrade.bin the right way to go? The sysupgrade firmwares are the correct one for the ubiupdatevol? What's the name of the ubi-partition i have to look for?
And running the command from a normal booted device is ok, no need for failsafe mode?
No, sysupgrade.bin for most NAND devices is actually a tar file. Install with
sysupgrade [-n] /tmp/some-squashfs-sysupgrade.bin
sysupgrade deals with the "dance" required to change root underneath a running system.
An end user would probably use ubiupdatevol to erase the overlay, as I outlined above.
A developer might use it to write locally generated UBI volume images, but that isn't common.
Thank you! This worked, I only additionally added the '0t' to the VLAN1 tagging!
I performed the sysupgrade like @jeff described and went through the configuration. So it's possible to use VLAN-tagging on the EX6150v2. Thank you so much!