Community discussions

MikroTik App
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Container Support to MIPS Architeture

Wed Jul 13, 2022 3:40 pm

Intentions:
The purpose of this post is to present reasons that make the idea that Mikrotik starts to support the MIPS platform for the Container feature in RouterOS 7.X and bigger.

Proportion of hardware with MIPS architecture in Mikrotik's portfolio:
I think it's almost unnecessary to bring up this argument, but it's always good to adjust to exemplify what the gain and increase in possibilities would be.
In the following link we have the Mikrotik product matrix officially published by itself.

I have attached the CSV that i downloaded on 2022-07-13 where 390 items are listed.
116 are related to the MIPS architecture (SMIPS->3, MMIPS->8, MIPSBE->105).
On a dry account we have 30% of the published portfolio being MIPS architecture.

And I am convinced that if mikrotik could add the number of devices produced/sold in each row of this spreadsheet, the proportion of MIPS devices in absolute numbers would exceed 70%.

The existence of MIPS architecture support in Container technologies:
Docker:
It is a fact that the dominant tool in the world of Linux containers is Docker, and if I didn't make a mistake in the interpretation, the official information from Docker says that it does support the MIPS architecture.
docker-library/official-images
It says: "As of 2017-09-12, these other architectures are included under the non-prefixed images via "manifest lists" (also known as "indexes" in the OCI image specification), such that, for example, docker run hello-world should run as-is on all supported platforms."
The Open Container Initiative link points to supported architectures in:
$GOARCH on GO Language

Also, in the special MIPS architecture section of Docker Hub there are official images to Debian and Busybox.

Podman and other Container engines:
In addition to Docker, other engines like Podman and some listed at https://github.com/containers also support the MIPS architecture.

Possible uses:
Well, when talking about containers running inside devices like RouterBoards Mikrotik, we can say that if the limits of capacity and hardware characteristics are respected, "The sky is the limit".
P.S. Here is a suggestion of a hard/soft limitation previously defined by the configuration defaults to prevent some genius from unknowingly overloading the equipment's capacity and then complaining about the capabilities of the RouterBoard.

However functions that are in my plans at the moment are related to desirable services in an ISP/ITP management network, such as Zabbix Agent, or Syslog Collectors.
Note: Support for M.2 drives on miniPCIe got me really excited about these ideas.

Obviously, it doesn't stop there! Reverse proxy with NGINX or Traefik is very promising. And DNS-related services like an authoritative DNS engine, or things like pi-hole also need no explanation of how they would be useful to the niche market that Mikrotik serves.

And what about MetaRouter?
Well, Metarouter is/was something very smart! I think it did its job...
But today, if we compare the Workload of maintaining a Container Registry, or the idea of ​​having to build images to put services running inside a RouterBoard using MetaRouter, I think the reason to avoid thinking about Metarouter is quite evident.

"But it has already been said that the MIPS architecture will not be supported by RouterOS":
Yes, I've been reading and researching this before creating this post.
I found some answer from
Normis
,
pe1chl
,
jbl42
,
tangent
about that starting in post #214 in topic v7.3 and v7.3.1 [stable] is released!

However, I want to believe that these points that I have brought up here have not been fully taken into account at that time.

Thank you in advance for your attention and effort to understand these arguments.
 
tangent
Forum Guru
Forum Guru
Posts: 1333
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Container Support to MIPS Architeture

Wed Jul 13, 2022 5:07 pm

Proportion of hardware with MIPS architecture in Mikrotik's portfolio:

Proportion of official Docker tool chains for supporting that hardware: 0%.

Even if you posit that someone (who?) steps up and creates MIPSBE, SMIPS, and/or MMIPS Docker buildx toolchains for you, the MIPS hardware in MikroTik's line tends to be the lowest-end stuff, often without enough space to reliably do OS upgrades if you've got anything complicated going on in the background.

It's best to tare the baseline 16 MiB of storage out to "0" for the purposes of our discussion here. A 64 MiB device has 48 MiB free for Docker, etc. According to that data table you've linked to, that disqualifies 57 of the MIPS devices right there.

