Thanks for the information. I'll get the device tomorrow and report back.
Hello, I'm new to this forum but I was active in the old one. The problem was: If you ever configure an OpenWRT device correctly you have never to touch it for years. 
I recently bought a device based on the same chipset. For small money I got a Netgear EX6150v2 and it seems to be a nice device. The "problem" is, it only has one Ethernet port and I want to use it as a router for my local LAN.
So I have the VDSL2-Modem in the basement connecting it to my managed switch. Than I will patch the EX6150v2 to the managed switch.
After it I want to get at least 2 VLANs working on the one port of the Netgear device: One for the dedicated PPPoE connection to the VDSL2-Modem and one for routing the internet traffic to my LAN over the managed switch in the basement. So I will test it as well and hopefully it's working!
So I got the device and VLANs seem to work but a kind of a weird way for me.
I wanted to bridge a LAN port to WAN. This config does work
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 '64'
config interface 'wan'
option ifname 'eth1'
option proto 'dhcp'
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 '2 3 4 0t'
config switch_vlan
option device 'switch0'
option vlan '2'
option vid '2'
option ports '0t 1 5'
What is weird that I didn't have to bridge eth1 to eth0.2, and lan is still eth0, not eth0.1.
It looks like eth1 is connected to the switch somehow to port 5 and bridging is done by the switch.
VLANs 1and 2 are “magic” in the DTS/driver, so perhaps serendipity.
1 Like
I will look into the code and try to find out what this "magic" means.
1 Like
4 Likes
I'm currently configure a Netgear EX6150v2 (IPQ4018 and only one Gbit port).
I need a tagged VLAN7 on the port for my ISP Pppoe connection. The lan traffic should be untagged on the same port.
According to your explanation that's not possible, only VID1 and 2 are working like magic?
I would try setting it up like "normal" on the WAN port and the ethN.7 as appropriate.
I haven't gotten deep enough into the code to have a hypothesis of what works and what doesn't as far as config past the "normal". As running a VLAN on the WAN port is pretty normal, it may just work.
A lot of the problems I have run into seem to be related to spanning the WAN and LAN ports on the switch, especially when tagged on one port and not on others.
1 Like
Thanks Jeff! Here is my current config:
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 'fd7b:5eba:f476::/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 interface 'wan6'
option ifname 'eth0.7'
option proto 'dhcpv6'
option auto '0'
I see the interface in Luci and over the CLI with ifconfig.
But when I try to connect a modem to the port the connection attempt failed. A similar config is working on the C2600 but it has a different target and an integrated switchport.
Wan should be eth1.7 I guess.
I guessed eth0 because there is only one switchport in the device and the default interface is eth0 and it's working. So I assumed to give eth0.7 a try. 
I also listed all network devices as described in the Vlan documentation and it only shows me virtual interfaces and eth0.
What does
swconfig dev switch0 show
output?
This is not the default vlan setup and it is unclear which port is used on this device.
Please reset the device to defaults and post /etc/config/network including switch config.
I think tagging is needed on the port that is actually used.
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
~
1 Like
Fails on all non-JFFS2 overlays, which includes NAND/UBIFS
2 Likes
@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
1 Like