If you are using the cAP button on our products, please express your opinion about a proposed change.
current configuration: the ether1 is management port with dhcp-client and all wireless interfaces are in cap mode and placed in one bridge together with other ethernet ports if exist.
proposed change: put the management ether1 port also into the same bridge with wireless and rest of the ethernet interfaces and place the dhcp-client on the bridge interface.
Would you like the change or you want to leave is as is?
eth1: dhcp client, not part of any bridge
capsman discovery activated on eth1 (with info received from DHCP server), request-certificate: on
all other ethernet: disabled
basically CAPs don’t need a bridge if local breakout is not used.
mac-server/mac-winbox: disabled on all interfaces, explicitly enabled on eth1
disable services: telnet, ftp, www
The Current CAP config is only useful if you are using a tunnelled datapath, e.g. all SSID’s are tunnelled back to the CAPSMAN.
The Proposed CAP config allows for both “Local Breakout” as well as “Tunelled” datapaths.
I see no downside to the Proposed change. It is neither less secure, nor is it less performant.
It will allow cAP, wAP and wAP AC products to be deployed en-masse in either “Tunnelled” or “Local Breakout” without needing to login to every unit and change the bridge config.
i admit, local breakout is faster when it comes down to forwarding performance.
but the “new” setting is very similar to “defconf” to me. if i instruct the CPE using DHCP server to go for a CAPSMAN, i have the same functionality.
ether1 in BridgeLocal only (no WLAN - leave that for Capsman Datapath to sort)
Cap enable, Bridge=BridgeLocal, Discovery Interface=BridgeLocal
DHCP-Client on BridgeLocal
And my biggest wish - this be the Factory Default for all wAP and cAP products. Have E1 firewalled off by default is something that causes us so many calls from customers unfamilair with Mikrotik.
Points 1,2 and 3 are the Proposed config. The WLAN interfaces are only added by the datapath configuration on the CAPSMAN.
I also agree on your final point, this should be the defconf on all wAP and cAP products. These products are designed as “Controlled Access Points” not as “general purpose” routers, so out of the box from the factory they should start with the CAP config.
Sorry - I thought they were proposing including WLAN in the bridge ?
proposed change: put the management ether1 port also into the same bridge with wireless and rest of the ethernet interfaces and place the dhcp-client on the bridge interface.
Agree the rest of what I want is the same as the proposed change - just being thorough
Oh and one other change, enable cap for ALL Wlan interfaces - I think by default they only enable wlan1 ?
i am fine with the idea that the “AP-looking” devices shall have a different defconf as you guys already discussed:
no fw/nat active
single ethernet port is bridged together with wlan(s) acting as AP-bridge
maybe i’m the special snowflake with my concept that CAP’s wired link shall not be carrying unencapsulated user-plane traffic, but to be there for CAP-CAPSMAN communication only… however for me this is the real CAP setup.
I think it should switch to a configuration mode minimally required to get in contact with the cAPsMan and then retrieve
the desired configuration from that. Then each user can define the config they like.
I am lobbying for 2) Proposed change, and for the Proposed CAP config to become the default config for devices intended for use as “Controlled Access Points” e.g. cAP, wAP, wAP AC
This will vastly simplify mass deployment, making them “Plug and Play” out of the box.
