Using WifiWave2 to bridge two Audience wirelessly, thoughts? == 4-address mode

RouterOS RouterOS beta
1

Trying the wifiwave2 package on the Audience using v7.1rc6. My goal was to bridge two Audience devices using the 3rd 5Ghz “mesh” interface of the devices, while using newer wireless package on the “client” Wi-Fi interfaces. Basically want to test just bridging one LAN between the two units wireless; with the non-mesh Wi-Fi also just bridged to same LAN. Ideally being able to use VRRP on the bridge, so either LTE interface could provide internet if separated. This is obviously possible using standard Wi-Fi package, but was trying to see if possible someway using wifiwave2.

At the start, I actually though this be straightforward: set “station-pseudobridge” mode on “mesh” wi-fi interface on one of the Audiences, and I’d be done. Assuming all interfaces are just bridged on both units. But there is only “station” mode in wifiwave2, so not so simple. Certainly using ap on one, station on another does just connect. But the “mesh” wifi interface are ports of the bridge interface, the ONLY traffic that passes are the “Neighbors”/CDP broadcast but ARP goes unanswered so anything IP fails. Changing the ARP mode of the “mesh” wifi interface had no effects – tried them all (proxy-arp, local-proxy-arp, enabled, & disabled even) , in all combos on both sides, just in case. I would have though at least the far end of the wifi link would work, but if the connected router does not respond to requires for it’s own IP. Basically it seems once a wifiwave2 “station” goes into a bridge, ARP doesn’t work, at all.

Removing the “mesh” wifi interface from the bridge, assigning IPs and routing between the two Audience does work - so the “station” to “ap” does seem to work at 802.11-level. But my goal is bridge ONE L2 LAN between the two units, not just have them do L3 routing between them.

Not detoured, and curious to see if there was at least someway to make this work. My next idea was to use a EoIP tunnel (sorta like DTLS tunnels used CAPsMAN) over the non-bridge “mesh” interface, then add the EoIP tunnel to the bridge. This does in fact work, but obviously MTU is squashed. I ran into another issue with wifiwave2 in that it seemingly doesn’t allow the MTU to be changed (or perhaps the UI/CLI doesn’t correctly reflect the change) – for my testing, I just changed the EoIP tunnel to 1500 MTU.

Obviously the EoIP tunnel isn’t ideal and I suspect I’ve run into bugs/limits of the wifiwave2 package. So perhaps this is just a feature request for “station-pseudobridge” in wifiwave2 package.

Be also curious if I’m missing something/someway to bridge between two Audience using wifiwave2, to eventually eat some CAKE :wink:.

I’ll post the configuration, but basically I think there are still some bugs/missing things in wifiwave2…

The “Hub” Audience (e.g. “wifi” mesh interface is in AP mode):

# nov/14/2021 10:31:11 by RouterOS 7.1rc6
# software id = AC0K-0Z8R
# model = RBD25GR-5HPacQD2HPnD
/interface bridge
add name=bridge1
/interface lte
# SIM not present
set [ find ] allow-roaming=no name=lte1
/interface eoip
add comment="tunnel using non-bridged \"mesh\" wifi interface to another Audie\
    nce in station mode, so bridge1 is connect between an in-range peer" \
    local-address=192.168.71.1 mac-address=02:23:06:EB:8C:53 mtu=1500 name=\
    eoip-wifimesh remote-address=192.168.71.72 tunnel-id=71
/interface vrrp
add comment="use VRRP on bridge1 so only one default route for \"mesh bridge\"\
    \_(if peer cannot connect or is off, each unit still operates independentl\
    y)" interface=bridge1 name=vrrp-bridge1 priority=99
/interface list
add name=WAN
add name=LAN
/interface wifiwave2 security
add authentication-types=wpa2-psk,wpa3-psk disable-pmkid=yes name=mobileskyfi
add authentication-types=wpa2-psk,wpa3-psk disable-pmkid=yes name=noproblem
add authentication-types=wpa2-psk,wpa3-psk disable-pmkid=yes name=ztsecure
/interface wifiwave2 configuration
add channel.skip-dfs-channels=all .width=20mhz country="United States3" name=\
    M171 security=mobileskyfi ssid=M171
