On HAP and RB750G install successfull, Wireguard works to OpenWRT. But on first reboot after setup, both routers are reset to default settings. Restore from backup are not succesfull, every time after restart are factory settings on both routers active.

Backup are used when the hardware and router os software are the same. You can try to export config and import all or if that fails, use part and part until it fails.

Backup are used when the hardware and router os software are the same. You can try to export config and import all or if that fails, use part and part until it fails.

The Backups are prepared after first setup from this version. And of course from the same router, I'm not an rookie.
My experience with Mikrotik is over 10 years and I have 8 Routers in produvctive Environment and 4 in Lab.

I'm not an rookie.

With only 4 post here, its not easy to see :)

Hey,
is there anyone who owns a Chateau LTE12 and is able to use LTE mode only?
Currently I'm able to connect to internet only using 3G mode.
I'm in contact via Mikrotik support and I'd like to know if someone else is experiencing the same problem.

Here i am! I always use LTE mode only on Chateau LTE12 (and before on WAP LTE and LHG LTE too). It works well with all 3CA combination (provider 3 Italy, now Wind3)

Wow, great! Can we get in contact? I'm using VeryMobile by Wind, it works very well on smartphone, but on Chateau in LTE mode I get only Tx traffic not Rx one.
I tried to contact you, but the option is grayed.

It would be welcome when you release new v7 betas quickly even if they are only for single architecture, e.g. only for CHR.
That at least enables some testing and evaluation. Getting them to work on all devices is something that can trail after that.

If it only takes another day or two, I don't see the harm in waiting until they get it fixed. It would be different if it delayed it for weeks.

It would be different if it delayed it for weeks.

7.1beta2 (2020-Aug-21 12:29)

But on first reboot after setup, both routers are reset to default settings. Restore from backup are not succesfull, every time after restart are factory settings on both routers active.

I have seen this problem on my Chateau (V7.0.1). From time to time when I reboot this device, then device has no more configuration at all! (not even default).
When this happens, and I try to use backup file made before this reboot, it will not load that backup file (this file is then useless).
You then need to start all over again and go back to a backup file that is working...

So each time I need to power this device off, I hope and pray that when booting again it has still its config...!

Despite my optimistic signature message, I stopped doing anything on R7 for now and wait for some new release hopefully fixing some of the issues.

When you are in that situation, I would rather make a /export instead of a /system backup.
It is usually possible to import a /export even when this does not go as smooth as you may want.
You may need to remove certain lines, or at least make sure the config is *really* empty not even the dhcp client that the system likes to add by default.
Also at least in v6 there is an error in the /export of ipv6 that makes it impossible to import it, the sequence of commands is wrong.
But maybe you are not using ipv6, or maybe this error has been resolved in v7.

So ... it is friday and still no new release

I am still using OpenWRT with DSA on MT7621 because
Ros 7.1b2 does not work with vlans on RB750gr3/RB760igs
Ros 6.x does not have Wireguard

so if i want both "feature" i need to use OpenWRT

any chance for new beta?

Currently we are having issues with beta3 booting on TILE architecture. Beta3 will be available when we get these issues sorted out.

Is it possible to downgrade? I have that SSH issue on 7.1beta2 and beta3 after xmas is too late for me.

Run a /export and save it.
Use netinstall to install the router with 6.47.7 and restore the backup you made before you went to v7 beta.
Then use the /export to review any changes you made after going to the beta and that you now want to apply to your 6.47.7 install.

Hello everyone,

Just wanted to thank everyone for bringing the wireguard to the Mikrotik.
Of course, the work is still in progress and there are few (already addressed) bugs, but so far - so good. It works rock stable for me.

I've got a bounce server (Debian 10), publicly hosted on a static ip, and I can reach all my peers without any problems.

The only thing I'm still missing, or I was unable to figure it out, is the mikrotik discovery protocol (udp - 5678) over the bounce server.

Like I said, I can access the peers without any issues (webfig, winbox), but I can't see the peers in the discovered neighbors list.

Anyone have any tips and tricks on how to get it to work?

Port is open when trying to reach it from the bounce server, so that's good.

Thank you, and wish you all a wonderful weekend!

Best regards,
Dorian

Run a /export and save it.
Use netinstall to install the router with 6.47.7 and restore the backup you made before you went to v7 beta.
Then use the /export to review any changes you made after going to the beta and that you now want to apply to your 6.47.7 install.

