Community discussions

MikroTik App
 
wlfz
just joined
Topic Author
Posts: 9
Joined: Wed Jan 27, 2010 2:22 pm

A bug in the 7.x system?

Sat Jan 21, 2023 12:01 pm

Hi!All.

In the 7.x version system, a wireless interface and a wired interface are added to the mesh, and a dhcp server is set on the mesh interface.

The result is that the IP address can be obtained normally through the wired interface, but cannot be obtained through the wireless connection.

In the 6.x version system, both ways can obtain the IP address normally.

Is this a bug in the 7.x system? Or does the new version change the configuration?



/ip dhcp-client
add interface=ether1

/ip dns
set allow-remote-requests=yes

/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa-psk,wpa2-psk eap-methods="" group-ciphers=\
    tkip,aes-ccm mode=dynamic-keys name=profile1 supplicant-identity="" \
    unicast-ciphers=tkip,aes-ccm
	
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-eC \
    disabled=no frequency=auto mode=ap-bridge radio-name=AP1 \
    security-profile=profile1 ssid=Mesh-Clients
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=\
    20/40/80mhz-Ceee disabled=no frequency=auto mode=ap-bridge radio-name=AP1 \
    security-profile=profile1 ssid=Mesh-Clients

/ip pool
add name=dhcp_pool0 ranges=192.168.88.2-192.168.88.254

/ip dhcp-server
add address-pool=dhcp_pool0 interface=mesh1 name=dhcp1

/ip dhcp-server network
add address=192.168.88.0/24 gateway=192.168.88.1

/interface mesh
add name=mesh1

/interface mesh port
add interface=ether2 mesh=mesh1
add interface=ether3 mesh=mesh1
add interface=ether4 mesh=mesh1
add interface=ether5 mesh=mesh1
add interface=wlan1 mesh=mesh1
add interface=wlan2 mesh=mesh1

/ip address
add address=192.168.88.1/24 interface=mesh1 network=192.168.88.0

/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1-public src-address=\
    192.168.88.0/24
    
Last edited by wlfz on Sat Jan 21, 2023 12:50 pm, edited 2 times in total.
 
erlinden
Forum Guru
Forum Guru
Posts: 1918
Joined: Wed Jun 12, 2013 1:59 pm
Location: Netherlands

Re: A bug in the 7.x system?

Sat Jan 21, 2023 12:35 pm

I have absolutely no idea what you mean by mesh...if both interfaces are added to the bridge (and the wireless is configured as ap-bridge) clients on wireless will receive IP address.
Can you share your config to find out why it is not working for you?
/export file=anynameyoulike

Make sure to remove personal information before posting here.
 
wlfz
just joined
Topic Author
Posts: 9
Joined: Wed Jan 27, 2010 2:22 pm

Re: A bug in the 7.x system?

Sat Jan 21, 2023 12:48 pm

I have absolutely no idea what you mean by mesh...if both interfaces are added to the bridge (and the wireless is configured as ap-bridge) clients on wireless will receive IP address.
Can you share your config to find out why it is not working for you?
/export file=anynameyoulike

Make sure to remove personal information before posting here.
Sorry, I forgot just now, I just edited the original post and added the configuration information
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: A bug in the 7.x system?

Sat Jan 21, 2023 2:03 pm

what would you need the mesh for???

you have to put the ports in a bridge, not in a mesh...

You have only one mikrotik device?
If yes, probably you don't even know what that mesh menu is for...
https://help.mikrotik.com/docs/pages/vi ... Id=8978441
 
wlfz
just joined
Topic Author
Posts: 9
Joined: Wed Jan 27, 2010 2:22 pm

Re: A bug in the 7.x system?

Sat Jan 21, 2023 3:42 pm

what would you need the mesh for???

you have to put the ports in a bridge, not in a mesh...

You have only one mikrotik device?
If yes, probably you don't even know what that mesh menu is for...
https://help.mikrotik.com/docs/pages/vi ... Id=8978441


The wired backhaul mesh network has brought me a silky seamless roaming experience.