add channel.skip-dfs-channels=all country="United States3" name=SkyTower \
    security=noproblem ssid=SkyTower
add channel.skip-dfs-channels=all country="United States3" hide-ssid=yes \
    name=SkyBridge security=ztsecure ssid=SkyBridge+SkyTower
/interface wifiwave2
set [ find default-name=wifi1 ] configuration=M171 configuration.mode=ap \
    disabled=no name=wifi-2.4Ghz
set [ find default-name=wifi2 ] configuration=SkyTower configuration.mode=ap \
    disabled=no name=wifi-5Ghz
set [ find default-name=wifi3 ] arp-timeout=30s configuration=SkyBridge \
    configuration.mode=ap disabled=no l2mtu=1600 mtu=1550 name=wifi-MeshAP
/ip pool
add name=dhcp ranges=192.168.0.201-192.168.0.249
add name=dhcp_pool1 ranges=192.168.71.201-192.168.71.249
/ip dhcp-server
add address-pool=dhcp interface=vrrp-bridge1 lease-time=1h name=dhcp1
add address-pool=dhcp_pool1 interface=wifi-MeshAP name=dhcp2
/port
set 0 name=usb1
/interface ppp-client
add apn=internet name=ppp-out1 port=usb1
/zerotier
set zt1 comment="ZeroTier Central controller - https://my.zerotier.com/" \
    identity="xxx" name=zt1 \
    port=9993
/zerotier interface
add instance=zt1 mac-address=2E:D1:09:E9:A3:35 name=zerotier1 network=\
   xxx
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=wifi-2.4Ghz
add bridge=bridge1 interface=wifi-5Ghz
add bridge=bridge1 interface=eoip-wifimesh
/ipv6 settings
set disable-ipv6=yes
/interface list member
add interface=lte1 list=WAN
add interface=ether1 list=LAN
add interface=ether2 list=LAN
add interface=wifi-2.4Ghz list=LAN
add interface=wifi-MeshAP list=LAN
add interface=wifi-5Ghz list=LAN
add interface=bridge1 list=LAN
add interface=vrrp-bridge1 list=LAN
add interface=eoip-wifimesh list=LAN
add interface=ppp-out1 list=WAN
add interface=zerotier1 list=LAN
/ip address
add address=192.168.0.71/24 interface=bridge1 network=192.168.0.0
add address=192.168.0.1 interface=vrrp-bridge1 network=192.168.0.1
add address=192.168.71.1/24 interface=wifi-MeshAP network=192.168.71.0
/ip cloud
set ddns-enabled=yes
/ip dhcp-server lease
add address=192.168.71.72 client-id=1:c4:ad:34:86:57:ae comment=\
    "for M172-Rizi station (routing & EoIP need fixed IP address)" \
    mac-address=C4:AD:34:86:57:AE server=dhcp2
/ip dhcp-server network
add address=192.168.0.0/24 comment="bridge1 LAN (via VRRP)" dns-server=\
    208.67.222.222,8.8.4.4 gateway=192.168.0.1 netmask=24
add address=192.168.71.0/24 comment=\
    "PtMP Hub network for using \"mesh\" wifi interface without bridging" \
    dns-server=208.67.222.222,8.8.4.4 gateway=192.168.71.1
/ip dns
set servers=208.67.222.222,8.8.4.4
/ip firewall filter
add action=accept chain=forward comment="allow zerotier" in-interface=\
    zerotier1
add action=accept chain=input comment="allow zerotier" in-interface=zerotier1
add action=accept chain=input protocol=icmp
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=accept chain=input comment="always allow winbox" connection-state=\
    related dst-port=8291 protocol=tcp
add action=drop chain=input in-interface-list=!LAN
add action=drop chain=forward comment=\
    "invalid connections should not go out to LTE" connection-state=invalid \
    log=yes log-prefix=lteinvalid out-interface=lte1
add action=drop chain=output comment=\
    "invalid connections should not go out to LTE" connection-state=invalid \
    log=yes log-prefix=lteinvalid out-interface=lte1