I own the Chateau LTE12. I wouldnt use the beta otherwise. There is no download archive for beta versions I know of - so where to get a old beta release?

I just received the device this week 11.11. and it was shipped with 7.0beta6.

I own the Chateau LTE12.

Go to https://mikrotik.com/download
CTRL + F for searching: Chateau and you discover it at ARM family
RMouseB and copy URL
https://download.mikrotik.com/routeros/7.1beta2/routeros-7.1beta2-arm.npk
and edit it to:
https://download.mikrotik.com/routeros/ ... a5-arm.npk <- WORK ✔️
https://download.mikrotik.com/routeros/ ... a6-arm.npk <- NOT WORK
https://download.mikrotik.com/routeros/ ... a7-arm.npk <- WORK ✔️
https://download.mikrotik.com/routeros/ ... a8-arm.npk <- WORK ✔️

Thanks! I did not assume that they have "unprotected" Download-Links where I can simply modify the file-name and e.g. guess for the version! Works indeed!

Is this just wrong information or can there be a difference between routeros version and routerboard version?

Is this just wrong information or can there be a difference between routeros version and routerboard version?

Please study the difference between RouterOS version and firmware version. Firmware is the bootloader.
It was made confusing by having the same version on the bootloader as on a RouterOS (even when bootloader was not changed at all)
but still it is a different thing.
When you click "upgrade" in that screen it will upgrade the firmware to the same version as the currently running RouterOS.
But likely that will not change anything, as the firmware in v7.1beta2 is likely the same as in 7.0.beta6.

Thank you for the patient answer. I am still new to the Mikrotik universe (< 1 week) and I still not discovered all wiki and stuff yet. It just confused me, as I pressed the "Upgrade"-Button on that page - but nothing happened and after refreshing the page still the same information was displayed. But now after a reboot it shows the most current firmware. Still have to get used to the Mikrotik-way that is not very intuitive. But once you know - you know. ;)

Yes, it's not intuitive at all since Mikrotik decided to use same version numbering for routerboot and ROS. Before that, routerboot had it's own version number so it was easy to see if something changed or not and if it's really worth updating it. But now they keep version numbers in sync with ROS, so you don't really know if routerboot has to be updated or if only change is the version number. So you end up updating it just in case, wasting NAND writes of critical bootloader sector every time.
But it's still perfectly safe to run older version of routerboot and not update it unless you experience some problems. If some fix or new feature depends on a new routerboot, it's usually noted in the changelog.

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

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:
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.

Currently we are having issues with beta3 booting on TILE architecture. Beta3 will be available when we get these issues sorted out.

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

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?

Currently we are having issues with beta3 booting on TILE architecture. Beta3 will be available when we get these issues sorted out.

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

.

Tile is still very important. All the CCR10xx are still widely used, and very performant, no reason to ditch them.

Currently we are having issues with beta3 booting on TILE architecture. Beta3 will be available when we get these issues sorted out.

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

.

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.

but device software support should be the MAX 5years.

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.

Currently we are having issues with beta3 booting on TILE architecture. Beta3 will be available when we get these issues sorted out.

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

.

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.

But the main point of v7 is sort of multi thread bgp, which is a revolution for tile cpus...

but device software support should be the MAX 5years.

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.

:), 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 :))

Currently we are having issues with beta3 booting on TILE architecture. Beta3 will be available when we get these issues sorted out.

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

.

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.

But the main point of v7 is sort of multi thread bgp, which is a revolution for tile cpus...

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

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.

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.

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.

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.

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.

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

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.

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

