GL.iNet UI shows no clients connected due to use of VLANs

Routers
1

Hi there!

Essentially, the title says it all. But here's a bit more detail. :slightly_smiling_face:

Let me start by first saying as I've explored the GL.iNet product line, I'm routinely very pleased. My experience with GL.iNet has easily been my most pleasant home router experience. And your dedication to excellence and to your customers shows. So, all that to say, you have a new fan in me, and I've already left reviews stating such and started recommending you all via word of mouth. That said, I really think the issue I describe here should be fixed, and I don't imagine it'd be a difficult fix.

I completely understand that GL.iNet's UI does not directly support configuring VLANs. That's totally understandable given the complexities involved (though it'd be a really nice feature to see in a future release).

However, I've configured VLANs (and additional firewall rules) via LuCI. Those all work perfectly and all client devices connected to the VLANs are also working perfectly. But then, to my disappointment, the main GL.iNet UI now suggests there are no devices connected to the router. This is, of course, not true, as all client devices are connected to the router.

Can GL.iNet commit to fixing this UI bug soon? I am direct here in my choice to call it a bug, because, as mentioned above, I understand GL.iNet may not support configuring VLANs via the GL.iNet UI, but the GL.iNet UI should still correctly represent whether clients are connected to the router; in other words, the GL.iNet UI should not be rendered a low-fidelity (or, more directly, a no-fidelity) representation of client connections when users configure VLANs. I don't imagine this would be a difficult fix to implement. I realize I can see connections via LuCI, but that's not my point. Moreover, because the GL.iNet UI now incorrectly states no devices are connected, this impacts other, downstream functionality of the GL.iNet UI that is afforded by GL.iNet's UI "recognizing" or "acknowledging" connected client devices (e.g., seeing real-time stats, limiting speed, etc.).

Thanks for everything you all do, and again, thanks for your commitment to excellence (it shows!).

1 Like
2

Isn't the point of a vlan to make an invisible lan?

Making the gui part of a vlan might render it useless.

What I think you are asking is you want vlan gui added.

Kind of beyond typical home users. ??

I used to play with Cisco routers and I hated it when a site had 50 vlans and some with 2 members. Always seemed useless traffic speed wise. They claimed security but not sure that is true.

3

I don't think that's right. Getting a bit more technical, we're talking about Layer 2 (for the VLANs) vs. Layer 3 (for the router) of the OSI model. Of course, inter-VLAN routing is handled at Layer 3 via a router or Layer 3-capable switch, but that makes complete sense given you're talking about inter-VLAN routing. To put it more simply, though, VLANs segment a given network into separate, virtual networks (and, yes, prevent one network from "seeing" or interacting with the other without explicit permission to do so). But the router should absolutely still be aware of and faithfully report all network activity, including clients connected to it and the traffic it's processing. And that's what I'm saying is lacking in the GL.iNet UI. Right now, the GL.iNet UI is telling me the router has zero connected clients, which is flat out wrong. The existence of VLANs or an entirely flat network shouldn't factor into the fidelity of the router's reporting of client connections. And as a case-in-point, LuCI dutifully reports all client connections in one UI, irrespective of the VLAN to which the client is connected. Adding UI support for this on the GL.iNet side of things would (or should) have no bearing on the utility of VLANs.

I don't think this is beyond typical home users. Perhaps that's a matter of / difference of opinion, and that's totally fine. But running VLANs seems very much within typical home use. It's an extremely common way of setting up guest networks or segmenting IOT devices, for example.

50 VLANs is ... aggressive. I agree with you there for sure. :slight_smile:

1 Like
4

I guess the issue is more a end use. Since you were able to create vlans and assign clients to them in Luci it shows it can be done.

Guess looking to the CPU and ram use or other htop under vlan heavy use might be interesting versus subnet.

50 vlans in industrial facilities isn't a lot. Half of the sites were segmented aggressively and others simple subnet.

5

Yes, exactly. And my ask is simple. I'm not asking GL.iNet to make configuration possible via their UI, but the UI should absolutely be a faithful representation of connected devices, traffic, etc. Right now, their UI suggests the router is a ghost town.

I have several VLANs running on a Flint, and it's doing just fine! There hasn't even been a noticeable change from when I did some initial tinkering with it in other aspects while leaving the network flat (and not even activating their guest network).

I meant 50 VLANs would be aggressive for implementation on GL.iNet routers, not at an enterprise level. Sorry, should've been clearer about that.

6

Your skills might make a good how to for others.

7

Thanks for the kind words. I like teaching and helping, and I'd thus typically be happy to consider doing a tutorial. However, OneMarcFifty (https://youtube.com/@onemarcfifty, https://www.onemarcfifty.com) already happens to have a nice tutorial on setting up VLANs in OpenWRT: https://youtu.be/qeuZqRqH-ug. The tutorial gives clear instructions, importantly differentiating different ways to establish VLANs, including use of bridge VLAN filtering with DSA (distributed switch architecture) introduced in OpenWRT 21. I'd first point folks in that direction before doing my own tutorial. Folks may have to generalize a bit or discern where things do or don't apply based on their own topology (e.g., using one or more GL.iNet product(s) for the entire network vs. using a GL.iNet product just for the routing capabilities with the network topology also including, say, a managed switch and access points from another vendor for WiFi), but the above tutorial really hits the key points (and also points people toward related resources where relevant, such as configuring firewall rules).

I hope this helps!

1 Like
8

Thank you for the update. Good info.

9

In the front-end code of GL Web UI, the interface list is hard-coded: by default, only the two bridges br-lan and br-guest will be pulled from the client list. Even if you create VLAN interfaces such as br-lan.40 and br-lan.50 in LuCI (OpenWrt's advanced interface), the Web UI will not recognize them as "LAN" and will not query the DHCP or ARP tables on these interfaces to list clients.

The UBUS interfaces called by the Web UI (such as network.deviceStatus and dhcp.fileHosts) will only return data related to br-lan and br-guest in the current GL firmware, and VLAN interfaces are not included.

You can install third-party plug-ins to view client information on Luci.

luci-app-nlbwmon: A traffic monitoring plug-in that lists all DHCP clients of all interfaces in the "Client" list and can be viewed by interface group.

luci-app-statistics: Combined with collectd, it can generate real-time traffic charts for each interface, and can also help you identify which MACs are communicating on the VLAN interface.

10

Slightly OT, but its not just VLANS per se. I don't run VLANS on the router, but I do have different subnets ascribed by DHCP on different interfaces. Any device on a subnet other than the default router subnet does not show as connected in the GL UI. It's in the LUCI UI, but not GL. I suspect VLan and Subnet visibility are connected and fixed by the same approach!

11

Thanks for the reply, @Miles! I realize there may be no good solution for this right now, but it sure would be great if the interface component you describe could be improved from being hard-coded to something like a dynamic checklist. It could, by default, include GL.iNet's default interfaces, but I can see something like a drop-down menu or menu hidden behind a cogwheel that contains a checklist (or something similar) of interfaces configured in LuCI that the UI could then include. Something to consider. :slightly_smiling_face:

12

Yeah, I agree. There are (as you probably know) a fair number of differences between VLANs and subnets (starting with where they are defined and operate within the OSI model), but even with VLANs in LuCI/OpenWRT, you still need to create interfaces. And for what it's worth, GL.iNet's Guest network isn't a VLAN; they use an approach similar to what you describe.