This is my 2nd Metal 52. First one works great and no prob configuring.
But right out of the box, I got “ERROR: could not connect to 192.168.88.1” with Winbox on this new one - bad sign. I could see this new unit but no connect. However, I changed the IP address on a second computer to 192.168.88.10 and could connect directly. With that, I was able to cookie cutter my 1st unit settings onto the new one with either Winbox or the web interface. It now works perfectly at 192.168.1.25. However, in its new configuration as WISP AP now, I can no longer connect to it in any way for configuration even though as I say, it works perfect. I get the title error message from Winbox (at “192.168.1.25”). My existing unit works perfectly with the very same configuration and is fully accessible via webpage on Winbox. Two Metal 52 units configured exactly the same way. Web interface will not connect at 192.168.1.25 nor Winbox. Perfectly fine on Metal unit #1 at 192.168.1.30 with same setup. Numerous factory resets in this struggle since that’s the only way I can reconfigure it.
If I leave the device default CPE setup and just change the IP address, I can access the device on my LAN. In that case, out of curiosity, I updated it to the same new 6.45.6 software version as in existing unit since that trick often works. But it didn’t here. Once reconfigured and working perfectly on my LAN, configuration access becomes impossible just as at the very start. What might I be missing, or is the device defective?
If you have Winbox loader open, does it find the Metal unit in the neighbor list? Can you click on the MAC address of the unit and then try to connect? Does that work?
The unit is all connected and working perfectly on my network. Smartphone is connected, and speed test is fast. However, right this moment, Winbox on this PC on the network can see my other unit but not this one either by IP or MAC. I got the MAC address just now off the back of the unit. Says “ERROR: could not connect to 74:4D:28:D5:C0:78” There was a second MAC ending in 79. Tried them both. Can’t connect with my browser to the IP 192.168.1.25. The IP does show normally on my IP scanner software. Very puzzling since it’s working perfectly with SSID, passwords, channel, BW, etc.. It was a huge hassle to configure it under these conditions, however. I was experienced enough to do that since I have the other Metal 52 unit. I could stay with it on Winbox once connected to do the configuration, but it will never connect again. So this one can’t be reconfigured in any way without hard factory default reset and going through those hassles again.
As I understand, your connection to the internet works fine, but you have no way to connect to the MikroTik “Metal” device itself?
SSH is also not working?
As for SSH and most other command line stuff, I’ve forgotten how to do that stuff. However, here’s another clue. If I ping it, the result is “Destination host unreachable”. I can ping the other Metal 52 at 192.168.1.30 and get an expected reply but not this x.x.x.25 unit. However, “Advanced IP Scanner” finds it in on my network and reports the MAC address. This is beyond my understanding.
Again please note that new right out of the box, I got the title error message. Even before I started messing with it, a Winbox connection was not possible. Connection was only possible on a PC whose IP address was temporarily changed to 192.168.88.10, and that’s how I configured it. Once configured though, it was never reachable again without a full factory default reset.
Guess the unit has some sort of hardware defect and needs to be replaced or refunded. I could use it like this, but it can never be reconfigured without taking it down from the pole and doing a full factory reset, which is unsatisfactory.
To eliminate unexpected variables, I’ve tried this on 2 PC’s plus switched cables, POE adapter, power supply, etc.. Restarted 16 port switch. None of this makes any difference. Have the OEM power supply and POE dongle from Metal 52 unit #1, and when I used that as shot in the dark, no difference. Problem is in the Metal 52 device itself for sure. Note that when I got it to be temporarily accessible on the 192.168.88.10 PC, I was able to update the software version to 6.46.6 as I’d previously done on unit #1. That didn’t upset my configuration and made no difference in the issue. Unit #2 is still inaccessible as described. With some fiddling, it can be accessed once and configured but once disconnected, it can never be accessed again even though it is set up just like unit #1 and does function as a WISP AP on my network. Right out of the box untouched, I got the error message in the title. Should’ve just returned it then and there instead of wasting all this effort.
Before I return this device, I thought I’d take one more stab at it. Sorry, but I was mistaken about ping. Once freshly configured with LAN address 192.168.1.25, it is pingable.
Per your suggestion, I downloaded PuTTY and found that the unit can be accessed by SSH until it is configured as a bridge exactly like my first Metal unit that works super. When it stops being accessible by Winbox and HTML, SSH goes dead as well. I can configure it on my 192.168.88.10 machine, and it then works OK as a bridge on my LAN just as well as Metal #1. Just cannot be accessed by SSH, Winbox, or HTML, likely due to a DHCP snafu that I can’t figure out how to change. This error never happened on the first unit. Digging in all the menus, the only difference between the two units is this:
Working unit DHCP menu http://ostenta.net/files/working-unit-1.jpg
Non-working unit http://ostenta.net/files/non-working-unit-2.jpg
If this is the issue, and you have some way to fix it, please respond ASAP before I give up and just go back to Ubiquiti. There was no obvious solution to me. I can get into the unit fine with commands by SSH until it is configured
If it initially works, then you change something and after that it doesn’t work, and it happened more than once, there’s clear pattern. Simplest explanation is that you change something in a way that locks you out. I don’t know if you’re changing modes in Quick Set or doing manual changes. The former could possibly be bug, but since I don’t use Quick Set myself, I won’t tell you much about it. If it’s the latter, you need to plan ahead, before you change something. For example, if there would be firewall allowing access only from specific interface and you’d add this interface to bridge, it would no longer work. Same could happen for access using MAC address. Or DHCP, although there the client should be temporarily moved by system from bridge port to bridge. Things like that.
I find it best to reset RB to completely clean state without any default config. Then connect to MAC address and start creating config from scratch. But it may not be for beginner.
And about your screenshots, I see one with disabled dhcp client and one with invalid dhcp client, so the end result should be the same, no working dhcp client.
The first Metal 52 unit was easy to configure and works great. I just imitated exactly what I did for that one, configuring them as a WISP AP bridge. They both work perfectly in that role, but unit #2 cannot be accessed for configuration unless a full default reset is done. I updated the OS to latest version 6.45.6 as with unit #1, and that didn’t make any difference, so it’s not software. I have to decide whether to exchange it for another or give up and get a refund. I’ve already been through this thing over and over and am moderately experienced, not a beginner. A friend suggested I use these instead of Ubiquiti.
I’m thinking this product is unusable. I went to MikroTik support directly and got some questions from them but no answers. Unit xxx30 is the working MikroTik Metal while xxx25 is the one with problems. If this device can’t be made to run, I need to go to the seller, SIL MICRO, to complain and then stick with Ubiquiti for future needs. I returned one unit and may return this one. I’m puzzled why a unit bought earlier (xxx30) from a different supplier works so well while this new one (xxx25) does not, even when configured exactly the same.
Here are all the connection results:
IP Scanner visibility OK on network
Winbox no connection to xxx25
Ping to xxx25 is however successful
Telnet to xxx25 is unsuccessful
Telnet to xxx30 (the working Metal) is successful
SSH to xxx25 not successful
SSH to xxx30 is successful
No connection to xxx25 via HTML browser but OK on xxx30.
Metal in question, xxx25, works perfectly as WISP bridge but as above can’t be accessed for config. Smartphone speed test of unit xxx25 at 20 MHz BW is all OK at 46Mbps D/U.
This is a real mystery. Why would xxx25 work perfectly on the network but not be accessible for subsequent configuration? First Metal unit xxx30 works perfect.
Please, reset it once again.
Configure the same way you’ve done before.
And before you disconnect from it (losing the ability to connect again) make an /export of the config and post it here.
The non-working one has firewall ending with (and doesn’t allow much before):
/ip firewall filter
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
But other parts of config are:
/interface list member
add list=LAN <-- this doesn't make sense
add interface=ether1 list=WAN
add interface=wlan1 list=LAN
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=wlan1
/ip address
add address=192.168.1.25/24 comment=defconf interface=wlan1 network=192.168.1.0
/ip dhcp-client
# DHCP client can not run on slave interface!
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=wlan1
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
In other words, if you’re connecting to 192.168.1.25, in-interface is bridge, even though you have it on wlan1 (bridge takes over its ports). And it gets dropped, because it’s not in LAN list. And if you’re expecting to have another address from DHCP client, you have it on wrong interface, it should be on bridge1. And MAC access is blocked for the same reason.
Sorry about the delay posting requested configuration export text files. Before they see the light of day, I wanted to carefully look them over myself before I look too dumb. See an important difference plus have Sob’s information (thanks very much). The configuration export text file is a handy summary trick. This is such a cool product. The xxx25.supout.rif I posted is of an earlier configuration with some errors not now showing although my newer config after some changes still doesn’t work so far. Be back shortly. Thanks to all.
I didn’t realize it earlier, but I have two different Metal versions. Just bought the first one a few months ago from another supplier. I thought they were the same.
xxx30 is “Metal G-52SHPacn”
xxx25 is “RBMetalG-52SHPacn”
They have differences in their configuration. I can’t find on the Internet what other differences might be. I can only find descriptions of the RB version. Is the xxx30 “Metal” version downlevel?
One very important difference is that the xxx30 does not have this firewall statement:
/ip firewall filter
add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN
This is what fouled me up. However, it looks like a logical statement that shouldn’t cause a problem. But glad to figure that out thanks to all this assistance. I need to be more familiar with this great product. Sorry though, but I am only moderately experienced.
When I disabled that filter action above, my access problem went away (Yay!). The basic setup was done by Quick Set, and then I’ve tweaked some. The Quick Set configuration was/is a little messy. Note that anyone who uses Quick Set with this RB version to set up a bridge will have the same problem I did.
nov/01/2019 14:17:57 by RouterOS 6.45.7
software id = 4J5E-6KLJ
model = RBMetalG-52SHPacn
serial number = A80F0A87DC3D
/interface bridge
add name=bridge1
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=0 band=2ghz-b/g/n disabled=no
frequency=2422 installation=outdoor mode=ap-bridge ssid=sendero
wireless-protocol=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 mode=dynamic-keys
supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip pool
add name=dhcp ranges=192.168.1.10-192.168.1.254
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=wlan1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add disabled=yes list=LAN
add interface=ether1 list=WAN
add interface=wlan1 list=LAN
/ip address
add address=192.168.1.25/24 comment=defconf interface=wlan1 network=192.168.1.0
/ip dhcp-server network
add address=192.168.1.0/24 comment=defconf gateway=192.168.1.25 netmask=24
/ip dns
set allow-remote-requests=yes servers=192.168.1.254
/ip dns static
add address=192.168.1.25 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”
disabled=yes 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
/ip route
add distance=1 gateway=192.168.1.254
/system clock
set time-zone-name=America/Los_Angeles
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
I don’t think they are actually different. But they most likely come from different production batches and thus had different “factory software” of ROS installed. And the “board name”, sometimes it changes after initial production batch.
Factory default configuration evolves with time and that could explain the difference in configs. Mind that ROS upgrade doesn’t change config (unless there’s some architectural change requiring config change). So if one really wants to have identical config on two units, both should first be upgraded to same ROS version, their configuration reset to default, and only then config adjusted as desired.
There was one very significant difference between the two units. The firewall filter in “Metal” has 6 actions, while in “RBMetal”, there are 11. As mentioned, one of the latter actions caused the problem I’ve described and had to be manually disabled. It was enabled by default. Anyone choosing to set up a bridge with “RBMetal” using Quick Set will run into the access issue I had. Not being experienced with the brand (only simpler Ubiquiti), I thought both Metals were same unit and didn’t expect that a factory default firewall setting would cause a fatal issue requiring deeper inspection and manual intervention to resolve. When I buy more Metals, I have to keep this in mind.
Keep in mind that the more correct way to resolve the issue is not disabling this last firewall rule, but rather to make it work as intended by adding your bridge to interface-list LAN.
Not so critical in your current config, because all your interfaces are actually LAN. But can be crucial in other scenarios, for example if someday you will have multiple VLANs, and decide that access to the device need to be limited only to one management vlan.
