ts: update docs as according to new architecture

README.md

@@ -69,48 +69,48 @@ interfaces provided by mapcontroller
 * Mapagent will create interfaces as necessary, adding them to both mapagent
 and wireless configuration files
 
-**Some notes concerning multiap configuration files.**   
-While preparing the */etc/config/wireless* configuration, please note that some options may be changed during autoconfiguration proces. 
+**Some notes concerning multiap configuration files.**
+While preparing the */etc/config/wireless* configuration, please note that some options may be changed during autoconfiguration proces.
 Such options are wps_pushbutton and hidden of wifi-iface section. Actions taken and final value of those options depends mainly on type
-of multi_ap interface (value of option multi_ap in current wifi-iface section).  
+of multi_ap interface (value of option multi_ap in current wifi-iface section).
 
-For backhaul interfaces where 
-```  
+For backhaul interfaces where
+```
 option multi_ap '1'
 ```
 following rules apply:
-* 'hidden' option when provided stays as it is,  
-* if 'hidden' option is not provided in that wifi-iface section, it is set to hidden=1 by adding  
+* 'hidden' option when provided stays as it is,
+* if 'hidden' option is not provided in that wifi-iface section, it is set to hidden=1 by adding
 ```
-option hidden '1'  
+option hidden '1'
 ```
-  
-For fronthaul and combined interfaces where  
+
+For fronthaul and combined interfaces where
 ```
 option multi_ap '2'
-or 
+or
 option multi_ap '3'
 ```
-following rules apply:  
+following rules apply:
 * 'wps_pushbutton' option when provided stays as it is,
-* if 'wps_pushbutton' option is not provided in that wifi-iface section, it is set to wps_pushbutton=1 by adding  
+* if 'wps_pushbutton' option is not provided in that wifi-iface section, it is set to wps_pushbutton=1 by adding
 ```
 option wps_pushbutton '1'
 ```
-  
-Additional rule apply when traffic separation is enabled in */etc/config/mapcontroller* by  
+
+Additional rule apply when traffic separation is enabled in */etc/config/mapcontroller* by
 ```
 option enable_ts '1'
 ```
-in controller section of that config.  
-  
+in controller section of that config.
+
 Additional rule concerns guest network which should be added in */etc/config/mapcontroller* file always after already existing networks.
-This rule is that guest network will always have wps_pushbutton disabled by  
+This rule is that guest network will always have wps_pushbutton disabled by
 ```
 option wps_pushbutton '0'
 ```
 always placed in that wifi-iface section.
-  
+
 ### Example Start Configurations
 
 A default configuration file may look as such:

docs/QUICK_START.md

@@ -559,8 +559,6 @@ To enable Guest WiFi and Easymesh Traffic Segregation, the option 'primary_vid'
 and 'enable_ts' must be set to a non-zero value in the map-controller config's
 global section.
 
-NOTE: Currently, only primary_vid = '1' is supported:
-
 ```
 config controller 'controller'
 	option enabled '1'

docs/README-Traffic_Separation.md

@@ -20,7 +20,7 @@ comes from the map-controller.
 To enable traffic separation there are two requirements for map-controller to
 pass the necessary Traffic Separation and Default 802.1Q Settings TLVs:
 * Traffic separation must be enabled via configuration (option enable_ts)
