SXTsq 5 ac loosing http/webfig access after applying PtP bridge AP mode, pings OK :/

Hi all, and wishes for a happy new year!

this has probably been answered a gazilion times already, but bear with me since I’m new to MT gear and trying to get myself educated as I go, with (obviously) a long way ahead of me still :wink:

This is an effort to evaluate my chances with MT as a viable substitute coming from a different vendor operating a small fleet of 5Ghz PtP links. I’m currently to the point of having already acquired some SXTsq 5 acs, however I find myself in the situation where running sets of 2 in headless mode (i.e. not connected to other devices - therefore assigning static IPs to all the respective fields) upon changing the operation mode from CPE to PtP bridge AP for the units set to act as such I completely loose http/winbox access to them requiring a reset to defaults…This actually does not happen immediately, but I get the chance to “play” around with the bridge AP’s settings to begin with, i.e. set the transmit channel, WPA credentials and what have you, however upon hitting ‘apply configuration’ all is nuked…The devices in question all respond ping requests on said new IP, however http/webfig even winbox access is rendered impossible.

It’s worth noting that I’m not really pushing the limits of the devices with any difficult to pull configs, mostly basic stuff to make this as transparent as possible and leave routing to devices outside the domain of the AP/CPEs, still I find this quite confusing that this happens so early in the setup stage.

Any help appreciated

Reminds me of http://forum.mikrotik.com/t/error-could-not-connect-to-192-168-88-1/134083/1

TL;DR, there may be a problem with config generated by Quick Set when changing modes.

I have SXTsq acs running in ptp. There is a limitation in the number of ptp connections set to 1 for this level 3 RouterOS license.
The AP mode can not be set with level 3. So I don’t know what this quickset “ptp bridge AP” will try to do in de wireless mode, or in what mode it will end up.
I did not use quickset, but simply set it up as “bridge” on one side and “station bridge” on the other side.
In the cases where I need to connect multiple SXTsq ac’s then I use the “SXT SA5 ac” in “AP bridge” mode. This is a level 4 device.

See also: https://wiki.mikrotik.com/wiki/Bridging_Networks_with_SXT

Thanks for the pointers everyone, will try some of your suggestions and report back. One would wonder however how such a mature software product suffers from such ill-effects..

I’m afraid following the wiki @ https://wiki.mikrotik.com/wiki/Bridging_Networks_with_SXT yields the exact same results. In doing so I -obviously- skipped the Quick Setup procedure altogether and in addition I even tried starting with a completely empty config to mitigate possible firewall / NAT defconfig issues, but still to no avail..

..so to recap; For me to evaluate whether MT is a viable alternative or not I wish to set an RBSXTsq5ac in pure standalone - headless bridge mode. This will allow me to test the broadcast from a few alternative receivers across my test field by connecting to it and subsequently run performance tests.

Is there someone who could provide such a plain setup for me to feed into the device in some way?

I need this to initially broadcast plain 802.11, on a 20Mhz channel width, with an SSID for example “MT_test” on channel 5700, no WPA security, an IP of 192.168.1.25, DHCP disabled, no other prerequisites per se, other than being able to log into it both locally AND remotely over the bridge.

Shouldn’t be a difficult task, yet I’m still struggling :confused:

Any help appreciated

Just another check:

Channel 140, 5700 MHz takes at least a 1 minute delay before it starts, due to DFS requirements.
Some channels even have a delay of 10 minutes. This is (selected) country regulation specific.
https://metis.fi/en/2018/02/5ghz-channels/

And to connect to the devices, you use Winbox discover, and use the MAC address connection if you are not fully IP-subnet compatible yet. (No DHCP? Hmmm … check your IP addresses!)
“IP Neighborgs” in the Winbox session should see the other Mikrotik device when the connection is set up.

Maybe start with posting the config of the devices, failing that, maybe contact a certified Mikrotik consultant to physically meet you onsite

https://mikrotik.com/consultants

Thanks for the replies all.

First things first:

a. this inability to access the http(webfig)/Winbox(IP) RBSXTsq5ac unit that is physically connected via a UTP cable to the system performing the configuration is completely unrelated to DFS which is a different beast solely related to the wireless domain and the laws in-place to coexist with other technologies (weather radars and such) which these APs share operating frequencies with. On that front (DFS channel) I can get the transmission up and running after about 1 min (pending DFS clear scan ) no probs there..Channel 140/5700Mhz is set to be within the EU outdoor DFS broadcast spectrum limits in order to use the unit in a lawful way.

b. Further tests seem to indicate that in following the wiki above to setup bridge / station bridge access via http/ssh/Wibox(IP) is lost at the step when adding ether1 port to the bridge, OR when changing the default IP (88.1 to 1.25) or deleting that and using solely x.1.25 via the IP/Adress List window.

c. Here’s a copy of the defconf that sets the unit in CPE / Station pseudobridge mode after reseting the unit via WinBox and/or pressing the reset button while plugging the PoE cable for 5’’ based on v. 6.42.7 of the facroty f/w

# jan/02/1970 00:02:44 by RouterOS 6.46.1
# software id = WCLX-LZLW
#
# model = RouterBOARD SXTsq G-5acD
# serial number = 898E09xxxxxx

