My CCR2004 keeps crashing after some seconds after creating a Wireguard interface. It even gets into a loop then so it’s booting, then the router is working some seconds and then it crashes again. Have to remove the interface immediately after the boot to prevent crashing again.
Is this a known issue? Is it fixed with beta3?
I think this is a known problem with TILE, have seen other reports before.
(I do not have beta3, so I can not check there.)
Oh, ignore this post… CCR2004 is ARM64, not TILE.
hoping to see the CRS318 line, specifically the netpower 16p, with hardware accelerated routing.
It was very exciting openvpn on udp, but sadly I go back to stable versions.
I have this problem:
nov/20/2020 10:05:46 by RouterOS 7.1beta2
# software id = 786I-NUGZ
#
# model = RBD52G-5HacD2HnD
# serial number = XXXXXXXXXXX
/interface ethernet
set [ find default-name=ether1 ] advertise=10M-half,10M-full arp=enabled arp-timeout=auto auto-negotiation=yes bandwidth=unlimited/unlimited disabled=no full-duplex=yes l2mtu=1598 loop-protect=default loop-protect-disable-time=5m \
loop-protect-send-interval=5s mac-address=XXXXXXX mtu=1500 name=ether1 orig-mac-address=XXXXXXXXX rx-flow-control=off speed=1Gbps tx-flow-control=off
It is not a cable problem.
From the graphical interface it hangs when I try to change any option and when returning it is always the same.
From GUI does not force changes.
Hi Emils, just want to say thanks to all in Mikrotik for the hard work, but I believe you guys making your life too hard by supporting all hardwares, there is a retirement for everything including the hardware, every wonders are moving to ARM as Mikrotik did too and can I ask please please stop making hardware with 16Mb nand and 128mb ram, that is the main issue, Mikrotik need to say ok there is a device which not going to support V7 this is easy for everyone, us as a customer and you as vendor, we now we shouldn’t buy that and you know its going be easy and fast to get new version out.
There is CCR2004, RB4011, HAP AC3, … (fantastic hardwares)
just stop the Tile hardwares, even Mipsbe, Smips, and please no more 16mb and 128mb, providing cheap hardwares is ok but they you are going to spend more money to fixed the software.
Have a good weekend to all Mikrotik users, and looking for ward to see much faster release on V7
I don’t think it is time to retire the TILE hardware yet, but I think it is better to release further betas for other architectures while issues with TILE are resolved.
That way, work on debugging v7 can continue while engineers work on TILE support.
Anyway, it is friday today so always a chance we will get a new beta today around 4 o’clock (5 o’clock in their timezone)…
So, THAT’s the usual release time?
And You are right: they should move the development ahead, even if tile lags behind. It’s called beta for a reason!
Concur! Btw, is Mellanox still pushing rnd for the tile procs?
Tile is still very important. All the CCR10xx are still widely used, and very performant, no reason to ditch them.
Fair enough, but maybe they just keep it on V6 and not going for V7. but I think it tike to Move to ARM, all vendor including Mikrotik are doing it, also its too good that Mikrotik still supporting 10years old or even more device, and have them running the latest version, but device software support should be the MAX 5years.
also V6 is already good enough, V7 is the future then should be for New ARM Base devices or at least 1st for ARM devices and when is ready if they have time start adding more hardware to it, but holding it because there is an issue with Tile and keep it less than 16MB just because all then and in the devices are 16MB, its just too wrong, and they already know it.
Hope they just try bring the V7 to the stable version and then start supporting more device for it.
I’m not opposed to what you wrote before, but that sentence made me cry. Sorry, but having a look on climate change and limited ressources of the world it should be MINIMUM 5 years for every hardware/software vendor. There is no reason to ditch even older routers when they fullfill the needs and easily can be supported. Newer kernel and routing architecture in v7 lead to performance and feature improvements (think of wireguard or new encryption schemes) and thus might make older hardware even longer fulfill people’s needs.
Exactly. WinBox and long software support is what makes RouterOS so great. I assume that I wouldn’t be the only customer who would be seriously disappointed, if after just few years I’d have to choose between no new features and bugfixes, and throwing out perfectly functioning and otherwise sufficient device. MikroTik is doing it the right way.
But the main point of v7 is sort of multi thread bgp, which is a revolution for tile cpus…
:), agreed I was bit harsh, but all come from the frustration, I really can't see anymore Mikrotik with 16MB and low storage, also waiting long time for a next beta to be release, its call beta for a reason, they should go ahead with ARM and when they have it right now start adding other architecture, I have 3x CCR1072 and they are in the Core of my BGP network of course I want then to ran V7, but if that going to slow down the development of V7 Im more than happy to stay on V6 till V7 is fully ready and is in LTS.
Also I really can't see any more 16MB devices :))
Totally agree with multi thread bgp, and I see your point, but are you going to wait till they find a way to fix the boot issue or you are happy to make the V7 ready and then add Tile?
this is al my point, stick with ARM and make the V7 ready and in LTS version then start make the Tile support, also I really don’t like to see they limit them to not reaching 16MB because of very wrong decision of just having 16MB nand, you don’t like to have ZeroTire? or …
you are right that way Im using mikrotik for over 15Y, but I have a issue with them too, no Mac support for WinBox and funny enough most of them using Mac, it too nice of them to still have support for all routers.
Mikrotik is doing ‘SHOOT YOURSELF IN THE FOOT’ exactly
maybe it is time to cut off and make decision
v6 is OK.
So maybe MKT could keep it alive, backporting some patches, maybe some smaller modification,features, and this is it
OpenWrt implemented Wireguard on older kernel, so i don’t see reason why MKT could not
v7 should be available on devices with more than 16Mb storage. Mostly on ARM
it is not normal that you have 8 different architecture
XX differently assembled device with different ways of connecting CPU and Switch chip … different GPIO, different PoE
XX different switch chips, etc
and try to make same feature, same functionality on all of them
and limit your self to 16Mb storage
It is already irritating that you buy one device, learn something, and when you try to implement what you lear on another one, there is always a problem
Switch chip is not the same, so it is not working same way, or RSTP working, but without HW accel, or some WiFi card work well in one type of board, but not in another, etc
Then, what is the use of same SW features when your HW could not support them??
nothing, meaningless
so, no, MikroTik is NOT doing it the right way.
Well that is your opinion, mine is different. MikroTIk IS doing it the right way!
Other manufacturers (I have experience with e.g. Draytek and AVM) usually release new devices and have a firmware available only on that specific device.
Each new device introduces some new function which is available only in that firmware, older devices will never get that new function or will have to wait until new firmware is released for that device.
And when a new device is on the market, new firmware for older devices quickly stops appearing, except maybe for security fixes.
Existing and wellknown bugs remain in the firmware forever, you have to buy a new product to get them fixed.
This is not an issue with MikroTik als the RB750 or RB2011 you bought nearly 10 years ago still gets a new firmware version every month or so, and adds more and more new features, fixes bugs, etc.
There are changes in the hardware, that is inevitable. New SoC appear and others are no longer manufactured or no longer attractive in price, so new products are developed to match that, and some capabilities necesserarily change over time.
16MB flash is less optimal but can be explained due to cost reasons (not how many customers on the forum are discussing about price, likely more of an issue for them than for me).
In itself it is not the main problem yet, it only becomes a real problem when RAM size is also limited. Like on some of the lite/mini devices.
And of course with 16MB flash you cannot use partitioning.
What could be done better:
- development of WiFi to get modern features that everyone else already has. when necessary, drop NV2/Nstreme and move over to standards like 802.11ax.
- release v7 betas when new functionality is available for testing, when necessary limit to a few architectures like ARM and CHR at first.
Ok, then tell me
the new firmware, what is the use ov rb750/2011 with OpenVPN ? or with wireguard?
does these devices have capable CPU of handling these features ? NO
Is new FW useful? NO
ok, another example
MT7621, Could you make untagged vlan on Switch chip ? NO
does OpenWRT could do this? YES
is new FW useful? NO
and, maybe the most brutal question
32/16 devices, or maybe 64/16 devices intended for home use, mostly equiped with 100mbps ports
what is the use of new FW ?
multi core BGP? Hhahahahaha
so, what i was wrote, maybe not so clear, that v6 need to stay as it is
with slight improvements to support old devices, few security patches per year, and this is it
old HW is NOT cappable for new FW.
when you cut off old devices, and don’t try to make v7 work on all of them, then you could make 1 release per month
maintaining compatibility for old HW and mess of switch chips with Kernel 5.x is impossible