-* Primary VID must be set to a non-zero value (Today only '1' is supported)
+* Primary VID must be set to a non-zero value
 
 ```
 config controller 'controller'
@@ -94,6 +94,33 @@ reconfigure */etc/config/network* to enable VLAN filtering on *al_bridge*
 (default br-lan) and configure VLAN for Ethernet ports that were already bridged
 to *al_bridge*.
 
+
+### Leveraging 802.1Q Ethernet interfaces
+
+Due to technical limitations of bridge VLAN filtering, if a packet is ingressing
+to the bridge and has to access a layer 3 service running on the bridge, i.e.
+DHCP, the packet is untagged and then the outgoing packet is re-tagged with the
+set PVID value. Thus true separation cannot be achieved as we can only re-tag
+packets with one specific VID.
+
+To solve this problem 802.1Q Ethernet sub-interfaces, one for each supported
+guest VID. The primary vid is still untagged by the bridge and it accesses
+services running on the bridge and is re-tagged based on PVID, whereas all the
+guest traffic is untagged by the sub-interfaces, which in turn has services
+running on them. The sub-interface can then correctly re-tag the egress packet.
+
+The sub-interfaces require their own DHCP server, firewall rules and network
+configuration, which are setup accordingly by map-agent.
+
+### Default Firewall Rules
+
+The default firewall rules added will:
+* Forward guest zone traffic to wan zone
+* Reject INPUT and FORWARD traffic
+* Whitelist DHCP, DNS and ping betweens guest client and guest bridge sub-interface
+
+### Bridge Vlan Usage
+
 Individual VLAN IDs for ports are configured using *bridge-vlan* network config
 entries. A bridge-vlan section allows a configuration of how a VLAN ID should
 be appended or untagged at the bridge and each specified port.
@@ -153,7 +180,7 @@ an example output can look like:
 
 ```
 root@iopsys-021000000001:~# bridge vlan
-port              vlan-id  
+port              vlan-id
 eth1              1 PVID Egress Untagged
                   20
                   50
@@ -169,14 +196,12 @@ eth4              1 PVID Egress Untagged
 wl0               1 PVID Egress Untagged
 wl1               1 PVID Egress Untagged
 br-lan            1 PVID Egress Untagged
-                  20 Egress Untagged
-                  50 Egress Untagged
+                  20
+                  50
 wl1.1             1 PVID Egress Untagged
 wl0.1             1 PVID Egress Untagged
-wl0.2             1 Egress Untagged
-                  50 PVID Egress Untagged
-wl1.2             1 Egress Untagged
-                  20 PVID Egress Untagged
+wl0.2             50 PVID Egress Untagged
+wl1.2             20 PVID Egress Untagged
 ```
 
 PVID Egress Untagged entries will add/remove VLAN ID tag on for
@@ -188,7 +213,8 @@ tags are dropped. In example above *eth2* will:
 * Remove tags for outgoing frames
 
 For wireless port *wl0.2*:
-* Transfer untagged traffic to vid 50.
+* Tag ingress traffic with vid 50
+* Pass and untag egress traffic with vid 50
 
 
 ## Wi-Fi Guest-to-Guest Isolation
@@ -223,33 +249,84 @@ config agent 'agent'
 
 When traffic separation is enabled as provided by **Default 802.1Q Settings TLV**
 and **Traffic Separation Policy TLV** and the option `guest_isolation` is set
-map-agent will create ebtables rules as follows:
+map-agent will create ebtables for traffic:
 
+* Traffic that ingress over an ethernet interface and egress via a guest AP
+	* This rule will *NOT* be applied for an ethernet backhaul interface
+* Traffic that ingress over a guest AP interface and egress via an ethernet interface
+	* This rule will *NOT* be applied for an ethernet backhaul interface
+* Traffic that ingress via guest AP and egress via a 4 address mode link
+* Traffic that ingress via an 4 address mode link and egress via a guest AP
+* Traffic that ingress via a guest AP and egress to another guest AP with the same VID on a different band
+
+This prevents any traffic from flowing over the guest network between
+clients connected at different nodes, radios irrespective of backhaul type.
+
+Example rules generated:
 ```
-root@iopsys-44d43771b730:~# ebtables -L
+root@smarthub3-001020304001:~# ebtables -L
 Bridge table: filter
 
+
+
 Bridge chain: INPUT, entries: 0, policy: ACCEPT
 
