> > But it is a curious setup. Did you do it just to test the functionality? >
Yes, mainly for testing purpose. > > Good to hear a more usual setup does work. I assume this is with the patch > you > sent earlier? Yes, using the patch I posted before. > In that case the common case where a port has both untagged and > tagged memberships fails, right? > Yes, port untagged and tagged membership fails. > > Watch out for the primary VLAN ID; "pvid" property of the port. "swconfig > dev > eth1 show" is your friend. The PVID might not always be what you expect. > Seeing > where untagged packets go is something that needs to be tested for the FC > chip. > The M chip is configured such that untagged packets coming in on a port are > only > accepted if the port is a member of its PVID, and sent out to other members > of > that VLAN. If a port is not a member of the VLAN that is in its PVID, the > packets are dropped (i.e., source port filtering, both for tagged and > untagged > packets). Note that it doesn't matter if a port is a tagged or untagged > member > of a VLAN, just if it is a member at all. > > Is this mechanism worked for M chip? Anyone can confirm whether FC chip has such capabilities?
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