I am not that interested in wireguard, but its proponents always claim that it is so much faster than IPsec, so when they are right it should be useful.
IPsec on those devices will do like 20-30 Mbit/s and that is usually okay for the normal usages of a VPN.
(I am not talking about the usage of routing all your traffic from/to internet over some remote party's network)

ok, another example
MT7621, Could you make untagged vlan on Switch chip ? NO
does OpenWRT could do this? YES
is new FW useful? NO

MikroTik internally uses VLAN to be able to configure each port completely independently. It looks like the switchchip-level VLAN is used for that.
Maybe in other software it is done differently, e.g. when they do not have that capability.
Or maybe there is some lack of support of a certain switch chip.
Does OpenWRT support hardware-accelerated routing on switch chips, like new RouterOS now does?

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

No, but new firmware could have support for newer WiFi features that the hardware of those devices could support
but the software until now didn't. (because of the use of in-house written drivers instead of those provided by chip manufacturers and used by other companies)
It also could have improved IPv6 support which everyone can use, also in home use.

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.

This has not been shown. Apparently there is work being done on some issues with TILE and I do not like that releases for other architectures are held back because of that, and I think the hAP lite and mini have to be dropped (they do not work well with v6 either), but other than that things seem to go a lot better than at the named other companies.

I think we as LONG time MT customers should ask and suggest to put more time and resources to development of V7 for the ARM and CHR and release a weekly or so beta and then when V7 became stable or in the LTS then start adding more devices in if it possible.

And I'm sure changing for 16MB to even 1GB nand will cost MT less than $1, can we ask then to prevent using abd developing hardware with less than 128MB.

I am not that interested in wireguard, but its proponents always claim that it is so much faster than IPsec, so when they are right it should be useful.
IPsec on those devices will do like 20-30 Mbit/s and that is usually okay for the normal usages of a VPN.

Ok
we are talking about 20/30 mbps as MAX on old devices
So, at this moment, i am "home" user, with FTTH drop
FTTH is not so SCI-FI today. Or internet speeds > 100mbps

These devices have 100mbps ports, capable of 20mbps VPN, and ?
It is normal to force kernel 5.x on 100mbps devices?
How could you expect that somebody with FTTH connection say: OK, i have a giga input, but my old router is 100mbps. Woow :)
And i could do 20-30mbps VPN. Woow x2 :)

no, it is not enough. Even for internal network
So what is use of wasting time/resource for these old devices? From my point of view, security releases for v6 is enough
Modern kernel on old device for what? And other people who have modern device, suffering from MKT decision to postpone v7 because compatibilty issues...

ok, about OpenWRT
Yes, they are running DSA, HW offload, on most architecture with Kernel 5.x
I am using it every day
No, i don't say it is perfect, but, it is community driven project, and it is WORKING!
MKT is paid project, and it is NOT working. Do you see difference?

and no, i am not arguing
only higlighting some facts and wrtiting my oppinion why MKT should drop support for 32MB ram and 16MB flash in v7

have a nice weekend
73 & DX from from ex HAM, op Peca, yu7ady/yz7rly

@npeca75: Amuse yourself and look up average internet speeds. :) I'm also lucky home user with 200Mbit FTTH, but most people have much less. So someone who is happy with 20Mbit VPN is pretty normal. If they now use TCP OpenVPN with v6, then new v7 with UDP OpenVPN is good example of useful improvement. And WG even better.

I won't defend all MikroTik's decisions. I think that some of them are really bad (16MB flash). But long term software support is good one, in comparison with others, where you get almost no updates. A something in between approach, where older devices would keep v6, but would still get new useful features, would probably be ok too. I mean for customers, but I'm not sure that it would help MikroTik that much. Backporting stuff needs work too. But once you get the new version going, you have just one to worry about.

In retrospect it seems unfortunate that they used so many different architectures. But it's not necessarily what's slowing them down now. Once you get the kernel going, lot of other stuff is user space and common for all architectures. Yes, they publicly admitted that they are waiting for TILE right now, but it's a special case, they can hardly cut off architecture used by their high end devices, especially when they still sell them. It would be much easier for e.g. SMIPS or PPC. I'd actually agree with SMIPS, because they already removed some features, so even v6 is not complete RouterOS, and the hardware is clearly too limited to have any bright future. And nothing against PPC, but no recent models have it, so they could get away with it (but I'm not saying they should, unless it's too big burden).

I agree with Sob, my internet is 100 Mbps down 30 Mbps up so for a VPN my speed is not going to be above 30 Mbps. And that is even quite high, on other connections it may be 5 or 7 Mbps in this country.

Also, I prefer RouterOS over OpenWRT any time. But I think those that don't are welcome to use OpenWRT (even on MikroTik hardware).

Simply put, version drift is bad. Even if older devices get a limited version, having everything on a single version level is valuable.

