Page 2 of 2
Re: v7.15beta [testing] is released!
Posted: Thu Mar 21, 2024 10:40 pm
by Sit75
I don't know what is happening with MikroTik. We are screaming here that for 15.3 MiB Flash memory devices is not possible to use existing RouterOS images or simply you can not make reboot if flash memory goes to 0. And the result of next release - just bigger Flash ROM image :-) Well, RIP MikroTik.
Well MikroTik guys, I went through your .npk files and I really, really don't understand why on ARM devices with 15.3 MiB flash ROM it is necessary to have QCA9984 which is only for RB4011iGS+5HacQ2HnD-IN with 512 MiB flash ROM? Does it mean that all hAP, wAP are tossed just for the sake of having a common package for ARM with RB4011iGS+5HacQ2HnD-IN?
Is this the right incredible reason?
And in addition you can save additional 400 kB ROM (with removing of QCA9984 more than 1 MB in total!) by extracting "hotspot" feature into separate package from RouterOS main package.
Re: v7.15beta [testing] is released!
Posted: Thu Mar 21, 2024 10:43 pm
by wispmikrotik
... is necessary to have QCA9984 which is only for RB4011iGS+5HacQ2HnD-IN ...
... and for RBD25G-5HPacQD2HPnD (Audience). Admittedly Audience has flash larger than 16MB as well.
He is right, I didn't see him.
Thank you.
Re: v7.15beta [testing] is released!
Posted: Thu Mar 21, 2024 10:52 pm
by eworm
And in addition you can save additional 400 kB ROM (with removing of QCA9984 more than 1 MB in total!) by extracting "hotspot" feature into separate package from RouterOS main package.
I guess you have to look at packed size... Packages are compressed.
Re: v7.15beta [testing] is released!
Posted: Thu Mar 21, 2024 10:59 pm
by infabo
Sit75, this is already known. Sadly.
Re: v7.15beta [testing] is released!
Posted: Thu Mar 21, 2024 11:13 pm
by t0mm13b
Normis did mention there was one big behemoth driver to rule them all.
Is the smb / rose storage / dlna / drivers for containers still compiled into kernel? This is even more why the wee bugger takes up too much space.
This is going against the essence of what a router/switch should be, heck even enterprise routers/switches do not even have any sort baked into it. Why put extra pressure on the processor to deal with SMB / Containers, let the processor deal with handling / routing of packets. However the KISS philosophy is gone out the window. What next? some AI module that will be proactively monitoring and injecting rules into the filter dynamically?
You want containers, use raspberry pi. You want smb,use raspberry pi. You want widget x, heck use raspberry pi, you see the drift.
Why overload the basics of router/switches with everything but the kitchen sink?
Am torn and am leaning to actually ditching the wifi from the Chateau and acquisition another MT device instead which will take care of wifi.
Re: v7.15beta [testing] is released!
Posted: Thu Mar 21, 2024 11:50 pm
by Amm0
... is necessary to have QCA9984 which is only for RB4011iGS+5HacQ2HnD-IN ...
... and for RBD25G-5HPacQD2HPnD (Audience). Admittedly Audience has flash larger than 16MB as well.
with an footnote on RB4011i, that new wifi-qcom-ac only helps with 5Ghz, and the driver does not work for 2.4Ghz AFAIK... but RB4011 more storage too.
Perhaps some new "wifi-qcom-ac-lite" without QCA9984 driver? And the "wifi-qcom-ac" can still be used on Audience and RB4011, even if it has "unneeded" drivers for IPQ-4019 since that prevent breaking folks already using wifi-qcom-ac on 16MB today.
Re: v7.15beta [testing] is released!
Posted: Thu Mar 21, 2024 11:54 pm
by mbovenka
This is going against the essence of what a router/switch should be, heck even enterprise routers/switches do not even have any sort baked into it.
Weeellll...:
https://www.cisco.com/c/en/us/products/ ... index.html
But I agree, MT needs to stop with this 'everything but the kitchen sink' idea. Please, focus on the basics.
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 12:01 am
by toasterk
Hey there!
I can't upgrade either, due to "upgrade failed, free 113 kB disk space for a (null)upgrade"
That has been happening since beta 6 but my memory and HHD space is looking good to me:
All this happening on a : CCR2004-1G-12S+2XS Version 7.14.1 (stable)
Any Ideas?
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 12:21 am
by elbob2002
This is going against the essence of what a router/switch should be, heck even enterprise routers/switches do not even have any sort baked into it.
I have several Catalyst C9500-48Y4C switches at work. 8 Core Xeons with 32GB RAM and a 960GB SSD. Granted they're in a slightly different league than Mikrotik products but they very much have a similar expanded feature set!
They also have considerably more than 16MB of embedded flash storage too.
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 12:34 am
by t0mm13b
This is going against the essence of what a router/switch should be, heck even enterprise routers/switches do not even have any sort baked into it.
I have several Catalyst C9500-48Y4C switches at work. 8 Core Xeons with 32GB RAM and a 960GB SSD. Granted they're in a slightly different league than Mikrotik products but they very much have a similar expanded feature set!
They also have considerably more than 16MB of embedded flash storage too.
Well, that's monstrous storage space/RAM. for what, to shuffle network packets around, granted, still,apples and oranges aside, apart from price comparisons :)
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 5:58 am
by MWComms
Whilst you're re-working route attributes, do you think it would be possible to display different AFI's (e.g. vpn4) within the ip > route context?
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 6:31 am
by strods
Please keep in mind that this is beta. This version is released mainly to test particular fixes. For example, test Media feature, Traffic Flow fixes, SFP fixes or any other ones. As you can see in the changelog - "space" issue is being addressed. This is not a stable release yet. Nobody is forced to use beta releases, and definitely not all of them. These versions are released strictly for testing "fixes". Yes, something can be broken in the way. We have never promised that beta will work on any router with any configuration without any problems.
We do not delay beta releases and wait for "everything to be ready" before the release. Otherwise, the first beta should be rc1 right away.
Package size issue is being addressed! Please wait for the rc releases at least. There is no need for flooding this topic just regarding this issue.
Also, as always - the system administrator is responsible for adjusting configuration for the hardware. You can also upload a film to CCR and say that there is no space for an upgrade. Quite often, the problem actually is that you might have needed to choose another product for your needs. Our main focus is to get routers with default configuration to be able to upgrade, and an extra space left for something. But definitely there will be no update which will add more disk storage to a router.
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 6:39 am
by strods
These fixes had nothing to do with BTH directly. We added WireGuard logging. Turned out that WireGuard tries to connect to peer even if it does not know the peer IP. Then it tries to connect to IP 0.0.0.0. This fix changes that and router will not try to connect to 0.0.0.0 if it does not know the real client address.
I would like to know what you are doing here --> *) route - rework of route attributes;
Can you post sample text or something, sounds ominous!!!
Also, what is meant by: *) wireguard - added option to mark peer as responder only (CLI only);
Is this followup work to this improvement that maybe was not sufficiently doing the job?
*) wireguard - do not attempt to connect to peer without specified endpoint-address;
I am trying to understand what problem you were addressing as it didnt occur before BTH.
Is this the device (normally acting as server for handshake) trying to cconnect to a client type device??
Or is this what happens when two devices both without public IP access join and then only one designated device keeps checking in (persistent keep alive) but the other device was also trying the same????
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 6:42 am
by strods
Here is the correct Delegated-IPv6-Prefix usage example:
/user-manager/attribute/print detail where name~"Delegated"
Flags: * - default
8 * name="Delegated-IPv6-Prefix" default-name="Delegated-IPv6-Prefix" vendor-id=standard type-id=123 value-type=ip6-prefix packet-types=access-accept
standard-name="Delegated-IPv6-Prefix"
Delegated-IPv6-Prefix still not recognized by 7.15beta8 (and also by alpha218):
18:51:21 radius,debug,packet Unknown-Attribute(type=54) = 0x326130313a396138303a313031303a3a
in my dictionary:
ATTRIBUTE Delegated-IPv6-Prefix 54 string
early today your support comunicated that attribute was added in response to ticket SUP-134793
regards
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 7:06 am
by arm920t
RTL8125 2.5GbE Controller works well with 7.15beta8
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 7:44 am
by mkx
And the "wifi-qcom-ac" can still be used on Audience and RB4011, even if it has "unneeded" drivers for IPQ-4019 since that prevent breaking folks already using wifi-qcom-ac on 16MB today.
Audience has both IPQ-4018 (used as SoC and for 2.4GHz + lower 5GHz radio) and QCA9984 (for higher 5GHz radio). So the "full qcom-ac" package will need both firmwares/drivers.
But yes, "wifi-qcom-ac-lite" would come handy for the rest of IPQ4018 devices of which many come with the dreaded 15.3MB flash.
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 8:25 am
by rpingar
Here is the correct Delegated-IPv6-Prefix usage example:
/user-manager/attribute/print detail where name~"Delegated"
Flags: * - default
8 * name="Delegated-IPv6-Prefix" default-name="Delegated-IPv6-Prefix" vendor-id=standard type-id=123 value-type=ip6-prefix packet-types=access-accept
standard-name="Delegated-IPv6-Prefix"
Delegated-IPv6-Prefix still not recognized by 7.15beta8 (and also by alpha218):
18:51:21 radius,debug,packet Unknown-Attribute(type=54) = 0x326130313a396138303a313031303a3a
in my dictionary:
ATTRIBUTE Delegated-IPv6-Prefix 54 string
early today your support comunicated that attribute was added in response to ticket SUP-134793
regards
thanks Strods,
Degated-IPv6-Prefix attribute is missing from accounting request when it is assigned by ipv6 pool.
this is needed to account a dynamic prefix to a particular user.
regards
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 8:39 am
by strods
Did you see the last changelog? This option was just added in this release.
*) ppp - added "enable-ipv6-accounting" option under PPP AAA menu (CLI only);
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 8:48 am
by rpingar
Did you see the last changelog? This option was just added in this release.
*) ppp - added "enable-ipv6-accounting" option under PPP AAA menu (CLI only);
not present..... and the attribute also with your description is still not recognized
this is the log:
07:30:53 radius,debug,packet Unknown-Attribute(type=153) = 0x326130313a396138303a313031303a3a
07:30:53 radius,debug,packet 2f3634
07:30:53 radius,debug,packet Message-Authenticator = 0xa3a2726155160eb698779597ea83bcb4
07:30:53 radius,debug received reply for 1b:1b7d
07:30:53 radius,debug new request 1b:00 code=Accounting-Request service=ppp called-id=ULLPPPoE
07:30:53 radius,debug sending 1b:00 to xxx:1813
07:30:53 radius,debug,packet sending Accounting-Request with id 8 to xxx:1813
07:30:53 radius,debug,packet Signature = 0x5c7859434a129534ace69e4592476799
07:30:53 radius,debug,packet Service-Type = 2
07:30:53 radius,debug,packet Framed-Protocol = 1
07:30:53 radius,debug,packet NAS-Port = 15728644
07:30:53 radius,debug,packet NAS-Port-Type = 15
07:30:53 radius,debug,packet User-Name = "provaopen3"
07:30:53 radius,debug,packet Calling-Station-Id = "00:90:0B:BA:4C:B5"
07:30:53 radius,debug,packet Called-Station-Id = "ULLPPPoE"
07:30:53 radius,debug,packet NAS-Port-Id = "bonding-Network"
07:30:53 radius,debug,packet Acct-Session-Id = "81e00001"
07:30:53 radius,debug,packet Framed-IP-Address = yyy
07:30:53 radius,debug,packet Acct-Authentic = 1
07:30:53 radius,debug,packet Event-Timestamp = 1711089053
07:30:53 radius,debug,packet Acct-Status-Type = 1
07:30:53 radius,debug,packet NAS-Identifier = "FTTxAS1-test"
07:30:53 radius,debug,packet Acct-Delay-Time = 0
07:30:53 radius,debug,packet NAS-IP-Address = 192.168.12.196
07:30:53 pppoe,ppp,info,account provaopen3 logged in, yyy from 00:90:0B:BA:4C:B5
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 10:26 am
by rpingar
was able to pass the delegated-ipv6-prefix to MT by radius using this configuration for the attribute:
ATTRIBUTE Delegated-IPv6-Prefix 123 ipv6prefix
log:
09:20:01 radius,debug,packet Delegated-IPv6-Prefix = 2a01:9a80:1111::/64
still I don't see it in accounting request.
regards
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 11:15 am
by strods
As mentioned before - IPv6 accounting must be enabled under PPP/AAA menu. If you can not make it work, then please as always contact
support@mikrotik.com. Debugging should not be done here in general version release topic.
https://help.mikrotik.com/docs/display/ROS/PPP+AAA
"Enable IPv6 separate accounting. PPP service counts Layer2, IPv4 and IPv6 data all together when reporting network usage statistics to the RADIUS server by default. If it is required to differ IPv4 and IPv6 traffic, then this option can be enabled. Prerequisites for it to work are that Delegated-IPv6-Prefix must be provided for PPP user from the RADIUS and also rate-limit must be provided by the RADIUS as well. Dynamically created queue statistics will be used as counters for IPv6 data, which then will be included in accounting packets as separate IPv6 statistics attributes."
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 12:36 pm
by Ullinator
Another bug. Missing "health" values in CAP AX with ROS7.15Beta8.
I firstly regognized it in my Nagios monitoring after the update.
hc_251.jpg
The red ones are CAP AX with ROS7.15Beta8, the greenone a CAP AX with ROS7.14.1.
In the devices itself the error is viewed like this.
ROS7.15Beta8:
hc_249.jpg
ROS 7.14.1:
hc_248.jpg
Support ticket is open. (SUP-147767)
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 1:47 pm
by infabo
*) health - added "cpu-temperature" for IPQ50xx devices;
🤔
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 3:56 pm
by Sit75
We do not delay beta releases and wait for "everything to be ready" before the release. Otherwise, the first beta should be rc1 right away.
Package size issue is being addressed! Please wait for the rc releases at least. There is no need for flooding this topic just regarding this issue.
It would be good to at least inform customers in the changelog that it is strongly not recommended to use on 15.3 MiB Flash ROM devices. It would be fair. But none of this information exists, nothing. You can't expect customers to wait patiently and quietly to see if something might (or might not) happen with the next release if you don't communicate.
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 4:03 pm
by pe1chl
with an footnote on RB4011i, that new wifi-qcom-ac only helps with 5Ghz, and the driver does not work for 2.4Ghz AFAIK... but RB4011 more storage too.
Perhaps some new "wifi-qcom-ac-lite" without QCA9984 driver? And the "wifi-qcom-ac" can still be used on Audience and RB4011, even if it has "unneeded" drivers for IPQ-4019 since that prevent breaking folks already using wifi-qcom-ac on 16MB today.
It is a pity that even with the new structure of wifi drivers as an external package, you still cannot install wifi-qcom-ac and wireless alongside eachother and have both 5 and 2 GHz working on the 4011. I cannot imagine that a lot of 4011 users migrate to wifi-qcom-ac and accept losing their 2GHz.
Even more sad when other devices suffer from the addition of a driver for the 4011 that they do not need, and that 4011 users do not use.
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 4:18 pm
by infabo
File tree of wifi-qcom-ac-7.15beta8
[4.0K] .
├── [4.0K] lib
│ ├── [4.0K] bdwlan
│ ├── [4.0K] config
│ │ ├── [3.7K] global.ini
│ │ ├── [4.0K] internal
│ │ │ ├── [ 679] AR900B_i.ini
│ │ │ ├── [2.7K] global_i.ini
│ │ │ ├── [ 680] IPQ4019_i.ini
│ │ │ ├── [1.7K] QCA5018_i.ini
│ │ │ ├── [1.5K] QCA6290_i.ini
│ │ │ ├── [ 653] QCA9888_i.ini
│ │ │ ├── [ 680] QCA9984_i.ini
│ │ │ └── [1.6K] QCN6122_i.ini
│ │ ├── [ 72] QCA5018.ini
│ │ ├── [ 72] QCA6290.ini
│ │ ├── [ 84] QCA9984.ini
│ │ ├── [ 72] QCN6122.ini
│ │ └── [ 235] wifi_module_param.ini
│ ├── [4.0K] firmware
│ │ ├── [4.0K] IPQ4019
│ │ │ └── [4.0K] hw.1
│ │ │ ├── [377K] athwlan.bin
│ │ │ ├── [203K] athwlan.codeswap.bin
│ │ │ ├── [ 12K] boarddata_0.bin
│ │ │ ├── [ 12K] boarddata_1.bin
│ │ │ └── [4.6K] otp.bin
│ │ └── [4.0K] QCA9984
│ │ └── [4.0K] hw.1
│ │ ├── [390K] athwlan.bin
│ │ ├── [268K] athwlan.codeswap.bin
│ │ ├── [ 12K] boarddata_0.bin
│ │ ├── [ 12K] boarddata_1.bin
│ │ ├── [2.0K] ext_boardData_QCA9984_CAS03_dual_band_5G_2G_YC325_v1_001.bin
│ │ └── [9.1K] otp.bin
│ └── [4.0K] modules
│ └── [4.0K] 5.6.3
│ ├── [4.0K] kernel
│ │ └── [4.0K] net
│ │ └── [4.0K] wireless
│ │ └── [266K] cfg80211.ko
│ ├── [4.0K] misc
│ │ ├── [8.9K] asf.ko
│ │ ├── [329K] ipq_cnss2.ko
│ │ ├── [4.5K] mem_manager.ko
│ │ ├── [1.7M] qca_ol.ko
│ │ ├── [136K] qca_spectral.ko
│ │ ├── [147K] qdf.ko
│ │ ├── [3.8M] umac.ko
│ │ └── [607K] wifi_2_0.ko
│ └── [ 197] modules.dep.wifi-qcom-ac
└── [4.0K] nova
├── [4.0K] bin
│ ├── [151K] localphy-qcom-ac
│ └── [ 25K] qcawificfg
└── [4.0K] etc
└── [4.0K] pciinfo
└── [ 414] wifi-qcom-ac.x3
20 directories, 38 files
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 4:42 pm
by Amm0
Package size issue is being addressed! Please wait for the rc releases at least. There is no need for flooding this topic just regarding this issue.
Both @strods and @normis have acknowledged the problem... Let's give them time to come up with something. Personally, getting older routers to 7.12.1 might be a good call while we wait – since that already in the way before 7.13+.
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 4:50 pm
by Amm0
Different topic. I noticed you added Dante QoS support "in 7.15":
https://help.mikrotik.com/docs/pages/vi ... QoS)-Dante
Starting from RouterOS v7.15, all MikroTik QoS-Capable devices comply with Dante.
I'm just not sure what changed, since AFAIK this was possible before. And nothing in release notes here about it.
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 5:38 pm
by TomSF
As was the case in the previous Beta, the log has errors such as
"executing script from dhcpclient failed, please check it manually" and similar log entries for netwatch and scheduler scripts.
Although annoying and misleading, I think the scripts actually do run. For netwatch, all the script does is call another script and all it does is create a log entry saying my ISP is up or down. Those log entries appear, implying the script ran. For my schedular script, I added statements to generate log entries at various points in the script. Those log entries appear, again implying the script actually ran.
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 7:55 pm
by infabo
Personally, getting older routers to 7.12.1 might be a good call while we wait – since that already in the way before 7.13+.
Still at 7.13.5. Space is plenty. If one with a 16mb arm devices likes to have the benefits of wifi-qcom-ac > 7.13.x is your friend.
Re: v7.15beta [testing] is released!
Posted: Fri Mar 22, 2024 8:00 pm
by ID
at v7.15b8, in dhcpv6 server before interm update interface disappear somehow,
dhcpv6.png
and since dynamic rule can't removed, user can't login again because of
could not add dhcpv6 server with pool : server with such name already exists (7)
@strods can you update vendor dictionary with new radius attributes also?
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 8:41 am
by rpingar
at v7.15b8, in dhcpv6 server before interm update interface disappear somehow,
dhcpv6.png
and since dynamic rule can't removed, user can't login again because of
could not add dhcpv6 server with pool : server with such name already exists (7)
@strods can you update vendor dictionary with new radius attributes also?
it seems a pppoe crash similar the one we reported more then one year and half ago, MT unable to reproduce or fix by supout (that is generated) SUP-97493.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 10:43 am
by nz_monkey
RTL8125 2.5GbE Controller works well with 7.15beta8
RTL8125 never works well if you consider CPU utilisation
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 11:47 am
by strods
Package wifi-qcom-ac for ARM devices has always been an "extra". Yes, using ARM 16 MB device with wifi-qcom-ac will not leave you with much free space left. But this package for a reason is not installed "out of box". If you use such combination, you know that you will be living on the edge regarding the disk usage.
Also from our point of view, router "disk" should be used only for system files. For extras there are USB ports, SD slots, M.2 slots, mountable disks, etc. For now, 16 MB are still enough for each and every device with 16 MB chip to run the system as intended for the particular model device. Usually, if you need more, then you most likely need more powerful device. That is the beauty and the curse of RouterOS - we do not limit you. Use features as you like, but be aware that there are hardware limitations and you will not be able to run, for example, ISP VPN server on hAP lite, although all the features are there.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 12:22 pm
by mkx
For now, 16 MB are still enough for each and every device with 16 MB chip to run the system as intended for the particular model device.
So you're saying that e.g. hAP ac2 was intended to offer wifi4 performance even though it's got wifi5 hardware? Because that's what one essentially gets when using legacy wireless driver on mentioned device. And such intention was never clearly marketed.
That's a pitty.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 1:26 pm
by templeos
Package wifi-qcom-ac for ARM devices has always been an "extra"
For extras there are USB ports, SD slots, M.2 slots, mountable disks, etc.
What does this mean? Is this a hint that we will be able to load
"extra" packages from
"USB ports, SD slots, M.2 slots, mountable disks, etc."?
I really hope that this below is NOT your solution for allowing us to use
wifi-qcom-ac :
For now, 16 MB are still enough for each and every device with 16 MB chip to run the system as intended for the particular model device. Usually, if you need more, then you most likely need more powerful device.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 1:38 pm
by eworm
I use a lot of scripts. These work just fine on mAP, but hAP ac² fails because of limited storage. That's ridiculous.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 1:39 pm
by strods
It simply means that when these ARM devices were designed and released, such package did not exist yet.
We are stilll doing our best to fit it in there.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 1:48 pm
by ToTheFull
@strods I'm using 7.15alpha195 and am delighted with the way that performs compaired to 7.15beta4/6.
is 7.15beta8 closer to 7.15alpha195.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 2:54 pm
by Amm0
It simply means that when these ARM devices were designed and released, such package did not exist yet.
Fair enough. Y'all never marketed them as Wi-Fi 6. A lot of vendors would just tell folks to upgrade.
But a lot of the great flexibility is lost when you cannot remove unneeded features & broken upgrades result.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 3:31 pm
by mkx
It simply means that when these ARM devices were designed and released, such package did not exist yet.
Neither did exist the advanced SMB (from ROSE) nor DLNA nor wireguard ... and yet you (MT) are pushing these (among other things) into base package.
If anything has to be done (and I'm glad it's being done), then to me improving existing base functionality (e.g. wireless performance) rather than adding new functionality makes much more sense. To paraphrase what you said: if you want to use extras, get a more capable device. In essence: I bought hAP ac2 to act as router and AP. Gimme the best it can do in this field (and we know it can do great with wifi-qcom-ac driver) and don't screw it with add-on functionality. If I want that add-on functionality, I'll buy more suitable device (actually I already have a mini server so I couldn't care less about most of new stuff getting stuffed in base package).
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 3:35 pm
by gabacho4
For the record, I 100% support a back to basics RoS version which preserves routing features and capabilities while removing non-routing enhancements like SMB, DLNA, adlists, etc.
Maybe it's time for Mikrotik to make some clear statements about device support. Clearly older devices must one day be made EOL or limited to a final OS or package version. The Hex, for example isn't recommended to be used with RoS 7 from what I've seen posted multiple times. Sure it works (until it doesn't) but it isn't advisable. It is unreasonable to expect Mikrotik to support every device with latest and greatest features forever.
So maybe the time has come for Mikrotik to say that, for example, the cAP AC is not recommended to be used above RoS 7.xx.x and with only the wireless package. You can upgrade beyond the recommended RoS version and/or install the wifiwave2 package at your own risk, but Mikrotik is on record acknowledging that the device is optimally limited to their recommendation. These limitations are a function of the technology that was available at the time they were created and the target price point. Sure it makes us unhappy to find out a device we bought is no longer going to get updates, but after years of support can you really be mad?
Mikrotik recommendations should be made for all the devices with insufficient storage memory (16MB). These recommendations must be made very clearly on their product pages so that buyers 100% know and understand what they are purchasing. if I buy a cAP AC, I do so understanding what I'm getting with no expectation of more.
The only other viable alternative I see is for Mikrotik to just EOL the devices that can't be further updated. Maybe provide security fixes or whatever but not much more. As they actively market many of those devices still, they would still be on the hook for 5 years of support.
One way or the other, it looks less and less possible to continue to develop software when the range of product capabilities is so great.
EDIT: less and less possible to continue to develop software if Mikrotik insists on adding new, non-routing features. MKX's post above mine hits it right on the head. I bought a router to route.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 3:44 pm
by Panbambaryla
We are stilll doing our best to fit it in there.
@Strods,
Nobody from your side responded to our biggest accusations regarding the combo your are trying to build. In majority we need router functionality not all these extra features you are trying to deliver like DLNA, DOCKER and so on. Just reconsider your goals and eventually build modular OS or eventually 2 versions: for home users with all the things you think want and the other one for professional use, with no extra (unnecessary) features. Please, tell us, what are your future development plans or at least if your consider that kind of approach.
Thanks in advance.
Best, Bam
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 4:34 pm
by baragoon
The Hex, for example isn't recommended to be used with RoS 7 from what I've seen posted multiple times.
BTW, hEX works great with 7.14.1 and even can handle 4 full ipv6 BGP transit sessions.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 4:37 pm
by holvoetn
My Hex runs ROS7 since it was still in beta.
Never had a problem with it, apart from some beta related glitches.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 4:42 pm
by infabo
So maybe the time has come for Mikrotik to say that, for example, the cAP AC is not recommended to be used above RoS 7.xx.x and with only the wireless package
Are you joking?! What a
waste of resources and capabilities! CAP AC was crippled until wifi-qcom-ac unleashed the full chipset potential. And now some smart one likes put this device back into wireless stoneage just because of what? Producing electronical waste?
if I buy a cAP AC, I do so understanding what I'm getting with no expectation of more.
If I buy a cap ac I see it has a IPQ4019 CHIPSET inside and when I view the tech sheet over at Qualcomm webpage, I really expect to have 802.11ac wave2. And not Mikrotik legacy wireless drivers not fully unleashing the hardware capabilities.
MT made a huge step by publishing wifi-qcom-ac drivers. Now cap ac is really competitive device.
Please don't take this away.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 4:43 pm
by DanMos79
Yes, using ARM 16 MB device with wifi-qcom-ac will not leave you with much free space left. But this package for a reason is not installed "out of box". If you use such combination, you know that you will be living on the edge regarding the disk usage.
@Strods
This statement is a little ironic. Except for Audience and hAP ac³, all models from the compatibility list of the wifi-qcom-ac package are equipped with 16MB of storage.
https://help.mikrotik.com/docs/display/ ... patibility
I also think that Amm0's suggestion of another wifi-qcom-ac(lite) package without the QCA9984 driver could be an advantage. Those who need the driver also have enough storage.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 4:44 pm
by gabacho4
The Hex, for example isn't recommended to be used with RoS 7 from what I've seen posted multiple times.
BTW, hEX works great with 7.14.1 and even can handle 4 full ipv6 BGP transit sessions.
My hEX works just fine as well, just repeating what I have seen before. That wasn't the point. The point is, if a device is limited (due to storage, CPU architecture, whatever) Mikrotik needs to say as much so up front so that users/buyers have that knowledge. With RoS and Wifi basically exhausting the 16MB on many devices, it is kinda crazy that those devices continue to be sold without a disclaimer indicating that they are not compatible with latest versions.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 4:50 pm
by gabacho4
So maybe the time has come for Mikrotik to say that, for example, the cAP AC is not recommended to be used above RoS 7.xx.x and with only the wireless package
Are you joking?! What a
waste of resources and capabilities! CAP AC was crippled until wifi-qcom-ac unleashed the full chipset potential. And now some smart one likes put this device back into wireless stoneage just because of what? Producing electronical waste?
if I buy a cAP AC, I do so understanding what I'm getting with no expectation of more.
If I buy a cap ac I see it has a IPQ4019 CHIPSET inside and when I view the tech sheet over at Qualcomm webpage, I really expect to have 802.11ac wave2. And not Mikrotik legacy wireless drivers not fully unleashing the hardware capabilities.
MT made a huge step by publishing wifi-qcom-ac drivers. Now cap ac is really competiting device.
Please don't take this away.
You guys have missed my point entirely. My example was entirely hypothetical. I'll chalk it up to language barriers or phase of the moon. Whatever. I am running happy with a RB5009 and cAP AXs so I have no dog in the fight. Mikrotik can add SMB, DLNA, adlists, Doom III, etc and I'll be just fine. I'm trying to illustrate the need for Mikrotik to manage expectations and make their intentions clear to those of you with more modest hardware who are encountering bricked devices as a result of updates and package size increases.
EDIT: RoS 7.15beta8 works great on my setup. Look forward to the seeing the next enhancements and package size increases that break others' devices. Keep it coming Mikrotik!
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 5:15 pm
by Amm0
While I have confidence Mikrotik will figure out something for 16MB in 7.15 to improve the situation....
The open question, and worry, is 7.16, 7.17, etc. If all new features/fix go to the main package, we'll be in the same boat again soon. And there does not seem to be a plan to deal with that.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 5:24 pm
by gabacho4
The open question, and worry, is 7.16, 7.17, etc. If all new features/fix go to the main package, we'll be in the same boat again soon. And there does not seem to be a plan to deal with that.
I fear the plan is one that no one wants to hear. Upgrade to 128MB or higher devices or be left out. The bitterness of that pill is that Mikrotik is literally releasing new products with 16MB storage which elicits a major WTF from me. If the plan is for RoS to grow in size, then how can they possibly be releasing new devices that are incapable of running it?!
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 6:25 pm
by sirbryan
Guys, remember that most of the lab devices they are developing on have nothing else on the disk, so 7.14/7.15 etc. all fit and work fine because likely the CI/CD setup is wiping those test devices with a fresh netinstall every time. You can't expect a lab device to load up all the cruft many of us tinkerers have put on our routers over the years, unless they have one of our supouts they're playing with.
My own devices are likely going to have tons of junk on them because of playing with them, but you can bet the vast majority of my customer's hAP AC2's will upgrade just fine when I finally pull the trigger. Even then, most of them don't know/don't care about WiFi Wave 2 (and they don't have broadband packages that could take advantage of anything over 200-300Mbps on WiFi anyway). For those who do, I've been putting in hAP AC3's or hAP AX3's.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 6:45 pm
by pe1chl
Guys, remember that most of the lab devices they are developing on have nothing else on the disk, so 7.14/7.15 etc. all fit and work fine because likely the CI/CD setup is wiping those test devices with a fresh netinstall every time. You can't expect a lab device to load up all the cruft many of us tinkerers have put on our routers over the years, unless they have one of our supouts they're playing with.
I too suspect that their testing scheme is too simple. We have read before about how they test all upgrades on default configuration, most likely by netinstall of version X, then upgrade to version X+1.
But a device that has been updated several times and has been reconfigured a lot of times accumulates wasted space on the disk that is never recovered.
You can e.g. see that when you make a /system/backup the file you get is much larger on a device that has been used for some time than on THE SAME type of device with THE SAME configuration, only it has just been netinstalled and the config was imported from an export. That can easily be 5 times the size!
So unless they test in such conditions, their tests will not hit any problems while our devices "in the field" do encounter them.
It could already help if there was some "compact database and remove unnecessary files" command. That would re-pack all database files to the minimal size and remove old saved v6 config and other backup files there may be in the system. It could be an option to the /system/check-installation command.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 6:48 pm
by infabo
You guys have missed my point entirely. My example was entirely hypothetical. I'll chalk it up to language barriers or phase of the moon. Whatever. I am running happy with a RB5009 and cAP AXs so I have no dog in the fight. Mikrotik can add SMB, DLNA, adlists, Doom III, etc and I'll be just fine. I'm trying to illustrate the need for Mikrotik to manage expectations and make their intentions clear to those of you with more modest hardware who are encountering bricked devices as a result of updates and package size increases.
Your suggestions on how MikroTik should proceed were crystal clear. There was no language barrier. Of course hypothetically speaking - I took note of it and since none of us makes decisions for or at MT. Time will show.
EDIT: RoS 7.15beta8 works great on my setup. Look forward to the seeing the next enhancements and package size increases that break others' devices. Keep it coming Mikrotik!
Yeah, happy to hear.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 10:04 pm
by infabo
Even then, most of them don't know/don't care about WiFi Wave 2 (and they don't have broadband packages that could take advantage of anything over 200-300Mbps on WiFi anyway).
I also don't have internet access that could fully utilize bandwidth beyond 300Mbps. Even with the old wireless package, I would be satisfied with the bandwidth. However, the wifi-qcom-ac drivers bring other significant improvements that go beyond throughput. With the old wireless package, I had to use access lists to force clients to roam to 5GHz or vice versa. 802.11v, 802.11r, and 802.11k are heaven-sent, and roaming between 2GHz and 5GHz is a dream. It also seems to me that the 2.4GHz band is less susceptible to interference and more stable.
Re: v7.15beta [testing] is released!
Posted: Sat Mar 23, 2024 10:17 pm
by Paternot
For now, 16 MB are still enough for each and every device with 16 MB chip to run the system as intended for the particular model device. Usually, if you need more, then you most likely need more powerful device.
Here is where I disagree - because I think we should always have the option to partition the device. It's a blessing to upgrade knowing fully well that I can roll back to the known working config on the other partition. So, I would say the minimum should be 32 MB - and that's quite limited, since it would give two 16MB partitions.
Re: v7.15beta [testing] is released!
Posted: Sun Mar 24, 2024 12:18 pm
by pe1chl
However, the wifi-qcom-ac drivers bring other significant improvements that go beyond throughput.
Unfortunately they also bring the big disadvantage that you can no longer dynamically assign a VLAN to each client...
(via access list, mac authentication, or WPA2-EAP)
That really should be fixed before I can consider using it.
Re: v7.15beta [testing] is released!
Posted: Sun Mar 24, 2024 1:31 pm
by lubomirs
. . . For extras there are USB ports, SD slots, M.2 slots, mountable disks, etc. . . .
On the ax2 device ?
Re: v7.15beta [testing] is released!
Posted: Sun Mar 24, 2024 3:01 pm
by mkx
. . . For extras there are USB ports, SD slots, M.2 slots, mountable disks, etc. . . .
On the ax2 device ?
Let me quote @strods for you:
Usually, if you need more, then you most likely need more powerful device.
And "power", in a sense, is also ability to attach useful peripherials. In this sense, ax2 is not a powerful device (but e.g. ax3 is one).
Re: v7.15beta [testing] is released!
Posted: Sun Mar 24, 2024 3:07 pm
by elbob2002
Noticed very high CPU Usage on an RB750Gr3
Profile showed that the "management" process was using almost between 24% and 27% of CPU and another "unclassified" process was using another 16% CPU
NAME USAGE
ethernet 0%
console 1%
ssh 0%
firewall 0.1%
networking 5.6%
neighbor-discovery 0%
winbox 0%
logging 0.8%
management 24.3%
encrypting 0.1%
profiling 3.2%
unclassified 15.8%
total 50.9%
As this is a test device I reset it to defaults and with a simple default config same CPU usage occurs. No optional/wireless packages installed. As you can see below, the config could barely be simpler.
# 2024-03-24 13:01:03 by RouterOS 7.15beta8
# software id = XXXX-XXXX
#
# model = RB750Gr3
# serial number = XXXXXXXXXX
/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 interface=ether5
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/ip address
add address=172.20.0.254/16 interface=bridge1 network=172.20.0.0
/system note
set show-at-login=no
/system routerboard settings
set auto-upgrade=yes
I also have a test CHR running 7.15beta8 that does not display the same behaviour.
Re: v7.15beta [testing] is released!
Posted: Sun Mar 24, 2024 3:28 pm
by mkx
Management often equals winbox connection with multiple windows open and refreshing stats.
Re: v7.15beta [testing] is released!
Posted: Sun Mar 24, 2024 3:41 pm
by elbob2002
My initial thought as well.
No Winbox open. snippet above are from an SSH connection to the router.
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 4:21 am
by tamagochi
RB5009UPr+S+
Sign extension problem from righ shift, the lower 32bit is zero.
:put (-1 >> -1)
-4294967296
As far as I know, this gives a result of -1.
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 5:53 am
by Amm0
As far as I know, this gives a result of -1.
Depends. JS allows it and is -1. But in Python, it's an error. In C, it's left to an implementation detail.
But of all things to complain about in RouterOS scripts... And even if "wrong", you never know what might break changing stuff, someone could be relaying on the behavior.
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 8:57 am
by pekr
It simply means that when these ARM devices were designed and released, such package did not exist yet.
We are stilll doing our best to fit it in there.
Stuff like DLNA, SMB, back then, did not exist either. Please put those lesser used subsystems into the Extra packages archive. I also believe, that many users just don't use stuff like dynamic routing, Radius, Hotspot, etc. either.
I am well aware that if those things are not moduler / isolated in the code, it might not be easy to abstract them. But you are a bunch of clever guys down there, so I am sure you'll come up with something :-)
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 9:08 am
by Znevna
Noticed very high CPU Usage on an RB750Gr3
Profile showed that the "management" process was using almost between 24% and 27% of CPU and another "unclassified" process was using another 16% CPU
NAME USAGE
ethernet 0%
console 1%
ssh 0%
firewall 0.1%
networking 5.6%
neighbor-discovery 0%
winbox 0%
logging 0.8%
management 24.3%
encrypting 0.1%
profiling 3.2%
unclassified 15.8%
total 50.9%
As this is a test device I reset it to defaults and with a simple default config same CPU usage occurs. No optional/wireless packages installed. As you can see below, the config could barely be simpler.
# 2024-03-24 13:01:03 by RouterOS 7.15beta8
# software id = XXXX-XXXX
#
# model = RB750Gr3
# serial number = XXXXXXXXXX
/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 interface=ether5
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/ip address
add address=172.20.0.254/16 interface=bridge1 network=172.20.0.0
/system note
set show-at-login=no
/system routerboard settings
set auto-upgrade=yes
I also have a test CHR running 7.15beta8 that does not display the same behaviour.
And I wanted to return my RB750Gr3 to RouterOS...
Seems I'll wait a little longer.
Thank you!
PS: I doubt that they test the releases on these tiny devices.
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 2:42 pm
by PackElend
It simply means that when these ARM devices were designed and released, such package did not exist yet.
We are stilll doing our best to fit it in there.
do you still have use cases where the ARM devices work as full-fledged routers, so using any ROS feature, and not only as APs.
If second, why not offer a slimed main package for the "as AP only mode"?
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 3:54 pm
by Santi70
When trying to update from v. 7.14.1
157.png
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 4:15 pm
by Amm0
Be curious, do you have any other things in Files?
e.g. since photo shows 46 million sector writes, there could be none.
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 4:28 pm
by Santi70
Be curious, do you have any other things in Files?
e.g. since photo shows 46 million sector writes, there could be none.
11.png
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 4:37 pm
by pe1chl
Maybe you have "graphing" running with "store on disk" enabled (and store every 5 minutes)?
And/or DHCP "store leases on disk" set to "immediately" and a lot of DHCP activity (short lease time and/or unreliable connections)?
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 4:55 pm
by sinisa
Maybe you have "graphing" running with "store on disk" enabled (and store every 5 minutes)?
And/or DHCP "store leases on disk" set to "immediately" and a lot of DHCP activity (short lease time and/or unreliable connections)?
It would be great to be able at least to see those, even better if we could move them to USB storage, and leave the flash for firmware and config.
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 5:01 pm
by Amm0
Well, Mikrotik has said they're working on a "solution". And at least it failed gracefully. Using Netinstall let you test 7.15beta.
Whether it's fragmentation, "leftover" files from past, leases, graphing... The "math" using the UI is not always predictive of failure & there are limited options to free at this point. Other than netinstall.
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 5:46 pm
by Santi70
Maybe you have "graphing" running with "store on disk" enabled (and store every 5 minutes)?
And/or DHCP "store leases on disk" set to "immediately" and a lot of DHCP activity (short lease time and/or unreliable connections)?
# 2024-03-25 16:42:20 by RouterOS 7.14.1
# software id = G48Y-1U35
#
# model = RBD52G-5HacD2HnD
# serial number = XXXXXX
/ip dhcp-server
add add-arp=yes address-pool=default-dhcp interface=bridge lease-time=8h name=LAN
/tool graphing interface
add interface=vlan20 store-on-disk=no
/tool graphing resource
add store-on-disk=no
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 9:07 pm
by Etz
16MB devices are obsolete, face the fact, time to upgrade....
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 10:00 pm
by infabo
yeah, they are so obsolete that even MT doesn't know these are obsolete according to Etz.
https://mikrotik.com/product/chateau5gr16
Re: v7.15beta [testing] is released!
Posted: Mon Mar 25, 2024 11:43 pm
by Znevna
boy that's a crapload of money for a device with 16MB of ancient storage that was launched last year.
rip
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 6:15 am
by fragtion
LHGG lte6 also comes with 16MB Flash. Okay it's not supposed to be a fully fledged router but it's a modern unit and should run latest routeros for several years still
My 60ghz wireless wire kit are also 16MB
So there are many devices besides just hapac2 and chateau with 16MB and most of these aren't exactly ancient either
I'm sure Mikrotik have a solution in the works that involves better package management for these devices. Let's wait and see :) and no, that doesn't mean they need to scrap wireguard or container support. Yes this is a router not a raspberry Pi, but that doesn't mean it can't have some of these important features
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 7:59 am
by Jotne
The 16GB problem only aries when image becomes to large. Flash are mostly there to hold the boot image. So if MT are able to reduce the overall image so no router fails when begning upgrade, 16GB should be ok.
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 8:07 am
by zandhaas
16GB should be ok.
16
GB will for sure be OK even for the far future :)
I think you meant 16
MB
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 8:19 am
by holvoetn
16GB should be ok.
16
GB will for sure be OK even for the far future
I think you meant 16
MB
Be careful with that prediction.
640Kb was also deemed enough for the far future in early PC-days. Didn't last long.
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 8:29 am
by Znevna
That was regarding RAM.
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 8:33 am
by holvoetn
That was regarding RAM.
Same concept.
Besides, at that time storage was a measly 360Kb or 720Kb (I remember even less but those were not that common). And then play disc jockey to have some programs loaded ...
I also recall my fist HDD, it was 10Mb and cost almost as much as the complete PC.
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 11:36 am
by Santi70
The response received from support [SUP-148033] was:
Hello
Yes, this beta release is bigger than previous release. But that is why it is beta. Until the rc1 we will manage to make it smaller.
Of course upgrade will not make router disk bigger. So you should make sure that there are no unnecessary things stored on the router memory.
Best regards
Mārtiņš S.
I suppose that from rc1, as they say, they make the package smaller, since I don't have anything stored in the router's memory, so yes or yes to reach version 15 they will have to reduce it in some way if they want to continue supporting it with wave2 I hope so and thanks to support for responding.
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 12:27 pm
by pe1chl
What they mean is they are working on making it smaller, and that they expect to have something by the time rc1 is released.
As there has always been growth when adding new features, and the size of 16MB is already not very large compared to modern software "standards", I expect the only way to achieve that is to have a smaller base package and (optional) packages for extra features, either for everyone (i.e. back to the v6 situation) or just as an option for those that have a 16MB model (i.e. a new "RouterOS lite" base package maybe with a couple of optional packages of which you can choose only one).
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 12:40 pm
by loloski
Yes RouterOS lite it is and allow big files like drivers (wifi-qcom/wifi-qcom-ac) or any extra package to be loaded in external place like USB if present in the device. /* Dream On */
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 12:42 pm
by BartoszP
...Be careful with that prediction....
That was regarding RAM.
Same concept.
Besides, at that time storage was a measly 360Kb or 720Kb (I remember even less but those were not that common). And then play disc jockey to have some programs loaded ...
I also recall my fist HDD, it was 10Mb and cost almost as much as the complete PC.
1. In the beginning was the word, and in the word were two bytes, and there was nothing more.
2. And God separated the one from the zero, and saw that it was good.
3. And God said: "Let them become data." And it came to pass.
4. And God said: "Let the data be arranged in their proper places. And He created floppy disks and hard disks and compact disks.
5 And God said: "Let there be computers, so that there is somewhere to put the floppy disks, and the hard disks, and the compact disks." And he created computers and called them hardware, and separated software from hardware.
6 Software was not yet there, but God quickly created programmes - large and small - and told them, "go and propagate, and fill up all memory."
7. But God became weary of creating programmes Himself and said: "I will create a Programmer according to my likeness, and let him rule over computers, programmes and data." And God created the Programmer, and placed him in the Computing Centre to work in it. And He brought the Programmer to the directory tree and said: "In every directory you can run programs, only Windows don't use because you will surely die.
8 And God said: "It is not good for the Programmer to be alone; we will create for him one who will delight in the work of the Programmer." And He took from the Programmer a bone in which there was no brain, and He created That which would delight in the work of the Programmer, and He brought it to him. And He called It the User. And they sat together under a naked DOS and were not ashamed of it.
Translated with DeepL.com (free version) from Polish version
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 1:16 pm
by loloski
@MT quick question if MVRP implementation is working properly in the next few beta/rc, is it compatible with other implementation like Juniper or it will never be?
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 3:10 pm
by ormandj
16MB devices are obsolete, face the fact, time to upgrade....
This beta is a great example of what happens when a company cost-optimizes with narrow margins on storage; people can't test betas and are told to wait until RCs, which means the beta cycle will be less productive for MT since there will be fewer testers, which may result in more RCs instead of catching issues earlier. It's a business decision like any other, but it's definitely put my purchases on hold until they refresh their products with more storage, since the writing is on the wall. I'd love to be able to purchase newer devices with 128MB+ of storage.
Unfortunately, even some of Mikrotik's newer products have launched with 16MB of storage. It's just like all the recent switches launching with 10G ports instead of 25G, it doesn't make any sense to outsiders since the whole industry has shifted to 25G/100G and has prevented many purchases by myself and others who don't want to buy into something the industry has pivoted away from.
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 5:11 pm
by EdPa
Hi, loloski,
The MVRP is still under development, with more changes expected in the upcoming beta/rc versions. See documentation below:
https://help.mikrotik.com/docs/display/ ... ching-MVRP
The protocol is intended to be compatible with other vendors, but it is still undergoing testing to ensure compatibility.
Let us know if you have any feedback.
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 5:42 pm
by rushlife
Before ROS 7 there was so much more packages. So one could delete or disable packages for his own preference. Maybe is time to revert that and make ROS more light-small-able again.
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 6:57 pm
by sirbryan
do you still have use cases where the ARM devices work as full-fledged routers, so using any ROS feature, and not only as APs.
If second, why not offer a slimed main package for the "as AP only mode"?
I have situations where I use dynamic routing protocols and VPNs on low-power devices like hAP AC2, PowerBox Pros/hEX POE, and even mAP Lite, etc.
I have zero places where those devices use SMB/DLNA (we have SCP/(S)FTP/HTTP for uploading/download files).
Re: v7.15beta [testing] is released!
Posted: Tue Mar 26, 2024 8:51 pm
by miku
Hi,
Adlists do not load automatically after restart. I only tested lists from a local file, but I suspect it's the same in the URL version. If this is intentional behavior, there should be information in the documentation that after a restart you need to manually reload Adlist or include appropriate commands in the startup script.
Re: v7.15beta [testing] is released!
Posted: Wed Mar 27, 2024 5:34 am
by loloski
The protocol is intended to be compatible with other vendors, but it is still undergoing testing to ensure compatibility.
Let us know if you have any feedback.
Will going to test this thoroughly if it's working properly with CHR, I don't have a spare equipment at the moment to lab this up in actual device, in CHR as soon as you toggle MVRP in the bridge it bails out and the admin mac of the bridge is flapping
Re: v7.15beta [testing] is released!
Posted: Wed Mar 27, 2024 9:27 am
by ToTheFull
Hi,
Adlists do not load automatically after restart. I only tested lists from a local file, but I suspect it's the same in the URL version. If this is intentional behavior, there should be information in the documentation that after a restart you need to manually reload Adlist or include appropriate commands in the startup script.
Mine works perfect from url after restart, infact it checks every hour!
# Last modified: 26 Mar 2024 01:31 UTC
# Version: 2024.0326.0131.41
# Syntax: Hosts (including possible subdomains)
# Number of entries: 808933
1 url="https://raw.githubusercontent.com/hagezi/dns-blocklists/main/hosts/pro.txt" ssl-verify=no
match-count=31758 name-count=808933
Warning, the above file takes a cache size of 95164KiB
What device you using?
Re: v7.15beta [testing] is released!
Posted: Wed Mar 27, 2024 9:45 am
by AndiiiHD
Hi,
Adlists do not load automatically after restart. I only tested lists from a local file, but I suspect it's the same in the URL version. If this is intentional behavior, there should be information in the documentation that after a restart you need to manually reload Adlist or include appropriate commands in the startup script.
You can use the scheduler to update automatically, if you want it to be daily then run in terminal:
/system scheduler add name=reload_adlist interval=1d on-event="/ip dns adlist reload"
Re: v7.15beta [testing] is released!
Posted: Wed Mar 27, 2024 2:01 pm
by nmt1900
16MB devices are obsolete, face the fact, time to upgrade....
This beta is a great example of what happens when a company cost-optimizes with narrow margins on storage; people can't test betas and are told to wait until RCs, which means the beta cycle will be less productive for MT since there will be fewer testers, which may result in more RCs instead of catching issues earlier...
As betas cannot be tested (for this obvious reason), rc's will become betas - but that is hardly surprising as current development cycle looks like only hope for reliable releases are last versions of every release because every previous one of these are full of changelog entries like 7.14.1 currently has ("fixed - introduced in 7.14"). Then again first years of v6 were not much better either at some times if anyone is able to remember...
Re: v7.15beta [testing] is released!
Posted: Wed Mar 27, 2024 4:58 pm
by Amm0
Adlists do not load automatically after restart.[...] If this is intentional behavior, there should be information in the documentation [...]
You can use the scheduler to update automatically,[...]
What ever the reload strategy is it should be documented. Like what happens during the reload process, are ad still blocked or DNS resolution effected? e.g. 1d seems safe...if someone scheduled every 1m or even 1s is that still allowed/safe? The docs describe the options, nothing about operational effects.
Plus...If the idea of adlist is an easier alternative to a pihole/adguard/etc container, needing to read docs and use schedulers kinda goes against "easy".
Re: v7.15beta [testing] is released!
Posted: Thu Mar 28, 2024 4:39 pm
by gunther01
This may be by default and supposed to work this way.
But, Using bgp, we had accidentally set redistribute static and connected in bgp.
We "thought" turning off our output network would turn off any outbound network advertisements. But, that static route still pushed to our upstream.
IMO, kind of defeats the purpose of the output network field.. Or at least bypassed it.
We are seeing similar with OSPF filters. In that redistributed routes are bypassing filters also..
Re: v7.15beta [testing] is released!
Posted: Fri Mar 29, 2024 11:14 am
by bratislav
Why not remove, for example, Mesh from the ROS for ARM?
Surely it will be possible to gain a little in the size of the image.
Mesh is relatively small at around 75k, that is roughly half the size of pretty useless cloud and wproxy and only third of totally useless lcdstat since only RB3011 actually has a lcd which is basically worthless gimmick itself and actually enabling it uses around 10% of CPU making it total nonsense...
Re: v7.15beta [testing] is released!
Posted: Fri Mar 29, 2024 12:19 pm
by mrz
This may be by default and supposed to work this way.
But, Using bgp, we had accidentally set redistribute static and connected in bgp.
We "thought" turning off our output network would turn off any outbound network advertisements. But, that static route still pushed to our upstream.
This is unrelated to v7.15 release.
Originating with networks changes origin attribute.
There are a lot of resources over the internet explaining the origin, for example here:
https://www.packetswitch.co.uk/bgp-orig ... -examples/
Re: v7.15beta [testing] is released!
Posted: Fri Mar 29, 2024 4:20 pm
by gunther01
This may be by default and supposed to work this way.
But, Using bgp, we had accidentally set redistribute static and connected in bgp.
We "thought" turning off our output network would turn off any outbound network advertisements. But, that static route still pushed to our upstream.
This is unrelated to v7.15 release.
Originating with networks changes origin attribute.
There are a lot of resources over the internet explaining the origin, for example here:
https://www.packetswitch.co.uk/bgp-orig ... -examples/
So, in the case of our OSPF.. Filters have no effect on those? If I redistribute default route, and have if (dst==0.0.0.0/0){reject} as a rule. It won't work?? How could I get that to work then....?
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 11:46 am
by EdPa
What's new in 7.15beta9 (2024-Mar-27 21:55):
*) bgp - added initial vpnv6 support;
*) bridge - added MVRP support;
*) console - added "sanitize-names" property under "/console/settings" menu (option for replacing reserved characters with underscores for files, disabled by default);
*) console - added multi-line print in "/file" menu;
*) console - remove unnecessary serial ports for Alpine CPUs;
*) defconf - fixed 5ghz-ax channel width for L11, L22 devices;
*) dhcpv4-relay - added VRF support (CLI only);
*) eap - improved eap-peap, eap-mschap2 client authentication (dot1x/wireless/ipsec);
*) health - fixed missing "cpu-temperature" on IPQ-60xx devices (introduced in v7.15beta8);
*) ipv6 - properly initialize default ND "interface=all" entry;
*) media - added support for DLNA;
*) ppp - added "enable-ipv6-accounting" option under PPP AAA menu (CLI only);
*) ppp - fixed "Framed-IPv6-Pool" usage when received from RADIUS;
*) ppp - fixed reporting of frame error rate (introduced in v7.15beta8);
*) qos-hw - added "profile" and "map" support for CPU port;
*) qos-hw - added per-queue traffic shapers (CLI only);
*) sfp - added "100M-baseFX" link mode support for compatible devices;
*) sms - removed SMS for SMIPS;
*) system - general work on optimizing the size of RouterOS packages;
*) system - show "cpu-frequency" for Alpine CPUs;
*) vlan - added MVRP (applicant) configuration option;
*) wifi - added "reselect-interval" support;
*) wifi - rename "available-channels" parameter to "channel-priorities" and include desirability rating for each channel;
*) wifi - report current CAPsMAN address and identity on CAP;
*) wifi-qcom - added configuration.distance setting to enable operation over multi-kilometer distances (CLI only);
*) wifi-qcom - updated driver;
*) winbox - added key type and key length column for user SSH keys;
*) winbox - added passphrase option for SSH host key export;
*) winbox - added passphrase option for SSH host key import;
*) winbox - allow specifying size and rtmpfs size with M, G units under "System/Disks" menu;
*) winbox - do not show "Host Key Size" when using ed25519 key under "IP/SSH" menu;
*) winbox - renamed "Channel" column to "Current Channel" under "Wifi" menu;
*) winbox - show inherited properties for wifi interfaces;
*) winbox - updated icons for certain menus;
*) wireguard - added option to mark peer as responder only;
*) wireguard - fixed performance issues showing QR code;
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 12:08 pm
by infabo
*) console - added "sanitize-names" property under "/console/settings" menu (option for replacing reserved characters with underscores for files, disabled by default);
I guess this change will make some admins very happy! It is good to see the "opt-in" approach here. Thanks Mikrotik!
*) system - general work on optimizing the size of RouterOS packages;
Indeed! As far as I compared, compressed sizes of NPK (main package, wifi-qcom-ac) are nearly comparable to 7.13.x again. Looks promising! Thanks Mikrotik for taking all issue reports on the space-topic seriously!
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 12:41 pm
by loloski
MVRP appear to work correctly on my initial test :) I can't hold my excitement the vlan is withdrawn automatically in the other switch if for some reason a specific vlanids is no longer in-use :)
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 1:16 pm
by nz_monkey
What's new in 7.15beta9 (2024-Mar-27 21:55):
*) bgp - added initial vpnv6 support;
*) dhcpv4-relay - added VRF support (CLI only);
*) ppp - added "enable-ipv6-accounting" option under PPP AAA menu (CLI only);
*) ppp - fixed "Framed-IPv6-Pool" usage when received from RADIUS;
Is this the real life? Is this just fantasy?
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 1:24 pm
by rpingar
still waiting about Delegates-IPv6-Prefix handled in accounting request when selected by MT ipv6-pool and not by radius.
regards
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 1:26 pm
by loloski
I hope this 7.15 release once become "battle tested" in the field will become the LTS release this is long time coming and badly needed
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 3:00 pm
by riv
Still no progress on IS-IS ?
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 3:20 pm
by mantouboji
*) wireguard - added option to mark peer as responder only;
what means? which end should to set it "yes"? On an fixed IP server or an non-fixed IP client?
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 3:22 pm
by loloski
IS-IS is available for v4 and v6 as early as 7.13.3 if my memory serves correctly in CLI not winbox though
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 3:41 pm
by buset1974
something happen in beta6, in our MPLS L3 networks,
routing advertised by PE with 7.15beta6 suddenly cannot do recursive routing to other PE
i think this changed can caused it, not sure
*) route - rework of route attributes;
*) vrf - fixed VRF interfaces being moved to main table after reboot (introduced in v7.14);
all back to normal when downgraded to beta4 or 7.14.1
thx
I am waiting for 2 weeks after reported SUP-3085 and this problem still happen in beta9
please take a look the ticked and fixed the problem please
thx
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 4:33 pm
by clambert
*) bgp - added initial vpnv6 support;
*) dhcpv4-relay - added VRF support (CLI only);
Two of the features that I most expected in the same release. Great news!
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 5:04 pm
by Larsa
What's new in 7.15beta9 (2024-Mar-27 21:55):
*) console - added "sanitize-names" property under "/console/settings" menu (option for replacing reserved characters with underscores for files, disabled by default);
Thank you! The opt-in method is preferred when introducing breaking changes.
*) wireguard - added option to mark peer as responder only;
Question: Does this also fix the issue where the initial handshake response is sent back through the default gateway instead of being routed to the originating inbound interface?
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 5:39 pm
by pe1chl
It would be nice when the BGP Sessions window in winbox finally would become auto-refreshing as it was in v6.
When the sessions window is kept open, it shows a fake "uptime" and all other sessions status is not updated until F5 is pressed.
This is inconvenient. In v6 (BGP Peers) it worked fine, and in many other windows in v7 auto-refresh still works, so why not in BGP Sessions???
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 6:35 pm
by BitHaulers
Netinstall is also not working with 7.14.1 or 7.15beta8, every time when the wAP AC entered netinstall during reboot the netinstall(64).exe was terminated with an error similar to: "...was closed by remote"
Closed by remote, in my experience, is corruption. You need to figure out how to NetInstall it, because something is wrong with the file system somewhere.
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 9:12 pm
by Cha0s
It would be nice when the BGP Sessions window in winbox finally would become auto-refreshing as it was in v6.
When the sessions window is kept open, it shows a fake "uptime" and all other sessions status is not updated until F5 is pressed.
This is inconvenient. In v6 (BGP Peers) it worked fine, and in many other windows in v7 auto-refresh still works, so why not in BGP Sessions???
++
And I believe it is the only window in whole Winbox that doesn't refresh automatically.
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 10:47 pm
by Cha0s
I've been trying since the time of beta9 release and MikroTik cannot find the new version to auto upgrade.
mikrotik-upgrade.png
upgrade.mikrotik.com resolves to 159.148.147.251
mikrotik-dns-cache.png
Apparently the same IP resolves for everyone around the world according to whatsmydns.net despite the "global-balancer-e.mikrotik.com" CNAME record (which could suggest a CDN or something).
https://www.whatsmydns.net/?utm_source= ... krotik.com
What I mean is that this does not appear to be a CDN cache issue or a DNS cache issue. The IP 159.148.147.251 is MikroTik's and not some public CDN's, and yet something seems broken and System -> Packages > Check for Updates still shows the beta8 release log.
Anyone else experiencing the same issue?
Re: v7.15beta [testing] is released!
Posted: Tue Apr 02, 2024 11:13 pm
by patrikg
If you read the title it says testing.
Change channel
stable = 7.14.2
testing = 7.15beta9
development = 7.15beta8
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 12:20 am
by ToTheFull
I would rather they leave it like that for now, I'm seeing irregular behaviour since the driver change, I have lost signal 10db or so.
*) wifi-qcom - updated driver
I'm not saying it's a bad thing, but I do need to test more. if anything, stability seems to have gone up. Also I note that my IOS stuff seems to idle down to 6Mbps (TX Rate). My devices used to connect @1201Mbps Cap ax and Hap ax2, now they show 960.8/1080.9 as shown below. Like I said, just an observation!
I will roll-back tomorrow just to check again.
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 12:25 am
by clambert
*) bgp - added initial vpnv6 support;
In the first tests I am doing, I am finding it impossible to establish a vpnv6 session against the Route Reflector.
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 8:02 am
by Jotne
If you read the title it says testing.
Change channel
stable = 7.14.2
testing = 7.15beta9
development = 7.15beta8
Not so sure about that. Read first post in this thread. There you will find "
What's new in 7.15beta8 (2024-Mar-21 09:12):"
posted in testing channel as well.
So here I think it MT that has made a mix up in what belongs to what.
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 8:09 am
by Kanzler
I'm seeing irregular behaviour since the driver change, I have lost signal 10db or so.
I have exactly the same problem, starting with version 7.13 (hAP ac3 + wifi-qcom-ac). No issues with wifiwave2 (7.12 and below)
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 10:06 am
by pajapatak
I'm seeing irregular behaviour since the driver change, I have lost signal 10db or so.
I have exactly the same problem, starting with version 7.13 (hAP ac3 + wifi-qcom-ac). No issues with wifiwave2 (7.12 and below)
I can confirm that; also hAP-ac3, currently at 7.13.1 (in the short period it was at 7.14, that particular behavior was still present). With legacy wireless drivers, the signal was indeed stronger, but the speeds clients could achieve was lower.
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 10:16 am
by patrikg
If you read the title it says testing.
Change channel
stable = 7.14.2
testing = 7.15beta9
development = 7.15beta8
Not so sure about that. Read first post in this thread. There you will find "
What's new in 7.15beta8 (2024-Mar-21 09:12):"
posted in testing channel as well.
So here I think it MT that has made a mix up in what belongs to what.
If you execute my script you see what Mikrotik uses, sorry not providing script for Windows, maybe someday a write down powershell script as well:
Bash shell:
#!/bin/bash
echo Mikrotik Versions of RouterOS/Firmware.
echo Ver 6
echo long-term = $(curl -s http://upgrade.mikrotik.com/routeros/NEWEST6.long-term | cut -f1 -d' ')
echo stable = $(curl -s http://upgrade.mikrotik.com/routeros/NEWEST6.stable | cut -f1 -d' ')
echo testing = $(curl -s http://upgrade.mikrotik.com/routeros/NEWEST6.testing | cut -f1 -d' ')
echo development = $(curl -s http://upgrade.mikrotik.com/routeros/NEWEST6.development | cut -f1 -d' ')
echo
echo Ver 7
echo long-term = $(curl -s http://upgrade.mikrotik.com/routeros/NEWEST7.long-term | cut -f1 -d' ')
echo stable = $(curl -s http://upgrade.mikrotik.com/routeros/NEWEST7.stable | cut -f1 -d' ')
echo testing = $(curl -s http://upgrade.mikrotik.com/routeros/NEWEST7.testing | cut -f1 -d' ')
echo development = $(curl -s http://upgrade.mikrotik.com/routeros/NEWEST7.development | cut -f1 -d' ')
echo
echo "Ver > 7.12"
echo long-term = $(curl -s http://upgrade.mikrotik.com/routeros/NEWESTa7.long-term | cut -f1 -d' ')
echo stable = $(curl -s http://upgrade.mikrotik.com/routeros/NEWESTa7.stable | cut -f1 -d' ')
echo testing = $(curl -s http://upgrade.mikrotik.com/routeros/NEWESTa7.testing | cut -f1 -d' ')
echo development = $(curl -s http://upgrade.mikrotik.com/routeros/NEWESTa7.development | cut -f1 -d' ')
Windows Powershell:
Write-Output "Mikrotik RouterOS Versions"
$versions = @("6", "7", "a7")
$channels = @("long-term", "stable", "testing", "development")
foreach ( $version in $versions )
{
Write-Output "Version ${version}"
foreach ( $channel in $channels )
{
$Content = Invoke-RestMethod -Uri "http://upgrade.mikrotik.com/routeros/NEWEST${version}.${channel}"
$Content = $Content -replace "`n", ""
Write-Output "${channel} = ${Content}"
}
Write-Output ""
}
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 12:36 pm
by Cha0s
If you read the title it says testing.
Change channel
stable = 7.14.2
testing = 7.15beta9
development = 7.15beta8
Up until beta8 it was (and still is) in development channel. As beta versions usually are.
I've always used development channel in v7 to get the latest beta.
Now they remembered that there's a testing channel? IMHO in testing channel there should be the rc releases.
In any case, MikroTik's channels have always been confusing, not following any naming standard, so I should have known better and tested all channels to find the latest beta...
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 2:27 pm
by SkyBeam
Up until beta8 it was (and still is) in development channel. As beta versions usually are.
I've always used development channel in v7 to get the latest beta.
Now they remembered that there's a testing channel? IMHO in testing channel there should be the rc releases.
I don't know if there is a commonly accepted naming convention for channels similar to versioning (
https://semver.org/). However also I was under impression that typical development cycle is:
- dev: Development and alpha or beta versions with known and unknown bugs built right from the latest code commits. Typically daily and automatic builds which might also be completely broken.
- testing: Public testing channel, typically containing release candidates with builds marked as "potentially stable" to open up testing for a wider audience with the purpose of finding less common issues in specific configuration at customer environments with technically skilled staff knowing the risks of installing non-stable software.
- stable: Releases widely tested and with no known blocker issues found in testing channel.
- long-term: Oldie but goldie. Remaining at the same functional level, getting only security and functional fixes, no new features for the sake of stability.
Obviously releasing a version to testing channel before it even made an appearance in dev channel is somehow weird.
In any case on my CRS310-1G-5S-4S+ any release after 7.12.1 was broken not bringing up any of my 1Gbps RJ45 copper SFP modules. Will test 7.15 when it's marked stable.
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 4:43 pm
by NickOlsen
Very interested to hear if anyone gets the new ARM64 CHR images running on the oracle cloud AMPRE instances. I've tried for a few hours and the closest I've gotten is the VM starts to boot CHR and then says ERROR: no system package found! and kernel panics and reboots. That was with UEFI and Paravirtual disk access. BIOS and any other sort of disk type results in either a UEFI boot failure screen (startup.nsh or whatever), or just nothing on the console.
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 5:10 pm
by pe1chl
Up until beta8 it was (and still is) in development channel. As beta versions usually are.
Well, now they have set the development channel to 7.15beta9 as well...
Apparently it is easy to set testing and development to any version, but difficult to set long-term to 7.12.1
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 7:04 pm
by Jotne
On my routers, 7.15beta9 are listed both under testing and development. So its not clear what is what
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 7:12 pm
by pe1chl
They are the same, as they always are. It is not clear why there is a separate "development" and "testing" channel, it only causes mistakes and confusion.
"development" could be some daily-build or alpha channel, but MikroTik does not publicly release alpha versions, they are sent only to people reporting a problem in some cases, and that does not work via the "release channel" mechanism.
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 7:48 pm
by massinia
Script error after reset to default configuration with hAP Lite and ROS 7.15beta9 (SUP-148968):
error while running default configuration script: syntax error (line 160 column 7)
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 8:35 pm
by infabo
but MikroTik does not publicly release alpha versions
Sure they are published on testing channel. 🤔
Re: v7.15beta [testing] is released!
Posted: Wed Apr 03, 2024 9:20 pm
by Wintermute
7.15beta9 seems to be a rotten potato. hAP Ax3 drops 5GHz Wi-Fi clients like crazy.
Log polluted with endless stream of messages like:
diconnected, connection lost
disassociated, SA Query timeout
Reverting to 7.15beta8.
Re: v7.15beta [testing] is released!
Posted: Thu Apr 04, 2024 8:06 am
by chris6671980309
On both of my RBD53iG-5HacD2HnD health missing "cpu-temperature" is this normal?
Re: v7.15beta [testing] is released!
Posted: Thu Apr 04, 2024 9:01 am
by infabo
Re: v7.15beta [testing] is released!
Posted: Thu Apr 04, 2024 2:16 pm
by Sit75
I have tested RouterOS 7.15beta9 on hAP ac^2 with 256 MB memory and it seems that "we are back in good times". :-). After stripping some waste from RouterOS, I have free roughly 800 kB with full configuration, what is good result. Even memory leakage, what was visible in beta4, probably disappeared. Good job!
Re: v7.15beta [testing] is released!
Posted: Thu Apr 04, 2024 2:18 pm
by infabo
Thanks for testing, Sit75. This is good news! 🥳
Re: v7.15beta [testing] is released!
Posted: Thu Apr 04, 2024 3:34 pm
by lubomirs
I have tested RouterOS 7.15beta9 on hAP ac^2 with 256 MB memory and it seems that "we are back in good times". :-). After stripping some waste from RouterOS, I have free roughly 800 kB with full configuration, what is good result. Even memory leakage, what was visible in beta4, probably disappeared. Good job!
Just to add: with which wifi package?
Re: v7.15beta [testing] is released!
Posted: Thu Apr 04, 2024 3:58 pm
by Sit75
I have tested RouterOS 7.15beta9 on hAP ac^2 with 256 MB memory and it seems that "we are back in good times". :-). After stripping some waste from RouterOS, I have free roughly 800 kB with full configuration, what is good result. Even memory leakage, what was visible in beta4, probably disappeared. Good job!
Just to add: with which wifi package?
With Qualcomm Wave 2 drivers. I encountered only one drawback - the Mikrotik iOS application is not fully compatible with RouterOS 7.15beta9, especially the WiFi part - for example, the application does not show the SSID and the configuration on the main page does not work. But it only applies to the iOS app. Winbox works fine.
Btw, the upgrade was done by Netinstall (64bit) with the preserve configuration checkbox.
Re: v7.15beta [testing] is released!
Posted: Thu Apr 04, 2024 9:54 pm
by pe1chl
I upgraded the LHG 5ac I use for testing (only) from beta6 to beta9 and the Free HDD space went from 188 to 844 KiB!
(using the new WiFi driver)
So that is good!
However I cannot upgrade my hAP ac2 until the dynamic VLAN assignment per user on WiFi interfaces (via accesslist and RADIUS) is back.
Re: v7.15beta [testing] is released!
Posted: Fri Apr 05, 2024 10:03 am
by domagoj
Hi
Has anyone tested if capsman vlan assignment per SSID works with new wave2 drivers?
Is there updated wifi chipset support for new drivers or its the same? We have a lot of routerboards with plenty of space and with minipcie wifi modules, and would love to be able to upgrade them with new dual band ax modules, if they are supported by wave2 drivers..
Re: v7.15beta [testing] is released!
Posted: Fri Apr 05, 2024 11:02 am
by pajapatak
Testing ROS7.15beta9 on hAP ac3 (wifi-qcom-ac) resulted in random reboots every few hours.This behavior was noticed already in 7.14 (stable), while version 7.13.1 (stable) worked just fine. The only extra package is container. Support ticket [SUP-149159] created.
Re: v7.15beta [testing] is released!
Posted: Fri Apr 05, 2024 11:34 am
by WeWiNet
hap-ac2, 5Ghz Wifi interface in station-bridge mode, Wifi is randomly not working.
It won't connect to its AP.
Trying to do a scan will not work/ no Wifi SSID shown.
Nothing at all in the debug logs.
The AP (hap-ax3) has nothing in his debug logs, AP not receiving any packet from the station.
This is very annoying, I have 3 of hap-ac2 as range extenders around an hap-ax3 and they just hang without connecting.
This was never present in previous releases.
Re: v7.15beta [testing] is released!
Posted: Fri Apr 05, 2024 11:37 am
by pe1chl
Did you update both sides? Maybe the bridging protocol in the "wifi-qcom - updated driver" is subtly different from the previous one?
Re: v7.15beta [testing] is released!
Posted: Fri Apr 05, 2024 11:38 am
by bighead
Hi
Has anyone tested if capsman vlan assignment per SSID works with new wave2 drivers?
Is there updated wifi chipset support for new drivers or its the same? We have a lot of routerboards with plenty of space and with minipcie wifi modules, and would love to be able to upgrade them with new dual band ax modules, if they are supported by wave2 drivers..
Capsman vlan assignment working with CAP AX(probably on all AX devices) but you need to create a bridge with VLAN filtering and create your VLANs ID on each CAP manually.
On AC devices is not working.
Re: v7.15beta [testing] is released!
Posted: Fri Apr 05, 2024 1:32 pm
by fs0c13ty
please add kvm and extra-nic package for x86 to cdn.mikrotik.com so routeros can fetch them during update.
it raise package not found (404) and must be installed via iso file.
Re: v7.15beta [testing] is released!
Posted: Fri Apr 05, 2024 2:48 pm
by hadesinua
Noticed a typo in the debug message while experimenting with 7.15beta9:
"assocation rejected, does not have matching pairwise cipher"
assocation = association?
Re: v7.15beta [testing] is released!
Posted: Fri Apr 05, 2024 7:59 pm
by dwnldr
SPAM here, since lot of comments are aiming storage issues... In my opinion :
Maybe ROSv6 "package style" where only basic functions was involved in the main package and everything else could be added from extra packages is better way as 5different wireless sets :) But let guys decide which way is better
Re: v7.15beta [testing] is released!
Posted: Fri Apr 05, 2024 8:01 pm
by dwnldr
I have tested RouterOS 7.15beta9 on hAP ac^2 with 256 MB memory and it seems that "we are back in good times". :-). After stripping some waste from RouterOS, I have free roughly 800 kB with full configuration, what is good result. Even memory leakage, what was visible in beta4, probably disappeared. Good job!
How did you managed that please ? As far as i know, ROS7 needs to have specific checksum to be able to install it via netinstall and therefore cannot be touched. My goal would be exactly to remove unused "stuff". Was exactly mentioning this in my previous post.
Thank you !
Re: v7.15beta [testing] is released!
Posted: Fri Apr 05, 2024 8:56 pm
by infabo
...by just netinstalling beta9? As stated. No hacks.
Re: v7.15beta [testing] is released!
Posted: Fri Apr 05, 2024 9:07 pm
by dwnldr
if your reply was aimed to me, then "...after stripping some waste from RouterOS, I have free roughly 800 kB with full configuration, what is good result"... gives me reason to think that something was customized by user
Re: v7.15beta [testing] is released!
Posted: Fri Apr 05, 2024 9:14 pm
by holvoetn
Netinstall does the stripping of the waste.
Normal upgrade usually results in leftovers.
Re: v7.15beta [testing] is released!
Posted: Fri Apr 05, 2024 10:43 pm
by pe1chl
Maybe they added some cleanup code, as I mentioned above after an upgrade to beta9 my Free HDD space went from 188 to 844 KiB!
So this was not using netinstall, just an upgrade from within RouterOS.
I think (but I am not sure) that this device was upgraded from v6, not netinstalled, so it may be that they finally are deleting v6 configuration files.
Re: v7.15beta [testing] is released!
Posted: Sat Apr 06, 2024 10:21 pm
by npeca75
is there ANY chance that MT implement DPSK on WIFI ?
Dynamic selection of VLANs based on passphrase ?
don't care if it is old-wireless, new-wireless, capsman, call-it-as-you-want
WIFI->Access List -> allow use multiple empty mac address and use combination of passphrase+vlanid
until then, we are doomed of flashing OWRT on MT devices ...
Re: v7.15beta [testing] is released!
Posted: Sun Apr 07, 2024 12:34 am
by Kevdevon
Issue with the Mikrotik Audience, QCA9984 stuck on "selecting channel' after second radar detection.
This hasn't happened with previous beta firmware.
Re: v7.15beta [testing] is released!
Posted: Sun Apr 07, 2024 3:09 pm
by Kevdevon
Issue with the Mikrotik Audience, QCA9984 stuck on "selecting channel' after second radar detection.
This hasn't happened with previous beta firmware.
When you disable and re-enable the interface, the status stays as 'disabled'.
My understanding is that the router can't use a DFS channel for 30 minutes once something is detected.
I'm guessing this is broken in this version? Did the audience get a firmware update for the wifi cards?
The system has been rebooted to upgrade the firmware, under system, RouterBOARD.
Re: v7.15beta [testing] is released!
Posted: Mon Apr 08, 2024 6:12 am
by UpRunTech
7.15beta9 seems to be a rotten potato. hAP Ax3 drops 5GHz Wi-Fi clients like crazy.
Log polluted with endless stream of messages like:
diconnected, connection lost
disassociated, SA Query timeout
Reverting to 7.15beta8.
Same with beta 9, getting SA query timeouts and roaming fails on a late model iPad Air and a laptop with an AX200 that worked and roamed with no problems on previous versions.The iPad started asking for the password again and it kept being rejected until I forgot the network, powered the iPad off and on and rejoined. Using a 5009 with 2x hAPAX^2. I suspect the "*) wifi-qcom - updated driver;" is the culprit. A bit late in the beta cycle to be dropping in newer drivers.
Re: v7.15beta [testing] is released!
Posted: Mon Apr 08, 2024 8:55 am
by infabo
A bit late in the beta cycle to be dropping in newer drivers.
LOL? Seems not to be easy for MT. add drivers in a testing release: people moan. Exchange drivers in beta (!) release: people moan. Exchange drivers at all: people moan. 🤣
Re: v7.15beta [testing] is released!
Posted: Mon Apr 08, 2024 7:11 pm
by merkkg
You forgot to add also if they don't change driver people moan
Re: v7.15beta [testing] is released!
Posted: Wed Apr 10, 2024 11:02 am
by Kevdevon
Mikrotik Audience, wifi, 2.4Ghz reconnects occurring on a regular basis. Strong signal, logs just show reconnecting.
I’ll stick with this for a bit longer for diagnostics.
Currently have an open ticket with support file: SUP-149531
Re: v7.15beta [testing] is released!
Posted: Sat Apr 13, 2024 2:32 am
by gunther01
We seem to be having issues with BGP with this version. I really don't have a baseline to go off of, except 7.14.2 seems to be working.
In one case, I have two ospf advertise default routes from two routers pointed towards a FW. That firewall only shows one default route. Shouldn't it show both, but then have one that is active and the other that is not??
We have had issues with our bgp filters seem to not either work. Or not show our advertised routes in rout bgp ad print commands..
Just random things when working with new bgp servers. It seems wonky, and doesn't "act" like we think it should when doing commands. Like I'm not showing advertisements, but the peer is seeing them at times.
Re: v7.15beta [testing] is released!
Posted: Sat Apr 13, 2024 11:10 am
by mrz
route will not show if that router is also originating default route and one of the other two routers selected it as best.
Re: v7.15beta [testing] is released!
Posted: Sat Apr 13, 2024 3:28 pm
by gunther01
route will not show if that router is also originating default route and one of the other two routers selected it as best.
I'm talking about the router that is receiving from two routers sending originate default. It would be the router choosing which one to pick that doesn't show both routers. Wouldn't it be an eigrp situation then? Or at least show both defaults and then have picked one in its table??
Re: v7.15beta [testing] is released!
Posted: Sat Apr 13, 2024 4:23 pm
by bajodel
ehm.. you mean ECMP, it can be but only if the two routes have the same cost (to reach both devices advertising the default).
And yes, you should see at least one of them in the routing table (as long as you do not have another better default from another source, or you are filtering it).
Re: v7.15beta [testing] is released!
Posted: Sat Apr 13, 2024 4:43 pm
by gunther01
ehm.. you mean ECMP, it can be but only if the two routes have the same cost (to reach both devices advertising the default).
And yes, you should see at least one of them in the routing table (as long as you do not have another better default from another source, or you are filtering it).
Yes, ECMP lol..
These other two routers are directly connected to the 3 that is getting the defaults from the other two. So, should be the same cost(s) I do see them both in the OSPF LSA table. So, the router is getting both. I just find it odd that the main table doesn't show both, and that it's choosing one over the other in there. ie not listing both, and then showing one as active and the other not.. No filters enabled on OSPF.
We still had some weirdness with bgp and the router not showing advertised routes. Or even showing routes in the main table.. So, while I can't quite prove my "feelings" here. Some things seem weird, and we went back to the stable for a working config.
Re: v7.15beta [testing] is released!
Posted: Sat Apr 13, 2024 5:14 pm
by Kevdevon
ehm.. you mean ECMP, it can be but only if the two routes have the same cost (to reach both devices advertising the default).
And yes, you should see at least one of them in the routing table (as long as you do not have another better default from another source, or you are filtering it).
Yes, ECMP lol..
These other two routers are directly connected to the 3 that is getting the defaults from the other two. So, should be the same cost(s) I do see them both in the OSPF LSA table. So, the router is getting both. I just find it odd that the main table doesn't show both, and that it's choosing one over the other in there. ie not listing both, and then showing one as active and the other not.. No filters enabled on OSPF.
We still had some weirdness with bgp and the router not showing advertised routes. Or even showing routes in the main table.. So, while I can't quite prove my "feelings" here. Some things seem weird, and we went back to the stable for a working config.
I'm assuming it is only showing the installed routes in the routing table, OSPF will release the inactive route when it becomes active. Less items in the routing table result in faster speeds.
Re: v7.15beta [testing] is released!
Posted: Sat Apr 13, 2024 6:04 pm
by gunther01
Yes, ECMP lol..
These other two routers are directly connected to the 3 that is getting the defaults from the other two. So, should be the same cost(s) I do see them both in the OSPF LSA table. So, the router is getting both. I just find it odd that the main table doesn't show both, and that it's choosing one over the other in there. ie not listing both, and then showing one as active and the other not.. No filters enabled on OSPF.
We still had some weirdness with bgp and the router not showing advertised routes. Or even showing routes in the main table.. So, while I can't quite prove my "feelings" here. Some things seem weird, and we went back to the stable for a working config.
I'm assuming it is only showing the installed routes in the routing table, OSPF will release the inactive route when it becomes active. Less items in the routing table result in faster speeds.
Sure. But it doesn't work that way with BGP routes.. so why with OSPF...?
Re: v7.15beta [testing] is released!
Posted: Mon Apr 15, 2024 10:26 pm
by nithinkumar2000
I think Mikrotik can think of ECMP with BGP Also... Which will unlock more possibilities
Re: v7.15beta [testing] is released!
Posted: Mon Apr 15, 2024 11:32 pm
by gunther01
I think Mikrotik can think of ECMP with BGP Also... Which will unlock more possibilities
It can, and shows routes in the main FIB for multiple devices just fine.. It even shows routes for ECMP that aren't default originates just fine in the proper way as well.. Just not two default originate routes in the main fib properly.. It only shows the one that it picked. So, it gets confusing. You aren't sure if you are getting both routes until you check LSA's
Re: v7.15beta [testing] is released!
Posted: Mon Apr 15, 2024 11:35 pm
by fischerdouglas
I think Mikrotik can think of ECMP with BGP Also... Which will unlock more possibilities
I could be wrong...
But ECMP is not a RIB thing, but a FIB thing.
I don't know what this is like in the MikroTik world, but you can have ECMP even with static routes.
But in general, talking about ECMP without talking about TE, and especially without RSVP, doesn't make much sense.
Re: v7.15beta [testing] is released!
Posted: Tue Apr 16, 2024 9:34 am
by burn3r
Lots of ext4 USB stick container problems with hAP ax³ and 7.14.2 or 7.15beta9, downgrade to 7.13.5 and everything works:
viewtopic.php?t=206110
Re: v7.15beta [testing] is released!
Posted: Tue Apr 16, 2024 9:51 am
by holvoetn
Lots of ext4 USB stick container problems with hAP ax³ and 7.14.2 or 7.15beta9, downgrade to 7.13.5 and everything works:
viewtopic.php?t=206110
Based on TWO reports, why do you say LOTS ?
Besides, you're cross-posting, you know ...
Re: v7.15beta [testing] is released!
Posted: Tue Apr 16, 2024 1:55 pm
by gigabyte091
I'm not having any problem with USB stick on ax3 at my parents house. Its some no name 64G stick. Working without a problem on 15beta9.
Re: v7.15beta [testing] is released!
Posted: Tue Apr 16, 2024 2:20 pm
by pajapatak
Lots of ext4 USB stick container problems with hAP ax³ and 7.14.2 or 7.15beta9, downgrade to 7.13.5 and everything works:
viewtopic.php?t=206110
Based on TWO reports, why do you say LOTS ?
Besides, you're cross-posting, you know ...
I can add the third report (not ax3, though) :) And, for what it's worth, the support has managed to reproduce the problem:
[SUP-149159] At the moment we have been able to replicate the issue you are having, it's software bug we are working on,
Re: v7.15beta [testing] is released!
Posted: Tue Apr 16, 2024 2:24 pm
by holvoetn
Based on TWO reports, why do you say LOTS ?
I can add the third report (not ax3, though)

And, for what it's worth, the support has managed to reproduce the problem:
[SUP-149159] At the moment we have been able to replicate the issue you are having, it's software bug we are working on,
If I read you initial mentioning of this ticket number correctly, the behavior is different.
In your case, the device randomly reboots.
In the case of burn3r and LOTS of others, the USB stick simply gets corrupt and unusable anymore.
Re: v7.15beta [testing] is released!
Posted: Tue Apr 16, 2024 3:17 pm
by bbs2web
Any chance we could please fix DHCP snooping please?
CRS devices (CRS112-8P-4S, CRS328-24P-4S+, CRS326-24G-2S+ and CRS354-4S+-2Q+) drop DHCP requests when we enable dhcp snooping and there are VLANs configured. Yes, the 'trusted=yes' is correct set on the uplink port.
Herewith a summary of the switch configuration:
https://imgur.com/a/4aYzTtY
Herewith the export from 7.14.2:
/interface bridge
add admin-mac=78:9A:18:3D:26:5F auto-mac=no dhcp-snooping=yes name=bridge priority=0x7000 vlan-filtering=yes
/interface bridge port
add bpdu-guard=yes bridge=bridge interface=ether1 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether2 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether3 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether4 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether5 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether6 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether7 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether8 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether9 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether10 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether11 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether12 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether13 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether14 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether15 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether16 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether17 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether18 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether19 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether20 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether21 pvid=17 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether22 pvid=17 restricted-role=yes
add bridge=bridge interface=ether23 pvid=25 restricted-role=yes
add bridge=bridge interface=ether24 pvid=25 restricted-role=yes
add bridge=bridge interface=sfp-sfpplus1 trusted=yes
add bpdu-guard=yes bridge=bridge interface=sfp-sfpplus2 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=sfp-sfpplus3 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=sfp-sfpplus4 restricted-role=yes
/interface bridge vlan
add bridge=bridge tagged="bridge,ether1,ether2,ether3,ether4,ether7,ether8,ether9,ether10,ether11,ether12,ether13,ether14,ether15,ether16,ether17,eth\
er18,ether19,ether20,ether21,ether22,sfp-sfpplus1" vlan-ids=14
add bridge=bridge tagged=bridge,sfp-sfpplus1 vlan-ids=17
add bridge=bridge tagged=bridge,sfp-sfpplus1 vlan-ids=25
add bridge=bridge tagged=bridge,sfp-sfpplus1 vlan-ids=31
add bridge=bridge tagged=bridge,ether5,ether6,sfp-sfpplus1 vlan-ids=100
add bridge=bridge tagged=bridge,ether5,ether6,sfp-sfpplus1 vlan-ids=101
add bridge=bridge tagged=bridge,ether5,ether6,sfp-sfpplus1 vlan-ids=102
add bridge=bridge tagged=bridge,ether5,ether6,sfp-sfpplus1 vlan-ids=666
add bridge=bridge tagged=bridge,ether5,ether6,sfp-sfpplus1 vlan-ids=667
/ip neighbor discovery-settings
set lldp-med-net-policy-vlan=14
Re: v7.15beta [testing] is released!
Posted: Tue Apr 16, 2024 3:20 pm
by burn3r
By lots I meant that I had a lot of different problems (mounting the USB stick, formatting to ext4, creating/extracting/importing container etc) when I tried to re-create Pi-hole container to a new USB stick with 7.14.2 and 7.15beta9, but after downgrading to 7.13.5 everything worked like they should.
The last time I created one was with 7.13.x version, and it worked just fine when I upgraded to 7.14.1, but the USB stick filesystem went read-only with 7.14.2, so it got corrupted or USB stick broke, and when I tried to re-create a new one with new USB sticks I couldn't. After founding the topic that I linked, and downgrading to 7.13.5 everything went smoothly, formatting the USB stick with ext4, creating Pi-hole container and starting it. All of those steps failed at some point with 7.14.2 and 7.15beta9, and if by some miracle the container was imported successfully then the container start would loop with the read-only filesystem error. None of those are happening with 7.13.5, so something has been broken with the newer versions.
Re: v7.15beta [testing] is released!
Posted: Tue Apr 16, 2024 3:55 pm
by holvoetn
And still you refer to LOTS of problems but it's only you ?
None of those are happening with 7.13.5, so something has been broken with the newer versions.
I am not saying you did not see those problems. But I am not (yet) convinced it's related to the ROS versions you refer to.
I have pihole running via container on USB stick via RB5009 (same ARM64), using every single ROS7 version you can think of since I have that router (currently 7.15b9).
I also have other containers running on usb stick on AX3 (7.15b9).
So it's not a generic problem or I would see it too. What's different then ? Most likely config.
I suggest you create a new topic detailing exactly all the steps you did with full disclosure of your config so others can review.
If we can not find the mistake / config error, I suggest you create a support ticket (in case you haven't already) with reference to that thread.
Re: v7.15beta [testing] is released!
Posted: Tue Apr 16, 2024 4:58 pm
by riv
IS-IS to non-MikroTik is not working, tried with Cisco and Juniper
Cisco is not receiving IIH message from MikroTik
Network type broadcast, stuck in INIT state
Network type ptp, neighbor not coming up at all
Re: v7.15beta [testing] is released!
Posted: Tue Apr 16, 2024 5:45 pm
by mrz
isis to cisco works for me and there are no isis changes that could break isis with cisco in v7.15beta versions. There must be something specific to your config which is not related to v7.15release
Re: v7.15beta [testing] is released!
Posted: Tue Apr 16, 2024 6:08 pm
by loloski
Yeah it's working fine with cisco in GNS3
2.png
1.png
Re: v7.15beta [testing] is released!
Posted: Wed Apr 17, 2024 1:07 am
by riv
isis to cisco works for me and there are no isis changes that could break isis with cisco in v7.15beta versions. There must be something specific to your config which is not related to v7.15release
Ok I just found something interesting
When I configure the link with MTU 1500, the neighbor came up
So maybe the IS-IS in MT is not ready for jumbo frame?
Re: v7.15beta [testing] is released!
Posted: Wed Apr 17, 2024 2:04 pm
by burn3r
FYI, I contacted
support@mikrotik.com about my issue above. I will keep you posted once I know more. Sorry for the trouble, just tried to be helpful.
And to be clear, the problem is not running the container, it's creating a new ext4 USB stick & Pi-hole container to it. I was only able to get it done with 7.13.5. Not with 7.14.2 or 7.15beta9. I believe if I would now update to either of those the container would work, but I would not be able create a new one once the USB stick gets corrupted or broken. Because I was running 7.14.1 successfully for a long time with the old USB stick & Pi-hole container in it.
Re: v7.15beta [testing] is released!
Posted: Wed Apr 17, 2024 3:31 pm
by own3r1138
And still you refer to LOTS of problems but it's only you ?
viewtopic.php?t=205246#p1063059
Re: v7.15beta [testing] is released!
Posted: Wed Apr 17, 2024 5:10 pm
by hats
7.15beta9 seems to be a rotten potato. hAP Ax3 drops 5GHz Wi-Fi clients like crazy.
Log polluted with endless stream of messages like:
diconnected, connection lost
disassociated, SA Query timeout
Reverting to 7.15beta8.
Same with beta 9, getting SA query timeouts and roaming fails on a late model iPad Air and a laptop with an AX200 that worked and roamed with no problems on previous versions.The iPad started asking for the password again and it kept being rejected until I forgot the network, powered the iPad off and on and rejoined. Using a 5009 with 2x hAPAX^2. I suspect the "*) wifi-qcom - updated driver;" is the culprit. A bit late in the beta cycle to be dropping in newer drivers.
I have had same behavior with CAP AX and 7.14.2. Looks like it won't be fixed in 7.15 release. Downgraded ros to 7.10.2 - looks like it is the last version with working FT aka roaming.
Re: v7.15beta [testing] is released!
Posted: Wed Apr 17, 2024 6:36 pm
by ormandj
Same with beta 9, getting SA query timeouts and roaming fails on a late model iPad Air and a laptop with an AX200 that worked and roamed with no problems on previous versions.The iPad started asking for the password again and it kept being rejected until I forgot the network, powered the iPad off and on and rejoined. Using a 5009 with 2x hAPAX^2. I suspect the "*) wifi-qcom - updated driver;" is the culprit. A bit late in the beta cycle to be dropping in newer drivers.
I have had same behavior with CAP AX and 7.14.2. Looks like it won't be fixed in 7.15 release. Downgraded ros to 7.10.2 - looks like it is the last version with working FT aka roaming.
Is there a SUP id for this? I'd like to reference it/other people in this thread might like to reference it. I've been seeing a lot of the same, and would prefer to piggyback on existing issues, as surely MT is aware of it by this point with how often it's been mentioned in this thread and the previous 7.14.x thread.
Re: v7.15beta [testing] is released!
Posted: Wed Apr 17, 2024 9:20 pm
by hats
I have had same behavior with CAP AX and 7.14.2. Looks like it won't be fixed in 7.15 release. Downgraded ros to 7.10.2 - looks like it is the last version with working FT aka roaming.
Is there a SUP id for this? I'd like to reference it/other people in this thread might like to reference it. I've been seeing a lot of the same, and would prefer to piggyback on existing issues, as surely MT is aware of it by this point with how often it's been mentioned in this thread and the previous 7.14.x thread.
No there is not any SUP. I have managed to get it working by downgrading to 7.10.2 and now i do not have any spare devices and free time to deep dive in it.
Re: v7.15beta [testing] is released!
Posted: Wed Apr 17, 2024 10:59 pm
by Rox169
Hi,
Is Mikrotik on holiday :) ? So long and no new beta?
Re: v7.15beta [testing] is released!
Posted: Thu Apr 18, 2024 12:39 am
by h1ghrise
My support ticket got closed, stating that the issue I reported was fixed and the fix will be included in a RouterOS release in the upcoming days. So lets see about that ;)
Re: v7.15beta [testing] is released!
Posted: Thu Apr 18, 2024 9:00 am
by burn3r
Response from support to my ext4 USB stick ticket:
"This issue is already fixed and will be included in upcomming RouterOS version."
Re: v7.15beta [testing] is released!
Posted: Fri Apr 19, 2024 1:00 am
by nz_monkey
Hi,
Is Mikrotik on holiday

? So long and no new beta?
Yes, they would have been on holiday and are probably in catch up mode now.
Re: v7.15beta [testing] is released!
Posted: Fri Apr 19, 2024 12:28 pm
by EdPa
Version 7.15rc1 has been released.
viewtopic.php?t=206877