*) bridge - added MLAG support for MSTP bridges;
*) bridge - added MVRP support (CLI only);
*) bridge - improved bridge VLAN configuration validation;
*) bridge - improved configuration speed on large VLAN setups;
*) bridge - improved protocol-mode MSTP functionality;
*) bridge - improved protocol-mode STP and RSTP functionality;
*) bridge - make "point-to-point=yes" default value for non-wireless bridge ports;
*) ovpn - added support for pushing routes;
*) system - expose "lo" interface;
Nice, thank you!*) bridge - try to set wireless bridge ports as edge ports automatically;
ethernet - resolved minor memory leak while processing packets;
did you test it yet? currious if it really worksno more fake loopback bridges required for ospf :)Code: Select all*) system - expose "lo" interface;
Nice*) system - expose "lo" interface;
And AFAIK it still cannot be applied "by hand" in 7.14, but trying to fq_codel on an interface returns same as previous versions:*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;
Tested and it worksdid you test it yet? currious if it really worksno more fake loopback bridges required for ospf :)Code: Select all*) system - expose "lo" interface;
That's true, physically ports can use "non rate limit" queues.I think the "failure: non rate limit queues are useless on this interface" warning is just if you try to assign a queue to the bridge, as opposed to just one of the ethernet ports.
e.g. what does "wired port" mean in the context of an LTE device's defconf...as the default configuration of an LTE device uses a bridge...*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;
That's true, physically ports can use "non rate limit" queues.I think the "failure: non rate limit queues are useless on this interface" warning is just if you try to assign a queue to the bridge, as opposed to just one of the ethernet ports.
But still not sure what the change does...
e.g. what does "wired port" mean in the context of an LTE device's defconf...as the default configuration of an LTE device uses a bridge...*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;
/queue type add name=fq-codel-ethernet-default kind=fq-codel fq-codel-ecn=no
/queue interface set [find default-queue=only-hardware-queue] queue=fq-codel-ethernet-default
I don't want to get my hopes up. I've only been requesting VTI since 2009....hmm, since we already have Loopback interfaces, maybe "soon" we will also see VTI interfaces :p
VRF HW forwarding support for CRS3xx/5xx and CCR2116/2216 incoming ?next to loopback interfaces tab, we have also vrf interfaces tab .. ?! what the heck ?
One example is you don't need to create a dummy bridge interface when terminating an EoIP tunnel at the router. Or anything that needs an IP set on a non-physical interface on the router itself. Correct me if I'm wrong.Tell me please, what are the advantages of a "exposed lo" interface over the old way?
I seen mention that it potentially can fix issue with MPLS VPN4 security firewall bug.Tell me please, what are the advantages of a "exposed lo" interface over the old way?
After updating to v7.14beta3, I noticed that my hAP ac3 is reverting vlan-mode settings in /interface/ethernet/switch/port to vlan-mode=disabled instead of the vlan-mode=fallback that was set before. This is happening on every reboot, even after setting to vlan-mode=fallback again.
Yes, openvpn in Linux is still far more flexible, with CCD and the ability to push any configuration, not only routes. Still it's progressing quite fast on Mikrotik, so I hope it will become as complete and flexible as it's in Linux.Just notice push route is in the ovpn server setting not per secret/user basis? I hope MT would make it more flexible
*) api - improved REST API stability when processing invalid requests;
And both are spelled in lowercase, while other interface types have a capital first letter and VRF is spelled all-caps in other places.next to loopback interfaces tab, we have also vrf interfaces tab .. ?! what the heck ? ;-)
Does this include fixes for CVE-2023-48795 - or is RouterOS already not vulnerable?*) ssh - refactored SSH service internal processes;
Upgraded KNOT working as Modbus TCP-to-RTU gateway, fingers crossed...*) iot - fixed modbus partial frame reception issue;
*) iot - improved modbus Tx/Rx switching behaviour;
I do agree. That would be the right thing to do. I always hide them. And now I know that FP in the column name stands for FastPath :) Thanks.Suggestion: can the 4 "FP" counters be removed from the default colums shown in winbox?
These were probably added when someone was very proud of having Fast Path, but they are not very relevant anymore.
And those who want to see them can always use the column selector to enable them again...
Code: Select all/queue type add name=fq-codel-ethernet-default kind=fq-codel fq-codel-ecn=no /queue interface set [find default-queue=only-hardware-queue] queue=fq-codel-ethernet-default
The fq_codel type is set for wired (Ethernet, SFP) interfaces in order to reduce bufferbloat. No interface queue for LTE interface itself.
That's true, physically ports can use "non rate limit" queues.
But still not sure what the change does...
e.g. what does "wired port" mean in the context of an LTE device's defconf...as the default configuration of an LTE device uses a bridge...
I'm not an expert, but I think @dtaht said somewhere that ECN off is a safer default as it can cause conflicts at times when it doesn't get what it expects?Why turning off ECN?
Default config is not applied when you upgrade. You can reset to defaults or add the new config manually.I was curious about the setup of this new queue and I upgraded a LtAP-mini to v7.14beta3. However, no new queue was created or applied to any interface. Am I doing something wrong?
Question does MVRP implementation will be vendor neutral? Once it become stable?
Why would you ever use OVPN between MikroTik routers?ovpn - MT<-->MT is totally broken, unlike MT--->windows.
Why is MikroTik loading wireless package into CCR models? Please explain WHY! This makes ABSOLUTLY no sense to me ...
Well, I certainly consider it a step backward that almost all functionality is now in a single "routeros" package.Why is there always OVPN ? IPSEC ? MPLS ? BGP ? ...
Same question. Not everyone needs it everywhere.
It's part of the main package. Don't use what you don't want to use.
1. When upgrading by using "check-for-updates", all versions earlier than 7.12 will display 7.12 as the latest available version. Upgrade from v7.12 to v7.13 or later versions must be done through 7.12 in order to convert wireless packages automatically. Fresh installation with Netinstall or manual package installation works in the same manner as always.
7.13 should be called 8.Of course! That is not going away... always first upgrade to 7.12 or 7.12.1
Rather the opposite, "no new features", but fixes may still come (with the third version number increasing).- "stable" means "no more fixes" :we moved on to new features
Mikrotik is not the only vendor doing this. GitLab is doing a similar thing (making minor versions a mandatory stop on the upgrade path) from time to time, if you wish an example.- point release are "blocking" paths in upgrades
The selling point of ROS 7 was: "we merged everything into a single ROS bundle."Well, I certainly consider it a step backward that almost all functionality is now in a single "routeros" package.
That I do understand :)Of course! That is not going away... always first upgrade to 7.12 or 7.12.1
*) bridge - added MVRP support (CLI only);
Oh common, new user interested in beta versions is either full of adrenaline or plain stupid. For all the rest, the release announcement for 7.13 has a few highlited warnings and the first item is talking about upgrade path with mandatory step of 7.12. I expect that such warning will be repeated in future announcements for stable releases for quite some versions to come.But for new user reading this thread and are not used to how stuff works, it should be written that to upgrade to 7.13 or later, you need first go to 7.12.x
I couldn't agree more on this, we have close to 340ish pieces of this hapAC2 as a CPE in the field that needs this wifi-qcom-ac + zerotier, if only we can remove some packages/components at will that will be awesome for now we stick to 7.12.1 for this reasonWell, I certainly consider it a step backward that almost all functionality is now in a single "routeros" package.
I can fully understand why packages like "DHCP", "PPP", "ipv6", "security" were merged with the system package! They often have nasty cross-dependencies and certain functions could fail to work when they are not installed.
But MPLS, BGP (and OSPF, IS-IS etc), CAPsMAN, Wireless, QuickSet and applications like proxy, SMB, should be in separate packages.
With a more user-friendly way to load/unload optional packages of course.
It would make devices like hAP ac2 and wAP ac become stable again. In most usage scenarios you don't need many of those packages and there would be breathing room in the flash again.
I do agree some, but this Information was posted in both 7.13 beta and 7.13 rc, so no reason not to hva the same information in 7.14 beta, since its importante to understand why you do not see 7.14 beta if you are no older version than 7.12 and try to upgrade from GUI. It may be a new function that are in 7.14 that you like to test out and hence has skipped allot of other version.Oh common, new user interested in beta versions is either full of adrenaline or plain stupid. For all the rest, the release announcement for 7.13 has a few highlited warnings and the first item is talking about upgrade path with mandatory step of 7.12. I expect that such warning will be repeated in future announcements for stable releases for quite some versions to come.
I do understand the frustration but that device has been released from the start with not enough flash storage.I couldn't agree more on this, we have close to 340ish pieces of this hapAC2 as a CPE in the field that needs this wifi-qcom-ac + zerotier, if only we can remove some packages/components at will that will be awesome for now we stick to 7.12.1 for this reason
100% agree ,this is old set up, and we are using vlans over ovpn, but the question is why is that still not fixed?Why would you ever use OVPN between MikroTik routers?
There are so many good alternatives!
LOL, you can upgrade beyond 7.12.1 and still have zerotier. What is your point?Yeah that's why we might stay indefinitely in 7.12.1 because we can't eat our cake and have it too :) unfortunately wireguard is not an option for us :p
Even with routeros+wireless+zerotier the hAP ac2 will probably run into trouble.I do understand the frustration but that device has been released from the start with not enough flash storage.I couldn't agree more on this, we have close to 340ish pieces of this hapAC2 as a CPE in the field that needs this wifi-qcom-ac + zerotier, if only we can remove some packages/components at will that will be awesome for now we stick to 7.12.1 for this reason
I do not understand the need all of a sudden.
When it was released, there was no mentioning yet of wave2 drivers for that device. You were happy with it as it was at that point in time ?
I can't upgrade to past/beyond 7.12.1 because this is the last version I can have a wireless + zerotier on this device, I'm just wondering why some people here is very apprehensive if all you want is to get the last ounce of $ you paid for the device, to give you proper context in home settings I might agree with most of you to upgrade to a next higher device and throw hapac2 in the bin, but when you are in business settings you can't just dump it and call it a day. there's no wrong if you are hoping one of these days that MT decided to break their monolithic approach to package and let the user choose whatever he/she wants to the device they already paid for, what pe1chl saying about breaking the package per feature is sane, coming from a sane mindsetLOL, you can upgrade beyond 7.12.1 and still have zerotier. What is your point?
No. Even on the very latest v6 (6.49.11 as of this writing) you can still install individual packages in place of a bundle, leaving anything you don't really need out. v7 is very different in this regard.The latest versions of 6 were all bundled.
I too am a little confused. My hope was, like openwrt did in 2013, mikrotik would get bql working as universally as possible, and make fq_codel the universal default on wired interfaces, and one day wifi, and another day LTE. Run unshaped - native mode - with just bql backpressure - fq_codel by itself is really lightweight and automatically optimizes for any underlying speed, pause frames, and even to some extent cpu overloads coming from elsewhere in the system. Is that what this is? :-P :-P :-PThe fq_codel type is set for wired (Ethernet, SFP) interfaces in order to reduce bufferbloat. No interface queue for LTE interface itself.
That's true, physically ports can use "non rate limit" queues.
But still not sure what the change does...
e.g. what does "wired port" mean in the context of an LTE device's defconf...as the default configuration of an LTE device uses a bridge...
my post to this: viewtopic.php?p=1036269#p1036269That is why I am for splitting into different packages again, so users of wireless do not get the management part of wifi-qcom
*) wifi - added "station-pseudobridge" interface mode (CLI only);
1/2) yes, I tried saving it on a skin different than default, have tried that several times, and nothing is actually saved (json file timestamp is unchanged). That's really not the case. Since my first report, the skin is not 'default' and saved on a different name, applied to the admin group.It looks like your problems are not actually bugs, but you misunderstand how it works or what is meant.
1/2. you need to actually save it. either as "default" or as another name, which you then assign to a user group.
3. it is the traffic of the webfig session, the traffic of the webpage you are viewing.
added a "vrf" interface for testing, now I cannot delete it. It doesn't even show up in the terminal if you export the config... looks like a bug to menext to loopback interfaces tab, we have also vrf interfaces tab .. ?! what the heck ? ;-)
The bug is probably that you're able to add them at all. These interfaces are the previously hidden ones that are automatically created when you create VRF (in /ip/vrf). See VRF and hidden interfaces for a bit about that.added a "vrf" interface for testing, now I cannot delete it. It doesn't even show up in the terminal if you export the config... looks like a bug to me
You are right. I created a new VRF and added the previously created "vrf interface" to it, then I managed to delete the interface via deleting the whole VRF.The bug is probably that you're able to add them at all. These interfaces are the previously hidden ones that are automatically created when you create VRF (in /ip/vrf). See VRF and hidden interfaces for a bit about that.added a "vrf" interface for testing, now I cannot delete it. It doesn't even show up in the terminal if you export the config... looks like a bug to me
You have provided so many details that they are sure to find a solution!!!I am still having a lot of errors on my two LR8 Lorawan gateways.
I don't know what happened with those products but for 6 months it seems to be a real mess.
Thank you, now its back to normal.What's new in 7.14beta4 (2023-Dec-29 10:05):
*) leds - do not show LTE connection state/mode using RGB power LED from configless LTE modems;
~100MB more free RAM on hAP ax^3*) system - improved memory allocation for ARM64 devices;
What's new in 7.14beta4 (2023-Dec-29 10:05):
*) system - expose "lo" and "vrf" interfaces;
Rather having the capability natively from the zerotier package, instead of just another workaroundYou should already be able to do that using containers.
Can confirm... The bug that broke bonding in 7.13 is fixed.*) bridge - fixed auto "path-cost" for bonding interfaces (introduced in v7.13);
200mb more free for me also on AX3, this is awesome @mikrotik .Thank you, now its back to normal.What's new in 7.14beta4 (2023-Dec-29 10:05):
*) leds - do not show LTE connection state/mode using RGB power LED from configless LTE modems;~100MB more free RAM on hAP ax^3*) system - improved memory allocation for ARM64 devices;
Yes. Brackets are special characters in ROS and using them in file names calls for ambiguity and problems.Or is there any reason
wg-rw: XN58CdM6ppiSQpDaQT0bh1IMYgUP0czYYY92N1IBwE3c=: Handshake for peer did not complete after 5 seconds, retrying (try 2).
/export file="FileNameChars_in_ROS_X.xx.x_can_also_be_!@#%^&()-=[]{}~|,.;"
/file print
1 FileNameChars_in_ROS_7.12.1_can_also_be_!@#%^&()-=[]{}~|,.;.rsc
2 FileNameChars_in_ROS_7.13.x_can_also_be_!@#%^&__-_____~__._.rsc
3 FileNameChars_in_ROS_7.14.x_can_also_be_!@#%^&__-_____~__._.rsc
There is a lot going on now in /ip/cloud. Perhaps the key/QR code should just be a function in the "BTH Users" dialog box for the user now... instead of the kinda odd "BTH VPN Wireguard" tab. While I get the need/difference... having two tabs (using dorky acronyms) & now a button for BTH is kinda confusing. Basically using only one tab that said explicitly "Back To Home" be a lot cleaner.*) bth - added simple "Back To Home Users" manager under IP/Cloud menu;
do you have a persistent-keepalive configured? that may trigger that log msgHi,
When installing the latest beta 7.14beta4 I got these messages on a wireguard road warrior connection, with the stable 7.13 (and earlier) it didn't happen:
Code: Select allwg-rw: XN58CdM6ppiSQpDaQT0bh1IMYgUP0czYYY92N1IBwE3c=: Handshake for peer did not complete after 5 seconds, retrying (try 2).
When I connect from my mobile it doesn't appear anymore but when I disconnect it keeps popping up this message.
What can happen?
a) Persistent-keepalive is not configured.do you have a persistent-keepalive configured? that may trigger that log msg
also, maybe the logging became more verbose. means, the message always has "been there" but never popped up in the log. cannot verify
Excuse my ignorance, could you be more specific or put the complete scripts?
/system logging set [find where topics="info"] topics=info,!wireguard
Or perhaps, a "Status" tab in /ip/cloud to show BTH tunnel things (and ideally last DDNS/time update)There is a lot going on now in /ip/cloud. Perhaps the key/QR code should just be a function in the "BTH Users" dialog box for the user now... instead of the kinda odd "BTH VPN Wireguard" tab. While I get the need/difference... having two tabs (using dorky acronyms) & now a button for BTH is kinda confusing. Basically using only one tab that said explicitly "Back To Home" be a lot cleaner.*) bth - added simple "Back To Home Users" manager under IP/Cloud menu;
since 7.13 it is pretty stable with fastpath disabled and L3HW offload enabled. A lot of issue were fixed and some yet to fix but pretty close to a stable enviroment.@rpingar I hope if you don't mind asking hpw's all your ticket related to BGP issues? did MT respond or fix most of your issues? we are going to retry again to put MT in IX scenario and i just feared we are going to pull it again and replace it with Juniper platform inadvertly due to instability
I've seen in your previous post you are one of the users who has larger peers i've seen here, thanks in advance
not it is a bug.Probably first you need to make sure that it is actually using 100% "for ever". When you have a full BGP feed and you also have created route filters that can take long to evaluate, it sure can take a long time to complete the first pass over the entire table.
rpki is working in my design with routinator in a vm not docker, BFD is not present in my config.Hmm.... that's reassuring but we need to test this thoroughly specially rpki validation this will surely a showstopper to us, BFD is working properly glad it was sorted out.
CCR1072 (tile) is more stable then CCR2216 (arm64) [latest is affected about fastpath stability and implementation of l3hw], in one nap we have two 1072 and the one cpu locked at 100% is the only issue we are experiencing with 7.13 (hope 7.14beta3 passed it, now they are running since 4days ago and the issue is not araising).yeah we have our own instance of routinator too, that's good to hear that it was working well, you are in 2216 i'm on 1072 this is what really scare me now :)
Well, I am using BGP in private networks so there are not so many routes, and I do not see this bug.not it is a bug.Probably first you need to make sure that it is actually using 100% "for ever". When you have a full BGP feed and you also have created route filters that can take long to evaluate, it sure can take a long time to complete the first pass over the entire table.
a case is a ip/route/print command run while any cli or winbox windows is closed.............
but there are also other case were some job on routing table never end.
+1 for this request!!Please add the capability of ZeroTier controller to use private roots/moons
Like zerotier-cli orbit on linux
It's no longer a separate tab in winbox AFAIK (it was in prev. beta). It's on the main interface tab only in winbox (and CLI).where is "lo" interface on 7.14beta4?
Not necessarily, there are cases, where having multiple lo’s is completely valid usecase.This seems right... there should be only one loopback interface.
I guess for those usecases you can still use the existing workaround in RouterOS: a bridge without ports.Not necessarily, there are cases, where having multiple lo’s is completely valid usecase.
@MikroTik staff. Yes, this is good news, this is a massive step forward in the industry (Yes, I am serious). But there's a problem.The fq_codel type is set for wired (Ethernet, SFP) interfaces in order to reduce bufferbloat. No interface queue for LTE interface itself.
YES - please add BQL to MikroTik RouterOS.Solution for MikroTik:
Please add BQL support.
Once you add BQL support, we get performance boost (CPU usage will drop) + long-term viability of fq_codel for service provider networks and also enterprise.
Next step is industry adoption of fq_codel on ASICs, I don't know if this is possible or not with Marvell ASICs though.
Regarding ECN, in my testing in production networks, leaving ECN marking enabled by default works better in the long run, assuming BQL is well-supported by the underlying platform. Overall, I would suggest leaving ECN enabled.
Is 7.14aplpha155 newer than 7.14beta? If not the test should be run on 7.14beta.ticket SUP-136050 updated with autosupout generated on crash of 7.14alpha155
I am very curious as to observed bufferbloat at line (not shaped) rate with fq_codel on various mikrotik devices. I have generally assumed that at least some have BQL support already, but did find at least one that didn´t, and told mikrotik about the patch, as per your third link above. It is fairly straightforward to test for bloat with a lack of bql at line rate, just send data from two ports into an fq_codeled one with a bunch of iperfs or flent and measure the latency with ping. Anything greater than 1ms at 100mbit or 2ms at 1gbit line rates indicates an overlarge device ring that bql would otherwise be managing for you. flent´s rtt_fair_* tests will do this for you and generate a nice plot.@MikroTik staff. Yes, this is good news, this is a massive step forward in the industry (Yes, I am serious). But there's a problem.The fq_codel type is set for wired (Ethernet, SFP) interfaces in order to reduce bufferbloat. No interface queue for LTE interface itself.
MikroTik RouterOS Linux queuing doesn't support BQL: Artificial bufferbloat shows up in bufferbloat tests when we use fq_codel on MikroTik RouterOS on physical wired interfaces, the same problem doesn't happen on Debian for example with BQL.
ROS uses Kernel 5.x IIRC. So these patches should be in ROS?The patch has been accepted into mainline Linux (along with Felix Fietkau’s follow-up fix for a power save-related crash bug) and was released as part of Linux 4.11. The code is also in the LEDE project firmware from version 17.01.
Not necessarily if you compile Kernel yourself, you have “options”… :)Regarding airtimefairness patches:
ROS uses Kernel 5.x IIRC. So these patches should be in ROS?The patch has been accepted into mainline Linux (along with Felix Fietkau’s follow-up fix for a power save-related crash bug) and was released as part of Linux 4.11. The code is also in the LEDE project firmware from version 17.01.
MikroTik is probably the only network vendor on the planet that commercially uses the Linux kernel for the data plane, which means, they have good reason to keep up with the latest kernel tree/versions. But for some reason, they do not. Other vendors use Linux only on the control plane, data plane will be merchant silicon SDK or some custom code.In my world, linux kernel version 5.7 is totally obsolete and i am hoping most of all that they start a version 8 running linux 6.1 or later. Particularly our mt76 and mt79 drivers evolved a lot since even 6.1!
I hope we see step 1: BQL support RouterOS-wide, MikroTik hardware-wide sooner than later.dtaht, thank you very much for your offer and continuous support on this forum. we will see what we can do and will let you know if we have any questions
I think you are conflating three things. The underlying LTE buffers in the device(s) are huge. I have seen 25 seconds of it on one device, tested recently. (and they still shipped it!) LTE/5g/etc itself throughout its entire stack has major bufferbloat problems, for which multiple fixes for the enode-bs, rans, and clients have been proposed, none, implemented. https://scholar.google.com/scholar?hl=e ... erbloat+5g - for some papers on it. There are three proposals in that list that I like a lot. Fixing the underlying buffering on cell phones and routers actually requires changes to the signalling in the (chipset specific) lte/5g driver stack to essentially have a completion interrupt for a BQL like interface, or better reports of underlying buffering to the overlying driver. Might be happening in a few phones soon, can´t tell, but only works on the uplink side. There are zillions of other things LTE operators do wrong today, like have a lousy performance setting on the uplink scheduler. 1 number, changed in their operations, would make online gaming for 5G fwa work a lot better. There´s a really great paper on that, too, that I cannot find right now.Offtopic here but: I tried OpenWRT on a Linksys WRT3200ACM with CAKE enabled. Connected my Mikrotik Chateau LTE12 on WAN-port (all ROS queues disabled). It did not perform any better and bufferbloat was still evident. Then I tried https://github.com/lynxthecat/cake-autorate and I did not know why, but with that cake-autorate enabled my LTE speeds dropped to like 5mbit down, 1mbit up. And i usually have varying 20-90mbit up and 10-25mbit up. Very disappointed by the OpenWRT defaults of CAKE and with cake-autorate addon even more. I really loved and used OpenWRT for many years, but my experience with the WRT3200ACM (and WRT1200 before) were really unstable and bogged (because I used a davidc502 custom builds) - compared to the stability of ROS and Chateau LTE12.
Won't work for me. I would like to know how to get beyond 1st-level ISP support to someone who would understand the topic. Not actively taking measures - just understand what bufferbloat means.Someone strapping the CEO of T-Mobile or Verizon in a chair and saying, "if you fix your bufferbloat, you will take another 5+ million FWA customers next year..." might work. It worked for me on musk: https://www.youtube.com/watch?v=c9gLo6Xrwgw
Thanks @normis to pay attention to all these messages!infabo, please make a new topic about bufferbloat and cake testing.
dtaht, thank you very much for your offer and continuous support on this forum. we will see what we can do and will let you know if we have any questions
It's not LTE carriers that are the problem per se. They follow the 3GPP/etc specs. LTE is a shared media, so speed changes with other's usage, sometime rapidly. It's the modem manufacturers that are the issue IMO. e.g. none that I know report the current bandwidth assigned (which should be deterministic with RBs assigned), which prevents using current channel capacity to set the max-bandwidth in CAKE/etc. Mikrotik could ask their modem vendors for some way to extract the current bandwidth from the modem, because that's what missing for LTE and queues.Won't work for me. I would like to know how to get beyond 1st-level ISP support to someone who would understand the topic. Not actively taking measures - just understand what bufferbloat means.Someone strapping the CEO of T-Mobile or Verizon in a chair and saying, "if you fix your bufferbloat, you will take another 5+ million FWA customers next year..." might work. It worked for me on musk: https://www.youtube.com/watch?v=c9gLo6Xrwgw
I don't completely agree.MikroTik is probably the only network vendor on the planet that commercially uses the Linux kernel for the data plane, which means, they have good reason to keep up with the latest kernel tree/versions. But for some reason, they do not. Other vendors use Linux only on the control plane, data plane will be merchant silicon SDK or some custom code.In my world, linux kernel version 5.7 is totally obsolete and i am hoping most of all that they start a version 8 running linux 6.1 or later. Particularly our mt76 and mt79 drivers evolved a lot since even 6.1!
There's always good reasons to use latest Kernel version for networking, one of the recent ones:
https://www.phoronix.com/news/Linux-6.8-Networking
Not all features/data plane functionality is 100% L3HW. This is MikroTik, not Juniper MX/PTX.I don't completely agree.
Mikrotik linux kernel is a control plane if you use L3HW....
regards
I fail to see how that may be relevant for a router.They should upgrade to Linux Kernel 6.8, read this for why:
https://www.phoronix.com/news/Linux-6.8-Networking
Which part ofI fail to see how that may be relevant for a router.
is unclear?Not all features/data plane functionality is 100% L3HW. This is MikroTik, not Juniper MX/PTX.
[admin@tik] /interface/lte> firmware-upgrade lte1
status: unknown current version
I specifically quoted the part that is unclear. You posted a link to an articles that talks specifically about a TCP end-point optimization to prove your point that the kernel on routers absolutely must be upgraded. How does one relate to the other?Which part ofis unclear?Not all features/data plane functionality is 100% L3HW. This is MikroTik, not Juniper MX/PTX.
It is definitely not related only to "end-points". If you go into pull request, the patch is really huge.. But engineers from Mikrotik should say, if they use Linux TCP/IP network stack or Qualcomm SDK (especially for WiFi - what I expect).I specifically quoted the part that is unclear. You posted a link to an articles that talks specifically about a TCP end-point optimization to prove your point that the kernel on routers absolutely must be upgraded. How does one relate to the other?Which part of is unclear?
This has been reported, and i've been adviced that will be fixe in 7.14 stable[admin@tik] /interface/lte> firmware-upgrade lte1 status: unknown current versio
/interface/wifi/security set management-protection=required
/interface/wifi/security set management-protection=allowed
/routing/pimsm/uib-sg
/ipv6firewall/mangle
Someone else already explained here:I specifically quoted the part that is unclear. You posted a link to an articles that talks specifically about a TCP end-point optimization to prove your point that the kernel on routers absolutely must be upgraded. How does one relate to the other?
No, of course I don't! But I want you to validate specific pieces of evidence you post before actually posting them.Do you want me to look up each kernel change log and flood this forum post with 500+ lines of networking stack change log?
I will admit, that I generally don't “elaborate” in depth and just assume the other user gets it based on their potential to do their homework (as I always share sources).Please note that I, personally, do not argue against the need to upgrade to the later/latest kernel, nor do I argue in favor of. You posted a link presumably describing some changes in a specific kernel version that should have explain why Mikrotik should upgrade their kernels to at least 6.8. I was curious, so I opened the link and read that articles, but failed to find anything really relevant for the routers in there, hence replied accordingly. Should I were wrong in my conclusions, do you think you (as an engineer) could have replied in a more constructive manner?
oooo I have the same problem on 7.13.1 between RB5009 and hAP ac.Latest 7.14beta6 changed something in RB4011 relating to the SFP+ port.
The XS+DA0001 DAC cable stopped working for me, it's flapping the connection with a TP-LINK TL-SX3008F.
I reverted back to 7.13.1 and everything works again.
MikroTik should just adopt latest LTS 6.6.x.
WireGuard is a Peer-to-Peer protocol with built-in 4in6/6in4 mechanisms for easy encapsulation. There's no such thing as “server” or “client” in WireGuard protocol. There are only peers.Wireguard configuration should add an "Client MTU" parameter.
MikroTik can afford to just stick with latest stable kernel (upgrade once every 4–6 months) directly, though, ditch the LTS approach completely.Linux LTS kernels have quite a short lifespan, the risk averse way is using the SLTS kernels maintained as part of the Civil Infrastructure Platform (CIP), of which the latest is the v6.1(-rt) series. Just to put the length of support in perspective: the oldest kernel series maintained as part of the CIP namely the v4.4(-rt) ones has later EOL date than the newest LTS (v6.6 series) Linux).
You are 100% correct. But unfortunately many people [including so called gurus] on this forum refuse to accept that important FACT because they are mired in the client/server model ...WireGuard is a Peer-to-Peer protocol with built-in 4in6/6in4 mechanisms for easy encapsulation. There's no such thing as “server” or “client” in WireGuard protocol. There are only peers.
You're so humor .WireGuard is a Peer-to-Peer protocol with built-in 4in6/6in4 mechanisms for easy encapsulation. There's no such thing as “server” or “client” in WireGuard protocol. There are only peers.Wireguard configuration should add an "Client MTU" parameter.
Set MTU to 1420 on all peers and problem solved, if underlay is less than overlay, the underlay (such as LTE/5G networks that failed to deploy jumbo frames) will fragment the UDP encap, the overlay inside the tunnel will remain clean PMTUD end to end.
Now that I think about it, I've never seen too many “default changes” as often as MikroTik on Juniper, Huawei, Arista etc.I think "home users" are best served with automatic upgrades and configuration updates.
Many home routers will be running with default config and have changed only things like admin password, wifi ssid+password, and internet connection parameters (like PPPoE client).
When not any other change has been made, and RouterOS is (automatically) upgraded, new defaults can be installed, preserving the above changes.
When it is detected that other config has been done, of course it should not blindly apply new default config.
I've seen the same stupidity on Cisco and Juniper community forums as well, so definitely not MikroTik community-specific on this one.You are 100% correct. But unfortunately many people [including so called gurus] on this forum refuse to accept that important FACT because they are mired in the client/server model ...
He was probably referring to this MikroTik feature: Adding an MTU field in there can be done, so the exported peer config includes MTU too.WireGuard is a Peer-to-Peer protocol with built-in 4in6/6in4 mechanisms for easy encapsulation. There's no such thing as “server” or “client” in WireGuard protocol. There are only peers.Wireguard configuration should add an "Client MTU" parameter.
Set MTU to 1420 on all peers and problem solved, if underlay is less than overlay, the underlay (such as LTE/5G networks that failed to deploy jumbo frames) will fragment the UDP encap, the overlay inside the tunnel will remain clean PMTUD end to end.
Jason A. Donenfeld created the WireGuard protocol, he knows better than you, me and anyone else on how the packet header was designed:
https://lists.zx2c4.com/pipermail/wireg ... 02201.html
I feel like it's a necessary evil to help the so called "home users" understand what they're setting up, the types of people that don't immediately spot the problem with copying private keys around to other devices etc. In the way those users are going to use WireGuard they are setting it up in a pseudo client-server regime anyway.I've seen the same stupidity on Cisco and Juniper community forums as well, so definitely not MikroTik community-specific on this one.You are 100% correct. But unfortunately many people [including so called gurus] on this forum refuse to accept that important FACT because they are mired in the client/server model ...
MikroTik can afford to just stick with latest stable kernel (upgrade once every 4–6 months) directly, though, ditch the LTS approach completely.
a document that at its beginning stated as ita VLAN interface and configure a PIM interface on VLAN
[a]pplies to RouterOS: v3.x, v4.x
Linux Kernel LTS is about 2 years support - This is long enough and reasonable enough. MikroTik can just use LTS for 2 years, upgrade to new LTS after two years, instead of the current "upgrade kernel once every 25 years" approach.I strongly disagree on this as MikroTik simply does not have the required engineering resources to make the necessary validation every six month. One can come to this conclusion just by considering the followings:
- Test results were not updated using v7 not even for products that were originally shipped with v6 than along the way were switched over to v7 as the minimum.
- There are still undocumented features (some of which I've noted a few posts earlier).
- The documentation is not kept in sync with the RouterOS version. It is not just that quite some of the provided examples are using v6 CLI style instead of v7 however also that the documentation still refers to long gone RouterOS versions. For example the Bridge IGMP/MLD snooping part of the documentation in the IGMP snooping configuration with VLANs section refers to
a document that at its beginning stated as ita VLAN interface and configure a PIM interface on VLAN[a]pplies to RouterOS: v3.x, v4.x- Even the more detailed part of the documentation such as the one for Spanning Tree Protocol is taciturn compared to Cisco's one covering the same topic.
By the way even the hyperscaler focused SONiC does not do what you have proposed despite being intended to be deployed on switches using 51.2 Tb/s silicon (to put it in perspective: MikroTik's top of the line is at 0.44 Tb/s).
Actually, you're right. MikroTik customers (me, you, everyone) have no idea how queuing actually works on MikroTik in conjunction to vanilla Linux equivalent.Not only for difference between versions, also in other areas the documentation is sometimes extremely lacking.
See for example "/queue simple". There is no documentation AT ALL, its manual section has only an example that uses only 1/5 of the available parameters. What the other parameters do and how the entire concept is working is not explained at all.
It does not even tell you how it is mapped to typical Linux shaping, so that you could find out in Linux documentation how it probably works.
I made a support ticket about that, nearly a year ago, but it hasn't changed the situation. It does not look like they have some employees specifically for documentation, it is likely done by the programmers who have other things to do.
This depends on how the peers talk with each other, for IPv4 the overhead is 60 bytes, for IPv6 it's 80, so if those peers will only ever talk via IPv4 you can use -60, but sure you can use -80 if you plan to let them speak via IPv6 in the future.WireGuard MTU = low level MTU - 80
for Ethernet, we use 1500-80=1420.
for PPPoE. use 1500 - 8 - 80 = 1412.
for my ISP, must use 1442 - 80 = 1362.
Correctly, 80 is the maximum value for both IPv6 peers, for IPv4 peers may use low level MTU - 60 . This is why 1420 works on PPPoE ipv4 link.This depends on how the peers talk with each other, for IPv4 the overhead is 60 bytes, for IPv6 it's 80, so if those peers will only ever talk via IPv4 you can use -60, but sure you can use -80 if you plan to let them speak via IPv6 in the future.WireGuard MTU = low level MTU - 80
for Ethernet, we use 1500-80=1420.
for PPPoE. use 1500 - 8 - 80 = 1412.
for my ISP, must use 1442 - 80 = 1362.
I'm getting the same error (7.14beta6) but on a "server" node (interface name = wg0) whose peers (several) all have no endpoint-address or endpoint-port assignedHi,
When installing the latest beta 7.14beta4 I got these messages on a wireguard road warrior connection, with the stable 7.13 (and earlier) it didn't happen:
Code: Select allwg-rw: XN58CdM6ppiSQpDaQT0bh1IMYgUP0czYYY92N1IBwE3c=: Handshake for peer did not complete after 5 seconds, retrying (try 2).
When I connect from my mobile it doesn't appear anymore but when I disconnect it keeps popping up this message.
What can happen?
No I want to see wireguard logs for any client peers experiencing issues. These are "server" endpoints (no client endpoint-ip/port information configured) and yet they are trying to connect to nowhere and spamming the logs about it in the processJust disable wireguard logging, sheesh.
This has its own problems: maybe my config used the old defaults because they worked for me - and the new ones would brake my setup.It could help when RouterOS would be clever enough to recognize that configuration is still at defaults (no additional user config done) and to a reset-to-new-defaults silently.
+1000I guess for some people it is always possible to invent a new problem...
Sorry, also for SMIPS?!) rose-storage - moved SMB service in the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service);
I wonder how this change affects the bundle size. Compared to beta6, the beta7 ARM and MIPSBE packages seem to be 20K larger, and for the 16M-flash devices 20K seems to be a lot nowadays.!) rose-storage - moved SMB service in the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service);
+∞Services like SMB should be moved into a separate package. Those who want to use it can install it and those who not need it (99% of the users) can gain some space.
To facilitate this, extend the "system->packages" menu with a list of not installed packages with associated button to install it, so users do not have to be guided through a process of downloading the correct .zip, unpacking it, and uploading a package.
+ 100 !Services like SMB should be moved into a separate package. Those who want to use it can install it and those who not need it (99% of the users) can gain some space.
To facilitate this, extend the "system->packages" menu with a list of not installed packages with associated button to install it, so users do not have to be guided through a process of downloading the correct .zip, unpacking it, and uploading a package.
Something needs to be done on this. Really urgently.10:46:37 system,error upgrade failed, free 33 kB disk space for a (null)upgrade
Be careful before updating: you can't add users or edit sharing from Winbox!!) rose-storage - moved SMB service in the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service);
you should review your statistics 🤣who not need it (99% of the users)
I do not test it, only on terminal???Be careful before updating: you can't add users or edit sharing from Winbox!!) rose-storage - moved SMB service in the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service);
The commands listed here don't work, ROSE ones should probably be used but what are they?I do not test it, only on terminal???
Be careful before updating: you can't add users or edit sharing from Winbox!
It not about NAND flash storage, its about SOCes used on devices and their physical capabilities.+1
wifi-qcom-ac contains the firmware for any compatible AC device. Mikrotik knows about 16MB flash and on some devices like hapac2 it is even a little less, but still they put the unneeded firmware in this package. And even I would be happy on my IPQ4019 devices not wasting space for QCA9984 firmware. Seems like 710kb just for QCA9984 firmware. Space that could be used for zerotier, container or other packages way more useful than just a pure waste of diskspace.
Personally, I have never felt the urge to use my router as a file server. And it would be too primitive and slow for that anyway.you should review your statistics 🤣who not need it (99% of the users)
[ma@MikroTik] > /ip smb print
enabled: yes
domain: WORKGROUP
comment: MikrotikSMB
interfaces: all
[ma@MikroTik] > /ip smb smb-share print
Flags: X - DISABLED; * - DEFAULT
Columns: NAME, DIRECTORY, REQUIRE-ENCRYPTION
# NAME DIRECTORY REQUIRE-ENCRYPTION
;;; default share
0 X* pub /flash/pub no
1 Router usb1-part1/Dati no
Did you try with the OpenVPN community (free) edition? Because that "OpenVPN Connect Client" (commercial version) is not completely compatible with the classic protocol.But we cannot get this to propagate to OpenVPN Connect Client 3.4.2
You and me both !I actually welcome the removal of SMB from the default image. I always considered it quite useless ¯\_(ツ)_/¯
That would be amazing and it would be a benefit for everything that has 16MB flash.With luck the new storage options will eventually allow packages to be stored and used on external storage.
Before onsider anything else,store packages on external storage
Exactly, v6 was better...probably 99.9% of users don´t need MPLS/BGP/PPP/... on an AP.
I can understand why PPP is to be in the main package. It is used as an underlying protocol for several other protocols.So still need some more modularization. For example: probably 99.9% of users don´t need MPLS/BGP/PPP/... on an AP.
Spero non fosse in produzione...7.14beta7
OH COME ON!!!routing is essential to install even connected and static routes for router to be able to forward anything at all. it does not makes sense to run router without a "routing package", which will render router useless.
I am. Therefore your statement is false.I wrote "auto-routing (BGP/OSPF/RIP/IS-IS)". Nobody is using that on their home NAT router
Fair enough. Imagine there a lot of dependency. BUT I think folks are looking for more ways to throw something off the boat, whatever/however possible. Dunno, maybe MPLS? Only Mikrotik would know what's possible... but the monolithic routeros package in V7 remains a backwards step from V6.There is no separate bgp/ospf etc processes that could be put into separate packages, everything is integrated.
And that's not a problem. But things can be in more packages for folks to select what they need.I am. Therefore your statement is false.I wrote "auto-routing (BGP/OSPF/RIP/IS-IS)". Nobody is using that on their home NAT router
I have fair number of 16MB flash things in remote/difficult places, so needing a netinstall after failed upgrade is kinda disastrous in my world – so all the failed upgrade due to space have me worried here... And I'm not sure all are attributable to using the new qcom drivers... which I can live without... but zerotier and iot fitting are important but still need some space for a few files from scripts and/or RIF files (which are also getting bigger).At the moment you are in the situation that the bad decision to use 16MB (or less) flash memory causes problems for some users.
Multiply that by all routing protocols and on 16MB devices most likely you will not be able to install routing package at all.
Me too. 😁I am. Therefore your statement is false.I wrote "auto-routing (BGP/OSPF/RIP/IS-IS)". Nobody is using that on their home NAT router
I think the point mrz is trying to make is that any perceived gains are far outweighed by the costs. The gyrations required by the development team to strip 100KB off the main package Into their own 1-2MB package, and the extra work requiring users to manually load/unload them doesn't add up in the end.That's the point: almost nobody will want to run routing protocols (none but static routing, which should not require any executable to run) on devices with only 16MB flash. But there are large number of users who want to run wifi-qcom-ac driver on same space constrained device and experience shows that every 20kB matters in such case (yes, we're hanging on shoestrings).Multiply that by all routing protocols and on 16MB devices most likely you will not be able to install routing package at all.
If one wants to run routing on device with 64MB+ flash space, then increase of flash space usage by a few tens of kB won't matter much as these devices typically are not tight on space. And for those few, who want to run dynamic routing on their (ARM?) devices, installation of optional package shouldn't be a problem, AFAIK setup of dynamic routing protocols is not exactly trivial, definitely harder than installation of an extra package.
I do OSPF on my router for fun, at home, but I still dont have anything except a static default route on my CAPs...Me too. 😁I am. Therefore your statement is false.
Look, I am using BGP myself. On my RB4011. But I don't think that there many users that would do that on their hAP ac2.Me too. 😁
I am. Therefore your statement is false.
It is not off topic! It is on the topic "current RouterOS releases consume too much flash space" and thus is related to the 7.14beta topic.And it goes out of topic again. If you want to discuss routing packages do it in one of already existing topics or create a new one.
The smartest poster ^I think the point mrz is trying to make is that any perceived gains are far outweighed by the costs. The gyrations required by the development team to strip 100KB off the main package Into their own 1-2MB package, and the extra work requiring users to manually load/unload them doesn't add up in the end.
It's all part of calculated risk. And the feedback from a handful of us complaining on the forums is considerably less significant than the feedback coming in from distributors, integrators, and trainers.
Personally, I have used CAPsMAN a total of one time, and that was to initially get a pair of Audience's meshed. I then undid all of that and used the 5.2GHz radios with a VXLAN or EOIP tunnel across the link to bridge the two. But I'm guessing removing CAPsMAN would be like removing the routing protocols... stepping over dollars to pick up pennies.
What RFC / part of RFC is being implemented here?dhcpv6-client - install dynamic IPv6 blackhole routes in corresponding routing-table;
Lol, for the first time, I agree with MikroTik staff's opinion.routing is essential to install even connected and static routes for router to be able to forward anything at all. it does not makes sense to run router without a "routing package", which will render router useless.
MikroTik is moving towards vendor networking with their Marvell switching SDK. Meaning, Linux will be limited to just few system functions. Control plane will be Tik-specific userspace apps, data plane will be the SDK.Then change that back! In v6 and in general Linux there certainly was and IS a layer that does the routing itself and a separate process or processes that manages the auto-routing like BGP.
At the moment you are in the situation that the bad decision to use 16MB (or less) flash memory causes problems for some users, and you cannot maintain the position that these users, who often use only very limited features of the system, have to suffer because all the software was made in a monolithic way.
Besides that, there are other optional features you can isolate in optional packages. So do that, to make it work again.
Or promote 7.12.1 to "long-term" version so the users of those devices can remain on that version.
I don't think there is an RFC that states this, but it's always good practice to blackhole aggregates to prevent layer 3 loops. Most end-users won't know how to do this, so this auto-feature, will take care of that.What RFC / part of RFC is being implemented here?
OpenWrt doesn't sell routers.Lol, for the first time, I agree with MikroTik staff's opinion.routing is essential to install even connected and static routes for router to be able to forward anything at all. it does not makes sense to run router without a "routing package", which will render router useless.
This is how FRR works, this is how BIRD works, this is how Cisco works, this is how Juniper works, this is how Nokia works.
What kind of network vendor sells a router with only static route process? If you want that, go for OpenWRT.
Obviously they don't dude. It was a joke. My point stands, want Linux vanilla networking? Go for Debian or OpenWRT.OpenWrt doesn't sell routers.
You can install BIRD / FRR on OpenWrt.
_OpenWrt doesn't sell routers.
There's nothing to joke about this. OpenWrt WILL sell hardware that will put every 16MB flash Mikrotik to shame. (BPi will distribute it, but still it will be official OpenWrt hardware)Obviously they don't dude. It was a joke. My point stands, want Linux vanilla networking? Go for Debian or OpenWRT.
MikroTik is a vendor, and they will do what ALL vendors in the market do, i.e. integrated routing stack.
No USB port. We all know that it was a big mistake not including that. Then you say to take ax3, but that's $139 MSRP. OpenWrt One aiming below $100. And you get tons of other goodies.Apples and oranges.
Base storage is already 128M.
Take ax2 then.
In the market for hAP ac2 (a basic home router/AP with NAT), it is very unusual to have anything but connected routes + default route obtained from DHCP or PPPoE. No support for any of BGP, OSPF, IS-IS etc. At most in some cases RIP.Obviously they don't dude. It was a joke. My point stands, want Linux vanilla networking? Go for Debian or OpenWRT.
MikroTik is a vendor, and they will do what ALL vendors in the market do, i.e. integrated routing stack.
ax2 - IPQ6010... Adding speakers or USB to a chip that doesn't support them entails a significant increase in cost.....
Ok, but on SOHO the USB on the modem is perfect as a backup connectionNever used USB, camera, speaker, GPS or touchscreen on network devices before.
for use an LTE modem?is perfect as a backup connection
Cutting costs, would probably be the one...Older devices from times of CRS226 etc had 128 MB of storage. Is there any way to explain what happened?
Exactly. To an extent, we've been spoiled for a long time. Look at how long some of these <$200 routers have been in production, let alone continually supported with newer updates. You don't see that with $1000 phones.It is an advantage of RouterOS that MikroTik releases new versions for old devices for a very long time. Other manufacturers have a separate image for every device, and they simply stop releasing updates for older devices, except sometimes for security issues.
It could be considered to have a "RouterOS Lite" for the tiny devices, but apparently developers are not prepared to spend effort on that.
Then at least put a line in the sand for upgrades, to prevent people wasting time or causing problems by just following the upgrade to new versions.
I don't believe number of pins is the issue. SPI flash comes in many sizes and doesn't require more than a handful of pins. Same for eMMC - you could have gigabytes of capacity and unless you need high speeds, just a handful of pins is all that's needed.One reason probably is that 16MB is a boundary for some old storage technology and having more than 16MB requires more pins from the SoC that can also be used e.g. to drive LEDs. So to keep costs down, it seemed attractive to have 16MB storage only.
Apologies, but I'm not following. What routes will be automatically added as blackholes to the routing table by DHCPv6 client?I don't think there is an RFC that states this, but it's always good practice to blackhole aggregates to prevent layer 3 loops. Most end-users won't know how to do this, so this auto-feature, will take care of that.
The delegated prefix. Client receives /56 PD from upstream, /56 aggregate is blackholed.Apologies, but I'm not following. What routes will be automatically added as blackholes to the routing table by DHCPv6 client?
Ah I see, the changelog could have worded it better. Hopefully it's configurable, to allow proper ICMP errors via firewall.The delegated prefix. Client receives /56 PD from upstream, /56 aggregate is blackholed.
The limitation us usually 24 bit addressing supported by ROM bootloader (that's part of SoC mask and cannot be modified). But it doesn't mean that larger SPI chip cannot be used - it just means that the next stage bootloader must be in the first 16MB. Bootloader from SPI can be booted from the first 16MB and can access the whole flash.I've heard that many chips used to require SPI of 16MB or less to boot from; and if you need more room you add NAND flash in addition to the SPI that is still needed to boot from.
... it just means that the next stage bootloader must be in the first 16MB.
I have 2 ipq4000 based devices - same platform yet one has 16 MB of storage and other has whole 512 MB - hap ac2 and RB450Gx4. I have a hard time to believe that it can be a technical issue. I'd really like to see what would Mikrotik do with almost all of their switches with their 16 MB of storage. It is only a question of time when RouterOS would not fit into that. There was a time when switches and access points (really old SXT devices come to mind) had 128 MB in them - what the *** happened with that?I don't believe number of pins is the issue. SPI flash comes in many sizes and doesn't require more than a handful of pins. Same for eMMC - you could have gigabytes of capacity and unless you need high speeds, just a handful of pins is all that's needed.One reason probably is that 16MB is a boundary for some old storage technology and having more than 16MB requires more pins from the SoC that can also be used e.g. to drive LEDs. So to keep costs down, it seemed attractive to have 16MB storage only.
Parallel flash is a different issue, but most SoCs support SPI and eMMC, so no real need to use parallel flash.
I would say costs or large stock of unused flash is the issue here. It's definitely not a technical issue.
Why waste efforts/CPU cycles on ICMPv4/v6 replies for non-existent pathways? I know there's an RFC for ICMPv4/v6 replies on the LAN, but that was written 20 years ago.Ah I see, the changelog could have worded it better. Hopefully it's configurable, to allow proper ICMP errors via firewall.
I think we discussed that previously elsewhere? For DC, SP etc it does make sense. For a SOHO CE router it does not.Why waste efforts/CPU cycles on ICMPv4/v6 replies for non-existent pathways? I know there's an RFC for ICMPv4/v6 replies on the LAN, but that was written 20 years ago.
At some point devices with 16MB appeared, usually really low-end devices. But at some point even much more expensive devices got released with 16MB, and they are still being sold today.There was a time when switches and access points (really old SXT devices come to mind) had 128 MB in them - what the *** happened with that?
We already know what our reply will be even before they reply. Pretty much it is pointless to buy anything that has 16MB flash so distributors will be stuck with a bunch of old inventory that they cannot sell anymore. With no ways to update them will be the last nail in the coffin. You can sweep everything under the rug, but for how long?Now that it no longer fits, and they refuse to do any modularization to make it fit, I wonder what the next reply will be.
And also helps potential attackers to scan IPv6 address space much more effectively. I don't know if potentual benefits actually outweigh drawbacks.... with proper ICMP troubleshooting is so much nicer and it is so much friendlier to the software as it allows immediate and accurate error reporting to the user.
Perhaps. But the problem — in 7.14beta7 — is NOT theoretical. At least specifically on 16MB ARM-based wAPacR's.At the moment you are in the situation that the bad decision to use 16MB (or less) flash memory causes problems for some users.And it goes out of topic again.
Guess I'm dumb. But I thought the whole idea is feedback on the beta. What worked, now does not work. And, upgrade to 7.14beta from 7.13 fails — with no options to fix. Presumably there aren't security issues between 7.12.1 and 7.14 – but that's going to be a problem since 7.12.1 is last version that fits my needed packages.The smartest poster ^And the feedback from a handful of us complaining on the forums is considerably less significant than the feedback coming in from distributors, integrators, and trainers.