Metal 52 ac - stuck "searching for network"

RouterOS General
1

I have been test running the Metal 52 ac as CPE connected via ethernet to an hAP ac configured as Dual AP.
For testing purposes before deploying, it is connected wirelessly to the home WiFi.
After working fine for a few days, at some point the Metal disconnected from the WiFi and refuses to reconnect to the same network that worked fine for several days and it rather gets stuck into the “searching for network” stage.
I am puzzled that it would connect fine for some time and than be unable to reconnect to the same Wireless network.
I suppose I could wipe the configuration clean and start over reconfiguring and reconnecting hoping for better luck, but I’d like to understand the cause of the behavior and how to prevent.
Do you see anything in the configuration below that look suspicious?
Any other suggestions about what to do next?
Thanks,
Steven

# oct/07/2020 10:13:02 by RouterOS 6.47.4
# software id = RYP6-C6X1
#
# model = RBMetalG-52SHPacn
# serial number = B7DA0B68CC0B
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=6 band=5ghz-a/n/ac \
    channel-width=20/40/80mhz-XXXX country="united states" disabled=no \
    frequency=auto installation=outdoor mode=station-pseudobridge ssid=\
    Mazz_net wireless-protocol=nv2-nstreme-802.11
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa-psk,wpa2-psk group-ciphers=\
    tkip,aes-ccm mode=dynamic-keys supplicant-identity=MikroTik \
    unicast-ciphers=tkip,aes-ccm wpa-pre-shared-key=******* \
    wpa2-pre-shared-key=*******
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip pool
add name=dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=dhcp disabled=no interface=ether1 name=defconf
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=ether1 list=LAN
add comment=defconf interface=wlan1 list=WAN
add list=LAN
/ip address
add address=192.168.88.1/24 comment=defconf interface=ether1 network=\
    192.168.88.0
/ip dhcp-client
add comment=defconf disabled=no interface=wlan1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/system clock
set time-zone-name=America/New_York
/system identity
set name=NinaBooster
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
2

If you do a scan with NetMetal, it find the network that you want?

On AP side check if the WPA password and default authenticate are ok.

Regards.

3

Try using selecting 2.4 ghz band. I had a similar problem and this solved it.

4

My wild guess - could it be that the AP has the channels that may conflict with radars enabled and therefore hasn’t started the 5 GHz radio yet?

Can you run /interface wireless scan at the Metal and see whether it can see any networks at all around you? No idea where you are located, so there may or may not be something other than your AP in the air - you can use the hAP ac, even though it runs as an AP, using /interface wireless scan background=yes, to check for other networks.

5

@krafg, yes it finds it. It is there and it has been connected to it for days, until it disconnected and would not reconnect. I have disconnected hAP and connected the Metal directly to the PC to make sure that the metal side connects fine.
@sindy. The command /interface wireless scan finds a handful of networks, including the one to which the metal can successfully connects until it disconnected and was not able to go back. I do not understand what “could it be that the AP has the channels that may conflict with radars enabled and therefore hasn’t started the 5 GHz radio yet” can you please elaborate or reword?
@vron. I had the same problem with 2Ghz bands. It would disconnect and would not reconnect.

Now, while studying your responses, I repopulated the fields in the Quick Set screen, Wireless section, with identical selections as before, and it did reconnect. Which makes me suspect that the Quick Set may create some issue somehow. Is such a thing a possibility? Would it be better to avoid and use the the GUI (which seems friendly enough or terminal?
Anyhow, I don’t know if this is just an odd annoyance or a problem, but the behavior is a little mysterious.
Many thanks,
Steven

6

What is in the log about this, after you set the topic “wireless” in /system logging ??

There is no need for “station-peudobridge” as you are using NAT to connect clients to the AP. “station” or “station bridge” will do, and is more stable than “station-pseudobridge”.
In 6.47.4 is “station roaming” disabled by default already? If not, and if there is only one AP to connect to, or things are static, then go for “disabled station roaming”. Every roaming check brings extra instability.
Don’t use “tkip” if not absolutely needed. TKIP based encryption cannot keep up with higher speeds.