And some other supported modems are … brand/model ?
There are thousands of models out there. It is not MikroTik’s job to direct you to their spec sheet, especially for something that they do not sell or even support (beyond best-case effort of generic driver). If you need to find one, go browse Fibocom or Quectel product sheets and look for chipsets that support eSIM - simple as that.
Since this is the beta thread… questions and feedback should be encouraged — without insulting comments from others. I made the points I want to make about eSIM — it was feedback to Mikrotik, not you. I like Mikrotik and their products & making suggestion for improvement in communication. If you think I’m “lazy”, I don’t care.
Anyway… different topic…
I came here to actually report about file-share. I’ve done a bit of testing of it & I think it’s going to be a very useful feature.
Overall, file-share worked well, both in direct mode and via the proxy. I’ve mainly been testing in proxy-mode* since I want the https REST server working. And using it to copy scripts from my desktop to test router, without scp/etc. So I know the “Allow Uploads” works. 
If anyone’s curious on how it works, without the spiff website, using command-line curl, I wrote that part up here: http://forum.mikrotik.com/t/uploading-files-from-bash-to-7-18s-ip-cloud-file-share-feature-using-curl/181789/1 .
My main issues come when sharing a single file… (which improved since beta2, so still oddities in beta4).
“File Direct Url” should use the single file as part of the URL. While the link works, what happens is the filename is the “File Share Key” without extension (so the file cannot be opened by type). Adding the file the url does work, but it should be cut-and-paste from the Direct Url
You can set the “Allow Uploads” when you have a single file, but the UI does not show an upload button when enabled. The idea being you might want to REPLACE a single shared file.
After upgrade to beta5, my /ip/service/https was in “I” invalid state. Disabling and enabling the HTTPS service, didn’t fix the invalid. I disabled all the /ip/cloud/file-share, and then disable and re-enabled HTTPS… and that worked to bring things back. I do have IP restricts set on /ip/service/https, so maybe that confused something. Anyway, the confused relationship (or perhaps just inversed?) with /ip/service/https and file-share is a bit confusing.
On the positive side,
Liked how the web UI changed to a “icon view” when it was only a single — nice touch. (*other than upload button getting lost)
Since I had to use “Inspect” of the file-share’s webpage, to figure out file-share used “multipart/form-data” encoding. I took a peek at the HTML page… absolutely loved the minimalist/framework-less implementation - no libraries, just plain JavaScript!
My only enhancements be…
While the CLI in /ip/cloud/file-share/settings/print tells the proxy vs not proxy. This is not obvious to most folks I’d imagine but effect troubleshoot… So file-share “status” should be in the webfig/winbox UI too. Also, the IP > Cloud dialog box is kinda odd now, since it shows ALL the BTH stuff on the “main” screen, while nothing about file-share. Basically IMO /ip/cloud/file-share/settings should appear as a top-level tab in winbox4, along with the BTH one (which has 3). Or perhaps the BTH should be also moved to a separate dialog to keep main IP > Cloud dialog “cleaner” or just pure status. Dunno… Anyway some thought should be given to look-and-feel on the “main” /ip/cloud screen … now that it’s getting more stuff under it ;).
And, want some user-level control on proxy mode or direct mode - the automatic switch based /ip/services REST is kinda weird and should be controllable in some way. Perhaps some master switches in /ip/services is kinda where you configure the router’s port listeners, dunno…
TLS is so critical for many things now… and while kinda esoteric file-share has nifty support for automatically dealing with certificates. Poor /certificate/enable-ssl-certificate requires a complicated dance to deal with LE’s HTTP auth (port 80) and the whole renewal is manual process repeats that pain. But, boy, /ip/cloud/file-share has all that down it seems… while “enable-ssl-certificate” is still – after years – a rather complex affair that likely detours TLS usage on webfig/IPSec/etc. Lots of places use TLS in RouterOS…
Along same line, CORS support for REST API is still missing – that others could build nifty SPAs using REST, like file-share.
Anyway, generally, good work on file-share.
On the note of above, can we please separate cloud package from routeros? Devices like wAP do not need cloud or file share support (on what? that 16M of FLASH or 128M of RAM, maybe? or maybe user is expected to solder to USB pads on PCB?). I’m not gonna ask you to separate SMB/NFS/Btrfs support since that’s all done in kernel modules and complicates your codebase (though would provide much needed space on devices with 16M FLASH storage, not like they’re gonna be mounting any Btrfs disks anyway), but Cloud is just your code that can be separated easily and with how its growing in size, it might be about time to do it. I was quiet when you added BTH because it’s mostly a wrapper on top of WG interface, but if you have plans to introduce even more functionality that is not re-using code from base then it needs to happen, period.
Ideally you’d keep it pre-installed on new devices of course, so that users get full access to it without having to install any additional packages (though it would seem you have made some good progress on that front in this version with ability to download packages from ROS itself).
I can offer all my technical knowledge for VXLAN and L2VPN EVPN family (quite some). I am having really hard time get static VXLAN running between 2 CHR in different cloud providers. Version 7.17. I am not sure if there any limitation. All underlay is running, I can ping loopback’s. Overlay VXLAN is not forwarding traffic.
I think most common use case for EVPN family will be
East West stretch between leafs for internal any cast gateway
EVPN VXLAN Centralized Default Gateway
Cisco example
# Anycast Gateway MAC, identically configured on all VTEPs
fabric forwarding anycast-gateway-mac 0002.0002.0002
# Distributed IP Anycast Gateway (SVI)
# Gateway IP address needs to be identically configured on all VTEPs
interface vlan 201
no shutdown
vrf member Green
ip address 192.168.1.254/24
fabric forwarding mode anycast-gateway
My setup already uses the second url since day 1.
You are presumably a professional.
Professionally maintaining a system that other people use is different than running a home router and a couple of APs. That includes never installing updates without reading the changelogs, identifying possible critical changes and reading the relevant documentation. In case of doubts you contact your vendor for clarification (and not by accusing them on all kinds of things on their public forums).
And then you test the deployment and poke at the new changes before you make a decision to roll out in production. If any issues are identified, you contact your vendor and hold back on the roll-out.
What I’ve seen are people far to eager to install updates on production systems the second they get the notification and then complain when something changes that they could have read in the changelog and documentation.
Well, I really think that all applications should be separated in packages, not only that but also stuff like proxy, smb, hotspot, etc.
But as far as I understand the architecture there is some overhead for having a package, and thus the situation in a 16MB flash device where all the packages are loaded by default there will be even less available space.
Of course joe the average user will never remove the packages they do not need, so on average the situation will become worse.
However, now that adding a package has been made much easier (finally!) it might be possible to deliver the devices without such packages installed and direct the users to install them as needed. And on upgrades there could be some logic to install optional packages only when they had been configured at the time they were part of the base package.
(moved bottom)
https://forum.mikrotik.com/viewtopic.php?p=1125322#p1125322
I disagree … it’s about defining (MT’s job with input from us, users) basic set of functionality, expected to be run by flash space constrained devices. And that should be included in base package, the rest should be in separate packages.
If device has plenty of storage (e.g. 128MB+), then a few 100kB (or whatever the package overhead) of increased usage doesn’t matter that much. On the other hand inclusion of certain kernel modules and user space binaries (e.g. smb, nfs, BGP, etc.) to base package does eat into precious little storage on devices where those functions are not used. And I don’t buy the “it’s part of kernel, userland is neglectable” fame … kernel modules can be installed by packages as well, userland is never neglectable. For example: BTRFS module on kernel 5.10 on x86-64 machine is hefty 3MB file … yes, on ROS it’s likely a bit smaller, but even 300kB spent on 16MB flash device with no need for BTRFS ever is outrageous (BTW, most wireless drivers in same kernel are much less tgan 1MB in size … just to put things into perspective)
Yes, there will be people trying to use e.g. hAP ac2 (or CRS317) as NAS server, but most users will use it as intended (hAP ac2 as wireless router: no NAS, no routing protocols; CRS317 as switch: no NAS and no routing protocols). And mentioned two devices illustrate clearly why wifi/wireless drivers should not be part of base package … CRS without wifi drivers can afford additional package with routing services and should still leave some flash free.
But should we all suffer because of a fraction of users who want to squeeze last drop of juice out of their underpowered devices? I think not, everything has its limits, sometimes one simply has to purchase a better device. And it’s up to MT to decide about intended usage … and hopefully stick to it during entire device lifetime, it doesn’t resonate well for MT to decide that e.g. hAP ac2 is no longer a wireless router (instead it should be either simple AP or wired router).
It would already be sufficient if the 16MB devices (and there are quite a few of them) don’t run out of storage soon. The shrinking trend is once again noticeable with version 7.17 onwards.
Well of course it would be possible to have different routeros base packages, where the kernel modules and userland code for a lot of features are or are not present. I don’t see the typical hAP ac2 user use stuff like MPLS, for example.
I can understand why MPLS would be difficult to keep in a separate package (it was in v6…) but should not be a problem as compile-time option.
It should be doable to group a number of “home” and “business” features and make 3 RouterOS versions out of them. (home, business, both)
And then at some point in time, the 16MB hardware would no longer be able to run the “both” version.
On “16MB” devices (like hAP lite) much bigger issue is RAM. I was unable to normally use my hAP lite on v7 with standard config and additional WireGuard tunnel. It was working by itself for a short period, but when you try to connect via WinBox and do something, CPU jumps to 100% and everything stops working. After some time it goes to reboot. On v6 it runs flawlessly, but there is no WireGuard.
There are two distinct types of 16MB flash devices:
Your use case, with all due respect, falls into “device abuse” category. But with hAP ac2 and CRS317 (and several other devices) the flash size gets limiting factor even when using device in line with intended purposes.
Where is abuse here? It was using default config. I’ve only added WireGuard for being able to control it remotely and transfer files sometimes. But even without WG it was barely working and it was hard to just log in. After reporting to support, they’ve improved behavior a little bit (MT, thanks), but anyway, it’s far from ideal. It worked perfectly on v6 with IPSec instead of WG, but tunnel speed was twice slower compared to WG.
On that device, IPSec is hardware offloaded, while WG requires CPU… Question be how well does the IPSec config on v6 work when used as-is on v7 - that be more apples-to-apples test, given IPSec offloading.
But no doubt RouterOS v7 uses more RAM than v6. And I’m sure more optimization is possible in v7.
I add severity of issue as dimension in RAM vs flash debate. The lack of flash causes device upgrades to fail, while lack of RAM is trying too much on too small a device. I like the new file-share feature, and may try on 16MB thing - but I’m not playing using it on deployed fleet of wAPacR/hAPac2/etc (and can’t on MIPSBE things). On newer hardware eventually. So the flash issue is a bigger one, since broken routers in field are costly in my case.
Issue today is I really do not want to have to pick between security and potential outages due flash issue on upgrade with these older 16MB devices. I’m fine without file-share etc on them. Between the FUD around “device-mode” and borked upgrades on 16MB flash… it is just going to cause folks to NOT upgrade & we’re back at unpatched system with vulnerabilities down the road.
Hardware offloading on hAP lite??? No, it’s not
True. My bad! I thought complaints were on hAPac2… My main point was changing two things at same time, makes it hard to judge which is the bigger performance issue. i.e. V6+IPSec vs. V7+WG
This. It’s a lite, for Deity’s sake.
For RAM I’d say WG definitely … because IPsec is part of ROS since ages and I’m sure they did whatever possible to reduce its memory footprint. I don’t think they put the same amount of energy into WG so far.
I’m not saying anything about CPU utilization, but probably WG fares better (everybody’s saying how WG is lighter on CPU than just about anything else, including CPU-driven IPsec).
It would already be sufficient if the 16MB devices (and there are quite a few of them) don’t run out of storage soon. The shrinking trend is once again noticeable with version 7.17 onwards.
Thanks to file sharing, the growth between 7.17 and 7.18beta5 is about 120KiB. On a device that fits base + wifi-qcom-ac and minimalistic config with about 200KiB to spare (on 7.18beta5), this is worrying. On a device that wasn’t netinstalled and upgraded from factory v6 (as new wAP still came with v6 from factory in 2024 it seems) this free space might be more like 140KiB. Two more updates like this and the device reaches definitive end-of-life. And it’s not like these devices are old either, MikroTik has released devices with 16M storage in 2024 (see https://mikrotik.com/product/wap_ac_lte_kit24).
We need separation of packages like cloud for these ARM-based devices that are meant to be pure APs and come with 16M storage now and we need it badly, because users are suffering and unable to use their devices already.
I understand why MikroTik decided to abandon v6 model of dependent packages, but the growth rate of v7 has been unsustainable recently and I do not see easy way out if they want to continue cramming all the features into base ROS package. Really struggling how MikroTik gonna stick to their “5 years of upgrades after purchase date” for some of devices released in 2024, because they are already failing on user’s desks unable to take any config changes as they ran out of space!