/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN
/ip packing
add disabled=yes interface=eoip-wifimesh packing=compress-all unpacking=\
    compress-all
/ip route
add check-gateway=ping comment=\
    "static route to M172-Rizi \"station\" in \"mesh\" wifi" disabled=no \
    distance=12 dst-address=0.0.0.0/0 gateway=192.168.71.72 pref-src="" \
    routing-table=main scope=30 suppress-hw-offload=no target-scope=10
/ip service
set telnet disabled=yes
set ftp disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/ip upnp
set enabled=yes
/ip upnp interfaces
add interface=bridge1 type=internal
add interface=lte1 type=external
/system clock
set time-zone-name=America/Los_Angeles
/system identity
set name=M171-Yizi
/system logging
add topics=debug
/system routerboard settings
set auto-upgrade=yes cpu-frequency=auto
/tool graphing interface
add
/tool netwatch
add down-script=\
    ":log warn \"netwatch ping over local mesh NOT responding within 100ms\"" \
    host=192.168.71.72 interval=1s timeout=100ms up-script=\
    ":log info \"netwatch ping over local mesh responding within 100ms\""
add down-script=\
    ":log info \"netwatch ping to Google NOT responding within 250ms\"" host=\
    8.8.8.8 interval=1s timeout=250ms up-script=\
    ":log debug \"netwatch ping to Google responding within 250ms\""
add down-script=\
    ":log error \"netwatch ping to Google NOT responding within 500ms\"" \
    host=8.8.8.8 interval=1s timeout=500ms up-script=\
    ":log info \"netwatch ping to Google responding within 500ms\""
/tool sms
set port=lte1 receive-enabled=yes
/tool sniffer
set file-limit=10000KiB file-name=wifi-m171.pcap filter-interface=wifi-MeshAP

The “Station” Audience (e.g. “wifi” mesh interface is in Station mode):

# nov/14/2021 10:30:48 by RouterOS 7.1rc6
# software id = 8QEA-KKXK
# model = RBD25GR-5HPacQD2HPnD

/interface bridge
add name=bridge1
/interface lte
set [ find ] allow-roaming=no band="" mtu=1480 name=lte1
/interface eoip
add comment="tunnel using non-bridged \"mesh\" wifi interface to another Audie\
    nce in AP mode, so bridge1 is connect between an in-range peer" \
    local-address=192.168.71.72 mac-address=02:B4:CF:BA:59:9F mtu=1500 name=\
    eoip-wifimesh remote-address=192.168.71.1 tunnel-id=71
/interface vrrp
add comment="use VRRP on bridge1 so only one default route for \"mesh bridge\"\
    \_(if peer cannot connect or is off, each unit still operates independentl\
    y)" interface=bridge1 name=vrrp-bridge1
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface lte apn
set [ find default=yes ] apn=broadband ip-type=ipv4 use-peer-dns=no
/interface wifiwave2 security
add authentication-types=wpa2-psk,wpa3-psk disable-pmkid=yes name=mobileskyfi
add authentication-types=wpa2-psk,wpa3-psk disable-pmkid=yes name=noproblem
add authentication-types=wpa2-psk,wpa3-psk disable-pmkid=yes name=ztsecure
/interface wifiwave2 configuration
add channel.skip-dfs-channels=all country="United States3" name=SkyTower \
    security=noproblem ssid=SkyTower
add channel.skip-dfs-channels=all country="United States3" hide-ssid=yes \
    name=SkyBridge security=ztsecure ssid=SkyBridge+SkyTower
add channel.skip-dfs-channels=all .width=20mhz country="United States3" name=\
    M172 security=mobileskyfi ssid=M172
/interface wifiwave2
set [ find default-name=wifi1 ] configuration=M172 configuration.mode=ap \
    disabled=no name=wifi-2.4Ghz
set [ find default-name=wifi2 ] configuration=SkyTower configuration.mode=ap \
    disabled=no name=wifi-5Ghz
set [ find default-name=wifi3 ] arp-timeout=30s configuration=SkyBridge \
    configuration.mode=station disabled=no l2mtu=1600 mtu=1550 name=\
    wifi-MeshStation