However, in the networking mode of CAPSMAN (AP+AC), one or two data packets will be lost when switching APs.

I have several Mikrotik devices used for mesh nodes, and I only took one of them for the main routing device configuration to ask everyone for advice.

According to my above configuration, in the 6.x system version, the DHCP server on the mesh interface can normally assign IP to the wireless device, but not in the 7.x version.

If you put the port in the bridge first, and then put the bridge in the mesh interface, then no matter whether you are in the 6.x or 7.x system, the IP address cannot be assigned normally.
 
erlinden
Forum Guru
Forum Guru
Posts: 1918
Joined: Wed Jun 12, 2013 1:59 pm
Location: Netherlands

Re: A bug in the 7.x system?

Sat Jan 21, 2023 5:09 pm

Perhaps have a look at this:
https://help.mikrotik.com/docs/pages/vi ... Id=8978441

Mesh = wireless backhaul (and has absolutely nothing to do with seamless roaming).
 
wlfz
just joined
Topic Author
Posts: 9
Joined: Wed Jan 27, 2010 2:22 pm

Re: A bug in the 7.x system?

Sun Jan 22, 2023 8:19 am

Perhaps have a look at this:
https://help.mikrotik.com/docs/pages/vi ... Id=8978441

Mesh = wireless backhaul (and has absolutely nothing to do with seamless roaming).


Thank you for your reply. I have carefully read the part about HWMP+(Mesh) in the official document. In fact, my mesh network is configured according to the guidance of the official document.

I think you are right, mesh=wireless backhaul, but the mesh here is the Hybrid Wireless Mesh Protocol (HWMP), which is part of the IEEE 802.11s draft standard.

Mikrotik's HWMP+ protocol is its specific protocol, which allows the addition of ethernet to the mesh network. See the summary section of the official document:



HWMP+ is a MikroTik specific layer-2 routing protocol for wireless mesh networks. It is based on Hybrid Wireless Mesh Protocol (HWMP) from IEEE 802.11s draft standard. It can be used instead of (Rapid) Spanning Tree protocols in mesh setups to ensure loop-free optimal routing.

The HWMP+ protocol however is not compatible with HWMP from IEEE 802.11s draft standard.

Note that the distribution system you use for your network need not be a Wireless Distribution System (WDS). HWMP+ mesh routing supports not only WDS interfaces but also Ethernet interfaces inside the mesh. So you can use a simple Ethernet-based distribution system, or you can combine both WDS and Ethernet links!



Allows Ethernet interfaces to be added to the mesh network, for what if not for wired backhaul? I can't think of any other answer for now.

The "Problematic example 1: Ethernet switch inside a mesh" section in the official document is an example of a wired connection.

In fact, I have successfully configured and actually used the wired backhaul mesh network in version 6.x.

The problem encountered so far is only that in the 7.x version, the DHCP server set up on the mesh interface cannot assign IP addresses to the clients connected wirelessly, but there is no problem with the clients connected by wires.

Regarding "seamless roaming", my test method is: the wireless device uses the ping command to test the network. During the roaming process, the wireless device will not lose the test packet when switching the AP connection. In the CAPSMAN (AP+AC) mode , one or two packets will be lost.

It may not be rigorous enough, but the mesh network (HWMP+) does realize what I understand as "seamless roaming".

And because of the use of wired backhaul, there is no problem of wireless bandwidth loss in the case of WDS wireless backhaul.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11426
Joined: Thu Mar 03, 2016 10:23 pm

Re: A bug in the 7.x system?

Sun Jan 22, 2023 1:32 pm

It may not be rigorous enough, but the mesh network (HWMP+) does realize what I understand as "seamless roaming".

Mesh is about backhaul. Period.

