It does to the extent of tagged state being tied with setting the VID. But it does not for untagged state with a VID.
Looking the script
*t) append new_ifname "lan${port%t}.${vid}" ;;
appends the VID and thereby setting the tagged state.
*) append new_ifname "lan${port}" ;;
tough removes the VID and thus there is no VLAN iface.
I thought the solution there is to simply bridge the relevant lanN.N members with a lanN member?
default VID for lanN is 1. What if you want to change that, to say to lanN.6, with an untagged state though?
Without appending the VID to lanN its member is not participating in the vlan protocol 802.1Q.
noted some hickups with the timestamp in syslog…any ideas to fix that?
Jun 26 12:26:46 turris kernel:
Jun 26 10:26:46 turris netifd:
Jun 26 10:26:46 turris netifd:
Jun 26 10:26:46 turris netifd:
Jun 26 10:26:46 turris netifd:
Jun 26 10:26:46 turris netifd:
Jun 26 10:26:46 turris netifd:
Jun 26 10:26:47 turris adblock-nce started :
Jun 26 12:26:47 turris kernel:
Jun 26 10:26:47 turris netifd:
Jun 26 10:26:47 turris netifd:
Jun 26 10:26:47 turris netifd:
Jun 26 10:26:47 turris netifd:
Jun 26 10:26:47 turris netifd:
Jun 26 10:26:47 turris netifd:
Jun 26 10:26:48 turris firewall:
Jun 26 10:26:51 turris firewall:
Jun 26 10:26:54 turris ddns-scripts[1596]:
Jun 26 10:26:55 turris ddns-scripts[1596]:
Jun 26 10:26:55 turris ddns-scripts[1596]:
Jun 26 10:27:01 turris /usr/sbin/cron[2767]:
Jun 26 10:27:07 turris kresd[1534]:
Jun 26 10:27:07 turris kresd[1534]:
Jun 26 10:28:01 turris /usr/sbin/cron[2921]:
Jun 26 10:29:01 turris /usr/sbin/cron[3033]:
Jun 26 10:30:01 turris /usr/sbin/cron[3150]:
Jun 26 10:30:01 turris /usr/sbin/cron[3149]:
Jun 26 10:30:01 turris /usr/sbin/cron[3151]:
Jun 26 12:30:43 turris dnsmasq-dhcp[32222]:
Jun 26 12:30:43 turris dnsmasq-dhcp[32222]:
Jun 26 10:31:01 turris /usr/sbin/cron[3293]:
But did you test that? My point is with DSA re-using the “normal” tools for switch configuration bridging an untagged interface, say LAN1 with say LAN4.4 could be one way to express untagged LAN1, but I have not tested that myself (I keep my home-network as simple as possible, which means I use VLAN tags rarely, and on my “toy” omnia I have not had use for any LAN VLAN tagging at all yet, so I really am guessing here; feel free to not take this too seriously).
vlan protocol 802.1Q id is absent from any iface that is lacking the appended VID, which would seem logical.
no trouble with some brainstorming, just some users may depend their network layout on the feature to work
there is
but not sure whether that covers your case.
Unless explained of how to enable it with the logic that
it would appear that the untag state is a feature lost.
It is not. Ok please let me restate it.
What DSA does is that ports going out of switch are managed the same way in system as PHY directly connected to CPU. That means that VID and packet delivery works the same way as on any other Linux box. There is plenty of tutorial and explanation on how network works on Linux and how to configure it. You don’t have to look for DSA it self. If you know how to configure network on Linux you know how to use DSA in general.
Not sure why this now being referred to the management of the network stack in some other Linux systems when the matter at hand being DSA on TOS?
Could you be so kind to simply explain your laymen user base, that was able to get VID with untag state when managed by swconfig, of how to achieve a VID other than the default 1 with untag state now that it is DSA?
http://www.microhowto.info/tutorials/802.1q.html
Avoiding use of the default VLAN
It is considered good practice to move traffic off the default VLAN where possible, in order to minimise the extent to which an unconfigured switch port would give access to the network.
This does not mean that a network which uses the default VLAN is necessarily insecure, and vacating it may not be feasible since some devices have functions that are hardwired to a VID of 1. However, if you have the opportunity to use a different VLAN then that is usually preferable.
TOS is based on Linux so Linux system management is skill you need. I don’t see why Linux management should be other matter all together in TOS management.
Please read up on Linux vlans. Those have to be enabled. You are reading snippets and concluding without really reading clearly. I am not here to teach you how networking works. I am telling you that it works the same way as if you would have plain old phy. I don’t see what that makes it unclear.
lan0 is untagged interface. There is no implicit VID on untagged interface. That simply does not make sense. The comment you posted is that if you enable 802.1q on interface and you do not specify VID then it uses 1. Yes but in that case you would see that it is VID 1. That is just implicit VID value. lan0 is not 802.1q. It is untagged base interface so not VID. Is that clear?
Nobody asked for it, simply the matter of untag state with a specific VID. I do not see what is so complicated about it?
That is whole point - VLAN is not enabled at all with the VID omitted. It is either:
but lacking (lost feature)
Yes it is clear, like you say it is not 802.1q. But if a user wants it to be 802.1q and appends the VID - it then automatically invokes the tag state - which not always wanted but instead the untag state is sought after?
It seems you are missing the point - maybe an example helps
config switch_vlan
option device 'switch0'
option vlan '3'
option ports '5t 2'
option vid '3'
VLAN enabled, VID 3 with port 2 in untag state. The transition script
*) append new_ifname “lan${port}” ;;
will disable VLAN (802.1q) when it omits the VID.
Anyway, if you do not see this being an issue then perhaps it is better to cease further discussion on the subject here in the beta thread and wait until TOS4.x hits release and see what happens to use cases like in the above sample.
My understanding was that 5t means it is tagged…
Yes, that is correct and fine since not required with DSA as explained by @cynerd
and thus not the point.
The point is port 2 in untag state with VLAN enabled
Maybe you can share your use case, because I do no see why lan1 will not work for you.
hmm, this not clear from the previous thread entries?
If you got
you might like to share your use case with the community? For my part I would be humbled and grateful to learn how it works.
Not to me. I was hoping to see a higher level use case description.
If that is still not clear.
compared to the other option
Missing is a way to have
I understand this, but this is more like low level functionality that I want/need. What I think is still missing in this thread is because I need it to solve this particular high level problem.
That is your perspective of how to weigh it plus also questioning of why the user wants that functionality in the first place, which I am not going to argue since VLAN enabled with untag state is quite a common deployment scenario as opposed to being termed a particular high level problem.
The point is that is has been available with swconfig and there are plenty of TO users deploying it, e.g. this one DHCP on VLAN suddenly stopped working after energy loss (?) on 2 Omnias