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?

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.

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!

For 802.11r - you mentioned 'local' interfaces. Does this include those connected/generated by CAPsMan? Could you define 'local' in this case?

'Local' in this case means interfaces using radios of a single routerboard. In practice, this means that fast BSS transition is supported between the 2.4GHz and 5GHz interfaces of dual band APs.
Support for fast BSS transitions between multiple boards will be added in the future.

How often one needs a transition between the signle routerboard's 2.4 and 5GHz radios with a single device? :-)

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!

How often one needs a transition between the signle routerboard's 2.4 and 5GHz radios with a single device? :-)

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.

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 (...)

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.

It is not useful to mention all the problems that are not fixed and that are not in the changelist either (...)

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

I find it fully appropriate to have mentioned unfixed issues each release.

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.

'Local' in this case means interfaces using radios of a single routerboard. In practice, this means that fast BSS transition is supported between the 2.4GHz and 5GHz interfaces of dual band APs.
Support for fast BSS transitions between multiple boards will be added in the future.

How often one needs a transition between the signle routerboard's 2.4 and 5GHz radios with a single device?

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.

How often one needs a transition between the signle routerboard's 2.4 and 5GHz radios with a single device?

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.

I find it fully appropriate to have mentioned unfixed issues each release.

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.

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.

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 (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: 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"?

@pe1chl: About in-interface-list, you need at least 7.4beta2. More info: VRF and hidden interfaces

I have tried with 7.4rc1. Did you ever notice that interfaces in a VRF don't match with a normal interface list? Do I need a special interface list or a special way to match it?
(I would be happy when instead of an interface list I can match with a VRF, but there does not seem to be such a match)

I did another test and in short, MikroTik's latest fix/hack (select what's appropriate, I'm not sure myself) works only with in-interface but not with in-interface-list.

The problem stems from how VRF is implemented in Linux. There are dedicated VRF interfaces that real interfaces are linked to, and there's some (sort of but not completely) internal routing between them and real interfaces, at least from netfilter's perspective. So for example input doesn't happen directly from real interface, packet first goes in prerouting with in-interface=real, then again in prerouting with in-interface=vrf and then in input with in-interface=vrf (check the linked thread for more details). If it was Linux, you could allow it using in-interface=vrf. In RouterOS you can't, because this VRF interface exists, but it's not exposed to user.

In 7.4beta2 they changed it and got rid of hidden VRF interface, but only partially, it's still there, only it doesn't show as such. And for some reason it works only with in-interface and not in-interface-list. I guess it might be better if they simply exposed hidden interfaces and let us work with them. It probably doesn't solve all problems, because you wouldn't be able to match real interface within VRF. I'm not sure how that's handled in Linux.

Yes or at least allow to define an in-interface-list with a VRF as dynamic members. Then I can use that list as in-interface-list to allow traffic only from the VRF.
For now, let's keep the "manual VRF" I have been using for years, with only routing rules and copied connected routes. At least it works.
Thank you for the explanation, hopefully MikroTik read it too.