Short explanation: if there are many wireless APs and they mostly use wireless as backhauling and each sees multiple backhaul peers (mesh members), then each AP could use many different next hops towards internet (or towards other clients of same AP mesh). Traditionally that mess would be solved using different techniques (either routing protocols or perhaps xSTP). In modern times it's easier to use HWMP to figure that out. And all of it is so that if some AP in mesh drops, backhaul routing still works (via other nodes). Ethernet is part of mesh because there might be multiple mesh nodes connected to wired backbone, hence those ethernets have to be treated the same as wireless backhaul interfaces (with regard to redundancy and path cost). Not to forget: only wireless interfaces dedicated to backhauling should be members of mesh, wireless interfaces serving normal wifi clients should not. They should be members of btidge (which bridges mesh interface and other "normal" interfaces ... ethernet interfaces might be members of bridge if they are used to connect wired devices which are not part of backhaul/backbone.

But the whole thing has nothing to do with how WiFi client roams from AP to AP. Client is normally completely unaware of how backhaul does its job, it only cares about SSID it works with. There are other "one letter standards" which are about client roaming and don't care about how participating APs are connected to backbone (those are r/k/v and ROS just started to implement them).

Other vendors that follow 802.3 standards more closely, may have implemented all of them already so one might get false idea about which "single letter standard" is about which functionality.
 
wlfz
just joined
Topic Author
Posts: 9
Joined: Wed Jan 27, 2010 2:22 pm

Re: A bug in the 7.x system?

Sun Jan 22, 2023 8:42 pm

It may not be rigorous enough, but the mesh network (HWMP+) does realize what I understand as "seamless roaming".
Mesh is about backhaul. Period.

Short explanation: if there are many wireless APs and they mostly use wireless as backhauling and each sees multiple backhaul peers (mesh members), then each AP could use many different next hops towards internet (or towards other clients of same AP mesh). Traditionally that mess would be solved using different techniques (either routing protocols or perhaps xSTP). In modern times it's easier to use HWMP to figure that out. And all of it is so that if some AP in mesh drops, backhaul routing still works (via other nodes). Ethernet is part of mesh because there might be multiple mesh nodes connected to wired backbone, hence those ethernets have to be treated the same as wireless backhaul interfaces (with regard to redundancy and path cost). Not to forget: only wireless interfaces dedicated to backhauling should be members of mesh, wireless interfaces serving normal wifi clients should not. They should be members of btidge (which bridges mesh interface and other "normal" interfaces ... ethernet interfaces might be members of bridge if they are used to connect wired devices which are not part of backhaul/backbone.

But the whole thing has nothing to do with how WiFi client roams from AP to AP. Client is normally completely unaware of how backhaul does its job, it only cares about SSID it works with. There are other "one letter standards" which are about client roaming and don't care about how participating APs are connected to backbone (those are r/k/v and ROS just started to implement them).

Other vendors that follow 802.3 standards more closely, may have implemented all of them already so one might get false idea about which "single letter standard" is about which functionality.


Thank you for your patience and detailed explanation!

The earliest I paid attention to the mesh network is precisely because each node of it only needs to be powered to work without laying network cables. Nodes can be increased or decreased at any time according to needs, which is simply too convenient! (Ignore the bandwidth loss and the ability of the wireless signal to communicate between APs to penetrate obstacles)

I noticed the "wired backhaul" of the mesh network because I saw mesh APs launched by some brand manufacturers(TP-Link, Mercury, etc.) in the market in the past two years. Their advertising copy specifically pointed out that they support "wired backhaul". The AP was originally used for the "wireless backhaul" band to free up for coverage, so I tried to implement the same function on the Mikrotik product.

I really don't have a deep understanding of the mesh network, so I have some questions I would like to ask:

Mesh network has nothing to do with "seamless roaming". I basically agree with this. I have seen it in other materials before. Whether to switch APs is actually determined by the wireless client device itself, unless the signal strength threshold is set on the AP and it is automatically disconnected. Wi-Fi connection of wireless client devices.

So, how to explain that in the same network device and environment, using the CAPSMAN (AP+AC) method, if the wireless client device moves from AP1 to AP2 without the help of Access List, it is still connected to AP1, even though the signal has been significantly attenuated . With the mesh network method, it is quite sensitive to switch APs (regardless of "wireless backhaul" or "wired backhaul"). More importantly, during the process of switching APs, no data packets were lost in the ping test. So much so that I thought that the mesh network was born to solve seamless roaming.

