Having issues enabling the eSIMs with an error each time saying authentication error.
Unable to find logs that show this or anymore detail on what the issue is.
Have 3 different eSIMs, all the same issue
Hello,
For troubleshooting purposes, we will require more sensitive information from your end, such as the troubleshoot file, which may contain passwords, public IP addresses, serial numbers, and such. To avoid leaking this information, we have sent you a form to fill out, which you will receive in your e-mail inbox that you have registered your account with in the forums. In the *Ticket ID* field of the form, please enter the ID of this thread, which is *17581*.
Thank you,
What your lpac log is actually saying
These two lines are the smoking gun:
-
Eligibility failed: TAC [00000000] is present in the deny list. -
No eligible Profile for this eUICC/Device.
So the SM-DP+ server is reachable and the ES9 auth exchange is working (you got HTTP 200s), but the server is refusing to issue a profile to your device based on TAC eligibility and/or profile type eligibility. The GSMA status mapping for this kind of failure shows up as SubjectCode 8.2.5 “Profile Type” with a “No eligible profile” style outcome.
Key point: this isn’t you typing the activation/confirmation codes wrong. It’s the provider saying “not allowed for this device”.
What to put in Activation code and Confirmation code
Activation code
On Teltonika RUTM30, the “Activation codes” field is the eSIM profile activation code.
In practice that usually means pasting the whole LPA string exactly as given:
LPA:1$cel.prod.ondemandconnectivity.com$xxxxxxxx
Confirmation code
Leave it blank unless your provider explicitly gave you a separate confirmation code. Your own log shows it as confirmation code (null), which is totally normal.
Why TAC is killing it (and why yours shows 00000000)
TAC is the first 8 digits of the IMEI.
Your provider is doing an eligibility check against a deny list, but the router is presenting TAC as 00000000, which basically screams “I didn’t get a real TAC/IMEI for this check”.
So you’ve got two likely scenarios:
-
Your router/modem isn’t reporting a valid IMEI to the LPA stack (so the TAC becomes
00000000) -
Your provider blocks Teltonika/router/IoT devices (or this modem family) on purpose, even if IMEI is valid
Hello,
I appreciate your comments. I will discuss this with our R&D department and provide an update soon.
Best regards,
Eimantas
Thanks.
I think at this time the service provider might be blocking the IMEI of the Teletonika device, maybe purposely because they don’t want to allow the eSIM to be used by a router.
The baffling part is
Eligibility failed: TAC [00000000] is present in the deny list.
That reads like the Teletonika device is sending a IMEI of all zeros, but that can’t be right, so thinking its just the response of the deny. This is using an 02 eSIM in the UK.
We do have another exact Teletonika RUTM30, different supplier using, Vodafone eSIM and works fine, hence leaning on the service provider being the issue.
Anyway, let me know how you get on. Would be create if Teletonika could introduce some messaging to provide more definitive detail rather then generic authentication failure, as imagine I might not be first or last person to come across it. For consistency, here is the full logs for anyone else having same issue:
[02/02/2026 15:41:46] [INFO] [000.000198641 s] ** LPA Linux started [1.7] **
[02/02/2026 15:41:46] [INFO] [000.000787209 s] [LPA__start_rsp_] confirmation code (null)
[02/02/2026 15:41:46] [INFO] [000.020096395 s] [open_modem] 0 process PID: 31681 PATH: /sbin/lpac
[02/02/2026 15:41:46] [INFO] [000.055860984 s] ES10.GetEUICCInfo1
[02/02/2026 15:41:46] [INFO] [000.137445391 s] ES10.GetEUICCChallenge
[02/02/2026 15:41:46] [INFO] [000.173594627 s] ES9.InitiateAuthentication to the SMDP+ ‘cel.prod.ondemandconnectivity.com’
[02/02/2026 15:41:46] [INFO] [000.195892546 s] HTTP response status code 200
[02/02/2026 15:41:46] [INFO] [000.000976787 s] ES10.AuthenticateServer
[02/02/2026 15:41:47] [INFO] [000.984980181 s] ES9.AuthenticateClient to the SMDP+ ‘cel.prod.ondemandconnectivity.com’
[02/02/2026 15:41:48] [INFO] [000.430368306 s] HTTP response status code 200
[02/02/2026 15:41:48] [WARN] [000.000716005 s] [es9_json_extractor__status_code_data_value] subjectCode: 8.2.5
[02/02/2026 15:41:48] [WARN] [000.000297486 s] [es9_json_extractor__status_code_data_value] reasonCode: 4.3
[02/02/2026 15:41:48] [WARN] [000.000282825 s] [es9_json_extractor__status_code_data_value] subjectIdentifier: Profile Type
[02/02/2026 15:41:48] [WARN] [000.000383132 s] [es9_json_extractor__status_code_data_value] message: Eligibility failed: TAC [00000000] is present in the de
ny list.
[02/02/2026 15:41:48] [WARN] [000.000309433 s] [es9_json_extractor__authenticate_client_error] No eligible Profile for this eUICC/Device.
[02/02/2026 15:41:48] [ERROR] [000.000592066 s] [rsp__prepare_download] The AuthenticateClientResponseEs9 has an authenticateClientError(8). Aborting the Rem
ote Sim Provisioning procedure
[02/02/2026 15:41:48] [ERROR] [000.000485947 s] [rsp__start_with_activation_code] Error on Prepare Download, rc 13
[02/02/2026 15:41:48] [INFO] [000.010472225 s] [close_modem] 0 process PID: 31681 PATH: /sbin/lpac
[02/02/2026 15:41:48] [ERROR] [000.000513186 s] FATAL [LPA__start_rsp] failed, rc 13
[02/02/2026 15:41:48] [ERROR] [000.002255012 s] [LPA__command_manager] LPA__start_rsp failed, rc 13
{“result”:13, “response”:{“result”:13,“description”:“Profile installation failed due to authentication error”}}
Hello,
I have received feedback from the R&D team.
The following logs indicate denying profile download from the provider:
[02/02/2026 15:41:48] [WARN] [000.000383132 s] [es9_json_extractor__status_code_data_value] message: Eligibility failed: TAC [00000000] is present in the deny list.
[02/02/2026 15:41:48] [WARN] [000.000309433 s] [es9_json_extractor__authenticate_client_error] No eligible Profile for this eUICC/Device.
You should check with the carrier to see why this is being rejected. It might be a smartphone-only profile, so try requesting an IoT eSIM profile instead.
Best regards,
Eimantas
Thanks Eimantas.
It seems pretty concreate to me on those findings, albeit the service provider would not admit to it.
We tried eSIM and physical SIM and bot worked, so can now be closed resolved.
Many thanks for the support
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.