/interface wireless
set [ find default-name=wlan1 ] band=5ghz-a/n/ac channel-width=20/40/80mhz-XXXX \
    disabled=no frequency=auto ssid=MikroTik

/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN

/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik

/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254

/ip dhcp-server
add address-pool=default-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

/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

/tool mac-server
set allowed-interface-list=LAN

/tool mac-server mac-winbox
set allowed-interface-list=LAN

d. I finally managed to get to the point I needed in my ‘quest’ by tweaking it to a bare-bones config as follows, which indeed works and acts completely the way I described above for the purposed and methodology I wish to follow.

# jan/02/1970 00:36:22 by RouterOS 6.46.1
# software id = WCLX-LZLW
#
# model = RouterBOARD SXTsq G-5acD
# serial number = 898E09xxxxxx

/interface bridge
add name=bridge1

/interface wireless
set [ find default-name=wlan1 ] band=5ghz-n/ac country=debug disabled=no \
    frequency=5700 mode=bridge ssid=MT_test tx-power=1 tx-power-mode=\
    all-rates-fixed wireless-protocol=802.11

/interface list
add name=WAN
add name=LAN

/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk eap-methods="" mode=\
    dynamic-keys supplicant-identity=MikroTik

/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot

/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=wlan1

/interface list member
add interface=ether1 list=WAN
add interface=wlan1 list=LAN

/ip address
add address=192.168.1.25/24 interface=wlan1 network=192.168.1.0

This config - only by substituting country=debug with the respective choice to be within DFS operating requirements and tweaking the tx-power value to suit one’s needs - gives me the ability to access the AP both locally AND over the bridge on IP 192.168.1.25 in order to carry out tests that will aid my evaluations. At this stage It’s hugely important to note that in the meantime I did update the factory f/w from 6.42.7 to 6.46.1 prior to my success, so maybe there was something there in the defconf after reset that was bugging the hell out of this what_appeared_to_be_really_easy_config_in_the_first_place…

So there you have it, I hope this serves as a guide for whomever finds himself in a similar situation in the future..

Regards.

Hi, your IP address should be on the bridge, not on one of the slave interfaces WLAN1 or ether1.
To manipulatie IP adresses the connection via Winbox or Telnet MAC is handy.

I still see the “interface list” WAN and LAN. If there are default firewall rules , no interface should be in the WAN list. Bridge should be in the LAN list. WAN and LAN are used in the default firewall rules.

Management access is only through LAN list, not through WAN list interfaces.. If there are no firewall rules then WAN and LAN are not used.

Fixed

I still see the “interface list” WAN and LAN. If there are default firewall rules , no interface should be in the WAN list. Bridge should be in the LAN list. WAN and LAN are used in the default firewall rules.

Bridge in the LAN list - fixed.
Since there are no firewall rules this being a transparent bridge between two routers operating on different subnetworks, it makes sense for ether1 to be in the WAN list, or am I missing something?

Management access is only through LAN list, not through WAN list interfaces.. If there are no firewall rules then WAN and LAN are not used.

At this stage i require management access through LAN, wlan1 AND over the bridge station and indeed this config so far makes it so. I don’t understand the extra remarks you make based upon my specific requirements.

If there are no firewall rules there is no usage of the WAN and LAN interface list. It does not matter if and in what lists the interfaces are.. Those interface lists are just not used.anymore and so have no meaning.

The default firewall rules made “WAN” the NATted internet connection. (No incoming access allowed, no management allowed, no MAC based access, destination NAT for outgoing access.)
The “fast” way to use the device in a LAN setup (everything has full access locally) is to put all interfaces in the LAN list.
Removing the firewall rules is making the WAN list and LAN list definition obsolete (and avoids some overhead, like session tracking and firewall processing)

I’m with you all the way, makes complete sense.

What didn’t was that in setting this up according to the wiki as shown above should in theory lead to this setup, however I found that upon doing so I couldn’t access the unit both locally and over wlan1, hence this ordeal so far :confused: Don’t know if this had to do with a bugged defconfig in the previous factory f/w, however as it now stands (with an updated factory f/w to the latest - current - version) surely having started over from scratch it seems to do the things I need. So in conclusion I’ll just take it from here for the time being and see how / if i add further config args when / if these become relevant.

Thanks for your input so far, greatly appreciated.

Not entirely true. Default config limits MAC access (telnet and winbox) to interfaces members of LAN interface list. So if the limitation is not needed, don’t forget to set that to all for both services.

Yes MKX. “LAN” list name is used there as well. I had the process in mind where you do the setup without a default configuration.
Didn’t bother to mention it, as there was no reaction on the MAC based connection.possibility.(Don’t know yet if RoMON is also mac-server related.)
That’s why I prefer just to put everything in the “LAN” list, rather than removing the default config.. (e.g.I see It’s also used for IP discovery setting in the default config.)

Sometimes you want to use the Home AP (LAN connected) to make a separated or secured network. Uplink connection wired or wireless (‘hotspot extender’ function not repeater function). Then you go back to the WAN definitions, with its masquarade NAT rule and firewall protection.for the uplink. Otherwise ( transparant LAN connected) “LAN” should be used as interface list.. The name of the interface list could be different, but defconf uses LAN as name.