Also, you mentioned
only wireless interfaces dedicated to backhauling should be members of mesh, wireless interfaces serving normal wifi clients should not.

However, in the HWMPplus (Mesh) chapter of the official document, the first example adds both wlan interfaces to the mesh.

Repeat this configuration on all APs:
/interface mesh add disabled=no
/interface mesh port add interface=wlan1 mesh=mesh1
/interface mesh port add interface=wlan2 mesh=mesh1
 
 # interface used for AP interconnections
/interface wireless set wlan1 disabled=no ssid=mesh frequency=2437 band=2.4ghz-b/g/n mode=ap-bridge \
 wds-mode=static-mesh wds-default-bridge=mesh1
 
# interface used for client connections
 /interface wireless set wlan2 disabled=no ssid=mesh-clients frequency=5180 band=5ghz-a/n/ac mode=ap-bridge
 
# a static WDS interface for each AP you want to connect to
/interface wireless wds add disabled=no master-interface=wlan1 name=<;descriptive name of remote end> \
 wds-address=<;MAC address of remote end>
How should I understand this? Thanks again!
Last edited by wlfz on Mon Jan 23, 2023 10:54 am, edited 1 time in total.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11426
Joined: Thu Mar 03, 2016 10:23 pm

Re: A bug in the 7.x system?

Sun Jan 22, 2023 11:36 pm

Of those 3 standards (r/k/v) which collaborately enable smooth roaming between APs, the /k presents clients with data about APs serving same SSID and /r allows faster authentication with new AP using "Fast Basic Service Set Transition (FT)". Both need some sort of co-operation between APs and I guess using mesh functionality helps with it. If there wasn't mesh, then APs would not know about each other unless there's a wireless controller (in Mikrotik universe that's CAPsMAN and we can hope that capsman2 will implement necessary functions).
I can guess that other vendors' APs, which have mesh support, already implement r/k/v. So again, it's not mesh itself (i.e. 802.11s or some proprietary solution) which improves roaming experience, but it can help APs to properly perform roaming protocols (802.11 r/k/v).

I've no idea why should wireless interface serving normal clients be part of mesh. But if official documents say so, then it seems to be proper way.
 
wlfz
just joined
Topic Author
Posts: 9
Joined: Wed Jan 27, 2010 2:22 pm

Re: A bug in the 7.x system?

Mon Jan 23, 2023 11:14 am

Of those 3 standards (r/k/v) which collaborately enable smooth roaming between APs, the /k presents clients with data about APs serving same SSID and /r allows faster authentication with new AP using "Fast Basic Service Set Transition (FT)". Both need some sort of co-operation between APs and I guess using mesh functionality helps with it. If there wasn't mesh, then APs would not know about each other unless there's a wireless controller (in Mikrotik universe that's CAPsMAN and we can hope that capsman2 will implement necessary functions).
I can guess that other vendors' APs, which have mesh support, already implement r/k/v. So again, it's not mesh itself (i.e. 802.11s or some proprietary solution) which improves roaming experience, but it can help APs to properly perform roaming protocols (802.11 r/k/v).

I've no idea why should wireless interface serving normal clients be part of mesh. But if official documents say so, then it seems to be proper way.


By observing the mesh-FDB, I found that the wireless client device connected to Wi-Fi is identified as "direct", that is, the device "directly connected to the mesh network", which may be further understood as: the wireless client device has been Be part of a mesh network?

I figured that a wireless client device wouldn't be able to be part of a mesh network if the wireless interface that provided the connection to the wireless client wasn't added to the mesh network.

This is inconsistent with what we said that the mesh network is only used for the interconnection between APs.

Perhaps this is exactly what Mikrotik intended, so it is specifically stated in the official documentation:


The HWMP+ protocol however is not compatible with HWMP from IEEE 802.11s draft standard.


Because of this, maybe we shouldn't apply the standard mesh network concept to Mikrotik devices?

Unfortunately, more details of the HWMP+ protocol are not disclosed in the official document, and I look forward to learning more about it.

Who is online

Users browsing this forum: No registered users and 18 guests