I'd been having trouble with big dropouts on a non-line-of-sight wireless link using a 917Mhz transciever board with a pair of RB411s. I switched the protocol from nstreme to NV2 protocol and the problems just went away! Remarkable! Got close to no packet loss now. 802.11 was even worse than nstreme...
I have a wireless link between two buildings comprised of two RB411s (5.5, firmware 2.29), set up like in http://wiki.mikrotik.com/wiki/Transparently_Bridge_two_Networks The internet gateway is a dd-wrt router with QoS enabled for SIP and RTP. VOIP works consistently well when there is no other netw...
I have a wireless link between two sites using RB411s that is working well, but voip traffic over it degrades badly with other traffic on the link...I'm trying to configure QoS with it. On the far side of the link, wlan1 is the WAN. On the near side of the link, ether1 is the WAN. Snooping reveals t...
Am I missing something? My suspicions were correct... there were NO PACKETS whatsoever appearing in the forward chain even though the device was working forwarding packets. The reason was that I'm using the device in bridge mode, and if you in winbox go into the bridge and click settings, "Use...
1.) A queue tree on WLAN1 will only affect the download side of the traffic for starters (assuming that is your LAN side of the router). You'll need another queue tree on the WAN interface to get upload traffic as well. The scenario here is I have a wireless link between two sites. The wlan interfa...
What are you trying to achieve with this setup? All I am trying to do here is to successfully mark all incoming and outgoing packets to 117.53.171.171, and I would have thought that the packet counts would appear in the queue tree visible in winbox. My ultimate goal is to prioritise VOIP[SIP/RTP] t...
In the situation where the following simple rules are in place (and wlan1 is the WAN connection to the internet via RB411): /ip firewall mangle add action=mark-packet chain=postrouting disabled=no dst-address=117.53.171.171 new-packet-mark="special" passthrough=no /ip firewall mangle add a...
Try changing the chain to prerouting and check again. The sniffer might be grabbing them before postrouting. As you suggested, I tried the following: /ip firewall mangle add action=change-dscp chain=prerouting comment=("dscp_46_eth_port_range_1") disabled=no protocol=udp dst-port=16400-16...
I'm trying to use mangle to change the dscp value for packets bound for a certain port range, as follows: /ip firewall mangle add action=change-dscp chain=postrouting comment=("dscp_46_eth_port_range_1") disabled=no protocol=udp dst-port=16400-16405 new-dscp=46 Should the above work? Now I...