Hello,
I am on 6.49.3 and the datapath options “local forwarding” and “client-to-client forwarding” are managed with yes/no menu (instead of drop-down menu of old versions).
Maybe there is a bug:
Assume you have a configuration with nothing configured in the datapath tab (all values empty), only a link to a separated datapath template (with “yes/yes”).
It seems that the configuration forces always “no/no” if empty in the tab (= if forwarding not configured to “yes”, then it means “no”, and the linked datapath template is then ignored), while with the dropdown menu they would perhaps be “undefined” and values “yes/yes” taken from the linked template.
The wording you’re using to me implies you’re using one of GUI-s … either WebUI or winbox. winbox is separate software which contains its own bugs and sometimes doesn’t match functionality provided by underlying ROS (which is somehow expected as certain version ov winbox supports wide range of ROS versions). WebUI on the other hand is closely tied to ROS version.
That being said, if I go with WebUi (6.49.1, is 6.49.3 acting differently with this regard?), I can see the mentioned properties not defined by default. The arrow down (drop-down?) defines the propery and default is unchecked which means “no”. CLI is more explicit in what one configures and what not … and it is possible to configure datapath without setting any value to the mentioned two properties. Then it’s down to CAPsMAN what kind of behaviour to apply if property is not defined. CAPsMAN manual implies that default is local-forwarding=no and client-to-client-forwarding=no:
datapath.> client-to-client-forwarding > (yes | no; > Default: no> )
controls if client-to-client forwarding between wireless clients connected to interface should be allowed, in local forwarding mode this function is performed by CAP, otherwise it is performed by CAPsMAN
datapath.> local-forwarding > (yes | no; > Default: no> )
Controls forwarding mode. If disabled, all L2 and L3 data will be forwarded to CAPsMAN, and further forwarding decisions will be made only then.
Note, if disabled, make sure that each CAP interface MAC Address that participates in the same broadcast domain is unique (including local MAC’s, like Bridge-MAC).
I agree that GUIs should be more self-descriptive, specially so as documentation on Mikrotik’s web page seems to lag behind the ROS implementation from time to time. But that doesn’t excuse router admin from reading it
Sorry, I found the mistake.. I know the defaults are no/no, but I was using Winbox, and when you touch the black arrows, they open (for the forwarding entries) the 2 checkboxes (like on the right part of the image).
I tought that the empty checkboxes were the correct, “fixed” layout of the page, not noticing that the little black arrows were “opened”.. (maybe I was too tired..)
So, closing again the black arrows, the checkboxes are “deleted” and “undefined” again (as in the left part of the image), and the “datapath1” template values are now considered.
Thanks!
EDIT: maybe I would prefer a drop-down menu with values “yes”/“no” explicitly written when you open the black arrows, instead of an empty checkbox implicitly configuring to “no”.