Custom developed ("home made") devices drives and thread/concurrency problems like kernel-mode deadlocks are example of quite common issues and are particular error prone in case of low level development. The final 5% of the bug management often consume more than 90% of the total development time. That's why it's important to streamline the development process with ready made drivers and and skip as much as possible of the "not invented here" syndrome that might linger from the earlier days of RND.

I add few words to this OT,

parham :

And I'm sure changing for 16MB to even 1GB nand will cost MT less than $1, can we ask then to prevent using abd developing hardware with less than 128MB.

People think that way but this is not only a +1$ for memory chip... and the same for switch chip, many times this is CPU internal feature who have Ethernet on-board, means inside CPU.
How many people say... MikroTik, why LTE devices use 100Mbps, this is only +1$ to price. This is so common.

Example of 1$ upgrade for ETHERNET:

• 179$ LHG LTE6 kit
• 199$ LHGG LTE6 kit

give you +20$ and the PCB must be reorganise for new CPU... arch was change... but the same LTE module, the same antenna gain.. only CPU must be changed to reach 1GbE

20$ is for many people big difference. My 90% will be still normal LHGR without lte module + m.2 adapter + Quectel EM12-G

My summary is differ.
People not see a real bottleneck and can not understand why 100Mbps is sometimes a good option, crazy ?

• marketing bottleneck: 100Mbps, but people with SXTR/LHGR/LDFR buy this hw for build-in "external antenna" in one box for start reaching more then 10/2Mbps.
  Many person who write to me connect from far away where other ISP/WISP not exist . This is my scenario. They always say... this 100Mbps, if not this my LTE will be faster ? :)
• for me bottleneck a) - LTE modules base on regions SoC, not Global. Chateau use Quectel EG12-EA, why not global ? Because MikroTik belive lower price and differ devices for differ regions will keep the lower price.
• for me bottleneck b) - SLOT mPCIe... probably with ROS7 stable MikroTik introduce 5G modules base at M.2 SLOT, I hope but this open path to insert many other non-mikrotik devices in future. Maybe they stay at mPCIe and this will for us start of era close unit for only MikroTik lte modules because m.2 adapter cannot solve heat problem...
• for me bottleneck c) - R11e-LTE6 Cat.6 without 2CA for B1+3/7, I hope this will be solved by feature firmware update and new lte modules can do CA for UE B1/3/7/8/20 any combination.
• for me bottleneck d) - They are others, as always :)

In my opinion, the bottleneck a/b/c should be solved before or with 1GbE Ethernet feature. Solving 1GbE first by +20$ not change situation for me a lot.

Summary: Sentence to add 1 $ is fake.

Continuing OT

20$ is for many people big difference. My 90% will be still normal LHGR without lte module + m.2 adapter + Quectel EM12-G

Basically I agree regarding the GBE interface but it feels like a slightly twisted comparison with the other $20 since the price with your configuration using a "Quectel EM12-G" adds another $330.

Another major functional bottleneck is the antennas in LHG which are marketed for use in extreme rural conditions. Considering these conditions when only the lower LTE bands are available in practice, the LHG antenna has effetely no signal gain at all which is quite absurd and directly contradictory considering the marketed use case.

I believe it's on the edge of false marketing using a statement like this:

"The LHG XXX is a device for very remote locations that are within cellular network coverage. Mount it outdoors, on a pole, mast or any tall structure, and connect even where cell phones fail. Due to its large sized high gain antenna, LHG LTE6 kit can connect to cell towers in extreme rural locations, giving you the ability to provide last mile internet access where nothing else is available."

Regarding LTE-modules I would love to see a simple DSL (domain-specific language) with hooks (for ie "enable/disable/connect" etc) that can be used as a replacement or add a new drivers to control MBIM/AT for whatever reason. In the bottom line, it's just text to be acted on. That would make it extremely fast en easy to add new LTE-modules that make them functionally equivalent to for example R11e-LTE6.


EDIT: Changed DLS to the correct spelling "DSL" (Domain-specific language)

Larsa

Basically I agree regarding the GBE interface but it feels like a slightly twisted comparison with the other $20 since the price with your configuration using a "Quectel EM12-G" adds another $330.

LHGR (without lte module) 102$ + m.2 adapter 5$ + 2x pigtails (u.FL F <5cm,10cm> MHF4 F) 2.5$ + EM12-G 90$ = ~ 200$ for finish unit with 100MbEthernet limitation.
Contact me PM or Telegram or in other thread about details bcs it's to big OT.

