>> 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?
It works as I described on the M chip. It was suggested (by Jonas I believe) that the FC might not have the possibility to use both untagged and tagged membership on the same port. With regard to the filtering capabilities, no idea. I plan to implement identification of M and FC chips and having the driver behave differently for the chips. I suggest I initially submit a driver for inclusion in OpenWRT that only works for the M chip. I feel I have sufficiently tested that target that it ought to work for people with an M chip. It is unfortunate that nobody else appears to have it :). And then, I could have the driver support the FC chip in a manner where a port is either member of one or more tagged VLANs or member of exactly one untagged VLAN, since that is a configuration that appears to work for you, with your patch. You could then test that driver. I don't really feel comfortable submitting a driver for inclusion in OpenWRT for a device I do not have myself, but obviously you or someone else is free to submit that version. It's GPL after all :). Apparently there are a lot more people with FC chips. Having this functionality I intend to implement is already a great start, I suppose. Perhaps the FC can be coaxed to do more stuff as well. If somebody has better ideas on how to handle this properly and to everybody's satisfaction, feel free to offer a suggestion. Peter. PS: Not sure on how long it will take me to produce the two versions of the driver. We'll just have to see when it's ready. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
