I'm able to access an Landis + Gyr E650 with Landis + Gyr .MAP110 with client id 48 and "high level authentication with coded password". Do you know, or can you explain, what "coded password" means? (Landis + Gyr .MAP110 distinguish between "low level authentication with static password" and "high level authentication with coded password")
Unfortunately I'm unable to access the meter with same configuration (client id 48, high level authentication, same password) with DLMSDirector. I get the following error: Access Error: Device reports scope of access violated.
The Low-level password is sent as plain text and in High-level it's encrypted.
DLMS standard doesn't define the HLS encryption mechanism for HLS_2 and it can be anything.
If the manufacturer is not sharing how HLS_2 is encrypted there is no mutch to do.
Thank you very much for your information. I did some investigation and got the high level authentication on the L+G E650 to work! Unfortunately I needed to edit two parts of the Gurux.DLMS framework.
1. GXSecure.Secure
I need to completely exchange the code for the "Authentication.High" part within the method "GXSecure.Secure(...)". Here, it would be nice if we get the possibility to inject the necessary encryption code for high level authentication (may be trough the DLMSClient?). Espacially as you already said, that every manufacturer may has it's own encryption implementation.
2. DLMSClient.ParseApplicationAssociationResponse(GXByteBuffer reply)
Within the following code I get a strange response and the parse attempt fails:
if (client.IsAuthenticationRequired)
{
foreach (var it in client.GetApplicationAssociationRequest())
{
reply.Clear();
ReadDlmsPacket(it, reply);
}
client.ParseApplicationAssociationResponse(reply.Data);
}
The reply.Data are only 3 bytes [0D,01,00] and so the parse and compare of the challenge fails at all. But, I analyzed the protocol of the L+G MAP and this response seems to be correct:
07633734ms - DLMS set State: HLS_AUTHENTICATION
07633734ms - DLMS dlms SendReceive
07633734ms - DLMS S-> 060102FA580109083637364135363730
07633843ms - DLMS R<- 0D0100
07633843ms - DLMS HLS-Authentication succeeded
I have absolutely no clue about the protocol implementation, but if I skip the parse code (client.ParseApplicationAssociationResponse(reply.Data)), it works! I was at least able to set the meter time. Do you have an idea, about this response? Is there a way to allow such a response?
Thank you very much for your support, I hope we can extend the gurux library, to implement this case of L+G E650.
Challenge (what the client is sending) is something else if you change the password. I believe that challenge is the same if you write it again. Let's see if this is breakable. Can you share the password or try to write with a different password and share the password and what the meter is sending?
I just love this. I was thinking to check this before I go to eat and I succeeded to solve the calculation. :-)
You sent me just the correct passwords. 0000000 is always the best password if you want to solve the password encryption.
I'll think about how to add support for this. It'll take some time because public/private keys are still on testing.
I just tried your code and the encryption seems to work, but the second problem (see above in my post from 17. February 2021) still persists. As you describes in the readme.md (https://github.com/Gurux/Gurux.DLMS.Net), if HLS is used, the meter should send back it's own challenge. Unfortunately my meter does not do that. The meter just replies with 0D0100 -> Ok (Translated by Gurux DLMS Translator), and not with it's own challenge. Any ideas about this behavior?
The log of the L+G Map 110 does show the same behavior:
07633734ms - DLMS set State: HLS_AUTHENTICATION
07633734ms - DLMS dlms SendReceive
07633734ms - DLMS S-> 060102FA580109083637364135363730
07633843ms - DLMS R<- 0D0100
07633843ms - DLMS HLS-Authentication succeeded
The actual gurux code handles the response 0D0100 as error 13 (Access Error : Device reports scope of access violated). If I suppress this error with the debugger, of course i get the following error in GXDLMSClient.ParseApplicationAssociationResponse(GXReplyData): 'Invalid password. Server to Client challenge do not match.'
Thank you for the extremely fast implementation!
Unfortunately there are some more problems. The following code handles the response '0D0100' as error:
if (_client.IsAuthenticationRequired)
{
foreach (var it in _client.GetApplicationAssociationRequest())
{
reply.Clear();
ReadDataBlock(it, reply);
}
_client.ParseApplicationAssociationResponse(reply.Data);
}
Inside ReadDataBlock, within GetPdu(GXDLMSSettings, GXReplyData), '0D' (pos=0) is handled as 'Command.WriteResponse', and inside HandleWriteResponse(GXReplyData), '01' (pos=1) is handled as error (line 4011). The GXDLMSReader.ReadDLMSPcket(byte[], GXReplyData) within Gurux.DLMS.Client.Example.Net then throws an error if GXReplyData.Error is unequal to 0.
Thank you for your recommendations about this behavior.
Unfortunately I face random access problems with high level authentication and L+G E650. I tried to access about 100 meters with high level authentication, what ended in very different results. I often get a "Access Error : Device reports scope of access violated".
I can split the meters in three groups with different behavior:
1. Meters that work more or less without problems or very little access errors.
2. Meters that mainly decline access with access error, but with enough retries (something about more then 10) they perhaps work anyway.
3. Meters that do not work at all. Every access ends in an Access Error.
Stack trace of the error is always the same:
Gurux.DLMS.GXDLMSException: Access Error : Device reports scope of access violated. at SES.Metering.Unit.Adapter.Dlms.DLMSCommunicator.ReadDlmsPacket(Byte[] data, GXReplyData reply) at SES.Metering.Unit.Adapter.Dlms.DLMSCommunicator.ReadDataBlock(Byte[] data, GXReplyData reply) at
Any ideas about this behavior? I think it's very hard to track down this problem, because it seems to be random.
I believe there is an issue with the High-Level password count for Landis+Gyr. Can you try to connect with Map120 to the meter that fails? Then send trace and password to me by email.
I just tried the improved code with one meter, that before did not work at all, and now it works!
So it looks resolved, but I will try the improved code with more meters in the next days.
I have a lot less meters, that won't connect, but unfortunately I still have about 10-20 of L+G E650 meters, that won't connect, or have random connection issues, with High Level Authentication. On these meters I still get the error 'Gurux.DLMS.GXDLMSException: Access Error : Device reports scope of access violated.', but I can connect them with the L+G MAP110.
Any further suggestions, how we get rid of this problem? Thank you very much!
I just downloaded Gurux.DLMS (9.0.2112.903), but problem still persists. The meter, of which I sent you the trace is still not working. Error is still the same Access Error : Device reports scope of access violated.
wait a moment, I just downloaded the Gurux.DLMS.Client.Example.Net, and it seem to work correctly. I first have to check my own 'GXDLMSReader' code to ensure, that the problem really persists.
Your right, it's in 9.0.2112.904, and it works, at least with my reference meters, which did not work yet.
I just downloaded the source code to test it. As soon as it is available on nuget, I'll integrate it into my system and provide you some feedback (hopefully the last time) how it works with my 100+ meters.
I just tested the current Gurux.DLMS version with 93 meters (L+G E650). Good news, all of them work with high level authentication. Bad news, I still have about 5 meters that work very inconsistently. Means they work sometimes, but sometimes not. I would say 50% of all connection requests fail with the Access Error : Device reports scope of access violated.
Dear Andrea,
Dear Andrea,
The Low-level password is sent as plain text and in High-level it's encrypted.
DLMS standard doesn't define the HLS encryption mechanism for HLS_2 and it can be anything.
If the manufacturer is not sharing how HLS_2 is encrypted there is no mutch to do.
You can read more from High Authentication here:
https://www.gurux.fi/DLMSCOSEMFAQ
BR,
Mikko
Hey Mikko,
Hey Mikko,
Thank you very much for your information. I did some investigation and got the high level authentication on the L+G E650 to work! Unfortunately I needed to edit two parts of the Gurux.DLMS framework.
1. GXSecure.Secure
I need to completely exchange the code for the "Authentication.High" part within the method "GXSecure.Secure(...)". Here, it would be nice if we get the possibility to inject the necessary encryption code for high level authentication (may be trough the DLMSClient?). Espacially as you already said, that every manufacturer may has it's own encryption implementation.
2. DLMSClient.ParseApplicationAssociationResponse(GXByteBuffer reply)
Within the following code I get a strange response and the parse attempt fails:
if (client.IsAuthenticationRequired)
{
foreach (var it in client.GetApplicationAssociationRequest())
{
reply.Clear();
ReadDlmsPacket(it, reply);
}
client.ParseApplicationAssociationResponse(reply.Data);
}
The reply.Data are only 3 bytes [0D,01,00] and so the parse and compare of the challenge fails at all. But, I analyzed the protocol of the L+G MAP and this response seems to be correct:
07633734ms - DLMS set State: HLS_AUTHENTICATION
07633734ms - DLMS dlms SendReceive
07633734ms - DLMS S-> 060102FA580109083637364135363730
07633843ms - DLMS R<- 0D0100
07633843ms - DLMS HLS-Authentication succeeded
I have absolutely no clue about the protocol implementation, but if I skip the parse code (client.ParseApplicationAssociationResponse(reply.Data)), it works! I was at least able to set the meter time. Do you have an idea, about this response? Is there a way to allow such a response?
Thank you very much for your support, I hope we can extend the gurux library, to implement this case of L+G E650.
Best regards,
Andrea
Hi,
Hi,
"676A5670" that you are writing is working with your meter with your password.
http://www.gurux.fi/GuruxDLMSTranslator?pdu=060102FA5801090836373641353…
Challenge (what the client is sending) is something else if you change the password. I believe that challenge is the same if you write it again. Let's see if this is breakable. Can you share the password or try to write with a different password and share the password and what the meter is sending?
BR,
Mikko
Jap, "676A5670" is from the
Jap, "676A5670" is from the Landis + Gyr MAP protocol and is working (correct password).
Below I send you the communication protocol from the L+G MAP with correct and incorrect password with client id 48 [decimal, not hex].
ClientID: 48
Correct Password: 1234567
Protocol:
66573000ms - DLMS Open
66573000ms - DLMS set State: OPENING
66573000ms - DLMS Init ShortName CommandHandler
66573343ms - DLMS set State: AUTHENTICATION
66573343ms - DLMS S-> COSEM AARQ (with ACSE Requirements)
66573343ms - DLMS dlms SendReceive
66573343ms - DLMS S-> 603180020780A1090607608574050801028A0207808B0760857405080202AC028000BE0F040D01000000065F04001C13200000
66573468ms - DLMS R<- 6141A109060760857405080102A203020100A305A10302010E88020780890760857405080202AA0A80083635333630303030BE0F040D0800065F04001802200960FA00
66573468ms - DLMS check ACSE-Response Values
66573468ms - DLMS set State: HLS_AUTHENTICATION
66573468ms - DLMS dlms SendReceive
66573468ms - DLMS S-> 060102FA580109083737364135363730
66573578ms - DLMS R<- 0D0100
66573578ms - DLMS HLS-Authentication succeeded
ClientID: 48
Wrong Password: 0000000
Protocol:
66635453ms - DLMS Open
66635453ms - DLMS set State: OPENING
66635453ms - DLMS Init ShortName CommandHandler
66635812ms - DLMS set State: AUTHENTICATION
66635812ms - DLMS S-> COSEM AARQ (with ACSE Requirements)
66635812ms - DLMS dlms SendReceive
66635812ms - DLMS S-> 603180020780A1090607608574050801028A0207808B0760857405080202AC028000BE0F040D01000000065F04001C13200000
66635953ms - DLMS R<- 6141A109060760857405080102A203020100A305A10302010E88020780890760857405080202AA0A80083443314330303030BE0F040D0800065F04001802200960FA00
66635953ms - DLMS check ACSE-Response Values
66635953ms - DLMS set State: HLS_AUTHENTICATION
66635953ms - DLMS dlms SendReceive
66635953ms - DLMS S-> 060102FA580109083443314330303030
66636062ms - DLMS R<- 0D01010D
66636062ms - DLMS HLS-Authentication failed: AccessError = scope_of_access_violated
BR,
Andrea
Hi Andrea,
Hi Andrea,
I just love this. I was thinking to check this before I go to eat and I succeeded to solve the calculation. :-)
You sent me just the correct passwords. 0000000 is always the best password if you want to solve the password encryption.
I'll think about how to add support for this. It'll take some time because public/private keys are still on testing.
BR,
Mikko
Hi Mikko,
Hi Mikko,
Thank you very much for you effort.
I'm looking forward to hear from you :)
BR,
Andrea
Hey Mikko
Hey Mikko
Any news about the high level authentication?
Thank you, and best regards
Andrea
Hi Andrea,
Hi Andrea,
There is a new version available that can count Hugh Level password for Landis+Gyr.
If you are using example client add -L LGZ parameter.
GXDLMSDirector is doing this automatically.
Counting is here:
https://github.com/Gurux/Gurux.DLMS.Net/blob/5190e1b280a396d64578159c8e…
BR,
Mikko
Hi Mikko,
Hi Mikko,
I just tried your code and the encryption seems to work, but the second problem (see above in my post from 17. February 2021) still persists. As you describes in the readme.md (https://github.com/Gurux/Gurux.DLMS.Net), if HLS is used, the meter should send back it's own challenge. Unfortunately my meter does not do that. The meter just replies with 0D0100 -> Ok (Translated by Gurux DLMS Translator), and not with it's own challenge. Any ideas about this behavior?
The log of the L+G Map 110 does show the same behavior:
07633734ms - DLMS set State: HLS_AUTHENTICATION
07633734ms - DLMS dlms SendReceive
07633734ms - DLMS S-> 060102FA580109083637364135363730
07633843ms - DLMS R<- 0D0100
07633843ms - DLMS HLS-Authentication succeeded
The actual gurux code handles the response 0D0100 as error 13 (Access Error : Device reports scope of access violated). If I suppress this error with the debugger, of course i get the following error in GXDLMSClient.ParseApplicationAssociationResponse(GXReplyData): 'Invalid password. Server to Client challenge do not match.'
BR,
Andrea
Hi,
Hi,
https://gurux.fi/GuruxDLMSTranslator?pdu=0D01010D is access violated and
https://gurux.fi/GuruxDLMSTranslator?pdu=0D0100 is a success.
But you are right. There is no Server to Client challenge.
I create an issue from this.
https://gurux.fi/node/19356
This is now handled in C# code. Get the latest version. This will be part of GXDLMSDirector in the next release.
BR,
Mikko
Hi Mikko,
Hi Mikko,
Thank you for the extremely fast implementation!
Unfortunately there are some more problems. The following code handles the response '0D0100' as error:
if (_client.IsAuthenticationRequired)
{
foreach (var it in _client.GetApplicationAssociationRequest())
{
reply.Clear();
ReadDataBlock(it, reply);
}
_client.ParseApplicationAssociationResponse(reply.Data);
}
Inside ReadDataBlock, within GetPdu(GXDLMSSettings, GXReplyData), '0D' (pos=0) is handled as 'Command.WriteResponse', and inside HandleWriteResponse(GXReplyData), '01' (pos=1) is handled as error (line 4011). The GXDLMSReader.ReadDLMSPcket(byte[], GXReplyData) within Gurux.DLMS.Client.Example.Net then throws an error if GXReplyData.Error is unequal to 0.
Thank you for your recommendations about this behavior.
BR,
Andrea
Hi Andrea,
Hi Andrea,
Can you add GXDLMSDirector log (hex trace) here so I can check all the bytes?
BR,
Mikko
Hex-Trace:
Hex-Trace:
15:50:41 Send SNRM request.
TX: 7E A0 0A 00 02 82 FF 61 93 CA 09 7E
15:50:41
RX: 7E A0 21 61 00 02 82 FF 73 53 BF 81 80 12 05 01 80 06 01 3E 07 04 00 00 00 01 08 04 00 00 00 01 07 22 7E
15:50:41 Send AARQ request.
TX: 7E A8 4A 00 02 82 FF 61 10 E3 55 E6 E6 00 60 3E A1 09 06 07 60 85 74 05 08 01 02 8A 02 07 80 8B 07 60 85 74 05 08 02 02 AC 12 80 10 53 74 14 68 54 34 3D 62 65 5A 17 1E 75 6D 42 28 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 F8 4B 7E
15:50:41
RX: 7E A0 0A 61 00 02 82 FF 31 44 CB 7E
15:50:41 Send AARQ request.
TX: 7E A0 11 00 02 82 FF 61 12 00 5F 1C 03 20 FF FF 4E 99 7E
15:50:41
RX: 7E A0 53 61 00 02 82 FF 50 3D 8A E6 E7 00 61 41 A1 09 06 07 60 85 74 05 08 01 02 A2 03 02 01 00 A3 05 A1 03 02 01 0E 88 02 07 80 89 07 60 85 74 05 08 02 02 AA 0A 80 08 36 37 33 34 30 30 30 30 BE 0F 04 0D 08 00 06 5F 1F 04 00 18 02 20 09 60 FA 00 8B 51 7E
15:50:41 Authenticating.
TX: 7E A0 1F 00 02 82 FF 61 34 15 9D E6 E6 00 06 01 02 FA 58 01 09 08 37 39 36 38 35 36 37 30 7D 8B 7E
15:50:41
RX: 7E A0 12 61 00 02 82 FF 72 FE D0 E6 E7 00 0D 01 00 07 E4 7E
BR,
Andrea
Hi,
Hi,
This is fixed. Get the latest version from C#.
BR,
Mikko
Hi Mikko,
Hi Mikko,
It works!
Thank you very much for your support!
BR,
Andrea
Hi Andrea,
Hi Andrea,
Let me know if you have more problems with Landis+Gyr using High authentication. All the L+G meters are read without authentication or with Low.
BR,
Mikko
Hi Mikko,
Hi Mikko,
Unfortunately I face random access problems with high level authentication and L+G E650. I tried to access about 100 meters with high level authentication, what ended in very different results. I often get a "Access Error : Device reports scope of access violated".
I can split the meters in three groups with different behavior:
1. Meters that work more or less without problems or very little access errors.
2. Meters that mainly decline access with access error, but with enough retries (something about more then 10) they perhaps work anyway.
3. Meters that do not work at all. Every access ends in an Access Error.
Stack trace of the error is always the same:
Gurux.DLMS.GXDLMSException: Access Error : Device reports scope of access violated. at SES.Metering.Unit.Adapter.Dlms.DLMSCommunicator.ReadDlmsPacket(Byte[] data, GXReplyData reply) at SES.Metering.Unit.Adapter.Dlms.DLMSCommunicator.ReadDataBlock(Byte[] data, GXReplyData reply) at
Any ideas about this behavior? I think it's very hard to track down this problem, because it seems to be random.
BR,
Andrea
Hi Andrea,
Hi Andrea,
I believe there is an issue with the High-Level password count for Landis+Gyr. Can you try to connect with Map120 to the meter that fails? Then send trace and password to me by email.
I'll check what needs to change.
BR,
Mikko
Hi,
Hi,
You've got mail ;)
Thank you very much!
BR,
Andrea
Hi Andrea,
Hi Andrea,
This is improved. Get the latest version and let me know if you have problems.
BR,
Mikko
Hi Mikko,
Hi Mikko,
I just tried the improved code with one meter, that before did not work at all, and now it works!
So it looks resolved, but I will try the improved code with more meters in the next days.
BR,
Andrea
Hi Mikko,
Hi Mikko,
I have a lot less meters, that won't connect, but unfortunately I still have about 10-20 of L+G E650 meters, that won't connect, or have random connection issues, with High Level Authentication. On these meters I still get the error 'Gurux.DLMS.GXDLMSException: Access Error : Device reports scope of access violated.', but I can connect them with the L+G MAP110.
Any further suggestions, how we get rid of this problem? Thank you very much!
BR,
Andrea
Hi,
Hi,
Can you send a trace and password from some of the failed meters? I'll check it.
BR,
Mikko
Hi Mikko,
Hi Mikko,
Thanks, I just sent you a mail with password and GXDLMSDirector trace.
BR,
Andrea
Hi,
Hi,
This is improved. Get the latest version from .Net code.
BR,
Mikko
Hi,
Hi,
I just downloaded Gurux.DLMS (9.0.2112.903), but problem still persists. The meter, of which I sent you the trace is still not working. Error is still the same Access Error : Device reports scope of access violated.
Sorry for the bad news.
BR,
Andrea
Hi Mikko,
Hi Mikko,
wait a moment, I just downloaded the Gurux.DLMS.Client.Example.Net, and it seem to work correctly. I first have to check my own 'GXDLMSReader' code to ensure, that the problem really persists.
I'll check my code and provide you a feedback.
BR,
Andrea
Hi,
Hi,
It should work. It's in 9.0.2112.904. There is something strange in nuget.org and new versions are released very slowly or fail for time-out.
BR,
Mikko
Hi,
Hi,
Your right, it's in 9.0.2112.904, and it works, at least with my reference meters, which did not work yet.
I just downloaded the source code to test it. As soon as it is available on nuget, I'll integrate it into my system and provide you some feedback (hopefully the last time) how it works with my 100+ meters.
BR,
Andrea
Hi Mikko,
Hi Mikko,
I just tested the current Gurux.DLMS version with 93 meters (L+G E650). Good news, all of them work with high level authentication. Bad news, I still have about 5 meters that work very inconsistently. Means they work sometimes, but sometimes not. I would say 50% of all connection requests fail with the Access Error : Device reports scope of access violated.
I'll send you a mail with the trace and password.
BR,
Andrea