If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Not so pleased. I installed Wireshark and viewed the traffic on an "Apartment" port. It appears that when the destination of a packet coming from the router port is on a port whose PVID matches the router port's, the packet is sent out that port only. Otherwise, the packet is broadcast to all ports on the router port's primary VLAN. Thus my blinkenlights.

So my gut feeling was right then? You have one big VLAN with secondary VLANs in a primary VLAN causing blinkenlights?

Yes, it's technically a nightmare as it also is with PVLANs.

TP-Link should fix it and please: also fix the messy default VLAN 1 assignment for untagged packets or let the user choose a default VLAN ID for them at least.
I would be able to sell more TL-SG108Es and EAPs.

Yes, the SG108e's thread-bare implementation follows your deduction but only as an economy and not a necessity. If the SG108e were to consult its table for known MAC addresses in other PVIDs, it would cut down on broadcast traffic and blinkenlights (even if it only kept one MAC address per PVID, it would cut broadcast almost to a minimum in my network).

VLANs.that overlap, i.e. use the same transmission media, should cut down on traffic, too, just like VLANs that don't overlap. They have made this stuff so mysterious that even magicians are baffled.

I abandoned Default_VLAN (except that the management interface implicitly remains there). The problem is they shortchanged the implementation, maybe for cost, maybe for performance, or maybe for product differentiation.

Again, I think the firmware is open source. However, my next step is to try to convert my router to DD-WRT. I expect there will be some performance degradation as a result.

Which brings up a question: My (cheap) WGR614v8 supports port-based VLANs but I don't know if it supports 802.1Q based VLANs. I hope I can do a "trunk" on one router LAN port connected to the SG108e port configured to output 802.1Q VLAN tags (as you seem to have done?) Otherwise I may have to use two ports on both my router and switch. If I need another router port at some point (to add nodes) I don't suppose I'll need 802.1Q VLANs on the router; port-based VLANs should be sufficient (with some network jiggering).

No, speed test alone from within one of the VLANs did not light up all LED

This contradicts my observation and diagnosis. My theory is that the inbound traffic is broadcast because it's destination port is not known to be among the ports with the same PVID as the inbound port, thus the blinkenlights. Either there was something about your setup that didn't match mine or my theory needs tweaking.

Which brings up a question: My (cheap) WGR614v8 supports port-based VLANs but I don't know if it supports 802.1Q based VLANs. I hope I can do a "trunk" on one router LAN port connected to the SG108e port configured to output 802.1Q VLAN tags (as you seem to have done?)

The WGR614 should support 802.1Q VLANs under DD-WRT, although it's noted '?' in the table below.

But it seems it's really very old gear. It isn't listed anymore in Netgear's archive for old devices with DD-WRT support.

This contradicts my observation and diagnosis. My theory is that the inbound traffic is broadcast because it's destination port is not known to be among the ports with the same PVID as the inbound port, thus the blinkenlights. Either there was something about your setup that didn't match mine or my theory needs tweaking.

I did the speed tests with ports 7 of VLAN 3 (PVID=3) and had another device at port 2 of VLAN 2 (PVID=2). There were some regular broadcasts originating from my network on Port 1, but nothing unusual. Anyway, if you use a true trunk port and separate subnets, the problem should be gone.

OK. So I've been tearing my hair out over setting up a VLAN trunk on the WGR614v8 after flashing it with DD-WRT ( I need more steam than I built up.) I exhausted all hunches as to how to correct my configuration so I broke out Wireshark again, this time to examine the VLAN field in the tagged packets coming out of port 1 of the SG108e. Wireshark claims that the length field in the VLAN field is malformed because the packet is not as long as indicated. a), I wonder if theWGR614v8 is rejecting these packets for that reason, and b) why didn't this cause problems for you, R1D2?

a), I wonder if theWGR614v8 is rejecting these packets for that reason, and b) why didn't this cause problems for you, R1D2?

Regarding a): No idea. There are indeed devices with the BCM 5354 for which the driver in DD-WRT supports 802.1Q, such as the Asus WL520, so I see no reason that the BCM 5354 driver should not be able to support them also on other devices - except it has been explicitly disabled by the person doing the port. You have to ask in the DD-WRT forum.

As for b): The VLAN field is inserted in the data part of an Ethernet packet, there is no such thing as "VLAN length field". There are just 4 additional bytes in the data part of an Ethernet frame. Maybe, wireshark can't handle this and indicates an invalid Ethernet package because of the additional 4 bytes? See the screenshot from CocoaPacketAnalyzer below, it indicates VLAN ID correctly, there are absolutely no errors in TP-Link's implementation (VID was 2 coming from TL-SG108E in this quick test, laptop was connected to trunk port, data comes from an EAP120 on an untagged port with PVID=2, laptop also did send something on DefaultVLAN):

Setup of a VLAN trunk ports in OpenWRT (and hence also in DD-WRT) should be straight-forward. Following shows the default setup of the config file /etc/config/networks on a TL-WDR4300 running OpenWRT. This router has a built-in switch with five physical Ethernet ports. The port labelled "Internet" on the box is internally assigned port #1. The four LAN ports labelled "1" to "4" are internally assigned port #2 to #5. Port #0 is the CPU trunk, an internal (virtual) connection between the Ethernet chip and the CPU of the router.