It's only 57 if you keep the ones with external storage options on the theory that you could put the container there, leaving the internal storage free for OS upgrades. That's an iffy choice, since USB memory sticks and microSD cards are notorious for crapping out when made to run applications long-term.

USB does allow for a proper SSD, but if you were hoping to run containers on your cAPs and hAPs and mAPs, this is likely to require doubling your hardware investment.

the official information from Docker says that it does support the MIPS architecture.

The page you reference points to a "Community Organization," meaning it's entirely non-official. Some rando on the Internet got a bee in his bonnet and created these containers.

Doubtless one could take this work and retarget it to the CPU architectures MikroTik actually uses, but are you that one? I'm not.

Architecture details matter. "MIPS" isn't a single thing, it's a wide family of architectures spanning decades, and they aren't all mutually compatible. In this case, the community project you reference ships containers for MIPS64-LE, a 64-bit little-endian CPU architecture.

The 105 devices in your CSV that run on MIPS-BE are completely incompatible. That's a 32-bit big-endian CPU architecture. Either difference would be enough to prevent those binaries from running.

All of the 8 MMIPS devices and the 3 SMIPS devices fall into the "16 MiB storage limit" bucket. Some do allow the user to add USB or microSD storage, but since these are also 32-bit architectures, they're still incompatible with those MIPS64-LE images.

if the limits of capacity and hardware characteristics are respected, "The sky is the limit"

That must be the sky bumping into my ankles, then. :)

Zabbix Agent

That container's nearly 16 MiB all by itself. It probably wouldn't even upload to the 63 devices on your list with 16 MiB of built-in storage, much less unpack and run.

Syslog Collectors

If logging to internal flash was a good idea, RouterOS would do that already. It defaults to logging to RAM instead to avoid burning out SoC's on-chip storage, since that failure mode is functionally irreparable. It's BER for depot replacement on the inexpensive end of the MIPS devices, and beyond practical field repair for any user without a hot-air rework station, a JTAG programmer, and steady hands.

Logging to microSD or a USB stick is likely to burn that out, adding an ongoing replacement cost to your plan.

No, set up remote logging to a proper server and be done with it. It's not only going to avoid all these problems, it gives the benefit of central logging.

If you were thinking to make a single RouterOS box your central logging host, then my objections above multiply by the number of devices feeding it. If your storage's MTBF is an optimistic 5 years with one device logging to it, it drops to half a year if you have 10 hosts spamming the poor thing.

Support for M.2 drives on miniPCIe got me really excited about these ideas.

The slot in MikroTik hardware is generally for an LTE modem or similar. You either need a second slot to make that work, or you have to buy an "LTE" product and then use it as a wired or WiFi product.

In any case, there are likely only a few MIPS-based products in MikroTik's line that might be able to do this, if you lump all the wAP* things together and such.

Reverse proxy with NGINX

The official Docker container for nginx is 141 MiB. There are zero MIPS devices in MikroTik's line with enough internal storage for that.

One could doubtless squeeze some fat out of that and maybe get it to fit on a 128 MiB device, but if it were me, I'd use something else entirely, something inherently small, not the single most powerful web server in the world.
Last edited by tangent on Tue Mar 28, 2023 2:31 pm, edited 1 time in total.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Container Support to MIPS Architeture

Wed Jul 13, 2022 5:44 pm

@fischerdouglas

I want container on my RB133C3, is mipsle, is possible?
Has 16MB SDRAM and 64MB NAND
 
User avatar
chechito
Forum Guru
Forum Guru
Posts: 2989
Joined: Sun Aug 24, 2014 3:14 am
Location: Bogota Colombia
Contact:

Re: Container Support to MIPS Architeture

Wed Jul 13, 2022 5:46 pm

MiPS devices have too scarse resources to run containers (CPU, RAM memory, internal storage, high speed interfaces for additional storage, 64bit support)
 
r00t
Long time Member
Long time Member
Posts: 672
Joined: Tue Nov 28, 2017 2:14 am

Re: Container Support to MIPS Architeture

Wed Jul 13, 2022 7:29 pm

Just because containers so far are huge doesn't mean you can't have single purpose one that's just a few kB in size. In the end container can be as small as you can make statically linked executable. No, you are not going to run pihole or your web server on it. But for something like port mapper or multicast to HTTP proxy or maybe MQTT agent, it can be tiny.

