Incomplete frame detection question - causes RR loop on Kamstrup

Hi Kurumi,

I’m using Gurux DLMS with HDLC and based part of my receive logic on the examples in the Gurux repository. In particular, I copied the pattern here (https://github.com/Gurux/Gurux.DLMS.Net/blob/751914f4a9a6fd504e5b8c6430…) where a reply is treated as “no data yet” when:

reply.Error == 0 && reply.Data.Size == 0

This generally works, but I ran into a subtle issue during disconnect handling, specifically with Kamstrup meters.

What I’m seeing:

When I send an HDLC Disconnect (DISC), the meter correctly replies with UA.

UA is a valid HDLC control frame and has no DLMS payload, so reply.Data.Size == 0.

Because reply.Error == 0 && reply.Data.Size == 0 matches, my code enters the loop that sends Receiver Ready (RR) / continuation frames.

This causes Gurux to think more data is expected, even though the link was cleanly disconnected.

The request and response is:

TX: 7E A0 07 21 25 53 E0 16 7E // DISC
RX: 7E A0 07 25 21 73 E3 33 7E // UA

GXDLMSDirector decodes this correctly as DISC / UA.

My question:

Is the (reply.Error == 0 && reply.Data.Size == 0) condition intended to be used only for I-frames / DLMS-level continuation, and not for HDLC control frames like UA?

Should user code explicitly check the HDLC frame type (UA/DISC/SNRM/etc.) and avoid sending RR / GetMoreData in those cases?

Or is this a limitation/bug in the example that should be guarded with additional checks?

My workaround is to add a bool parameter which I set to true when sending disconnect. I add it to the clause checking for empty data above so I don't enter the while loop if it is true and I received a valid frame with no data. This fixes the issue. I just want to confirm the intended pattern so I can use it if there is something more explicit.

Thanks — and thanks for the excellent library.