In my case im using WDS. I found that i can change the SSID on the remote side and sill i can have connectivity by the futures “wds ignore ssid”.
Everything is okay..as long as those two sides are without encryption. As soon as i add encryption (WPA,NV2). The link will not connect at all.
My question is why i can use “wds ignore ssid” with any kind of encryptions
For the same reason why you can attach IP configuration to a slave port of a bridge which is also a wrong configuration but you can set it up like that and even the auto-generated warning comments in the configuration do not appear to notify you about that. It needs a specific talent to be able to guess in advance what misconfiguration the device administrators might come up with and check for it 
So you can help Mikrotik R&D advance with this by providing them with a list of misconfigurations you’ve ran into which are not searched for and notified about so that they could add it to the sanity check algorithms.
Sorry Sindy I couldn’t get nothing useful from your message.
My question was very simply, i will repeat again.
So when i’m using “wds ignore ssid” (wiki: If this property is set to yes, then SSID of the remote AP will not be checked.) It works excellent without security profile, as asson i as do the link is not going to be established. Does anyone notice that?
Couldn’t it be related to the fact that there was little useful information in your OP?
In fact the original question was a different one -
.
So I’ve answered exactly that question - why can you (i.e. are allowed to) set something that doesn’t work. In your configurations which you haven’t posted there is probably some combination of settings which cannot work but it is impossible for the developers to anticipate every mutually incompatible combination of settings which a user may invent and warn about all such incompatible combinations or make it impossible to set them.
Now on a more constructive note: I’ve just tested the same what I suppose you to do. So my settings at the AP end are:
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa2-psk mode=dynamic-keys name=wpa2-test supplicant-identity=MikroTik wpa2-pre-shared-key=
secure-wds-key
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=2 band=2ghz-b/g/n country=redacted disabled=no distance=indoors
frequency-mode=regulatory-domain mode=ap-bridge security-profile=wpa2-test ssid=somessid wds-default-bridge=br-test
wds-ignore-ssid=yes* wds-mode=dynamic wireless-protocol=802.11
At client side, there is
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa2-psk mode=dynamic-keys name=wpa2-test supplicant-identity=MikroTik wpa2-pre-shared-key=
secure-wds-key
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=3 band=2ghz-b/g/n country=redacted default-authentication=no disabled=no
distance=indoors frequency=auto frequency-mode=regulatory-domain mode=station-wds security-profile=wpa2-test ssid=“”
wds-default-bridge=br-wds wds-ignore-ssid=yes wds-mode=dynamic wireless-protocol=802.11
/interface wireless connect-list
add interface=wlan1 security-profile=wpa2-test wireless-protocol=802.11
With these settings, wds interfaces are auto-created at both ends and added as ports to the bridges as configured. As you can see, the ssid field is empty in both the /interface wireless setting and /interface wireless connect-list item, and nevertheless the ping between IP addresses associated to these bridges passes through successfully as /tool sniffer quick interface=wds21 shows:
wds20 0.02 1 ← CC:2D:E0:xx:xx:66 64:D1:54:xx:xx:5A 192.168.163.3 192.168.163.1 ip:icmp 70 0 no
wds20 0.02 2 → 64:D1:54:xx:xx:5A CC:2D:E0:xx:xx:66 192.168.163.1 192.168.163.3 ip:icmp 70 0 no
wds20 1.024 3 ← CC:2D:E0:xx:xx:66 64:D1:54:xx:xx:5A 192.168.163.3 192.168.163.1 ip:icmp 70 0 no
wds20 1.024 4 → 64:D1:54:xx:xx:5A CC:2D:E0:xx:xx:66 192.168.163.1 192.168.163.3 ip:icmp 70 0 no
So something must be set differently in your case which breaks your SSID-ignoring WDS connection when you use a security profile on it.
My guess, completely uneducated: the station with wds-ignore-ssid=yes connects to AP with different wireless security profile … and in that case the link breaks … probably. But then, how’s station supposed to know that some random AP uses different security profile than the one configured in station?
I really wonder what’s rationale behind wds-ignore-ssid=yes if there’s no control over which ssids are usable and which are not?
That how my config looks like.
Keep in mind Sindy both side have to be APs,because wds-ignore-ssid=yes will work between APs
In this case wds-ignore-ssid=yes will not work,if i switch security-profile=WPA2 to default, i can change SSID on both side and the link will established.
With security-profiles doesn’t, that i want to find out why.
/interface wireless security-profiles
name=“WPA2” mode=dynamic-keys authentication-types=wpa2-psk unicast-ciphers=aes-ccm group-ciphers=aes-ccm
wpa-pre-shared-key=“” wpa2-pre-shared-key=“test.test.test1”
/interface wireless
name=“wlan2” mtu=1500 l2mtu=1600 mac-address=00:0C:42:3A:C9:BB arp=enabled interface-type=Atheros AR92xx mode=ap-bridge
ssid=“WDS” frequency=2462 band=2ghz-g/n channel-width=20mhz secondary-channel=“” scan-list=default
wireless-protocol=802.11 vlan-mode=no-tag vlan-id=1 wds-mode=static wds-default-bridge=none wds-ignore-ssid=yes
bridge-mode=enabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0
hide-ssid=no security-profile=WPA2 compression=no
At client side, there is
name=“WPA2” mode=dynamic-keys authentication-types=wpa2-psk unicast-ciphers=aes-ccm group-ciphers=aes-ccm
wpa-pre-shared-key=“” wpa2-pre-shared-key=“test.test.test1”
/interface wireless
name=“wlan1” mtu=1500 l2mtu=1600 mac-address=00:0C:42:18:E6:73 arp=enabled interface-type=Atheros AR92xx mode=ap-bridge
ssid=“test” frequency=2462 band=2ghz-g/n channel-width=20mhz secondary-channel=“” scan-list=default
wireless-protocol=802.11 vlan-mode=no-tag vlan-id=1 wds-mode=static wds-default-bridge=none wds-ignore-ssid=yes
bridge-mode=enabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0
hide-ssid=no security-profile=WPA2 compression=no
I’ll only be able to test it practically in hours from now, but the manual says the following:
Security profile for WDS link is specified in connect-list. Access point always checks connect list before establishing WDS link with another access point, and used security settings from matching connect list entry. WDS link will work when each access point will have connect list entry that matches the other device, has connect=yes and specifies compatible security-profile.
I cannot see any /interface wireless connect-list item in the configuration you’ve posted. Just a note, ssid is not a mandatory parameter of these items.
@mkx, I read the presence of the possibility to use WDS with ignore-ssid set to yes as a way to save one SSID otherwise necessary for the WDS to work; if you want to run a disjunct set of SSIDs on each AP and at the same to allow them to create a WDS network (which may dynamically reorganize itself), with this setting in place it is enough that they use a common security profile for the purpose.
sindy, even with /interface wireless connect-list doesn’t have any effect. however Thanks.
I confirm your observation, so I’d say it’s time for an e-mail to support@mikrotik.com (with supout.rif from both your machines), asking them to either clarify the documentation or fix a bug.
Log is the same at both devices (different MAC addresses of course):
10:14:49 wireless,info CC:2D:E0:xx:xx:66@wlan1: connected, is AP, wants WDS
10:14:59 wireless,info CC:2D:E0:xx:xx:66@wlan1: disconnected, unicast key exchange timeout
10:15:29 wireless,info CC:2D:E0:xx:xx:66@wlan1: connected, is AP, wants WDS
10:15:39 wireless,info CC:2D:E0:xx:xx:66@wlan1: disconnected, unicast key exchange timeout
I will wait for couple of days,there already on this forum.
update from MikroTik
This is not a bug, because when you set the WPA2 security profile the PSK key is generated passphrase+SSID and that is why the connection in this type of scenario is not possible.
Best regards,
Viesturs R.
OK. I had a suspicion this was the reason but I couldn’t quickly find a reference back then confirming that both the SSID and the passphrase are used to generate the actual key. So it is not a bug, and thus the documentation should be updated with this limitation (and preferably also explanation).