Community discussions

MikroTik App
 
fragtion
Member Candidate
Member Candidate
Topic Author
Posts: 257
Joined: Fri Nov 13, 2009 10:08 pm
Location: Johannesburg, South Africa

Not strictly related to: v7.4rc1 is released!

Tue Jul 05, 2022 4:08 pm

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?
 
hecatae
Member Candidate
Member Candidate
Posts: 244
Joined: Thu May 21, 2020 2:34 pm

Re: v7.4rc1 is released!

Wed Jul 06, 2022 12:35 am

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.
 
daaf
just joined
Posts: 11
Joined: Sun Jan 12, 2020 4:39 am

Re: v7.4rc1 is released!

Wed Jul 06, 2022 9:29 am

The problem with container mounts persists. They are not created at container startup time.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10183
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.4rc1 is released!

Wed Jul 06, 2022 10:55 am

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!
 
User avatar
pekr
Member Candidate
Member Candidate
Posts: 169
Joined: Tue Feb 22, 2005 9:05 pm
Location: Czech Republic
Contact:

Re: v7.4rc1 is released!

Wed Jul 06, 2022 12:58 pm

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? :-)
 
erlinden
Forum Guru
Forum Guru
Posts: 1900
Joined: Wed Jun 12, 2013 1:59 pm
Location: Netherlands

Re: v7.4rc1 is released!

Wed Jul 06, 2022 1:08 pm

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!
 
User avatar
sirbryan
Member Candidate
Member Candidate
Posts: 298
Joined: Fri May 29, 2020 6:40 pm
Location: Utah
Contact:

Re: v7.4rc1 is released!

Wed Jul 06, 2022 5:49 pm

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.
 
Edified
newbie
Posts: 37
Joined: Thu Sep 16, 2010 9:02 am

Re: v7.4rc1 is released!

Wed Jul 06, 2022 6:01 pm

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.
 
User avatar
woland
Member Candidate
Member Candidate
Posts: 258
Joined: Mon Aug 16, 2021 4:49 pm

Re: v7.4rc1 is released!

Wed Jul 06, 2022 6:12 pm


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
 
pe1chl
Forum Guru
Forum Guru
Posts: 10183
Joined: Mon Jun 08, 2015 12:09 pm

Re: v7.4rc1 is released!

Thu Jul 07, 2022 10:06 am

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.
 
FurfangosFrigyes
newbie
Posts: 43
Joined: Sun Feb 25, 2018 11:45 am

Re: v7.4rc1 is released!

Thu Jul 07, 2022 10:14 am



'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.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: v7.4rc1 is released!

Thu Jul 07, 2022 11:31 am

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.
 
User avatar
woland
Member Candidate
Member Candidate
Posts: 258
Joined: Mon Aug 16, 2021 4:49 pm

Re: v7.4rc1 is released!

Thu Jul 07, 2022 12:09 pm

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
 
ech1965
just joined
Posts: 23
Joined: Wed Mar 20, 2019 3:53 pm

Re: Not strictly related to: v7.4rc1 is released!

Thu Jul 07, 2022 3:26 pm

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 ;-)
 
pe1chl
Forum Guru
Forum Guru
Posts: 10183
Joined: Mon Jun 08, 2015 12:09 pm

Re: Not strictly related to: v7.4rc1 is released!

Fri Jul 08, 2022 9:45 am

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)?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Not strictly related to: v7.4rc1 is released!

Fri Jul 08, 2022 10:33 am

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.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10183
Joined: Mon Jun 08, 2015 12:09 pm

Re: Not strictly related to: v7.4rc1 is released!

Fri Jul 08, 2022 10:55 am

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)
 
pe1chl
Forum Guru
Forum Guru
Posts: 10183
Joined: Mon Jun 08, 2015 12:09 pm

Re: Not strictly related to: v7.4rc1 is released!

Fri Jul 08, 2022 11:52 am

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?
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Not strictly related to: v7.4rc1 is released!

Fri Jul 08, 2022 1:32 pm

@pe1chl: About in-interface-list, you need at least 7.4beta2. More info: VRF and hidden interfaces
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: Not strictly related to: v7.4rc1 is released!

Fri Jul 08, 2022 1:57 pm

Maybe I've misunderstood things but has this functionality changed between "7.4beta2" (or earlier) and "v7.4rc1"?
 
pe1chl
Forum Guru
Forum Guru
Posts: 10183
Joined: Mon Jun 08, 2015 12:09 pm

Re: Not strictly related to: v7.4rc1 is released!

Fri Jul 08, 2022 2:20 pm

@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)
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Not strictly related to: v7.4rc1 is released!

Fri Jul 08, 2022 6:43 pm

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.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10183
Joined: Mon Jun 08, 2015 12:09 pm

Re: Not strictly related to: v7.4rc1 is released!

Fri Jul 08, 2022 7:26 pm

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.

Who is online

Users browsing this forum: Google [Bot] and 24 guests