/ip pool
add name=dhcp ranges=192.168.0.201-192.168.0.249
/ip dhcp-server
add address-pool=dhcp interface=vrrp-bridge1 lease-time=1h name=dhcp1
/routing table
add fib name=""
/user group
set full policy="local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,pas\
    sword,web,sniff,sensitive,api,romon,dude,tikapp,rest-api"
/zerotier
set zt1 comment="ZeroTier Central controller - https://my.zerotier.com/" \
    identity="xxx" name=zt1 \
    port=9993
/zerotier interface
add instance=zt1 mac-address=2E:28:C3:96:80:D3 name=zerotier1 network=\
    xxx
/interface bridge port
add bridge=bridge1 comment=defconf ingress-filtering=no interface=ether2
add bridge=bridge1 comment=defconf ingress-filtering=no interface=wifi-2.4Ghz
add bridge=bridge1 comment=defconf ingress-filtering=no interface=wifi-5Ghz
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=eoip-wifimesh
/ip neighbor discovery-settings
set discover-interface-list=LAN
/ipv6 settings
set disable-ipv6=yes
/interface list member
add interface=bridge1 list=LAN
add interface=lte1 list=WAN
add interface=ether1 list=LAN
add interface=ether2 list=LAN
add interface=wifi-2.4Ghz list=LAN
add interface=wifi-MeshStation list=LAN
add interface=wifi-5Ghz list=LAN
add interface=vrrp-bridge1 list=LAN
add interface=eoip-wifimesh list=LAN
add interface=zerotier1 list=LAN
/ip address
add address=192.168.0.72/24 interface=bridge1 network=192.168.0.0
add address=192.168.0.1 interface=vrrp-bridge1 network=192.168.0.1
/ip cloud
set ddns-enabled=yes
/ip dhcp-client
add comment=\
    "PtMP Station for \"mesh\" wifi interface (obtain IP from \"hub\" AP)" \
    default-route-distance=21 interface=wifi-MeshStation use-peer-dns=no \
    use-peer-ntp=no
/ip dhcp-server network
add address=192.168.0.0/24 comment="bridge1 LAN (via VRRP)" dns-server=\
    208.67.222.222,8.8.4.4 gateway=192.168.0.1 netmask=24
/ip dns
set servers=208.67.222.222,8.8.4.4
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=forward comment="allow zerotier" in-interface=\
    zerotier1
add action=accept chain=input comment="allow zerotier" in-interface=zerotier1
add action=accept chain=input protocol=icmp
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=accept chain=input comment="always allow winbox" dst-port=8291 \
    protocol=tcp
add action=drop chain=input in-interface-list=!LAN
add action=drop chain=forward comment=\
    "invalid connections should not go out to LTE" connection-state=invalid \
    log=yes log-prefix=lteinvalid out-interface=lte1
add action=drop chain=output comment=\
    "invalid connections should not go out to LTE" connection-state=invalid \
    log=yes log-prefix=lteinvalid out-interface=lte1
/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN
/ip packing
add disabled=yes interface=eoip-wifimesh packing=compress-all unpacking=\
    compress-all
/ip route
add check-gateway=ping comment="static route to \"hub\" for internet routing, \
    used if local LTE interface is down" disabled=no distance=15 dst-address=\
    0.0.0.0/0 gateway=192.168.0.71 pref-src="" routing-table=main scope=30 \
    suppress-hw-offload=no target-scope=10
/ip service
set telnet disabled=yes
set ftp disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/ip upnp
set enabled=yes
/ip upnp interfaces
add interface=bridge1 type=internal
add interface=lte1 type=external
/system clock
set time-zone-name=America/Los_Angeles
/system identity
set name=M172-Rizi
/system logging
add topics=debug
/system package update
set channel=development
/system routerboard settings
set auto-upgrade=yes cpu-frequency=auto
/tool graphing interface
add
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
/tool netwatch
add down-script=\
    ":log warn \"netwatch ping over local mesh NOT responding within 100ms\"" \
    host=192.168.71.1 interval=1s timeout=100ms up-script=\
    ":log info \"netwatch ping over local mesh responding within 100ms\""
