Nothing mentioned about fixing the container issue with new mounts directories not being created.. I guess we need to wait for 7.4beta6 for more container fixes then?
This is 7.4rc, you can not go back to beta, maybe rc2 if enough broken stuff is reported.
The problem with container mounts persists. They are not created at container startup time.
It is not useful to mention all the problems that are not fixed and that are not in the changelist either.
I do not mention every time that @#$^$@ BFD is still not implemented either!
How often one needs a transition between the signle routerboard’s 2.4 and 5GHz radios with a single device? 
In case of a single device it might be usefull. But hey…small steps towards better Wifi experience!
This is a big deal if you’re on a phone or video call in an area where the phone prefers WiFi vs. LTE. Without it, the device will hang on to the AP as long as it can and quality will suffer.
For example, if you’re walking around in a large space (office, large home, back yard, warehouse), due to distance or obstructions like walls and furniture, you’re likely to walk in and out of the 5GHz radio’s range multiple times during a call but still be within decent 2.4GHz range.
Once per version at least until acknowledged. It’s useful because the dev team may not have been able to reproduce an issue, it may not be in an internal issue tracker, it may be a blind spot and it may be related to other issues.
Alternatively, if Mikrotik doesn’t want repeat posts for persistent bugs on subsequent versions they could provide a public facing bug tracker, but frankly that’s a whole other can of worms.
Hi
I find it fully appropriate to have mentioned unfixed issues each release. As there is no public issue tracker , it´s nice to have this information without the need of going over every post about every release. Also useful to have some people reporting the success (or problems) during the updates. Especially, because I had to use netinstall a few times recently.
In this sense I had no problems upgrading (7.4 beta2 > 7.4rc1) my hAP mini, RB5009 and CRS305 and did not encounter any issues since then. (just using basic stuff, switching, vlans, static routes, firewall in a lab).
BR
W
There is no need to do so!
Issues mentioned here on the forum will not be added to the internal issue tracker and will not be fixed unless you (or someone else) explicitly creates an issue in the tracker.
Discussions here are just for mutual information and entertainment, MikroTik does not pickup issues from here unless there is a concerned developer who reads here that his recent changes have caused problems and takes the responsibility to fix it.
MikroTik employees have repeatedly confirmed the above and have repeatedly stated “this issue was never reported” for issues that were discussed in-depth in the release topic.
If your 5GHz interface is on DFS channel than your device can connect to the 2GHz radio while the scanning is checking the channel and after that switch to 5GHz radio for better speed.
Typically 2GHz radios have slightly higher Tx power (if permitted) than 5GHz radios, pathloss (both free atmosphere and penetration loss through obstacles, such as walls and ceilings) of 2GHz is lower than of 5GHz. Which means that if Tx powers are not highly hand-optimized, 2GHz signal will have farther reach. Device closing towards AP will thus likely first connect to 2GHz cell and later re-select to 5GHz.
Hi,
thanks, I know this, but I still like to read what current issues I might face with each release. I appreciate if someone has tested something and either confirms something is working or sthg is still broken.
MT will have an internal issue tracker, but we don´t have this luxury. So: best way to be informed is reading the forums. I don´t want to re-read old conversations every time, so warnings about bugs in current releases work with me.
Anyway: the discussion on the beta releases is growing way too long, so I guess moving some of the messages away is OK.
W
Dear mikrotik (or forum mainteners)
Please create a new topic with each release
in topic for 7.2beta2 we have anouncements posts lost in the middle of the tread
in the v.1rc3 docker post if has been asked to “keep” posting on this topic even if the docker support re-introduced in later versions is very different !
this create a lot of confusion: stale info in the first posts, lack of visibility of new versions …
or maybe “they” want to be invited in “guiness book or records” for the longest thread in the world 
Now that v7.4rc1 adds more VRF support, I consider changing my setup from “multiple route tables with route rules” to VRF.
I want to use this for an overlay network that now uses a second route table (populated by BGP) and it has several tunnels for traffic in that network (GRE, GRE/IPsec, L2TP/IPsec) and also direct links on ethernet ports.
I currently have a route rule table that has several rules matching on interface, plus a rule that matches on the local router address as source address (for the services).
Now the first question I hit before even starting to reconfigure everything is: what will happen when I put a tunnel interface in a VRF? I presumed the tunnel itself would become part of the VRF, but the “outside” would remain in the main VRF. However, reading through old postings it appears that is not true, and a tunnel cannot be part of a VRF, you need to use route marking to steer the traffic in such cases. That would make the entire operation useless.
Is this still true in v7? As an experiment I tried if GRE tunnels accept the @vrf construct for their tunnel peer addresses, and it appears they don’t.
Does anyone have experience with such config (where the inside of tunnels is part of a specific VRF and the outside is in another VRF, in my case just the main VRF)?
It is a perfectly valid setup when an interface (including tunnel interfaces) is a part of the VRF, but the tunnel session is in the main table.
Not sure what you mean by “GRE tunnels accept the @vrf”, if you mean to establish GRE session on the VRF then currently it is not supported.
Ok, so it should be possible to have the tunnel endpoint in the VRF and the outside tunnel packets in the “main” VRF.
I was worried that putting a tunnel in a VRF would put EVERYTHING in the VRF and I would need to explicitly indicate that I want my tunnel traffic @main.
(I do not need tunnel traffic inside the VRF. so that seems to match the current implementation)
Well, that did not go as planned… while it seems that the GRE tunnel works with VRF, there are other issues:
- BGP template is marked “Invalid”, no idea why
/routing bgp template
add as=4220406101 disabled=no input.affinity=remote-as name=hamnet \
output.affinity=remote-as .network=bgp-networks router-id=44.137.41.110 \
routing-table=hamnet vrf=hamnet
(I added vrf=hamnet, it did not have that before)
After a reboot it is in black (not invalid) but when I open and OK it, it again becomes invalid.
- There appears to be a firewall issue as well. I have a firewall rule for input:
add action=accept chain=input comment=BGP dst-port=179 in-interface-list=\
hamnet protocol=tcp src-address=44.137.60.0/22
The interface-list hamnet contains the required interfaces, same set as now is in the VRF. But the rule does not match.
When I remove the in-interface-list check it works and the BGP connection comes up. But when I re-add it, it again fails.
Is in interface-list invalid when part of a VRF? What has to be changed to allow such a list?
@pe1chl: About in-interface-list, you need at least 7.4beta2. More info: VRF and hidden interfaces
Maybe I’ve misunderstood things but has this functionality changed between “7.4beta2” (or earlier) and “v7.4rc1”?