Firmware RMERLIN 3.0.0.4.220.17 - VLAN Id > 15 not supported ?

[orev]

Hi all,

My ISP is using VLAN VID 100 for IPTV.

My network architecture is (Router RT-N66U with firmware RMERLIN 3.0.0.4.220.17) :
ISP modem >> port 0 > Router > port 1 >> Switch >> Misc equipments and ISP TV Player

I am trying to bridge VLAN VID 100 on WAN port 0 and LAN port 1.

NVRAM's tested configuration is :
vlan2hwname=et0
vlan2ports=0 8u

vlan1hwname=et0
vlan1ports=1 2 3 4 8*

vlan100hwname=et0
vlan100ports=0t 1t 8

But, after reboot, there is no /proc/net/vlan/vlan100.

I can create this file using the command vconfig add eth0 100. However, the bridge doesn't seem to work properly.

If I use a VID value X < 15 for NVRAM settings (e.g. vlanXhwname anf vlanXports), the file /proc/net/vlan/vlanX is correctly created after reboot.

There is a similar discussion about VLAN range limitation (VID range VS number of VLANs) in DD-WRT forum : http://www.dd-wrt.com/phpBB2/viewtopic.php?t=86919&postdays=0&postorder=asc&start=90

Is someone knows a solution (bypass, or driver fix) ? Do I need to change firmware ?

Thanks.

 

[orev]

Patch to enable 802.1q vlan IDs >15 on BCM53115 switches

Hi RMerlin,

I have just finished to review the patch submitted on the DD-WRT forum :
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=533830#533830

It is compliant with the Broadcom 53xx RoboSwitch device driver, provided in Asus native firmware, found in this file : release/src-rt/shared/bcmrobo.c

The patch allows to circumvent the limitation of 15 VLANs (but the max number of simultaneous declared VLAN is still 15 - hardware limit due to the switches VLAN config register which is 16 bits wide and where 4 bits are used for the VLAN Id and 12 bits are used for the tag), by adding a new NVRAM setting vlanXXXXvid, which allows to map a VID > 16 to a declared VLAN ID (from 1 to 15).

For example, map VLAN 10 to VID 920 :
set vlan10ports="0t 1t 8"
set vlan10vid=920 (if omitted, VID remains 10)

It would be a nice improvement over the native firmware.

Are you agree to add this patch to your next release (I can be your beta-tester if you want) ?

Thanks,
Orev

 

[RMerlin]

Are you agree to add this patch to your next release (I can be your beta-tester if you want) ?

Not at this time. That patch only applies on the older driver (the 6.x driver code used by the RT-AC66U is different), and too many unknowns as to what side-effect it can cause (for instance, other bits of code might expect a 4-bit value, and get thrown off by having a 8-12 bits value instead). This could lead to really hard-to-troubleshoot bugs that could be device-specific.

Maybe someday when the rest of the code is solid enough to start getting more experimental, but the firmware hasn't reached that stage yet.

 

[orev]

RMerlin, thank you for your quick answer.

I understand your concern regarding your primary goal for this enhanced but stable native firmware.

Do you know any workaround using your firmware to solve my ISP constraint (bridge of VLAN ID 100) ?

Or I have to change my firmware, I read that Tomato shibby version has implemented this fix :
http://repo.or.cz/w/tomato.git/commit/1e0e835b00038aade91fad42c42d359bab0a0dab

 

[RMerlin]

RMerlin, thank you for your quick answer.

I understand your concern regarding your primary goal for this enhanced but stable native firmware.

Do you know any workaround using your firmware to solve my ISP constraint (bridge of VLAN ID 100) ?

Or I have to change my firmware, I read that Tomato shibby version has implemented this fix :
http://repo.or.cz/w/tomato.git/commit/1e0e835b00038aade91fad42c42d359bab0a0dab

No idea, I never played with VLANs.

If ISPs are using such high numbered VLANs while Broadcom (a pretty major router SoC manufacturer) doesn't support them, then something is wrong IMHO. Means those ISPs have done zero reasearch before setting up their network.

I recommend you Email Asus about this (you can contact CL-Jeremy here, he can relay the information to the right persons at Asus), as this is something Asus will want to look into, possibly by asking Broadcom about it. I would feel more comfortable if this issue were to be resolved by Broadcom or Asus, as they are far more familiar with the kernel code.