Using the same port numbers, tagged and untagged sounds like a bad idea.
Remove all gateways and DNS from the downstream interfaces.
Also remove backslash in the end of the network config.
That may be, no argument - but trying to understand. As uhttpd is listening on 0.0.0.0, is it really a concern? I would have thought this would be OK, but I may be wrong!
Sure, will remove DNS, NP! But why gateways? Again, just to understand.
That's not real, just confirmed. Fat-fingered that somehow when I pasted it. Sorry!
Will let you know when I remove the gateways and DNS. Appreciate it!
Removed gateways, and DNS - exactly the same. Dang it!
BTW, are gateways not needed, because LAN is automatically forwarded to WAN? Again, just to understand.
As above, DHCP works, as does ping, ssh. Just not LuCI. Weird.
Thanks!
FYI, a bit more info on this - went to another machine, set up the same VLAN (i.e. 250) => same thing ... DHCP works, ssh, just gets "stuck" with LuCI. Will keep digging!
Actually, bumped into one more oddity - ssh works great, but scp fails. Huh? LOL!
Thanks!
SLIGHT UPDATE (that may help?) - I decided to grab another router, give it a try. It works! Here is the difference,
a) Original Router, Linksys EA3500, Kirkwood. New DSA approach, right? Seems like VLAN is configured through "Bridge VLAN filtering" ... this seems to have issues?
b) New try, ASUS RT-ACRH13 (RT-AC58U), ipq40xx, older switch approach, correct? Here VLAN is set up in the Switch config (doesn't even exist on the EA3500), all working, no issues. OK, minor issue, uplink (WAN) is not getting an IP via DHCP, but I think I just have that messed up yet 
.
Thanks!
OK, close 
. On the second router (with "Switch"), I can get VLAN working ... ssh, DHCP, scp, LuCI. All good on the LAN side. And the switch setup is like this (seems standard from what I have found),
But (of course there's a but ) ... I can't get out on the WAN. Thinking the VLAN is somehow messing with it, but I just can't figure out why.
Thanks!
There are 2 recommended approaches:
- Use unique port numbers and do not share ports among VLANs.
- A specific port number can only be shared when all its entries are tagged.
Thanks! Sorry, a couple dumb questions - I may be getting confused by some of the terminology (and yes, it's on me 
). BTW, I had found this VLAN link ... similar, but still leaving me a bit perplexed.
I think you're meaning / saying that if a port is tagged or untagged (either one!) in one VLAN, make sure it's off in all the others. Do I have that right? I'm OK with that, just making sure.
OK, so not allowed is a port with tagged in one VLAN, untagged in another ... correct?
Where I am getting messed up I think - all the examples also show WAN => but this doesn't exist in my case. And I admit, I'm not 100% how the "CPU" plays into this.
Thanks again!
1 Like
BTW, here is my routing table => really not getting an IP on the WAN side 
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.250.0 * 255.255.255.0 U 0 0 0 br-lan
192.168.251.0 * 255.255.255.0 U 0 0 0 br-wlan
Thansk!
There are multiple threads on the forum about bugs of built-in switches.
Some models cannot assign ports to different VLANs, others glitch with specific VIDs.
So, with built-in switches, it is best to use only the approaches described above.
1 Like
Will do some more digging - and trying now the notes above. Thanks!
My struggle is that somewhere along the way I lose my uplink. Let me reset the router, walk through slowly to see where that is. Appreciate the pointers!
1 Like
Regarding the tagged and untagged networks...
The 802.1q spec allows you to use zero or one untagged and zero, one, or many tagged networks on any given port. You are allowed to use untagged + tagged on the same port. However, there are some who will recommend that a trunk port should never contain an untagged network. This is a matter of personal/professional opinion, and its s often based on the fact that an untagged network has some level of ambiguity (regarding the actual VLAN it belongs to) once it is downstream of the respective switch port, and can thus lead be prone to human error with the configuration of any downstream devices.
The other consideration is that if you have any non-VLAN aware devices (i.e. unmanaged switches, most end devices such as computers, STBs, etc.), you should only connect those to access ports (i.e. a port with an untagged network + zero tagged networks).
With respect to your specific issue, some lower end/older devices have switch chips that don't properly support the full 4095 VLAN IDs. For those, I think it is often limited to a range of 1-16. So try again with your VLAN IDs within that range.
I would recommend configuring an access port on your router for each of the VLANs so that you can literally just plug your computer into a port, test a specific VLAN, then move to the next port and test the next VLAN and so on. This helps troubleshoot the VLANs in the most straightforward way. Then, once all has been verified with the VLAN configuration in general, you can make a trunk port and then do the same on the managed switch on the other end -- thus verifying that the trunk is configured correctly as well as the managed switch.
1 Like
hi @arrmo
Actually, bumped into one more oddity - ssh works great, but scp fails. Huh? LOL!
did you ever try to determine MTU ?
here i mean, ping size 1490, 1496, 1500 byte ?
because if ping,ssh,dhcp work, and Luci won't ... maybe it is DSA/Vlan (4byte header) issue ?
Really appreciate the comments / thoughts - thanks! Like I mentioned above, I'm going to reset back to defaults, walk through the setup and try to see where things break
To try to clarify ... VLAN on the LAN side is working great (with the device not having DSA, if I understand the delta correctly). The issue is that I seem to lose WAN in the process somehow => that's my core / key issue (on the non-DSA router) ... no uplink anymore.
On the DSA router (again, if I have them right), that one I can't get to scp or LuCI, but ssh and DHCP work (over VLAN). Very odd. But getting back to that one, after figuring out why WAN is broken (above, non-DSA case).
Hopefully that's all clear. And again - thanks!
Start with the LAN from the default configuration -- verify that it works properly. Then create one new VLAN and configure it against another port on the built-in switch (as an access port). Keep it simple. If the LAN works but the second network doesn't, post your configuration details and we'll help figure out what might be wrong.
1 Like
That part it did - before at least ... LOL. That's why I plan to reset, start clean / fresh.
Sorry, just to understand ... do you mean, only add VLAN to a single port, don't mess with the others? And ... "access" port - you mean to check with the VLAN modified port, and one that is not part of the VLAN, correct?
Thanks!
An access port is a port that has only one network assigned -- untagged (no tagged networks).
What I am suggesting, in plain terms, is to start with the default configuration. In that setup, a device with 5 built-in ports would typically have a WAN and then 4 ports dedicated to the LAN. Test this first to make sure everything works as expected. Then, add another network/VLAN (call it LAN2), but assign it to say port 2 as untagged (and turn off VLAN 1 on port 2). Now you'd have port 1 = LAN, port 2 = LAN2. You can easily physically switch your computer's connection between ports 1 and 2 and see if the network functionality is operating as expected.
1 Like
Makes sense, will give it a try (once back home again, not good when work gets in the way of fun 
).
Thanks!
OK, to store / capture a baseline ... here is what I have currently, before reset. It's very odd. I like your idea of having an access port, so what I did ...
Port 4, connected directly to a PC NIC, no VLAN on.
Port 2, to managed switch, tagged traffic on VLAN 250. That switch is also connected to a PC NIC, with VLAN 250 enabled.
What seems right ... the PC NIC on VLAN 250, gets and IP, from the correct subnet (assigned to that VLAN). But what is odd,
- directly connected NIC gets and IP from my "other" DHCP server (on the network). Has to be untagged traffic, coming in on Port 4, back out on Port 2 (to the managed switch). I say that because,
- Really odd, and why I have no upstream (WAN) ... I see this in the kernel log. Huh?!?!
# dmesg | grep -i eth1
[ 24.831576] ess_edma c080000.edma eth1: Link is Down
[ 27.929472] ess_edma c080000.edma eth1: Link is Up - 1Gbps/Full - flow control off
It's not down! There is a connection there, even WAN LED on. Very odd. OK, time to factory reset
Take everything out of the equation except the WAN, the router in question, and one computer. Set the computer to get an address via DHCP on an untagged network (i.e. clear any tagged network settings on that computer).
Make sure that you can get connectivity after doing the reset to defaults. Then add in the 2nd network as I described (assign port 2 as an access port for the second network). Connect the PC to port 2 and see what happens.
Agreed! So, after a clean reset - all is OK and working. I can ping upstream, WAN IP looks right, as does the direct connection from my (untagged) PC NIC to Port 4 (getting 192.168.1.x from the router). VLAN (untouched) looks like this,
So then, I removed LAN1, untagged => off. Still all good.
Next up - add VLAN 250, all ports for that VLAN (CPU, LAN1-4 set to off) ... boom! I can no longer ping upstream. The routing table looks unchanged, but it's not working now. Delete that (unused) VLAN ... upstream ... ping is OK again.
But! Then I changed the VLAN ID ... upstream is OK, only as long as that second VLAN ID is 2 - no other value works. Hmm ... but then I can add more, if they are sequentially added => it's only happy if then I add 3, then 4. But then, if I go back and delete 3 ... leaving 1, 2, 4. It's OK. Sounds like a bug to me, no?
But that aside, if I now go back only keep 1 and 2. All off on VLAN 2, and upstream ping is OK. Like this,
But, as soon as I turn on (even untagged) LAN1 ... upstream ping is down (config like below). Set LAN1 back to off (VLAN 2), and upstream is OK. Seems like something is broken, no?
Thanks!