add down-script=\
    ":log info \"netwatch ping to Google NOT responding within 250ms\"" host=\
    8.8.8.8 interval=1s timeout=250ms up-script=\
    ":log debug \"netwatch ping to Google responding within 250ms\""
add down-script=\
    ":log error \"netwatch ping to Google NOT responding within 500ms\"" \
    host=8.8.8.8 interval=1s timeout=500ms up-script=\
    ":log info \"netwatch ping to Google responding within 500ms\""
/tool sms
set port=lte1 receive-enabled=yes
/tool sniffer
set file-limit=10000KiB file-name=wifi-m172.pcap filter-interface=\
    wifi-MeshStation

Couple side notes:

  1. The MTU docs don’t specifically mention the Audience: https://help.mikrotik.com/docs/display/ROS/MTU+in+RouterOS
  2. Out of curiosity, I’m not sure ip/packing does anything in v7.1rc6 - though it be radically different way to clamp L2 MTU and/or reduce packet sizes, curious at CPU/latency for the compression on something more powerful like the Audience. But didn’t seem to work, even though the interfaces I tried were all “neighbors”.
2

I don’t have wifiwave2 device so I can’t check if there’s really no station-bridge mode. You should avoid station-pseudobridge. For 2 nodes using mesh is overkill.

Best improvization I can think of is EoIP tunnel over the wifi connection using the IPs you have assigned to the interfaces. Just be mindful that EoIP + parallel IP path may cause weird effects, maybe you want to filter all IP traffic between the station and the AP and leave only the EoIP one.

3




Well, I was kinda hoping I just might be able to drop the wi-fi interface on both sides into the bridge, and have ROS “do the right thing” (e.g. infer some wifi bridging mode) based on the “station” being a bridge port member – no such luck. But @gdanov station-bridge is closer to what I was expecting exist in wifiwave2.



That’s a very fair concern - hadn’t dissected the packet flow diagram. But my bigger concern is I’m not sure the wifiwave2 MTU can go above 1500. This is a problem since any tunnel has overhead, with EoIP +42. Since so for the “wireless bridge” between the two Audience units to avoid fragmenting/cramping-MSS, the wifiwave2 interfaces needs >1542 MTU.

The photo above shows my concern, which appears to a bug in v7.1rc6 – winbox shows the “Actual MTU” as “1500”. But I can’t find “actual-mtu” in the CLI, so hard to know if just a “winbox things”…

But since I also tried using a VxLAN approach, instead of EoIP, it also thinks the MTU of the wavewifi2 interface is 1500, so it limits the VxLAN MTU to 1450. The following CLI snippet shows my MTU concerns, since EoIP would need a higher L2MTU (>1542) over the “wifi bridge” to avoid reducing MTU on either side:

[skyfi@M172-Rizi] /interface/vxlan> export
# nov/17/2021 17:43:05 by RouterOS 7.1rc6
# model = RBD25GR-5HPacQD2HPnD
/interface vxlan
add group=239.11.37.100 interface=wifi-MeshStation mtu=1450 name=\
    vxlan-skybridge port=8472 vni=100
[skyfi@M172-Rizi] /interface/vxlan> print detail 
Flags: X - disabled, R - running 
 0 R name="vxlan-skybridge" mtu=1450 mac-address=EA:D5:A5:1A:C5:73 arp=enabled 
     arp-timeout=auto loop-protect=default loop-protect-status=off 
     loop-protect-send-interval=5s loop-protect-disable-time=5m vni=100 
     group=239.11.37.100 interface=wifi-MeshStation port=8472 
[skyfi@M172-Rizi] /interface/vxlan> set 0 mtu=1500
failure: could not set mtu
[skyfi@M172-Rizi] /interface/vxlan> set 0 mtu=1451
failure: could not set mtu
[skyfi@M172-Rizi] /interface/vxlan> set 0 mtu=1449
[skyfi@M172-Rizi] /interface/vxlan> set 0 mtu=1450

