I think it would be best to just remove the 16 VLAN limit and keep the VID and VLAN numbered the same.
Yep, I agree with that.
It would actually simplify the patch for BCM53115 switches - just walk the whole range from 1...4094 and see whether anything is defined, and then just program it (since I'm remapping the vid in all places where it's programmed already, so no "table index" stuff here).
For "max 16 VLAN" switches, one would need to carry a "vlan_index" variable that counts vlans-in-use and is used in places where you need a vlan index (0..15) that points to the "real" VID - and if you reach 16, print a warning and ignore the rest.
My approach is basically a hack to see whether it can be done at all, and to get it done without having to touch anything in the existing userland tools for now (just setup "vlan920" manually, which is fine for our needs). Your approach needs some restructuring in the GUI (can't just display "all 15 VLANs" anymore, need to have <add> buttons...) and in the "create interfaces at bootup" code (walk to 4094, not only to 15). But that's all just some coding not fundamental "figure out whether the hardware can do it at all" stuff.
Posted: Sun Feb 06, 2011 12:46 Post subject: notice
hi,
just noticed that the patch I've posted has an oversight in there - it does "arl_entry[6] = (vid_map & 0x255);" which obviously should be "arl_entry[6] = (vid_map & 0xff);"
I'm not exactly sure whether these arl_entry settings have any effect - but *if* we poke a vlan ID there, it should be done properly
Posted: Sun Feb 06, 2011 13:19 Post subject: cleaned up patch
Hi,
a cleaned-up patch that doesn't print so much debug info but still works is attached. Functionally, it's the same changes (but with the arl_entry[] stuff fixed).
I've also tested vlan ID 4022 now (random VID >1024), and that also works (pinging from router, and adding vlan4022 to bridge groups).
gert
bcmrobo-c-patch2.txt
Description:
patch to enable 802.1q vlan IDs >15 on BCM53115 switches, like in the E3000 (for DD-WRT's bcmrobo.c)
Posted: Mon Feb 07, 2011 6:04 Post subject: Re: Awesome!!! thank you.
cron2 wrote:
My approach is basically a hack to see whether it can be done at all, and to get it done without having to touch anything in the existing userland tools for now (just setup "vlan920" manually, which is fine for our needs). Your approach needs some restructuring in the GUI (can't just display "all 15 VLANs" anymore, need to have <add> buttons...) and in the "create interfaces at bootup" code (walk to 4094, not only to 15). But that's all just some coding not fundamental "figure out whether the hardware can do it at all" stuff.
That's not really a fair statement. Both approaches need a GUI update for the GUI to be able to configure things and both approaches allow the user to configure nvram variables if the GUI isn't updated.
tangsoft wrote:
hope this patch would be built into next release version of firmware.
if it does trick on 5325 that is perfect.
I wouldn't expect it any time soon. Right now it's a rough proof of concept that needs to be cleaned up before implemented so that it doesn't cause more problems than it solves.
I'm going to try some more to get a build environment working so that I can help out with this because I really want better VLAN support. I have a VM that I think is close to being able to build but I put it on hold half a year ago to do a lot of research/documentation about VLAN support. If anyone has a VM with a working build environment I'd really appreciate a torrent of it, otherwise if I ever get mine working I'll put a torrent up. _________________ Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
Posted: Mon Feb 07, 2011 6:52 Post subject: Re: Awesome!!! thank you.
tangsoft wrote:
hope this patch would be built into next release version of firmware.
if it does trick on 5325 that is perfect.
Check next Tomato release, it wouldn't surprise me if they pick up this patch and includes it in their next release.
Both dd-wrt and OpenWRT has stopped Broadcom development so there isn't much chance of it appearing here or there. _________________ Kernel panic: Aiee, killing interrupt handler!
Posted: Mon Feb 07, 2011 7:07 Post subject: Re: Awesome!!! thank you.
LOM wrote:
tangsoft wrote:
hope this patch would be built into next release version of firmware.
if it does trick on 5325 that is perfect.
Check next Tomato release, it wouldn't surprise me if they pick up this patch and includes it in their next release.
Both dd-wrt and OpenWRT has stopped Broadcom development so there isn't much chance of it appearing here or there.
hmmm, now time here FTTH is getting more and more popular, and home WIFI router(or residential gateway) has to accommodate more services like IPTV/VoIP other than just Internet access. To put all these functions support into a single box, VLAN support is the key point, especially full 802.1q vlan feature. Maybe it is time to carry up your suspended plan and move faster.
I would be a volunteer for testing.
Posted: Mon Feb 07, 2011 8:02 Post subject: Re: Awesome!!! thank you.
phuzi0n wrote:
That's not really a fair statement. Both approaches need a GUI update for the GUI to be able to configure things and both approaches allow the user to configure nvram variables if the GUI isn't updated.
Sorry, I didn't want to sound derisive or anything. You're correct, to fully make use of the feature, the GUI has to be adapted no matter how the kernel side will look like - and in that case, your approach might be less complex.
phuzi0n wrote:
I'm going to try some more to get a build environment working so that I can help out with this because I really want better VLAN support (...) otherwise if I ever get mine working I'll put a torrent up.
My build environment is a big FAIL - things get compiled and put into an image, but the resulting kernel always panics, no matter which cross-gcc etc. I use. I feel I'm just missing a tiny bit here - so if you can get your VM running, I would very much appreciate the torrent.
Posted: Mon Feb 07, 2011 8:04 Post subject: Re: WRT54
nicmic wrote:
That patch would also work on a Linksys WTR54 right? That would be really awesome, this feature is really eagerly awaited!
It really depends on the switch chip used in the device. I know it works for the 53115, and there is a good chance that it will work for other bcmrobo chips - but we'll need to test (and if it doesn't work, you better have a serial cable around).
I don't know if it helps but I've compiled some builds a while ago and I've used Makefile.brcm26.
I also need this patch for my RT-N16 to get rid off Vodafone's router, which is Crapsom (Thomson actually). Seems that Vodafone uses vlan in 110-115 range.
I don't know if it helps but I've compiled some builds a while ago and I've used Makefile.brcm26.
Is this still working for you (and for E3000)? This would be good to know (because then I know it's something in *my* setup and not something in the DD-WRT source tree). I've used Makefile.brcm26 as well.
fggs wrote:
I also need this patch for my RT-N16 to get rid off Vodafone's router, which is Crapsom (Thomson actually). Seems that Vodafone uses vlan in 110-115 range.
Posted: Tue Feb 08, 2011 0:15 Post subject: the dd-wrt way of doing things
Mmmh. What we have now is nice theory, but I think it won't actually work in dd-wrt, because it wants to configure the robo switch at runtime.
As far as I understand, the call sequence goes something like this:
services/networking/interface.c:
- read "vlan<num>ports" from nvram
- poke ports to /proc/switch/eth0/vlan/<num>/ports
goes from there to kernel "switch_core" module, and from there to handle_vlan_port_write() in "switch_robo" module.
switch_robo is limited to 16 vlans, but only because it tells switch_core so (driver.vlan structure), and "interface.c" has a "for( i=0; i<16; i++)" bit in there...
So if someone can cofirm that indeed this is the path that is used for run-time configuration of vlans, it might be even easier to adapt (just rebuild the modules)...
What confuses me a bit is that there is other code that does, well, "other things", like rc/vlan.c that calls "vconfig" to setup VLANs - and I don't really understand which part is being used (either? both? none) and under which conditions.
Yes switch_core and switch_robo handle the live reconfiguration of VLAN's for Broadcom switches if the VLAN boardflag is enabled but if these modules aren't loaded then the switch driver just loads the VLAN configuration on its own. If the VLAN boardflag is disabled then the kernel's VLAN tagging support (vconfig/VLAN tagging on the networking page) can be used for the entire switch but ports can't be separated into specific VLAN's. All the other platforms (Atheros, Ralink, etc.) only support the kernel's VLAN tagging currently.
BCM4704 CPU's + BCM5325F switches are an even odder case because it has two MII's (internal connections), one for the WAN port and one for the LAN ports, so the Broadcom specific stuff still applies to the LAN ports, but the WAN port has to use the kernel's VLAN tagging support no matter how the boardflag is configured. _________________ Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
OK, patching switch-bcmrobo.c works, and I can get my vlans 920+930+940 that way - but it's somewhat ugly (/proc/switch/eth0/vlan is prepopulated with 1024 subdirectories now), and of course I'd need to recomple the run-time environment to make it "compatible".