By default, all ports #1 to #5 are access ports (1x for WAN, 4x for LAN). Internal CPU port #0 already has VLAN tagging turned on, so that the CPU is able to direct traffic from WAN and from LAN into the appropriate networks. Since both networks are on the same physical switch (eth0), even in default setup there must be VLAN tags enabled for the internal CPU connection (routers with two separate built-in switches for the WAN and LAN ports don't need this). The LAN interface of TL-WDR4300 is also bridged with a WiFi interface (not defined in network section except for the bridge option).

To create a VLAN, the VID is just appended to the name of the interface (eth0) separated by a dot. So we have the following default setup of TL-WDR4300 (note that each option line must be intended by starting with blanks or tabs, which are stripped away from the forum SW, so I have used ༺ here for a TAB ):

As you can see, internal port #0 is a member of both VLANs and it is a tagged port (the 't' or sometimes a '*' like in DD-WRT specifies tagged port).

Now we want to add another guest network with real (physical) tagged port to connect it with TL-SG108E and a second (untagged) port for local access to the guest network through the TL-WDR4300's switch. On the TL-WDR4300 we need to create a new network interface and a new VLAN:

That's it. Setup of DHCP and firewall rules for the guest network is left as an exercise for the reader. Every setting could be made through the web UI also and with this background it's very easy to do so using the web UI. Finally, a reboot might be required, if the Ethernet chip must be re-programmed for the VLANs by the driver at boot time. Then connect TL-SG108E's VLAN trunk port to port 1 (#2) of the TL-WDR4300 switch and enjoy LAN/guest network distribution to the TL-SG108E.

No magic here. If you can't get it going on your WGR614, do yourself a favor and replace the ancient Netgear router by a cheap, used one from the bay such as Netgear WNDR3700/3800 or TP-Link TL-WDR4300 or even an old, but legendary Linksys WRT54 - all of them and 7 other models I used in last years support 802.1Q VLAN tagging under OpenWRT. Of course, you could also choose a modern router supported by latest versions of OpenWRT, DD-WRT or Gargoyle.

Last edited by R1D2; 01-09-2017 at 02:13.
Reason: Oops, formatting destroyed after posting, I now changed font of comments

No blinkenlights! Thanks again, R1D2. I've got it working with DD-WRT - two trunked VLANs going to one port in the WGR614v8. I have yet to isolate the Apartment VLAN in the routing/firewall tables and will get my steam up again before I dig into that.

I wanted to understand what I was configuring in DD-WRT. Since there were so many and ambiguous options it took me a great while to find the simple configuration through the GUI. In addition, everyone prefers recipes rather than explanations - this is the standard and crappy way most infotech publications are written - so that it took sometime to realize that the Broadcom switch was probably handling the VLAN switching and the DD-WRT firmware the bridging. That helped me understand the GUI. OTOH, if I had started out with a simple configuration I might have progressed to my endpoint more smoothly.

I'm getting better than 45 Mbps download speed through my (cheap) WGR614v8. This setup will be more than adequate.

I have reported to TP-Link that they might have implemented the SG108e VLAN switching better. Too late for me to benefit and there'll probably be few attempting to do what I was anyway.

I've got it working with DD-WRT - two trunked VLANs going to one port in the WGR614v8. I have yet to isolate the Apartment VLAN in the routing/firewall tables and will get my steam up again before I dig into that.

Glad to hear that it worked out for you! Firewall settings are no big deal either. Just create a new zone for the guest network and set default policy to ACCEPT for input/output to the WGR614 itself (so devices in this network can communicate with the services of the router) and to REJECT for forwarding packets (to isolate the network from all others). Again, this can be done using the web UI, which then will set following config in /etc/config/firewall:

That's it! Additionally you could add rules to forward traffic from guest to LAN for specific services such as access to an internal web service running on some of your systems, printer sharing etc. See https://wiki.openwrt.org/doc/uci/firewall for an overview of possible settings.

In addition, everyone prefers recipes rather than explanations - this is the standard and crappy way most infotech publications are written -

Very true! I'm autodidact since I was a teenager, so I always wanted to understand things rather than only being able to follow recipes. Luckily UNIX, the predecessor of Linux, was very well structured and easy to understand at this time, while today's Linux is huge, but extremely powerful and flexible in every aspect. Welcome to a real operating system, which lets you do almost anything you want with your WGR614. So you managed the first step of the stage to a Linux Guru, whose most special skills is the knowledge of how many steps needs to be climbed to become one!

I have reported to TP-Link that they might have implemented the SG108e VLAN switching better. Too late for me to benefit and there'll probably be few attempting to do what I was anyway.

Yes, but on the other hand this has forced you to install Linux for yourself on your router instead of using a down-stripped Netgear Linux. Don't forget to have a look at the thousands of useful software packages you now can install on your router! Also, if you get used to the console (shell) interface of your router (via ssh or it's little OPEN/DD-WRT brother dropbear aka PuTTY on Windows), you could get things done in a fraction of time compared to the web UI - and also in comparison to Windows, haha.

Was a real pleasure for me to dig into these issues together with you, I learned something about VLANs on TL-SG108E, too.
Please mark this thread as 'solved', so others experiencing the same problem could benefit from it, too.

Port 1 is connected to my router which routes to my cable modem. Port 2 is connected to my server with torrent client on it. The rest of the "Home" ports, 3-6 are connected to various laptops and a wireless access point.