cfg check: is encryption enabled?

RouterOS Wireless Networking
1

hi all,
I’ve just been charged with the management of 2 wireless bridges based on routerboard; the information I have is that these 2 bridges have been put in service more than 10 years ago and abandoned.
I have been able to take one of the bridges offline just to dig & update & upgrade and I managed to upgrade the devices to the latest router os 7; I even put them back in service and they still connect successfully and perform as expected.

the question: is encryption enabled at all on the wifi link?
as per documentation, ‘mode=none’ in the security profile means that encryption is disabled, there is no encryption at all on the link

is there any other method/chance/possibility/option to enable a cypher on that wireless link without a VPN?
anything that may have been in use 10 years ago but is now abandoned/superseded?

I’m planning to enable the usual aes/wpa2/psk but I have no easy physical access to these devices (they are on a pole 10 meters above the roof) so I’m trying to cover all bases and avoid surprises down the road while updating the setup.

thank you for any hint.

here is the wifi configuration:

name=“wlan1” mtu=1500 l2mtu=1600 mac-address=4C:5E:XX:XX:XX:XX arp=enabled interface-type=Atheros AR9300 mode=station-bridge ssid=“SecondSSIDName” frequency=5200 band=5ghz-a/n
channel-width=20/40mhz-Ce secondary-frequency=“” scan-list=default wireless-protocol=any vlan-mode=no-tag vlan-id=1 wds-mode=disabled wds-default-bridge=none
wds-ignore-ssid=no bridge-mode=enabled default-authentication=yes default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0 hide-ssid=no security-profile=default
compression=no

here is the security profile:

name=“default” mode=none authentication-types=“” unicast-ciphers=aes-ccm group-ciphers=aes-ccm wpa-pre-shared-key=“” wpa2-pre-shared-key=“” supplicant-identity=“MikroTik”
eap-methods=passthrough tls-mode=no-certificates tls-certificate=none mschapv2-username=“” mschapv2-password=“” disable-pmkid=no static-algo-0=none static-key-0=“”
static-algo-1=none static-key-1=“” static-algo-2=none static-key-2=“” static-algo-3=none static-key-3=“” static-transmit-key=key-0 static-sta-private-algo=none
static-sta-private-key=“” radius-mac-authentication=no radius-mac-accounting=no radius-eap-accounting=no interim-update=0s radius-mac-format=XX:XX:XX:XX:XX:XX
radius-mac-mode=as-username radius-called-format=mac:ssid radius-mac-caching=disabled group-key-update=5m management-protection=disabled management-protection-key=“”

2

Wireless bridge is the same as normal AP/station. And AP setting security.mode affects encryption.

It’s pretty easy to enable it … set mode=dynamic-keys , authentication-types to e.g. “wpa2-psk” and set wpa2-pre-shared-key … first on remote side of link (if managing over same link) and then on local side. Set properties to same values on both sides.

3

that’s what I did in the end and looking back at it I was overthinking the whole thing…

after a couple of days of the up to date bridge running with no issues, I put offline the second bridge (the one still on 5.23) and after another few days updated that one too and that’s it.
enabled encryption, enabled ntp (the clocks on all 4 devices were on 1970), setup rtsp and now everything is back online as an active/standby dual bridge (the link carries a single s2s VPN connection).
just to give a full picture, it all started with link flapping on the eth when using switches younger that 4 or 5 years: I suppose issues with rtsp, loop protection or something related, but when I noticed the os version I choose not to dig and update first.

next step will be some test to have both links active: now that encryption is active on the link, the VPN could be dismissed and with routing we could achieve double bandwidth.

amazing how a piece of hardware 10 years old have been revived with a software upgrade; some hw limitation (100mbps eth) but still suitable for the task.