Now so far the EoIP tunnel over WifiWave2 does seem to work & seems stable from logs. In fact, since only one has an active LTE connection to internet, the 2nd audience needs to wireless link to get to the internet. I’ve also had ZeroTier enabled on both Audience in my testing here, that seems to be work the few times I tried from my Mac over the internet (with ZeroTier Mac client connected to same ZT network).

But the MTU issue is my first concern – but what’s going with the [un]packing of the EoIP tunnel in the bridge is worth more look too. Basically, I think there are still some bugs in WifiWave2…

4

They need to add “four address frame support” into wifiwave2 before it will support bridging.

5

No doubt, seemingly why only “station” is supported - more testing to find these things out :wink:.

But the MTU should be settable >1500 since 802.11 MTU is >2000. In my use case, being able to trunk VLANs over EoIP (or using a set of VXLANs to carry individual VLAN using Bridge “VLAN Filtering”) to tunnel inside a ap-to-station wi-fi link isn’t necessarily the worst approach – it’s just I rather not have the MTU compressed/fragmented by the tunnel, especially since 802.11 has a higher possible MTU than being allowed by the wavewifi2 package.

6

oh, obvious reason.

7

This can’t come soon enough.. I invested in 3 audiences and regretted it since.
Cannot get more than around 160Mbps between them even if they are in the same room!

8

Is it feasible to use MPLS/VPLS for better performance than EoIP? It is often done in PtP to have higher speed.
MPLS/VPLS needs a larger MTU, or the inner MTU should be reduced accordingly. (A smaller MTU, leading to smaller MSS, does not lead to fragmentation and is not so bad for performance).

http://forum.mikrotik.com/t/mpls-vpls-or-eoip/31769/1

Dutch video: https://www.wirelessinfo.be/mikrotik-point-to-point-link-eoip-vs-mpls/

Just thoughts !

9

MPLS+VPLS, now that’s cleaver for a PtP link. Didn’t try, but had a wacky idea to use IP>Packing to further reduce IP headers with EoIP but wasn’t that crazy.

I have a couple of Audience that we don’t use since the cell antennas aren’t that great. I’ve been using them to testing WW2 etc in V7. Basically bridging them without WDS/four-addresses I took as a Mikrotik puzzle. Since wireless bridging audience isn’t a critical use case, was kinda looking more looking for thoughts on the problem since it was kinda curious what to could be done without WDS.

But the Dutch article/video was interesting (Google’s English version). I’d have refresh my memory about MPLS etc. too – but will try at some point.

But yeah the MTU problem makes it more challenging, as the Dutch MPLS+VPLS PtP article points out:

MTU must be adjusted at MPLS / VPLS configuration to avoid fragmentation.
When the Mikrotik SXT encapsulates the Ethernet frame to send over VPLS pseudowire, it checks if the packet size + VPLS CW + MPLS tags exceed the MPLS MTU of the outgoing interface. If so, VPLS will fragment the frame. In this example, 1514 byte layer2 packets are forwarded over VPLS, router adds CW (4 bytes) and one MPLS tag (4 bytes). To avoid fragmentation, the MPLS MTU should be increased to 1522

It’s the current WW2 limit of 1500 MTU throws a wrench in either EoIP or MPLS (or even VXLAN): the network-wide MTU still have to lower than 1500 (e.g. 1478 it seems with MPLS+VPLS).

I did report the MTU being limited to 1500 as a bug. Wi-Fi MTU is certainly complex, but I know it’s always >1500 & so even with the saving from MPLS, it’s still more than 1500 limit in WW2 today. The case is still open, so I’ve taken it that it’s in queue to be fixed. As I said, this isn’t critical for me, and imagine other bugs lurking WW2. Now WDS, that seem like a missing feature, so hard to know when that will come.

But MPLS was an idea I’d missed here, specifically VPLS I hadn’t thought about.

10

Maybe some more protocols to explore, besides EoIP and VPLS

BCP, will split the packet over multiple PPTP channels to create a bigger MRRU to allow for the full MTU ? : https://wiki.mikrotik.com/wiki/Manual:BCP_bridging_(PPP_tunnel_bridging)

