I did release a patch to do most of this a while ago. It was for the 2.4 kernel series, but could be updated for 2.6 without too much trouble I'm sure. Search the list archives about a couple of years ago. Simon Sent from my iPhone On Jan 12, 2009, at 4:41 AM, "Lv Zheng" <lv.zheng@xxxxxxxxxxxxxx> wrote: >> I was talking about regular data packets. Usually, when refering to >> "port based" VLAN, we mean that the host (or the hosts) connected to >> that port has no knowledge whatsoever of what a VLAN is. >> >> If (and only if) this is what you want, then br0 should be directly >> connected to the physical port (bond or eth), and not on top of a >> vlan >> layer which will filter out untagged incoming packets, and tag >> outgoing >> packets. > > Greetings. > > 802.1Q defines that each bridge port > > shall support following parameters: > 1. acceptable frame types, one of the following: > A. admit only VLAN tagged frames > B. admit only untagged and priority-tagged frames > C. admit all frames (default) > 2. a PVID for port based VLAN classification > may support following parameters: > 3. a VID set for port and protocol based classification > > For port based VLAN, a netdevice might still be > VLAN-aware and at least 1 & 2 should be configurable > for the netdevice (known as EISS support). > > I noticed following differences are exist between > 802.1Q compatible switch chip's MAC port devices > and a normal NIC devices: > > Switch port do support 802.1Q parameters will > 1. drop untagged frames if it is configured to admit > only VLAN tagged frames and drop frames not > admitted > 2. drop any tagged frames whose tag is not in the > VID set if it is configured to admit only VLAN > tagged frames and drop frames not admitted > 3. handle any untagged frames as PVID tagged frames > if it is configured to admit untagged and > priority-tagged frames and handle such frames as > if they are coming from the default vlan > 4. handle any tagged frames whose tag is not in the > VID set as PVID tagged frames if it is configured > to admit untagged and priority-tagged frames and > handle such frames as if they are coming from the > default vlan > > While Linux does not support such features. > > Should following attributes be added to netdevice > to support port based VLAN? > 1. pvid > 2. admit_frame_types > VLAN ioctl command may be added for all > netdevice (like ADD_VLAN_CMD) to > manipulate above 2 vlan specific parameters: > SET_PVID_CMD > SET_FRAME_TYPES_CMD > SET_FRAME_ACTIONS_CMD > Addtional hooks might also be added to > netdevice: > vlan_set_pvid > vlan_set_admit_frames (types & actions) > if frames is not admitted, actions might be configured > to allow: > 2.1 DROP: drop the frame > 2.2 DEF_VLAN: handle the frame as if it is pvid tagged > 3. vlan_nr_groups: > set by NIC driver, its default value might be a Kconfig > option such as CONFIG_VLAN_8021Q_GROUPS > 4. vlan_gid_map > GID enabling bits, might be BITMAP(vlan_nr_groups) > 5. vlan_groups > VID <-> GID mappings, might be u16[vlan_nr_groups] > register_vlan_device / unregister_vlan_device > might maintain this map and gid array > > If hardware do support 802.1Q parameters, it might > report vlan_nr_groups on registration. > Hardware vlan_gid_map and vlan_groups might be > synchronized by supporting > vlan_rx_add_vid / vlan_rx_kill_vid. > Hardware PVID and admit_frame_types might be > synchronized by supporting > vlan_set_pvid / vlan_set_admit_frames. > > If PVID in netdevice was implemented, there might be > tow options we could choose: > 1. ensure there is always a ethx.pvid device exist > might be suitable for tag based switch applications > 2. ensure there is always not a ethx.pvid device exist > might be suitable for port based switch applications > > vlan_skb_recv might be modified to support EISS features > because this function will handle all VLAN-tagged frames > > netif_recv_skb might be modified to support EISS features > because this function will handle all VLAN-untagged frames > > dev_hard_start_xmit might be modified to support EISS > feauturs to do tagging on outgoing packets before hard_xmit > if pvid is set and no ethx.pvid device exists. > > If I were wrong, pls let me know. Thanks in advance. > > Best regards/Lv Zheng > _______________________________________________ > Bridge mailing list > Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/bridge _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
