Well, you (and mkx) probably assume that I have a deep understanding of how this stuff works (rest assured I don't).
I am trying to understand from the base, and I need to do this step by step, building from the base up, a layer at the time.
So you both provided more complex setups than the reference, and the only way for me to - maybe - understand your configurations is to remove the added complexities, one by one, and at my own pace and with my own methods, until I have something EXACTLY comparable to the base example and from that re-add the complexities.
But even if right now your posts are going whoosh well over my head, I will get there, before or later, so, please do post your considerations.
You probably have a typo on the third line of the /interface wifi provisioning, should be "CAP_AC.*"
When it comes to Capsman I poked around after reading and watching different approaches and came up with working setup somehow. I wouldn’t dare sharing it to be laughed at.
What really helped me a lot is Claude LLM, in my opinion is it’s the most efficient approach to sort through mikrotik related pieces of information here and there
Corrected a few typos (for sure "-"<->"_", "lab"<->"lan", but possibly some more I don't recall) and missing items and re-organized variables and names of things in a "unified" way.
As-is the thingy only works if ALL the variables are defined, it completely misses the logic needed to:
have only one or two wifi SSID's (i.e. only MAIN or only MAIN and GUEST)
have NOT a vlan for mgmt
the bridge configuration on CAPSMAN uses this (still not understood by me) ether2-trunk interface
the logic for tagged and untagged ports in bridges is completely missing, values are at the moment "fixed" Capsman_work_in_progress01.zip (31.0 KB)
Also it has to be understood (by me) how in practice the MACs are to be generated/attributed.
What does "ALL the variables are defined " mean to you?
It is also possible to manage it by configuring its provisioning settings.
On the forum, you can always find info - the best to have for VLAN config - separate VLAN for management. It helps to catch issues, especially if you misconfigure VLANs and start troubleshooting. Also, security is a good idea.
And here is the "magic" point for WiFi configuration.
If you want to mix AC and AX configurations in your network, the problem is how to be sure you connect to the SSID <=> VLAN.
In the Mikrotik example configuration, you have only 2 SSIDs <=> 2 VLANs. By default, the ORDER of the master-configuration=MAIN and the slave-configurations=GUEST is the same, with action=create-dynamic-enabled.
Now, if you have 2 CAP AC devices + CAPsMAN, prepare the configuration according to Mikrotik's help for VLANs (forget about the AC), but create provisioning:
Check what happened when you connected to CAP1 and to CAP2. What VLANs do you get for your device?
You will be surprised. The next surprise will be when you add another SSID :).
By my tests and experiments, I have figured out that the critical case is to have
correct bindings between SSID <=> wifi_interface <=> VLAN_ID
provisioning order corresponding to the wifi_interface order to the above point.
If you have more than 2 SSIDs, you do not have control over the slave (virtual) interfaces bindings. Also, when action=create-dynamic-enabled on CAPsMAN, you will have a headache. Please test it :).
For the "mac-address=4A:xx:xx:xx:xx:13", if you tested the above ideas, you can see what is happening when the "wifi" in CAPsMAN is created dynamically when you are on the CAP switch, the
/interface wifi cap enable=...
many times, you understand the problem.
So, this is why I'm generating and hardcoding some info, for example:
4A:xx:zz:ww:yy:yy
where:zz -> CAP number (max 99)
yy:yy -> VLAN_ID (4 digits)
ww -> wifi interface number
It only depends on your invention. I simply used "coding" wifiNumber + VLAN_ID (last digit).
I found some 90 "tokens" (settings) in the configuration that are "variable" and that can be (and are in the sheet) derived (auto-calculated) from 18 "base" variables (or choices).
As is, to produce the originally posted configurations equivalent "all 18 of them" need to be defined, these include:
a VLAN and a SSID for "MAIN"
a VLAN and a SSID for "GUEST"
a VLAN and a SSID for "IOT"
a VLAN for "MGMT"
Since it is not (yet) illegal to have NOT VLANs and some people may want to (examples):
have just a "MAIN" SSID, NO VLANs
have "MAIN" and "GUEST" BUT NOT "IOT", NOR a "MGMT" VLAN
....
I.e. the ultimate goal (mine) is to have a basic configuration to which the users can optionally add VLANs and SSID's (slave radios) as they see fit.
You mean "the thing on the opposite side of the hood (bonnet)"?
"ether2-trunk" does not exist "in nature", so a line needs to be added to the configuration like:
/interface ethernet
set [ find default-name=ether2 ] name=ether2-trunk
then, EITHER the CapAX OR the CapAC can be connect to it, so you will need another interface, like:
/interface ethernet
set [ find default-name=ether3 ] name=ether3-trunk
and - as I see it - the choice of using ether2 and ether3 should be given to the user, on a RB5009 (say) I would use ether6 for the CapAC and ether7 for the CapAX.
Personally (but not necessarily I am right) re-naming interfaces is largely an exercise in futility, but I do understand why some people like that.
If we take (say) D0:EA:11 as base, we can still have three custom fields:
D0:EA:11:xx:yy:zz
where:
xx = CAP number (even if the field is hex, one could use pseudo-decimal and have 1-99)
yy = VLAN number (even if the field is hex, one could use pseudo-decimal and have 2[1]-99)
zz = wifi interface number (even if the field is hex, one could use pseudo-decimal and have 1-99)
They seem enough to me.
Using hex (at the cost of making it less readable) might be an alternative, but I don't think it is needed, unless it provides a way out in the (hopefully rare) case of a MAC conflict.
A way to have a "configuration builder/helper":
a. a CAPSMAN (without "its own" wifi radios)
OR:
b. a CAPSMAN (with "its own" wifi radios)
AND
c. any[1] number of CAPs (AC)
AND
d. any[1] number of CAPs (AX)
with the options to have ALL of these:
e. VLAN for MAIN
f. VLAN for GUEST
g.VLAN for IOT
h. VLAN for MGMT
j. other custom VLANs
OR:
k. any subset of the VLANs #e to #j, including subset 0 (No VLANs at all, only a MAIN SSID)
Wherever we bring it.
We have ample margins for digression, as long as before or later we get back to the above topic.
Right now? On the network forum, but at the time I wrote that I was on the sarcasm forum .
[1] For a decently small value of any, let's say up to 9 CAPs
Yep, it must be found a good compromise between freedom of the user to change parameters and the inflexibility of a template.
About the different versions, besides a "smart" dynamic auto-magical multi-choice, should it be too complex to implement, nothing prevents from making more than one template, one for each of the listed configurations.
I am not expecting to create something that a complete newbie would be able to use to have a complete configuration with all the possible crazy settings, only something that can be use as a (hopefully) working base, without the possible typos.
As we have seen, the ratio between "settings" and "base choices" is 4:1 or 5:1, so the risk of a typo is very high when going "freehand".
It usually works the other way round, in my experience.
You first build something that works.
Then you make it pretty (or prettier).
Abbreviations are already defined (but can be of course modified and the area can be moved):
Column 1
Column 2
Column 3
The scheme is prefix_Name or - when useful - prefix_Name_vlan#
The prefix is what the thing is.
Name is one of the custom fields
vlan (where applicable) is the suffix corresponding vlan number
Prefixes:
br
bridge
cfg
configuration
sec
security
dp
datapath
wifi1
the first wifi interface, usually the 2.4 GHz one, but it depends on the device in use
wifi2
the second wifi interface, usually the 5 GHz one, but it depends on the device in use
vlan
vlan interface
I am attaching something else, not a lot of progress, but added MAC generation and some conditional behaviour.
Now it contains (should contain) the logic to allow choosing to have 1-3 SSIDs and 0-4 VLANs.
Next step will be to add provisions for automatic generation of:
/ip address
/ip dhcp client
for both CAPsMAN and CAPs
And:
/ip dhcp server
/ip pool
/ip dhcp-server network
on CAPsMAN for the various VLANs.
I think that using a /24 subnet (fixed) will be enough (covering - say - 99% of setups), with the scheme 192.168.<VLAN#>.0
So:
Base (no VLANs) 192.168.88.0/24
VLAN 10 192.168.10.0/24
VLAN 20 192.168.20.0/24
VLAN 30 192.168.30.0/24
VLAN 40 192.168.40.0/24
(please do not use VLAN 88, besides VLAN 1 )
For simplicity and to give some consistency to IP assignment, I am thinking of:
CAPsMAN to be device #1 (thus renamed to CAPsMAN#1) have .1 assignment (static)
CAP_AC to be device #2 (thus renamed to CAP#2_AC) have .2 assignment (static)
CAP_AX to be device #3 (thus renamed to CAP#3_AX) have .3 assignment (static)
And (for the ip pool) use .10-.254 (fixed), I don't think that "losing" (potentially) some 7 addresses out of 254 can be an issue, and the very few people needing more than 9 CAPs can well change the pool range manually.
Ok, we have something that may - at least partially - work.
There is no provision for a CAPsMAN that has also its own radios (but adding it in a later version/release should be relatively easy).
There might be omissions and also both logical/conceptual and implementation mistakes.
But at least it looks readable, documented and usable.
I am posting the generated configurations of the three devices, CAPsMAN, CAP_AC and CAP_AX for those that can read and understand directly configurations and don't want to play with the spreadsheet.
EDIT1: There is a mistake in the generator for the CAP AX in /wifi datapath, corrected the above snippet for the CAP AX and posted corrected version 8 of the sheet.
OK, I tried (and failed) to make sense of a comparison between what was created by the Generator (which should be - more or less and with all the caveats that my implementation imply - pmastal's suggested configuration) and the configuration snippets posted by mkx.
The comparison is complicated by the use of the three radios of the Audience, but besides that and the (obvious) different names of interfaces and numbering of vlans, the only thing clear to me is that the two have a VERY DIFFERENT APPROACH to make a set of CAPsMAN+CAP_AC+CAP_AX configurations.
I am attaching the comparison with "normalized" names of items (though not much useful for anything). Generator_vs_mkx_02.zip (12.0 KB)
My problem here is that I'm mostly reading this fotum on an android tablet ... which makes opening ZIP files and some fancy file formats a bit of a problem.
Something you may want to try is SpreadCE/Spread32, which does exist in an Android version (cannot say how good it is, the normal Windows version is IMHO like the third best thing in the world, after sliced bread and grub4dos), you can try the shareware version at no cost.
Of course the usual caveats for using a non-google_play tool apply, it comes in a .zip file that contains the .apk. https://www.byedesign.co.uk/
the "registered version" is actually available on google play for a small sum, but of course, even if it is not much and I can guarantee that the "base" program is exceptionally good, it is only up to you if you could find it useful and worth the investment: https://play.google.com/store/apps/details?id=uk.byedesign.spreadce
.