Containers are much more lightweight than complete VM that was done by Metarouter and yet we have used it before to run VOIP server on RB433 inside OpenWRT VM.
It would run even better in a simple container without VM overhead.

So having containers on MIPS would certainly make sense and it would be a good feature to have.
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: Container Support to MIPS Architeture

Wed Jul 13, 2022 9:46 pm

@fischerdouglas

I want container on my RB133C3, is mipsle, is possible?
Has 16MB SDRAM and 64MB NAND
https://mikrotik.com/product/rbm33g
2 Cores with 880Mhz, 4 threads
256 MB of RAM
Probably with an M.2 drive of 128GB
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: Container Support to MIPS Architeture

Wed Jul 13, 2022 10:25 pm

All of the 8 MMIPS devices and the 3 SMIPS devices fall into the "16 MiB storage limit" bucket. Some do allow the user to add USB or microSD storage, but since these are also 32-bit architectures, they're still incompatible with those MIPS64-LE images.
Could you help-me calculate the proportion of the devices on that list that:
- Are non-mips
- Are not wireless focused
- Are under U$79 on the sugested price
?

Its pretty obvious that Mikrotik is going to ARM world. Everyone iso going to...
But what about lower budget devices? Will then be based on ARM also?
Had you access to some information about mikrotik no using MIPS never more?
No, set up remote logging to a proper server and be done with it. It's not only going to avoid all these problems, it gives the benefit of central logging.
Yep, yep! Thas is good... Depending on how much lost logs are important to you operation.
I used to do something close to that... I even do it on now days.
But In some scenarios, a local acumulator of syslog, and than shipping that to central site when connecivity is available, is a good idea.
Have you already suffered with blidness of loosing logs?
Have you ever had an issue with equipments on a Site/POP that were isolated (backbone)?
Joining it(or caused by) an eletrical outage at the region, reaching 0% of baterry charge on no-breaks...
The slot in MikroTik hardware is generally for an LTE modem or similar. You either need a second slot to make that work, or you have to buy an "LTE" product and then use it as a wired or WiFi product.
CCR2116-12G-4S+, RB1100Dx4, RBM33G

P.S.:
Thank you so much for being so kind and polite.
I wish you have a wonderful day!
 
User avatar
chechito
Forum Guru
Forum Guru
Posts: 2989
Joined: Sun Aug 24, 2014 3:14 am
Location: Bogota Colombia
Contact:

Re: Container Support to MIPS Architeture

Wed Jul 13, 2022 11:52 pm

Maybe next generation of RB750G something like RB750Gr4 can be de lower end for container support using external USB 3.0 storage i think it will be ARM

somebody speculate it will be 2 core 1ghz arm cortex a53 marvell armada 88F3720 like n-ray this CPU datasheet says it supports KVM and Containers
 
tangent
Forum Guru
Forum Guru
Posts: 1333
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Container Support to MIPS Architeture

Thu Jul 14, 2022 1:15 am

Could you help-me calculate the proportion of the devices on that list that:
- Are non-mips
- Are not wireless focused
- Are under U$79 on the sugested price

Instead of "non-MIPS", let's just say "ARM," since the only other viable option is x86, which removes all the limitations we're discussing in this thread.

There are 19 ARM products in the CSV file with either more than 16 MiB of internal storage or with a USB port to break past that limit. All MikroTik ARM devices with microSD cards have more than 16 MiB of storage, so no help there.

I'm not sure why you want the WiFi devices filtered out, but okay, that takes us to 9.

And your arbitrary restriction on price takes us to 0 devices.

If your point is that there should be more cheap ARM devices with lots of storage options, I share that wish, but be realistic: a Raspberry Pi 3B with a crappy network subsystem was $35 for the naked board before the supply chain crunch. Kit it out with a good case, a solid power supply, a reliable microSD card, and a PoE hat, and you're right around your $79 target. How is MikroTik supposed to match that while providing much better multi-port network I/O on top of it all?

No, I think you'd best expect a higher price cutoff for reasonable Docker hosting performance. TANSTAAFL.

