While my esim LPA looks like this (i only have qr code): LPA:1$sm-v4-009-pla-gtm.pr.go-esim.com$O001-someNumbersAndLetters$$1
So if u understand correctly, the matching id should be O001-someNumbersAndLetters in that case right? Because the command line says $ is a finish line… even if i use “O001-someNumbersAndLetters$$1” i get the same error.
Can someone please help with this? Is this even esim feature even working now ?
Not that I know anything about this new command, but in the string the separator(s) seem to be the dollar sign:
LPA:1$sm-v4-009-pla-gtm.pr.go-esim.com$O001-someNumbersAndLetters$$1
So it seems it has to be parsed as:
LPA:1 <-unuesed/prefix
$ <-separator sm-v4-009-pla-gtm.pr.go-esim.com ← sm-dp-plus
$ ← separator
O001-someNumbersAndLetters ← confirmation-code
$ ← separator
← unused/empty field
$ ← separator
1 ← unused/postfix
Try opening a support ticket, being a new feature I wouldn’t be surprised if it still has some rough edges.
Wow, so we have lots of undocumented or mis-documented commands that do something somehow , and now also at least one fully documented command that does nothing.
For all we know it could be (another) anticipated 1st April joke/empty teaser.
It makes no sense to have released (and documented) a command that doesn’t work on released hardware in a RC, it could be acceptable in a pre-alpha-experimental-for-fun-only-release (but Mikrotik seemingly doesn’t really know how to mark alpha/beta/rc/release properly, let alone divide bug fixes from new features).
But this goes a bit further it seems like they are mocking their users.
I like to look at it positively. HW is there, not released yet.
So they already made everything ready to use it once it gets released.
The negative way of looking at it like you suggest, is purely waste of time and resources for everyone.
I don’t believe they would do that. Nobody sensibly thinking would since it can backfire quite hard.
Besides, it’s still waayy too early for April 1st jokes … we’re not even into March.
No one has explained eSIM support to community from Mikrotik. It rather annoying. I’ve asked “hey how do I use this?” on every release thread it appears. I use Mikrotik for LTE with custom modules, so if some module support it, we’d buy those to test.
Now, maybe it’s all software… and the OP guess to “just try” with a purchased eSIM might work, and it’s command usage issue. But we really don’t know. As I said, very annoying.
Well, the 3GPP rules have clue. Android SDK for eSIM, has a diagram that explains how this works. Critically, you’ll notice the dotted-line “eUICC chip” - and new 5G modules can embed them, or devices like LTE router can have eUICC on main board…or the eUICC can be a “run” physical SIM to allow eSIM profiles software too (factoid: SIM cards run apps, see JavaCard) .
Hundreds of pages in 3GPP – which I have not read - so maybe Rel XX has relaxed rules that eSIM keys can go directly to an OS, IDK. Someone knows however.
So while RouterOS can do all the “green boxes” in above… the CardController item need a eUICC to control. And that ain’t on Mikroitk routers to date, again, AFAIK.
I am not looking at this in a “negative” way, rather in a factual way, it seems like the direct opposite of Tesla Autopilot (the hardware is already on the car, the software will come soon), it is mocking/teasing customers about something that doesn’t (yet) exists.
Well, I think they spend too much time on YouTube, and not enough updating the documentation. It should be clear what device a feature supports. IMO, docs should be “done” (or very close) when something hit “rc”. How hard is it to update Confluence page?
With a slight difference that auto-pilot on cars has quite some legal consequences in case things go wrong.
That’s why it’s not really been fully used/accepted yet (except for some minor implementations and test setups ? I am not really up to date on that subject except for what I read left and right).
It does exist for quite a while already. But who is responsible when things go down the drain ?
And what if you change countries ? Then the outcome for the exact same mishap can be totally different.
Liability.
Physical SIM moving to e-sim is less of a problem. It already exists and is being used.
You just need to have the HW in place to handle that e-sim (theoretically it can perfectly be kept fully in SW, I would think).
So that makes me think “it’s coming”. However, don’t put me in the corner on the leadtime
I may be “old school” (actually, I am…) but I find decent documentation 100 times more valuable then any YT video.
Much quicker, much more handy to use and search.
But that’s me …
And on the OP’s command syntax question, which may lead to the hardware problem, but still…
The string used in the sm-dp-plus= part of the command should use quotes around it.
Any $ in the sm-dp-plus you decoded from the QR need to be escaped for RouterOS CLI — $ are variables & strings are interpolated. So you QR code string is, essentially, missing parts when it gets sent from CLI. You need to add a backslash in front of the $'s like “$”. I don’t think you’re run into double-quotes in LPA URI, but those would have be escaped too, like attribute=“my "quoted" string within a string”
EDITED: See 3GPP SGP.22 V3.1, page 220 for format of the QR code strings. TL;DR. Mikrotik example don’t show one with a confirmation code — so there should actually be no $ (nor escaping) needed…
But in the “eSIM QR code format”, the $ is actually a seperator. So issue from OP is the $$1 is two field, first is empty (meaning no "optional data), and next means “confirmation code required”.
So it look like this — again I don’t think it will work – but you’re not getting past the CLI’s parser with a valid eSIM QR code value…
The spec has the following example – since I suspect, at some point, how to read an eSIM QR code will come up…
Examples of the Activation Code are as follows:
• 1$SMDP.EXAMPLE.COM$04386-AGYFT-A74Y8-3F815 (if SM-DP+ OID and Confirmation Code Required Flag are not present)
• 1$SMDP.EXAMPLE.COM$04386-AGYFT-A74Y8-3F815$$1 (if SM-DP+ OID is not present and Confirmation Code Required Flag is present)
• 1$SMDP.EXAMPLE.COM$04386-AGYFT-A74Y8-3F815$1.3.6.1.4.1.31746$1 (if SM-DP+ OID and Confirmation Code Required flag are present)
• 1$SMDP.EXAMPLE.COM$04386-AGYFT-A74Y8-3F815$1.3.6.1.4.1.31746
(If SM-DP+ OID is present and Confirmation Code Required Flag is not present)
• 1$SMDP.EXAMPLE.COM$$1.3.6.1.4.1.31746
(If SM-DP+ OID is present, Activation token is left blank and Confirmation Code Required Flag is not present)
• 1$SMDP.EXAMPLE.NET$KL14XA-8C7RLY$1.3.6.1.4.1.31746$$A14D8-971
(If SM-DP+ OID and CI Public Key indicator are present)
The leading LPA:1$ is a prefix for version + separator (the $ sign).
Following there is the first field.
Then a separator (again the $ sign).
Then the second field.
What is peculiar in the OP string is the terminating $$1, that cannot be interpreted if not as empty field and 1, as seen before: https://forum.mikrotik.com/viewtopic.php?p=1128028#p1127918
but if the 1 means confirmation code required, then where one should put it?
Again, I’m working in theory here. I don’t think any hardware support these commands.
Now theoretically about the confirmation code, IDK. It’s marked as “Optional” in the 3GPP specs. But we’re beyond my paygrade on interpreting specs and vague info from Mikrotik.
All I can tell you how to parse one using RouterOS scripting:
{
And, My best guess is the “$$1” means that RouterOS’s confirmation-code= is needed… If that wasn’t there, then, I guess, confirmation-code= NOT provided. So in above example, it should check ($esimcode->4) is flag for “Confirmation Code Required” was present and NOT call the eSIM (or use [:ask] for it…)
Why? It’s release candidate ROS … and they might have a “release candidate HW” in their labs. Unlike RC software RC hardware doesn’t hit the streets, it has to be full release.
And why shouldn’t they include new SW functions in a ROS before HW is available at distributors? After all, factory software has to support all HW functions. And there’s no reason to skip a version just because factory needs function but general public doesn’t.
Mikrotik sell board that come ready to add modems (wAPGacR, LtAP’s, etc.). While I know the LM960A18 does not have eUICC on-module. Some 5G module do.
So there is some modem module they are testing this… which is not hard to share. And for the foreseeable future, there are no US-based LTE modems beyond CAT-6 (and limited CA)… so it’s either add a module or don’t use MIkroitk. While I only used Mikrotik for LTE. Now I’m largely forced to buy Pepwave for 5G, at way higher cost. And use Mikrotik when cost is more important.
So this secrecy around everything just cost them money. If I know some 5G module worked with eSIM, we could get a few and start testing them. Instead, just lost revenue to them.
If I know some 5G module worked with eSIM, we could get a few and start testing them. Instead, just lost revenue to them.
Vendors usually sell multiple variants of same model with different functions, or some functions must be provisioned on request by special firmware version. For example Quectel RM5xx series generally support eSIM functionality, but the presence of eUICC module is optional (they have different order numbers). Physically, built-in eUICC module function can also depend on whether (U)SIM2 slot is connected or left open, since the built-in eUICC module takes place of that slot when enabled. Please note, that in case of miniPCIe to M.2 adapters, it will be up to adapter to determine how U(SIM) pins are connected and whether they are exposed only to SIM slot on adapter or passed through card edge slot. Some adapters pass both (U)SIM1 and (U)SIM2, some pass only one while other is routed to SIM slot on adapter.
It is not as simple as to provide a model number and for you to buy it, these modems are generally not meant to be bought by end-users anyway.
If you absolutely need some reference, check RM520N-GL which does support eSIM and optionally come with eUICC module, but I will not be responsible if you buy version without eUICC or if you go to AliExpress and buy cheap variant customized for Lenovo/HP (which ironically is very likely to have eUICC module) and realize that they are physically locked to PCIe interface only.