So someone who is happy with 20Mbit VPN is pretty normal. If they now use TCP OpenVPN with v6, then new v7 with UDP OpenVPN is good example of useful improvement. And WG even better.

Hi @Sob

TCP and UDP OpenVPN are both (almost) useless in MKT
There is millions,billions,zillions OpenVPN servers with lzo or lz4-v2
And without password auth, only Cert.

So everyone who want to use MKT to reach these servers, need to call the IT dep and say: I am using MKT, and i have only partly implemented OVPN, please, could you setup your linuxes according to my MKT ? :)

and no, comparing WG and OVPN is not correct. WG could not replace OVPN as L2 tunnel (ethernet mode)

only partly useful improvement

You forget that there still is a use-case for the classical meaning of a VPN, a virtual private network.
It is e.g. a network between a company and its branches or employees working from home.
Both the server and the clients are under a single management which can decide what to buy to make them compatible.
The transfer rate is usually limited to the uplink speed of each connection, and it does not need to max out the downlink speed, it only need to match the requirements.

Today, many think that VPN always refers to the services that are intended to dodge your identity from law enforcement, media rights enforcement, etc.
But that is not the case and lots of users never use that form of VPN. I think those "newfangles" uses of VPN should use a different name, maybe EPN (enhanced privacy network) or so.
Of course in those cases you take the services from another company who decides on the parameters and when to change them.
Not a safe bet to buy equipment from another source which may not follow those changes.

This is clearly off-topic gone wild, but let me add my 2¢ anyways. :)

That 16MB flash thing is not only economical, but also technical. If you take a close look on the different RotuerBOARDs you'll notice that all those 16MB flash devices use SPI Flash chips, whereas devices with a larger amount of flash usually use NAND flash chips. And that's significant. For IPQ4018 SPI flash is the only available option, whereas IPQ4019 also supports SD/eMMC and ONFI interfaces. But as with a lot of other microcontrollers, some pins are usually shared between different interface, so you have to chose what to use. Have a look, for instance, at hAP ac3 and hAP ac3 LTE6 kit- the former has no mPCIe slots and 128MB NAND flash, whereas the latter has mPCIe slot (with LTE modem preinstalled) but only 16MB SPI flash. Are those related? I don't know for sure, but I guess they likely are.

For SPI flash, 16MB (128Mbit) is the maximum you can access using a "traditional" 3-byte addressing. I know (I googled) there are IPQ4018 devices on the market with 32MB SPI flash chips. What stops Mikrotik from doing the same? I don't know. There may be some hardware compromises to consider, or it may require architectural changes, or... I am just inclined to believe that they have a good reasons for that.

You forget that there still is a use-case for the classical meaning of a VPN, a virtual private network.
It is e.g. a network between a company and its branches or employees working from home.

no ! @pe1chl
YOU forget that world is not made by MKT
There is plenty other network equipment from other vendors.
So, you think, when company buy few MKT device, it should change all other equipment to MKT to maintain compatibility ?
I am using on my work lots of different network device. And strugling with MKT denial to implement things as it should be

Sorry, but whenever somebody say something against MKT, you shown on the forum, and start advocating, defending MKT
i don't care what is your personal reason for this behaviour, but it IS a forum, where user says oppinion about MKT gear,
eventualy, try to force MKT to implement stuff to full functionality
and if MKT implement only half of OVPN, only half of IPV6, only half of ...
Should i paid HALF of price?
Ok, let it be, to stop this OFFtopic
Tomorrow i am goin in shop, and i will paid only the half. When seller refuse to give me MKT device on half of price, i hope you will be there with same entusiasm defending me against seller, speaking that HALF IS ENOUGH !!!

offtopic closed

Should i paid HALF of price?

Well, you kind of do...
Maybe even less, compared to other brands :)

@npeca75: I think you misunderstood some parts. If for example MikroTik's OpenVPN implementation is lacking, it's not good, and I don't think you'll find anyone saying otherwise. But it still can be good enough for someone. If it's simple VPN used by employees to access office from elsewhere and RouterOS is server (I have this in several places), you have all interoperability you need, because every client will be able to connect to it. If it's the other way around and you need to connect RouterOS client to more capable server, it's problem and it's bad. But in first case it's almost fine. It will be even better with UDP OpenVPN or WG (which in this case is good replacement, because there's not need for L2). And it's good that updates bring these new features. Who knows, maybe one day we'll have full OpenVPN, and everyone will get it, because MikroTik releases updates even for old devices.

