Skip to main content
Home
for DLMS smart meters
Open source solutions for DLMS smart metering

Main navigation

  • Home
  • Products
  • About us
  • Open Source
  • Community
  • Forum
  • Downloads
User account menu
  • Log in

Breadcrumb

  1. Home
  2. Incorrect LastBlock Handling In Multi-block ActionRequest

Incorrect LastBlock handling in multi-block ActionRequest

By eriktrif , 17 July, 2026
Project
Gurux.DLMS.Python
Status
Active

multipleBlocks() in GXDLMS.py

Current code:
len_ += p.attributeDescriptor.size

Should be:
len_ += p.attributeDescriptor.available()

Reason:

For the second and following PDU blocks, attributeDescriptor has already been consumed in the first block.

At this point the buffer position is already at the end, so:
p.attributeDescriptor.available()
returns 0.

However:
p.attributeDescriptor.size
returns the full buffer size (9 bytes in this case), which incorrectly increases the calculated PDU length.

Because of this, for some boundary data sizes multipleBlocks() calculates an incorrect PDU size and the final block is generated with:
LastBlock = 0
instead of:
LastBlock = 1

This causes the receiver to wait for another block even though all data has already been transferred.

Priority
Normal
Category
Bug report
Profile picture for user Kurumi

Kurumi

1 month ago

Hi, Thank you for pointing…

Hi,

Thank you for pointing this out. This is still being tested because it affects all communication. The new version should be released this week once all tests are complete.

Regards,
Mikko

eriktrif

3 weeks 5 days ago

Hi, Thank you for taking on…

Hi, Thank you for taking on this issue!
While you are testing this area before the release, I noticed another related boundary issue in GXDLMS.getLNPdu().

When calculating whether the remaining data fits in the current PDU:

totalLength = len_ + len(reply)

totalLength does not account for the byte count header added right after by _GXCommon.setObjectCount(len_, reply).

Because of this, at the exact boundary where len_ + len(reply) == p.settings.maxPduSize, totalLength > p.settings.maxPduSize evaluates to False. The data is not truncated, and setObjectCount() adds 1 extra byte, resulting in a PDU that exceeds maxPduSize by 1 byte (e.g. 101 bytes instead of 100) while LastBlock is set to 0.

Proposed fix for both issues in GXDLMS.py:

1. In multipleBlocks():

Current code:
len_ += p.attributeDescriptor.size

Should be:
len_ += p.attributeDescriptor.available()

2. In getLNPdu():

Current code:
totalLength = len_ + len(reply)

Should be:
totalLength = len_ + len(reply) + _GXCommon.getObjectCountSizeInBytes(len_)

Hope this helps

  • Create new account
  • Reset your password

Hire Us!

Latest Releases

  • Wed, 08/26/2026 - 09:04
    Gurux.DLMS.Python 1.0.203
  • Mon, 08/17/2026 - 11:28
    Gurux.DLMS.Python 1.0.202
  • Mon, 08/17/2026 - 09:47
    gurux.dlms.cpp 9.0.2608.1701
  • Mon, 08/17/2026 - 09:25
    gurux.dlms.c 9.0.2608.1701
  • Mon, 07/27/2026 - 12:37
    gurux.dlms.cpp 9.0.2607.2701

New forum topics

  • Security vulnerability report — request for a private contact (GuruxDLMS.c / ANSI C)
  • Topic: Insufficient Memory Error When Reading Class 7 Profile Generic Objects
  • SN ReadResponse returns all-null values when response spans multiple HDLC frames
  • Gurux.Serial.Android 3.0.6 – CH340 (HL-340) USB-Serial Adapter Not Working,
  • Trying to talk to a L&G E360 meter (Using Python Gurux)
More
RSS feed
Privacy FAQ GXDN Issues Contact
Follow Gurux on Twitter Follow Gurux on Linkedin