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

2 months 2 weeks 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

2 months 1 week 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

  • Tue, 10/13/2026 - 12:00
    gurux.dlms.java 4.0.97
  • Tue, 09/22/2026 - 14:02
    Gurux.DLMS.Net 9.0.2609.2201
  • Mon, 09/21/2026 - 10:18
    Gurux.DLMS.Net 9.0.2609.2101
  • Wed, 08/26/2026 - 09:04
    Gurux.DLMS.Python 1.0.203
  • Mon, 08/17/2026 - 11:28
    Gurux.DLMS.Python 1.0.202

New forum topics

  • Need RJ45 pin configuration for Saral 300 and Saral 305 Secure meters
  • Query Regarding Class 63 Status Mapping Support in Gurux DLMS Python
  • Inhemeter
  • DLMS Server - Profile Generic - can't add too many items to profile generic capture object - how to set maximum profile entries
  • HDLC Frames sequencing
More
RSS feed
Privacy FAQ GXDN Issues Contact
Follow Gurux on Twitter Follow Gurux on Linkedin