To look at it another way, $79 is the MSRP of the hAP ac², which I'd class as barely capable of acting as a Docker host. Most tasks will require more. Either you've underestimated a "reasonable" price for this, or you rigged the question to force a "0" here.

But hey, let's be charitable and do a similar culling on the MIPS side; maybe we'll get a different answer. We start with 113 devices, which drops to 59 when you cut all the ones without enough storage, whether internal or add-on. Sounds great so far. Cutting it at your arbitrary price point reduces the list to 12, though, and removing devices with WiFi leaves us with only 3 options: the hEX, the hEX PoE lite, and the RBM33G.

To include the RBM33G is arguably cheating, by your criteria. It's a naked board, and adding the optional case brings it to $79. It isn't clear from the product page if it includes the power adapter, or if that's extra, too.

I'd toss the hEX PoE Lite from consideration as a 10/100 device. Yuck!

That leaves only the classic hEX. Okay, you got me there; one qualifying item versus zero. You win. 😛

And you're still left without a MMIPS Docker build toolchain.

Your point?

Had you access to some information about mikrotik no using MIPS never more?

Quite the opposite: both of the big 100G devices MikroTik has recently introduced are MIPS-based.

They're classed as switches (CRS) rather than routers, though, so CPU performance never was their major focus. I think Docker hosting is going to be limited to router/CCR class devices, since they focus on the CPU, which you need in this case, too. For that, yeah, there's a fair chance all new MikroTik router designs will be ARM-based. That's simply where all the R&D is going, driven by mobile and the cloud.

Have you already suffered with blidness of loosing logs?

Sure, it can happen, but that's why remote syslog is often part of a network monitoring system.

For myself, all of my MikroTik use is in the home, and "server" means the iMac I'm typing this on. :) Losing logs in that case has one of two likely causes. One, the Mac has fallen over, and I have bigger problems than what my RouterOS boxes are babbling about. Two, the CRS328 in the middle is down, with much the same effect.

The slot in MikroTik hardware is generally for an LTE modem or similar.
CCR2116-12G-4S+, RB1100Dx4, RBM33G

Two of those are ARM, so they're irrelevant to this discussion, and the RBM33G we already dealt with above.
Last edited by tangent on Thu Jul 14, 2022 4:26 am, edited 1 time in total.
 
tangent
Forum Guru
Forum Guru
Posts: 1333
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Container Support to MIPS Architeture

Thu Jul 14, 2022 2:14 am

single purpose one that's just a few kB in size.

The official Docker "hello world" container is 13 kiB, which I'd call more than "a few kB", but I'm willing to handwave that away. The thing is, what if you want the container to do something useful instead?

The limit where you put a 16 MiB RouterOS box at risk of being unable to update itself must be considerably lower than the total storage. You need space to download the new NPK, and space to unpack it. I wouldn't be surprised if 1 MiB containers made some of these 16 MiB devices non-upgradeable.

port mapper

Do you mean like a PCP agent, to augment RouterOS's UPnP implementation?

Based on the name alone, and the fact that it's written in C, I tried pulling a MiniUPnPd container, which also supports NAT-PMP and PCP. The most-downloaded one on Docker Hub comes to 174 MiB on x86_64.

I'm not giving the link to the container, because on inspecting it to find out why it's so big, I found this command:

/bin/sh -c echo victim:victim | chpasswd

🤦‍♂️!!