When bridging packets PPP tunnel need to pass packets with Layer-2 (MAC) header included , so default interface MTU (in case of pptp it is 1460) is not sufficient for this task. To ensure proper operation itbis suggested to override the value by specifying MRRU option in server settings to a higher value.

MRRU allows to enable multi-link support over single link, it divides the packet to multiple channels therefore increasing possible MTU and MRU (up to 65535 bytes)

.
VXLAN: yet another protocol ? https://help.mikrotik.com/docs/display/ROS/VXLAN (ROS 7.1)

11

I use VPLS and EoIP and BCP and VXLAN all the time. All are overcomplicated for this scenario and not suitable workarounds for that reason. We need four address mode support.

12

Don’t disagree, but right now the bigger bug is MTU being limited to 1500 on the wifiwave2.

@mducharme, when you say “four address mode”, to me that’s just the 802.11 data structure used to carry the add’l MACs – how it should be used is a better question in V7. V6 used it a few different ways however… Are you advocating for “station pseudo-bridge”, or standard WDS, or maybe HWMP+?

Personally I’d prefer Wi-Fi 6 support, which isn’t possible on the Audience. Which is kind why I’d rather see Mikrotik spend some time to think about new/better/cleaner ways of wireless bridging until they come out with 802.11AX hardware…

13

WDS at the very least, if not station-bridge.

station-pseudobridge I don’t believe uses four address mode at all. It only supports bridging one MAC and my understanding is that it is just simulated bridging.

14

Yup. I’m hopeful, something, will come soon. Not an expert on the driver/kernel stuff but imagine WDS is covered by Linux stuff - they’d may just need to add the UI. I’m guessing what ever bug is causing the MTU may be standing in the way.

i ask since personally , I’m not sure all the V6 options aren’t need - the mesh vs WDS, pseudo vs regular, etc seems like too many modes. I always have to go back to wiki/help every time to recall which mode does what :wink:

15

wiki/help every time to recall which mode does what

Don’t think you have a problem with these modes … :slight_smile: (not wifiwave2)

“AP -bridge” (bridge function (4-address) can be disabled, WDS function is included), “bridge” is the level 3 single connection version of AP-bridge
“Station - bridge” the only real station setting. “Station” can be used to not request the bridge (4-address) function from the AP.

Normally that’s all one needs. Bridge (4-address) function is great for PtP and PtMP wifi links between MT devices.

WDS is not needed for 4-address connections between MT.
WDS with “station-WDS” as WDS client, or “WDS slave” as WDS client+AP function.

Pseudobridge is a MAT (MAC address translation) L2.5 bridge. Has a mapping table for multiple IPv4 addresses for one receiving MAC (wifi is 3-address, MAT expands to multiple IPv4 clients)
(MT DHCP usually has problems with this). Is one-way for setting up connectios, because the table has to be built Not recommended. Is a typical function in non-MT “repeater” cases.

Waiting for 4-address bridge function in wifiwave2, or it is not suitable for PtP/PtMP.

16

WDS works with other vendors with 4 address mode though, if you make it an open AP without security. In some cases this can be a reasonable compromise even for PTP across vendors (ex. where you are encrypting everything over the link through some other means like IPsec anyway). It is the only way to get true bridging between MikroTik and non-MikroTik devices. I’ve used this where I have had to do a phased migration from third party radios to MikroTik. Obviously when WPA2 is involved WDS bridging only works between devices of the same vendor. station-bridge is preferable from MikroTik to MikroTik though, probably slightly more efficient than WDS.

17

I haven’t seen it mentioned in the change logs, but I’m assuming we still don’t have 4 address/bridging available in the Wave2 drivers?

18

You are right, 4-address mode is still not available with wifiwave2 drivers.

19

4-address mode must be a very low priority.

Three months later, and not a peep about it.

20

Long enough that I don’t even have the test setup anymore. :wink:

My business partner took one as a travel router, and a customer has been borrowing one for months. The Audience is a nice device and the WifiWave2 has worked flawless as a single AP, which why I don’t have them back :wink:. Have a few wAPac’s but worthless for testing WW2. Been waiting for newer"ax" devices for a while…

But anyone know if the MTU issue been fixed? It was limited to 1500, when I last tested it.