-Bridge chain: FORWARD, entries: 4, policy: ACCEPT
--p 802_1Q -i wl0.2 -o wds+ --vlan-id ! 1 -j DROP
--p 802_1Q -i wds+ -o wl0.2 --vlan-id ! 1 -j DROP
--p 802_1Q -i wl1.2 -o wds+ --vlan-id ! 1 -j DROP
--p 802_1Q -i wds+ -o wl1.2 --vlan-id ! 1 -j DROP
+
+
+Bridge chain: FORWARD, entries: 44, policy: ACCEPT
+-i wl0.2 -o wl1.2 -j DROP
+-i wl0.2 -o eth1 -j DROP
+-i eth1 -o wl0.2 -j DROP
+-i wl0.2 -o eth2 -j DROP
+-i eth2 -o wl0.2 -j DROP
+-i wl0.2 -o eth3 -j DROP
+-i eth3 -o wl0.2 -j DROP
+-i wl0.2 -o eth4 -j DROP
+-i eth4 -o wl0.2 -j DROP
+-i wl0.2 -o wds+ -j DROP
+-i wds+ -o wl0.2 -j DROP
+-i wl1.2 -o wl0.2 -j DROP
+-i wl1.2 -o eth1 -j DROP
+-i eth1 -o wl1.2 -j DROP
+-i wl1.2 -o eth2 -j DROP
+-i eth2 -o wl1.2 -j DROP
+-i wl1.2 -o eth3 -j DROP
+-i eth3 -o wl1.2 -j DROP
+-i wl1.2 -o eth4 -j DROP
+-i eth4 -o wl1.2 -j DROP
+-i wl1.2 -o wds+ -j DROP
+-i wds+ -o wl1.2 -j DROP
+-i wl0.3 -o wl1.3 -j DROP
+-i wl0.3 -o eth1 -j DROP
+-i eth1 -o wl0.3 -j DROP
+-i wl0.3 -o eth2 -j DROP
+-i eth2 -o wl0.3 -j DROP
+-i wl0.3 -o eth3 -j DROP
+-i eth3 -o wl0.3 -j DROP
+-i wl0.3 -o eth4 -j DROP
+-i eth4 -o wl0.3 -j DROP
+-i wl0.3 -o wds+ -j DROP
+-i wds+ -o wl0.3 -j DROP
+-i wl1.3 -o wl0.3 -j DROP
+-i wl1.3 -o eth1 -j DROP
+-i eth1 -o wl1.3 -j DROP
+-i wl1.3 -o eth2 -j DROP
+-i eth2 -o wl1.3 -j DROP
+-i wl1.3 -o eth3 -j DROP
+-i eth3 -o wl1.3 -j DROP
+-i wl1.3 -o eth4 -j DROP
+-i eth4 -o wl1.3 -j DROP
+-i wl1.3 -o wds+ -j DROP
+-i wds+ -o wl1.3 -j DROP
+
+
 
 Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
+root@smarthub3-001020304001:~#
 ```
 
-These rules are applied for any fronthaul interface with a guest VLAN ID. The
-ebtable rules will drop any traffic with a VLAN ID tag that differs from the
-primary that is egressing over a 4address mode link. And vice versa, any traffic
-with a VLAN ID tag that differs from the primary ingressing over a 4address mode
-link and egressing over a fronthaul interface with a guest VLAN ID will be
-dropped. This prevents any traffic from flowing over the guest network between
-clients connected at different nodes.
-
 To prevent intra-BSS traffic, hostapd `isolate` option is set over the
-guest fronthaul interfaces to prevent client to client traffic.
+guest fronthaul interfaces to prevent client to client traffic within a radio.
 
 ```
 config wifi-iface 'wl1_2_ap'

docs/layer3_ts.md

@@ -2,16 +2,20 @@
 
 The EasyMesh R2 specification only specifies behavior for layer 2 traffic
 separation, which IOPSYS Multi-AP components support and will automatically
-setup necessary configuration for when it is enabled.
+setup necessary configuration for when it is enabled. This includes separate
+subnets and network zones but not adding interfaces to a guest bridge.
 
-However, using the same solution layer 3 traffic separation is supported but
+Using the existing solution layer 3 traffic separation is supported but
 must be configured manually. This primarily refers to the creation of **bridge-vlan** sections,
 which dictates bridge and Ethernet port tagging rules. If a Traffic Separation
 TLV is received for which the necessary **bridge-vlan** sections are already
 present, map-agent will not setup any additional configuration or modify the
 existing rules. Map-agent will still be responsible for setting up tagging
 rules on the wireless interfaces as dictated by the EasyMesh specification and
-passed map-controller configuration.
+passed map-controller configuration. However, any custom rules that are made
+must be made with a different naming conventiton used by map-agent.
+
+**** Specificy all naming conventions as example of how not to name *****
 
 This leaves users with flexibility to setup layer 3 traffic separation
 or any other configuration as they require.