(I've reported it to Docker.)

I then tried downloading all the other MiniUPnPd containers. Half of them gave some complaint about a missing manifest. Of the rest, the smallest is 14 MiB, but it appears to be entirely NOP'd out. The next-smallest is nearly 16 MiB.

Your alternative, please?

multicast to HTTP proxy

This one is 43 MiB.

Same challenge: show me one with the features you need, which is considerably smaller than 16 MiB.

maybe MQTT agent

This one is 100 MiB.

If I understand Docker properly, you need at least twice that just to unpack the thing, much less get it running, which rules out even the 128 MiB devices.

Containers are much more lightweight than complete VM

Certainly. Several megs typical for a "small" container, versus gigs for a small VM.

The problem is, "several megs" is what so many RouterOS devices ship with. Over half of MikroTik's MIPS devices ship with only 16 MiB on-board and have no option to extend it via USB or microSD. If you consider adding external storage cheating or inadvisable, then you're down to 29% of MikroTik's MIPS line. That will include oddballs that don't fit into your world at all, like the KNOT. How many realistic choices will you be left with, after your local criteria come into it?
 
User avatar
fischerdouglas
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 55
Joined: Thu Mar 07, 2019 6:38 pm
Location: Brazil
Contact:

Re: Container Support to MIPS Architeture

Thu Jul 14, 2022 3:21 pm

For each possibility that everyone else sees with container, there is always some guy that already saw a problem!
Including creating problems that will be solved by increasing hardware that will nature come, like memory or disk(drive).

Still waiting for a low budget (under 79) RB with 256MB of RAM, and disk(drive) slot(micro-sd or m.2) using only the architecture of Mikrotik that supports container today(ARM64, ARM32, X86).

Other then that... I will still defend the idea of Container support for MIPS, at least MMIPS.
 
User avatar
chechito
Forum Guru
Forum Guru
Posts: 2989
Joined: Sun Aug 24, 2014 3:14 am
Location: Bogota Colombia
Contact:

Re: Container Support to MIPS Architeture

Thu Jul 14, 2022 3:55 pm

For each possibility that everyone else sees with container, there is always some guy that already saw a problem!
Including creating problems that will be solved by increasing hardware that will nature come, like memory or disk(drive).

Still waiting for a low budget (under 79) RB with 256MB of RAM, and disk(drive) slot(micro-sd or m.2) using only the architecture of Mikrotik that supports container today(ARM64, ARM32, X86).

Other then that... I will still defend the idea of Container support for MIPS, at least MMIPS.

then you don't want MIPS containers, what you really want is Cheap containers, i see no problem with that, i only say it for a matter of clarity

i think a cheap RB750Gr4 based on ARM will come soon so is matter of wait
 
tangent
Forum Guru
Forum Guru
Posts: 1333
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Container Support to MIPS Architeture

Thu Jul 14, 2022 9:48 pm

For each possibility that everyone else sees with container, there is always some guy that already saw a problem!

That's an ad hominem argument, painting me as the bad guy, the one preventing you from getting what you want, when all I'm doing is pointing out hard technical realities.

If you still believe this must be possible, practical, and/or easy, why haven't you taken up my challenges? Show me these tiny containers that would easily port over to small MIPS boxes without disturbing their factory functionality.

Data in hand, you'd then have a valid, logical argument.

"But I waaaant it!" is a poor argument.
 
rounin
just joined
Posts: 21
Joined: Thu Mar 24, 2022 6:03 am

Re: Container Support to MIPS Architeture

Sat Jul 16, 2022 1:10 pm

I would like to run a container on MIPS / MMIPS. Specifically, PowerboxPro, LtAP and RBM33G. I am putting PowerboxPro and LtAP into control cabinets where it would be interesting if it could run a little code, as it would save me needing to add a microcontroller or SBC to run 100 lines of code.

All the container needs to do is open a socket to a ethernet / dio bridge every few seconds, check the status of a few pins, and send a text string to set another dio based on a little logic. Maybe 100 lines of C code. Stuff like "monitor if the door was opened" and "turn off the battery relay if a remote dio is toggled, or if X/Y/Z happens and its tuesday".

This could be done with a mikrotik script probably. Or netcat and sed. But I am a C++ programmer, hah. As the state machine gets bigger I would rather it be in C or C++ than mikrotik script.

  • I have internet access, at least most of the time. The container could be fetched at boot and held in ram. Although, I guess it is not as simple as creating ramdisk area on "normal" linux since RouterOS is locked down. Nothing technically preventing this though. LTaP is sitting at 67/128 MB free RAM right now.
  • Container would be few 10s MB at most. C runtime and a few supporting files. Would have a root fs that looks more like yocto poky-tiny than normal docker bases, yocto has options for smaller space optimized libc instead of glibc, etc. Some docs say <10MB is typical for poky.
  • I deal with cross toolchains, mips is not that exotic of an architecture. It would be a painful few days / week.

I essentially want to write code I would run on a microcontroller, but don't want to add a microcontroller since I already have some CPE with a nice case, ground lug, redundant power in a box deployed. It would be somewhat simpler if I could just load a statically linked bin to get launched, if forgetting about security.
 
User avatar
chechito
Forum Guru
Forum Guru
Posts: 2989
Joined: Sun Aug 24, 2014 3:14 am
Location: Bogota Colombia
Contact:

Re: Container Support to MIPS Architeture

Sat Jul 16, 2022 4:28 pm


...check the status of a few pins, ...

which pins are you referring to?

EDIT:
I was not aware RBM33G has GPIO pins
Last edited by chechito on Sat Jul 16, 2022 5:09 pm, edited 2 times in total.
 
tangent
Forum Guru
Forum Guru
Posts: 1333
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Container Support to MIPS Architeture

Sat Jul 16, 2022 4:49 pm

it would save me needing to add a microcontroller or SBC to run 100 lines of code.

Classic X-Y problem: leading with the preconceived solution instead of the actual problem.

The feature you're looking for is called GPIO, and it doesn't require containers to access it. Indeed, containers should prevent access to the host's GPIO pins, if the security is set up properly.

Of your devices, only the RBM33G has exposed GPIO pins. (Details)

The other major item in the lineup with this feature is the KNOT.
 
rounin
just joined
Posts: 21
Joined: Thu Mar 24, 2022 6:03 am

Re: Container Support to MIPS Architeture

Sat Jul 16, 2022 8:56 pm

which pins are you referring to?
This is for a large control cabinet that happens to have mikrotik routers in it along with other hardware. The system contains several ethernet to DIO bridge, actually more like 0.5 amp relay controller. A Brainbox ED-588 - https://www.brainboxes.com/product/remo ... tal/ed-588. Other items in the system use some of these DIOs too. Not DIO on the mikrotik, those would need protection, level shifting (24V input signals, ~200mA output loads), there are not nearly enough of them on M33. The point is to share control of the external IO box.
Classic X-Y problem: leading with the preconceived solution instead of the actual problem.
Eh, more that I don't put all of my requirements, design tradeoffs, or thought process in a forum post. And this hardware is already deployed, and I don't want to add or change things. Just trying to say yes, I would use this feature if available, and that I think it is feasible. I can't violate my NDAs : ).
 
rounin
just joined
Posts: 21
Joined: Thu Mar 24, 2022 6:03 am

Re: Container Support to MIPS Architeture

Sat Jul 16, 2022 9:08 pm

If it makes sense, I would rather use netcat / sed / bash than mikrotik script language, ignoring the custom C code part. At least then I can use the same scripts on other systems rather than needing to support 2 scripts (one bash, one mikrotik language).
 
tangent
Forum Guru
Forum Guru
Posts: 1333
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Container Support to MIPS Architeture

Sun Jul 17, 2022 5:17 am

I would rather use netcat / sed / bash than mikrotik script language

Okay, I understand: you want Docker to be "bash in a box." Fine. If you put this minimal Dockerfile into a directory somewhere…

FROM alpine
RUN apk add --no-cache bash

…and then run…

$ docker build --tag dio-twiddler --platform=linux/arm/v7 .
$ docker save dio-twiddler -o dio-twiddler.tar  

…within that directory, you get a "dio-twiddler.tar" file that should run on any of MikroTik's current 32-bit ARM devices. Substitute "linux/arm64" if you have a 64-bit ARM test host, such as the RB5009.

All this image does is add Bash to Alpine Linux. It relies on the Busybox versions of nc and sed. You can go two ways from there: leave out Bash and rely on Busybox's barebones "/bin/sh" implementation, or make it bigger by substituting more powerful tools like socat and GNU sed.

That container won't do anything useful, since there is no way to log into it, and it doesn't have any of your custom code on it. Rather than add an sshd instance or similar and treat it like a traditional Linux VM, the Docker Way is to extend the Dockerfile, injecting your shell script at container build time. You can then arrange to have the shell script be the entry point of the container.

This custom C code of yours can be handled the same way.

The advantage of this methodology is that you get a reproducible build, rather than a hand-cultivated custom VM. You then don't have to worry about backing up the VM: you can rebuild it at need.

The thing is, even this nerfed container comes to 5.3 MiB here, for ARMv7. I happen to have just netinstalled a hEX PoE, and the current RouterOS 7.4rc4 NPK for that is nearly 12 MiB. That means you can't upload this container, unpack it, remove the tarball, and then still have room left over for an OS upgrade on a router with 16 MiB of local storage, as all three of your chosen devices do. Never mind if you've carefully scoped things so you have nothing else using local storage, you're already over the limit.

The LtAP and RBM33G have USB. Maybe a thumb drive would be reliable enough in this instance to hold the container without roaching itself, provided it didn't do much file I/O. Worst case, it's easier to swap a thumb drive than resolder and reprogram the router's SoC if its internal flash is roached by the same cause.

Nearly all of the image size is Alpine Linux. You need that base image to get a package manager, a C library, and other essentials. If you were willing to cross-compile the executables with static linking on your Docker build system and inject them into the image, you could pare some of this back, to the point that you should be able to get it under the critical 4 MiB limit point. How far under that limit you need to be to make the system usable is a local question, depending on what else your routers use local flash storage for.

And once again I remind you that you'd have to find or build that cross-compilation toolchain yourself, since Docker isn't providing it.

How hard are you willing to work to make this a reality?
 
rounin
just joined
Posts: 21
Joined: Thu Mar 24, 2022 6:03 am

Re: Container Support to MIPS Architeture

Sun Jul 17, 2022 7:02 am

And once again I remind you that you'd have to find or build that cross-compilation toolchain yourself, since Docker isn't providing it.

How hard are you willing to work to make this a reality?
I am an embedded firmware engineer. I know it is going to be painful, but I've done it (toolchains, cross compiling, yocto images, custom docker base images) before. Takes about a week full time messing with it.
and then still have room left over for an OS upgrade on a router with 16 MiB of local storage
I did mention in my original post that grabbing it from the network and decompressing to a ramfs would be interesting to me. yes, mikrotik does not offer a way to do this at the moment. But I currently have ~60 MB free ram, so ~30MB could be used to unpack and run an image that is a few MB. While we are dreaming, is there a technical reason a LtAP couldn't mount a NFS share? I'm not sure how large the client lib & driver is. I do think is unlikely that this (ramfs / nfs) would be permitted by mikrotik, but if I had say an imx.6 booting from a 16MB flash it wouldn't be thought to be that weird to use ramfs or NFS. Its not /that/ different spec wise from an LtAP, and the LtAP is nearly idle most of the time.

I don't /need/ containers per se, but mikrotik doesn't want to just give me a user account to run a binary from, or the ability to sign and upload my own package. docker/cgroups is a good security compromise.
 
tangent
Forum Guru
Forum Guru
Posts: 1333
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Container Support to MIPS Architeture

Sun Jul 17, 2022 10:41 am

is there a technical reason a LtAP couldn't mount a NFS share? I'm not sure how large the client lib & driver is.

The core parts of NFS on Linux are in the kernel, and as far as I can tell, RouterOS's kernel doesn't have it built-in. (There are userspace parts of NFS, but these are ancillary services.)

RouterOS does offer SMB, but only as a server, not as a client.

To do this kind of stuff client-side inside the Docker container, you'd have to rely on something like FUSE, which might not work the way RouterOS has its Docker implementation locked down.

No, if you want to pull files into the container, I'd rely on things like wget instead.

I realize you're hoping to delegate the storage part to another machine, but I don't see a workable method.
 
glow
newbie
Posts: 29
Joined: Sun Dec 05, 2021 1:56 am

Re: Container Support to MIPS Architeture

Sun Jul 17, 2022 5:07 pm

[...]
Had you access to some information about mikrotik no using MIPS never more?

Quite the opposite: both of the big 100G devices MikroTik has recently introduced are MIPS-based.

They're classed as switches (CRS) rather than routers, though, so CPU performance never was their major focus. I think Docker hosting is going to be limited to router/CCR class devices, since they focus on the CPU, which you need in this case, too. For that, yeah, there's a fair chance all new MikroTik router designs will be ARM-based. That's simply where all the R&D is going, driven by mobile and the cloud.
[...]
I had a bit of comment in mind before this post, so I'll make it an addendum for your snippet.

The MIPS usage in Mikrotik is a bit specific at times. It's basically products using much older chips.

For the newer switches specifically (CRS300/CRS500), the MIPS CPU is used as a pure management CPU, attached to the switch SoC via a 100Mbps or 1Gbps ethernet connection. The switch chip often has its own CPU cores, be it arm, mips, 8051 compatible (admittedly, I've only seen the latter on Broadcom recently, and MTK does not use their switch chips afaik), etc. For whatever reason (IMO, they are likely really good reasons), Mikrotik does not rely on the switch chip's integrated CPU cores.

For that management role, almost any CPU could have been used, but it seems that Mikrotik prefers those really old Qualcomm WiFi SoCs. WiFi is disabled. One ethernet port is wired directly into the switch chip, often the second Ethernet port is used as an external "management RJ45." This is how the CRS504, CRS354, and CRS312 are laid out. Items like the flash, the status LEDs, the RAM, a serial console connection, fans, etc, are all wired to the management CPU. These would be part of the "really good reasons" noted above, since the switch SoC may be lacking the appropriate I/O for this. Also, many managed switch ASICs require an external controller CPU/FPGA, so the higher end Marvell Switch ASICs that Mikrotik uses, might require a CPU. In many other high end switches, that was often an Intel Atom Cxxxx series chip.

For older switches (CRS100), the switch chip's built in management CPU is often MIPS. The Qualcomm switch chips in those used MIPS, which may have been a carryover from Atheros (a company Qualcomm acquired for WiFI and ethernet products, iirc). This may be a contributing factor in MTK's continued usage of old* Qualcomm MIPS SoCs as management CPUs.


* Old doesn't mean bad or terrible, but they are old designs.
 
jhgs
just joined
Posts: 1
Joined: Sat Feb 09, 2019 4:42 pm

Re: Container Support to MIPS Architeture

Sat Sep 03, 2022 9:18 am

The official Docker container for nginx is 141 MiB. There are zero MIPS devices in MikroTik's line with enough internal storage for that.
Lies, the RB450G (mipsbe) has 256MiB of RAM and 512MiB of internal storage - more than sufficient, I have many cloud containers running with a fraction of those resources. If you're simply ignoring discontinued devices, you shouldn't. RouterOS 7 runs on it just fine. So why not enable containers if the feature is part of the OS anyway and doesn't require hardware support? If the user needs to do extra steps to get stuff to work (own registry, modified tooling, etc) and it gets no official support from the vendor, so be it. Not everything needs to be a turn-key solution. This thread and comments elsewhere are evidence there is an interest in it, some people already managed to make it (mostly) work on a previous, unfinished version. Gating the finished product to x86 and ARM is just shortsighted in my opinion.
 
jonnors
just joined
Posts: 1
Joined: Thu Jul 13, 2023 6:22 pm

Re: Container Support to MIPS Architeture

Thu Jul 13, 2023 6:46 pm

There is support in Docker itself for MIPS now, including in Docker Desktop. https://docs.docker.com/build/building/multi-platform/
This is done via integration with QEMU. So at least for building small static binaries, the basic toolchain seems to be in place.

This could be a practical way to run custom software on Mikrotik devices. We would love to have it for the KNOT, for example. Just to run some <1MB FLASH/RAM services and not be limited by RouterOS.
 
heppth
just joined
Posts: 3
Joined: Sun Feb 04, 2024 1:53 pm

Re: Container Support to MIPS Architeture

Thu Feb 29, 2024 4:55 pm

There is support in Docker itself for MIPS now, including in Docker Desktop. https://docs.docker.com/build/building/multi-platform/
This is done via integration with QEMU. So at least for building small static binaries, the basic toolchain seems to be in place.

This could be a practical way to run custom software on Mikrotik devices. We would love to have it for the KNOT, for example. Just to run some <1MB FLASH/RAM services and not be limited by RouterOS.
I agree with that. There would be great customer potential if we could run our lightweight containers (approx. 2 MB) on a KNOT, for example. Provisioning for the different MIPS architectures would not be a problem.

Who is online

Users browsing this forum: No registered users and 5 guests