LMT Mikrotik LTE18 with RouterOS version 7.1beta2 is so buggyyyyy! :)

That's because it's beta. It's betta than nothin'...

Currently we are having issues with beta3 booting on TILE architecture. Beta3 will be available when we get these issues sorted out.

Damn straight says the CCR1009 owner! ;-)
Of course all the work should be done on TILE first and then ported to all other architectures. ;-P
Bets, ........ which comes first, v7 stable/long term release for my CCR, or a shot of covid vaccine ???

Bets, ........ which comes first, v7 stable/long term release for my CCR, or a shot of covid vaccine ???

My bet: shot of Canadian Rye comes first ... or in my case, shot of good home made juniper brandy (no, not gin, that one is tasteless compared to real thing).

I don't get Mikrotik. They just released "6.48beta58 (2020-Nov-24 08:31)" and "6.47.8 (2020-Nov-25 10:10)". While it is perfectly fine to work on STABLE releases - as people depend on it on their PRODUCTION devices.

But honestly - who cares for 6.48beta58? That's a REAL beta channel. Nobody is FORCED to use that 6x BETA - it is PURE voluntary. WHY has that channel PRIORITY over v7 beta??????!?!?!!?

v7 BETA instead runs on devices, which CLEARLY DO NOT SUPPORT ANY STABLE RELEASE OTHERWISE.

I don't get it. I will never understand, HOW so LESS energy and effort is put into developing v7 - WHEN THERE ARE DEVICES, WHICH CANT RUN ON ANY OTHER BRANCH THAN v7 INSTEAD. see Chateau LTE12.

That's because it's beta. It's betta than nothin'...

I can't see anybody laughing or clapping to this comment....

Well, your viewpoint is understandable from a user of a device that supports only v7, but for other users it is confusing that fixes introduced in the 6.48beta58 version get backported into 6.47.8 (stable) and released before even getting feedback on the resolution of the problems reported in the corresponding SUP tickets!

Long ago we must choose, new CCR with only v6.x or RB1100 and stable 5x.
We select CCR and problems happens, we hop from v6.4 to 6.19 who was first stable for us... so many frustration when you cannot comeback to real stable ROS.
The same all people who buy LMT LTE18 :), they cannot use netinstall and back to original ros7.0 stable...

I understand all that persons.

I am rebooting my chateau let12 at least twice a day, because of known dhcp issues. i guess i need to schedule a reboot every 6h or so.

I am rebooting my chateau let12 at least twice a day, because of known dhcp issues. i guess i need to schedule a reboot every 6h or so.

I had this issue with HAP AC^2 but on opening support ticket they provided me with rosv7.1 beta 3 and that resolved this dhcp issue.

Their Android app is buggy too. tried to add a schedule - but it does not accept a valid interval. hahahhaha

I don't get Mikrotik. They just released "6.48beta58 (2020-Nov-24 08:31)" and "6.47.8 (2020-Nov-25 10:10)". While it is perfectly fine to work on STABLE releases - as people depend on it on their PRODUCTION devices.

But honestly - who cares for 6.48beta58? That's a REAL beta channel. Nobody is FORCED to use that 6x BETA - it is PURE voluntary. WHY has that channel PRIORITY over v7 beta??????!?!?!!?

v7 BETA instead runs on devices, which CLEARLY DO NOT SUPPORT ANY STABLE RELEASE OTHERWISE.

I don't get it. I will never understand, HOW so LESS energy and effort is put into developing v7 - WHEN THERE ARE DEVICES, WHICH CANT RUN ON ANY OTHER BRANCH THAN v7 INSTEAD. see Chateau LTE12.

You buy a router that only support beta version maybe next time you will read the datasheet and take a router that support stable release if you don't want bugs.
Of course they still develop 6.X version. In 4-5 years maybe they will develop 8.X version and you will be happy when they will maintain your 7.X version.

Well I also have this router and there are some problems.. But, when I was choosing the router I did not read nothing about beta version of firmware on page of seller (in my case czc.cz)
So I did not expected that it has only beta firmware and I will have to solve, that the wireless clients are unable to connect and so on..

