as my further comment got somehow "lost" or was "deleted" (as it was a comment to an old topic) I'm opening a new topic concerning my problem accessing in an authenticated way a L&G e650 meter via Gurux Python Example Client.
My problem is that all tries fail with "Authentication failure" when using Gurux Python Example Client. Non authenticated access works without any problems.
As I was able to test/access the meter via L&G map.110 Windows Software. Low.Authentication as well as High.Authentication worked like a charm. Therefore I'm 100% sure that the password itself is not the issue.
I'm using the following CLI command to access the meter (XYZXYZX is a placeholder to not provide the real password here).
Command:
python main.py -S /dev/ttyUSB0:300:7Even1 -r sn -i HdlcWithModeE -a Low -P XYZXYZX -c 32 -L LGZ
Response:
gurux_dlms version: 1.0.137
gurux_net version: 1.0.19
gurux_serial version: 1.0.20
Authentication: Authentication.LOW
ClientAddress: 0x20
ServerAddress: 0x1
Standard: Standard.DLMS
Bitrate is : 9600
DisconnectRequest
Connection is permanently rejected
Authentication failure.
Ended. Press any key to continue.
Yes, starting a new question for the old topic is forbidden. It's hard to read the topic after a while if there are multiple questions. https://www.gurux.fi/ForumRules
Select Landis+Gyr as the manufacturer. Then select Low authentication. As you can see the client's address is 0x11. You have used 0x20 as the client address and I believe that is the reason why the client authentication fails. Try the same for high authentication.
I'm using Gurux Python running on a PI Zero (USB optical reader).
Map.110 is running on an old Windows 7 Laptop (optical device Siemens TS69 using an USB to RS232 adapter).
hmmm ... concerning the used password within map.110 ... I'm confused.
In map.110 I'm only able to enter a password with 7-characters and if I replace 1234567 by anything else accessing the meter in map.110 is no longer working. But anyway ... this is another story.
By using Gurux the mentioned password "04800840" also fails.
CLI:
python main.py -S /dev/ttyUSB0:300:7Even1 -r sn -i HdlcWithModeE -a Low -P 04800840 -c 17 -L LGZ -t Verbose
BUT:
I never explicetely tried to use "-c 32" in combination with -a Low. And: IT DOES WORK NOW!
My history shows a lot of other combinations of client-id, authentication, security, ... but not this one ...
Thank you very much for looking into my issue. This was not really an issue. More a typical "Case-18" error! :-)
Finally this is my working CLI command:
python main.py -S /dev/ttyUSB0:300:7Even1 -r sn -i HdlcWithModeE -a Low -P 04800840 -c 32 -L LGZ -g 1.1.31.7.0.255:2 -g 1.1.51.7.0.255:2 -g 1.1.71.7.0.255:2
Client address might cause problems. With some meters, the meter doesn't reply if the address is invalid; with some meters, you get a generic error that doesn't tell the real reason.
Because client addresses might vary between meter versions and models this is causing problems.
I'm glad you have solved this and can read the meter.
Hi,
Hi,
Yes, starting a new question for the old topic is forbidden. It's hard to read the topic after a while if there are multiple questions.
https://www.gurux.fi/ForumRules
Select Landis+Gyr as the manufacturer. Then select Low authentication. As you can see the client's address is 0x11. You have used 0x20 as the client address and I believe that is the reason why the client authentication fails. Try the same for high authentication.
BR,
Mikko
Hi Mikko,
Hi Mikko,
thank you for your response.
I commented the last topic as I assumpted the content/topic was matching/similar issue.
I just tried to use -c 17 (0x11) ... unfortunately: still authentication fails.
python main.py -S /dev/ttyUSB0:300:7Even1 -r sn -i HdlcWithModeE -a Low -P XYZXYZX -c 17 -L LGZ
gurux_dlms version: 1.0.137
gurux_net version: 1.0.19
gurux_serial version: 1.0.20
Authentication: Authentication.LOW
ClientAddress: 0x11
ServerAddress: 0x1
Standard: Standard.DLMS
Bitrate is : 9600
DisconnectRequest
Connection is permanently rejected
Authentication failure.
Ended. Press any key to continue.
Is there any kind of verbose/debug output I can provide helping to figure out what is going on here?
Thx and br,
e650sek
Hi,
Hi,
I believe that the problems were different even though they might look the same to you.
One of the parameters is different than what the meter expects.
You can add -t Verbose argument and you can see a hex trace, but it doesn't help you.
If you add a hex trace from Map 110 I can check what are the correct parameters. Only two first client requests are enough.
BR,
Mikko
Hello,
Hello,
here is Gurux CLI Call with "-t Verbose" which fails:
gurux_dlms version: 1.0.137
gurux_net version: 1.0.19
gurux_serial version: 1.0.20
Authentication: Authentication.LOW
ClientAddress: 0x11
ServerAddress: 0x1
Standard: Standard.DLMS
TX: 13:23:52 /?!
RX: 13:23:53 bytearray(b'/LGZ5\\2ZMD3104402.B32\r\n')
Bitrate is : 9600
TX: 13:23:54 06 32 35 32 0D 0A
TX: 13:23:55 7E A0 07 03 23 93 BF 32 7E
RX: 13:23:55 7E A0 1E 23 03 73 7B CF 81 80 12 05 01 80 06 01 3E 07 04 00 00 00 01 08 04 00 00 00 01 07 22 7E
TX: 13:23:55 7E A0 43 03 23 10 77 E0 E6 E6 00 60 35 A1 09 06 07 60 85 74 05 08 01 02 8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC 09 80 07 31 32 33 34 35 36 37 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 1C 03 20 FF FF EB FB 7E
RX: 13:23:56 7E A0 36 23 03 30 6F D5 E6 E7 00 61 28 A1 09 06 07 60 85 74 05 08 01 02 A2 03 02 01 01 A3 05 A1 03 02 01 0D BE 0F 04 0D 08 00 06 5F 04 00 18 02 20 09 60 FA 00 18 3A 7E
DisconnectRequest
TX: 13:23:56 7E A0 07 03 23 53 B3 F4 7E
RX: 13:23:56 7E A0 1E 23 03 73 7B CF 81 80 12 05 01 80 06 01 3E 07 04 00 00 00 01 08 04 00 00 00 01 07 22 7E
Connection is permanently rejected
Authentication failure.
Ended. Press any key to continue.
Here is the DLMS trace where authentication with Client ID 32 (default setting in - at least - my Map.110):
00154191ms - DLMS Open
00154191ms - DLMS set State: OPENING
00154191ms - DLMS Init ShortName CommandHandler
00156469ms - DLMS set State: AUTHENTICATION
00156469ms - DLMS S-> COSEM AARQ (with ACSE Requirements)
00156469ms - DLMS dlms SendReceive
00156469ms - DLMS S-> 603980020780A1090607608574050801028A0207808B0760857405080201AC0A80083034383030383430BE0F040D01000000065F04001C13200000
00156640ms - DLMS R<- 6128A109060760857405080102A203020100A305A103020100BE0F040D0800065F04001802200960FA00
00156640ms - DLMS check ACSE-Response Values
00156640ms - DLMS set State: OPEN
00156640ms - DLMS set State: SENDRECEIVE
00156640ms - DLMS dlms SendReceive
00156640ms - DLMS S-> 050202FD0802FF08
00156749ms - DLMS R<- 0C020009104C475A33323435343033370000000000000A03423332
00156749ms - DLMS set State: OPEN
00156827ms - DLMS set State: SENDRECEIVE
00156827ms - DLMS dlms SendReceive
00156827ms - DLMS S-> 0501023848
00156921ms - DLMS R<- 0C01000A25422E4D334243505453436D446F2E323430322E4C543053547647736172687370706E61676C
00156921ms - DLMS set State: OPEN
00157015ms - DLMS set State: SENDRECEIVE
00157015ms - DLMS dlms SendReceive
00157015ms - DLMS S-> 050102C1C8
00157077ms - DLMS R<- 0C0100091302840700840B00043000045000048001048002
00157077ms - DLMS set State: OPEN
00157093ms - DLMS set State: SENDRECEIVE
00157093ms - DLMS dlms SendReceive
00157093ms - DLMS S-> 052D0294500294580294600294E80294F00294F80295800295880295900296180296200296280296B00296B80296C00297480297500297580297E00297E80297F00298780298800298880299100299180299200299A80299B00299B8029A40029A48029A50029AD8029AE0029AE8029B70029B78029B80029C08029C10029C18029CA0029CA8029CB0
00157873ms - DLMS R<- 0C2D0009060101200700FF000500005C800002020FFE16230009060101340700FF000500005C210002020FFE16230009060101480700FF000500005BE80002020FFE162300090601011F0700FF0005000000E70002020FFE16210009060101330700FF0005000000BB0002020FFE16210009060101470700FF00050000015E0002020FFE162100090601015B0700FF0005000000FE0002020FFE162100090601010E0700FF0005000013870002020FFE162C0009060101100700FF0005000005CD0002020F00161B0009060101830700FF0005000001930002020F00161D0009060101510700FF0005000000000002020FFE16080009060101510701FF000500002EE00002020FFE16080009060101510702FF000500005E240002020FFE16080009060101510704FF0005000089800002020FFE16080009060101510705FF000500002A300002020FFE1608
00157873ms - DLMS dlms SendReceive
00157873ms - DLMS S-> 052D029D38029D40029D48029DD0029DD8029DE0029E68029E70029E78029F00029F08029F10029F98029FA0029FA802A03002A03802A04002A0C802A0D002A0D802A16002A16802A17002A1F802A20002A20802A29002A29802A2A002A32802A33002A33802A3C002A3C802A3D002A45802A46002A46802A4F002A4F802A50002A58802A59002A598
00158668ms - DLMS R<- 0C2D0009060101510706FF0005000060E00002020FFE160800090601010D0700FF0005000000570002020FFE16FF0009060101210700FF0005000000570002020FFE16FF0009060101350700FF0005000000520002020FFE16FF0009060101490700FF0005000000580002020FFE16FF00090600007F0000000005FFFFFFA80002020FFD16FF00090600007F0000000005000013280002020FFD162300090600007F0000000005000011C20002020FFD162300090600007F00000000050000114D0002020FFD162300090600007F0000000005000007DB0002020FFD16FF00090600007F0000000005000003BE0002020FFD162100090600007F0000000005000002980002020FFD162100090600007F00000000050000023E0002020FFD162100090600007F0000000005000039340002020FFD16FF010300050000A0370002020FFE1623
00158684ms - DLMS dlms SendReceive
00158684ms - DLMS S-> 052D02A62002A62802A63002A6B802A6C002A6C802A75002A75802A76002A7E802A7F002A7F802A88002A88802A89002A91802A92002A92802A9B002A9B802A9C002AA4802AA5002AA5802AAE002AAE802AAF002AB7802AB8002AB8802AC1002AC1802AC2002ACA802ACB002ACB802AD4002AD4802AD5002ADD802ADE002ADE802AE7002AE7802AE80
00159355ms - DLMS R<- 0C2D0103000500009F730002020FFE16230103000500009F570002020FFE162301030005000043730002020FFE1638010300050000032D0002020FFE163801030005000000610002020FFE16FF01030005000000590002020FFE16FF01030005000000640002020FFE16FF01030005000000600002020FFE16FF010300050000093F0002020FFF162301030005000009370002020FFF1623010300050000092F0002020FFF162301030005000000E80002020FFE162101030005000000B90002020FFE162101030005000001210002020FFE162101030005000012DC0002020FFF161B
...
...
...
I'm using Gurux Python running on a PI Zero (USB optical reader).
Map.110 is running on an old Windows 7 Laptop (optical device Siemens TS69 using an USB to RS232 adapter).
Thx and bye,
e650sek
Hi,
Hi,
Your password in Gurux command line app is "1234567" and in Map 100 "04800840".
Check your password.
BR,
Mikko
Good morning,
Good morning,
hmmm ... concerning the used password within map.110 ... I'm confused.
In map.110 I'm only able to enter a password with 7-characters and if I replace 1234567 by anything else accessing the meter in map.110 is no longer working. But anyway ... this is another story.
By using Gurux the mentioned password "04800840" also fails.
CLI:
python main.py -S /dev/ttyUSB0:300:7Even1 -r sn -i HdlcWithModeE -a Low -P 04800840 -c 17 -L LGZ -t Verbose
Response:
gurux_dlms version: 1.0.137
gurux_net version: 1.0.19
gurux_serial version: 1.0.20
Authentication: Authentication.LOW
ClientAddress: 0x11
ServerAddress: 0x1
Standard: Standard.DLMS
TX: 07:53:10 /?!
RX: 07:53:11 bytearray(b'/LGZ5\\2ZMD3104402.B32\r\n')
Bitrate is : 9600
TX: 07:53:12 06 32 35 32 0D 0A
TX: 07:53:13 7E A0 07 03 23 93 BF 32 7E
RX: 07:53:14 7E A0 1E 23 03 73 7B CF 81 80 12 05 01 80 06 01 3E 07 04 00 00 00 01 08 04 00 00 00 01 07 22 7E
TX: 07:53:14 7E A0 44 03 23 10 56 B7 E6 E6 00 60 36 A1 09 06 07 60 85 74 05 08 01 02 8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC 0A 80 08 30 34 38 30 30 38 34 30 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 1C 03 20 FF FF FF 8A 7E
RX: 07:53:14 7E A0 36 23 03 30 6F D5 E6 E7 00 61 28 A1 09 06 07 60 85 74 05 08 01 02 A2 03 02 01 01 A3 05 A1 03 02 01 0D BE 0F 04 0D 08 00 06 5F 04 00 18 02 20 09 60 FA 00 18 3A 7E
DisconnectRequest
TX: 07:53:14 7E A0 07 03 23 53 B3 F4 7E
RX: 07:53:14 7E A0 1E 23 03 73 7B CF 81 80 12 05 01 80 06 01 3E 07 04 00 00 00 01 08 04 00 00 00 01 07 22 7E
Connection is permanently rejected
Authentication failure.
Ended. Press any key to continue.
BUT:
I never explicetely tried to use "-c 32" in combination with -a Low. And: IT DOES WORK NOW!
My history shows a lot of other combinations of client-id, authentication, security, ... but not this one ...
Thank you very much for looking into my issue. This was not really an issue. More a typical "Case-18" error! :-)
Finally this is my working CLI command:
python main.py -S /dev/ttyUSB0:300:7Even1 -r sn -i HdlcWithModeE -a Low -P 04800840 -c 32 -L LGZ -g 1.1.31.7.0.255:2 -g 1.1.51.7.0.255:2 -g 1.1.71.7.0.255:2
Giving me:
Index: 2 Value: 108
Index: 2 Value: 91
Index: 2 Value: 63
Thx again and bye,
e650sek
Hi,
Hi,
Client address might cause problems. With some meters, the meter doesn't reply if the address is invalid; with some meters, you get a generic error that doesn't tell the real reason.
Because client addresses might vary between meter versions and models this is causing problems.
I'm glad you have solved this and can read the meter.
BR,
Mikko