I think, on sellers eshops should be information, that it is running only on beta firmware. If I knew it before, I would thing about to buy it.. Also I think that the information about beta firmware should be provided to the sellers by mikrotik - they gave them descriptions of the product... And this information is missing.

Nobody can expect, that if somebody is choosing router, that will go to the producer site and check datasheets.

You buy a router that only support beta version maybe next time you will read the datasheet and take a router that support stable release if you don't want bugs.
Of course they still develop 6.X version. In 4-5 years maybe they will develop 8.X version and you will be happy when they will maintain your 7.X version.

You buy a router that only support beta version maybe next time you will read the datasheet and take a router that support stable release if you don't want bugs.
Of course they still develop 6.X version. In 4-5 years maybe they will develop 8.X version and you will be happy when they will maintain your 7.X version.

WHat A dUmB CuStOmEr!!! buys a product and thinks it is ready for public! must be a real fool who buys hardware from mikrotik without checking if the hardware is running a stable software! these customers are real village idiots!111!!

I would be fine running v7 beta ROS on my device when I could see frequent beta releases - including fixes. Wireguard may be unstable - its okay - just beta. there may be missing features - its okay - just beta.

But since August no beta release is - to be honest - really unfair and disrespecting everybody who bought devices like CHATEAU LTE12. It looks like Mikrotik does not care for v7 at all.

Mikrotik cares but the Beta has problems with booting the Tile architecture so not released yet.

If your Chateau has problems the ask support if you can have Beta 3 already.

I got today beta3 from Mikrotik, seems to be solved.. clients are connecting correctly.

Does anyone have CHR version of beta3 to share? :)

I got today beta3 from Mikrotik, seems to be solved.. clients are connecting correctly.

For Chateau? Can you share it with me? I have issues too, I hope it will fix at least Wi-Fi issues.

Yes, write to the support, they react very fast and will provide you with the firmware

For Chateau? Can you share it with me? I have issues too, I hope it will fix at least Wi-Fi issues.

Yes, write to the support, they react very fast and will provide you with the firmware

For Chateau? Can you share it with me? I have issues too, I hope it will fix at least Wi-Fi issues.

Unfortunately, this time they don't react fast. Why you can't, they prohibit it?

UPD: Nevermind, I found the link in another topic.

Tried that version on my RB4011. Always crashes after some seconds after boot. Wonderful .. x_X. At least I was able to downgrade within these seconds.

Tried that version on my RB4011. Always crashes after some seconds after boot. Wonderful .. x_X. At least I was able to downgrade within these seconds.

Of course wise people (with devices with 128MB or more of flash) use partitioning so they can try a new version and go back to the old one without risk.

Wise people don't even try a beta version which isn't even released officially. ;)
So don't get me wrong.. I'm not really complaining. I wasn't clear in that way. I even have done that remotely. No risk, no Fun :D

But it never hurts to read about partitioning, how to set it up, and how it works e.g. when the system cannot boot.
I always use it on every upgrade on devices that I manage and that support it (i.e. everything besides the 16MB flash devices) and it has sometimes saved me.
Before I do an upgrade, I do a copy of part0 to part1, then I upgrade, and it has happened that I found the device running part1 with the old version after that.
(because the upgrade made it fail to boot)

The only thing you need to watch out for is erratic power. Either because local power grid has many breaks shortly after eachother, or impatient users pulling the plug.
When the power drops during the boot process, the router will boot the other partition when it comes back. When you do not notice that, it will be running an old version and/or old config.

But it never hurts to read about partitioning...

I didn't know about this, so the old adage is correct.. learn something new everyday. Thanks.

Ok one warning though: there is someone who claims that setting up partitioning (i.e. the creation of 2 partitions on a device that has only one) is broken in all 6.47 versions.
I cannot verify that right now as all my routers with that capability have been partitioned on older versions. For sure the copying between partitions still works in 6.47.x but it may be that setting up 2 partitions renders the router non-booting.
So at least make a backup and export before you try it and do it only in an environment where you can do netinstall if required.

Apparent OSPFv3 bug in v7.1beta3 - PTP network type is giving "wrong checksum" when trying to establish neighbor with ROS v6 device. OSPFv2 seems to work OK.

New version 7.1beta3 has been released in development RouterOS channel:

viewtopic.php?f=1&t=169992