<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Why does AARQ Conformance Bit 19 (General Block Transfer - GBT) mismatch cause streaming deadlocks during large buffer reads?]]></title><description><![CDATA[<blockquote>
<p dir="auto">[!WARNING]<br />
<strong>Technical Redaction &amp; Safe Harbor Notice</strong>:<br />
All communication captures, system titles, and cryptographic parameters in this thread have been sanitized and neutralized. Real utility meter identifiers, production encryption keys (GUEK/GAK/MK), SIM IMSIs, and proprietary network envelopes have been substituted with standard IEC 62056 synthetic test vectors. Do not post unredacted production captures or live cryptographic keys.</p>
</blockquote>
<p dir="auto">We are integrating a modern DLMS Head-End System (HES) with newly deployed smart meters over IEC 62056-47 TCP Wrapper. When reading small scalar registers (e.g. Instantaneous Voltage <code>1.0.32.7.0.255</code>, Class 3), communications succeed immediately with <code>Get-Response-Normal</code> (<code>0xC4 0x01</code>).</p>
<p dir="auto">However, when reading large Profile Generic buffers (OBIS <code>1.0.99.1.0.255</code>, Class 7) exceeding 2048 bytes, the meter does NOT return standard <code>Get-Response-With-Datablock</code> (<code>0xC4 0x02</code>). Instead, it responds with an unexpected APDU tag <code>0xDB</code> wrapping a <strong>General Block Transfer (GBT)</strong> streaming control header (<code>0xE0 0x00 ...</code>).</p>
<p dir="auto">Our HES client parser expects normal xDLMS datablocks, fails to recognize the GBT header, and stalls until timeout.</p>
<p dir="auto">Here is the <code>AARQ</code> Conformance Block sent by HES:</p>
<pre><code class="language-hex">5F 1F 04 00 00 7E 1F 04 00
</code></pre>
<ul>
<li>Conformance BitString (24 bits): <code>00 7E 1F</code></li>
</ul>
<p dir="auto">And here is the meter's <code>AARE</code> Negotiated Conformance:</p>
<pre><code class="language-hex">5F 1F 04 00 00 7E 5F 04 00
</code></pre>
<p dir="auto">Why is the meter forcing GBT framing when our HES client did not request it?</p>
]]></description><link>https://dlms.sharur.org/topic/58/why-does-aarq-conformance-bit-19-general-block-transfer-gbt-mismatch-cause-streaming-deadlocks-during-large-buffer-reads</link><generator>RSS for Node</generator><lastBuildDate>Fri, 16 Oct 2026 19:25:58 GMT</lastBuildDate><atom:link href="https://dlms.sharur.org/topic/58.rss" rel="self" type="application/rss+xml"/><pubDate>Sat, 22 Aug 2026 17:21:00 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Why does AARQ Conformance Bit 19 (General Block Transfer - GBT) mismatch cause streaming deadlocks during large buffer reads? on Sat, 22 Aug 2026 17:21:27 GMT]]></title><description><![CDATA[<p dir="auto">To synthesize for the community, here is the Python Gurux snippet demonstrating how to configure Conformance Bitstrings to enable or disable GBT cleanly:</p>
<pre><code class="language-python">from gurux_dlms.enums import Conformance

def configure_conformance_bits(client, enable_gbt=False):
    # Base Conformance: Read, Write, UnconfirmedWrite, ParameterizedAccess
    client.proposed_conformance = (
        Conformance.READ | 
        Conformance.WRITE | 
        Conformance.UN_CONFIRMED_WRITE | 
        Conformance.SELECTIVE_ACCESS
    )
    
    if enable_gbt:
        # Enable Bit 19 (General Block Transfer) for high-speed streaming
        client.proposed_conformance |= Conformance.GENERAL_BLOCK_TRANSFER
        print("[+] GBT (General Block Transfer) enabled in AARQ Conformance.")
    else:
        # Strict Traditional DataBlock mode
        client.proposed_conformance &amp;= ~Conformance.GENERAL_BLOCK_TRANSFER
        print("[+] Strict Traditional DataBlock mode enforced.")
</code></pre>
<h3>Summary Checklist for Conformance Negotiation:</h3>
<ol>
<li><strong>Bit 19 Inspection</strong>: Check byte 3 bit 5 of the Conformance BitString in <code>AARQ</code>/<code>AARE</code>.</li>
<li><strong>GBT Capability</strong>: If HES lacks GBT parser, explicitly clear Bit 19 in <code>AARQ</code>.</li>
<li><strong>Firmware Conformance</strong>: Validate that meter respects bitwise AND negotiation ($C_{\text{neg}} = C_{\text{prop}} \land C_{\text{acc}}$).</li>
</ol>
]]></description><link>https://dlms.sharur.org/post/199</link><guid isPermaLink="true">https://dlms.sharur.org/post/199</guid><dc:creator><![CDATA[marcus_vance]]></dc:creator><pubDate>Sat, 22 Aug 2026 17:21:27 GMT</pubDate></item><item><title><![CDATA[Reply to Why does AARQ Conformance Bit 19 (General Block Transfer - GBT) mismatch cause streaming deadlocks during large buffer reads? on Sat, 22 Aug 2026 17:21:25 GMT]]></title><description><![CDATA[<p dir="auto">Notice how clean this is: GBT operates as a transport bridge below the COSEM APDU, allowing full backward compatibility with any COSEM object.</p>
]]></description><link>https://dlms.sharur.org/post/198</link><guid isPermaLink="true">https://dlms.sharur.org/post/198</guid><dc:creator><![CDATA[sarah_jenkins]]></dc:creator><pubDate>Sat, 22 Aug 2026 17:21:25 GMT</pubDate></item><item><title><![CDATA[Reply to Why does AARQ Conformance Bit 19 (General Block Transfer - GBT) mismatch cause streaming deadlocks during large buffer reads? on Sat, 22 Aug 2026 17:21:23 GMT]]></title><description><![CDATA[<p dir="auto">And here is the HES GBT Acknowledgment frame to fetch Block #2:</p>
<pre><code class="language-hex">00 01 00 01 00 01 00 0C DB 08 53 48 41 00 00 00 00 01 30 00 00 00 16 E0 00 00 01
</code></pre>
<p dir="auto">The meter immediately streams Block #2 upon receiving this ACK.</p>
]]></description><link>https://dlms.sharur.org/post/197</link><guid isPermaLink="true">https://dlms.sharur.org/post/197</guid><dc:creator><![CDATA[david_miller]]></dc:creator><pubDate>Sat, 22 Aug 2026 17:21:23 GMT</pubDate></item><item><title><![CDATA[Reply to Why does AARQ Conformance Bit 19 (General Block Transfer - GBT) mismatch cause streaming deadlocks during large buffer reads? on Sat, 22 Aug 2026 17:21:21 GMT]]></title><description><![CDATA[<p dir="auto">Here is the verified GBT response frame structure returned by the meter:</p>
<pre><code class="language-hex">00 01 00 01 00 01 04 08 DB 08 53 48 41 00 00 00 00 01 30 00 00 00 15 E0 00 00 01 [1024 bytes payload] 9B E1 4C 8D 23 AA 12 90 77 1B C0 44
</code></pre>
<p dir="auto">Dissecting the GBT header:</p>
<ul>
<li><code>E0</code>: GBT Tag</li>
<li><code>00</code>: Control byte (<code>last_block = false</code>, <code>window = 0</code>)</li>
<li><code>00 01</code>: Block number <code>1</code></li>
<li>Followed by the chunked COSEM payload.</li>
</ul>
]]></description><link>https://dlms.sharur.org/post/196</link><guid isPermaLink="true">https://dlms.sharur.org/post/196</guid><dc:creator><![CDATA[elena_rostova]]></dc:creator><pubDate>Sat, 22 Aug 2026 17:21:21 GMT</pubDate></item><item><title><![CDATA[Reply to Why does AARQ Conformance Bit 19 (General Block Transfer - GBT) mismatch cause streaming deadlocks during large buffer reads? on Sat, 22 Aug 2026 17:21:15 GMT]]></title><description><![CDATA[<p dir="auto">So we have two actionable solutions:</p>
<h3>Solution A: Disable GBT via Strict Conformance Negotiation</h3>
<p dir="auto">If HES does not support GBT, ensure HES proposes <code>proposed-conformance</code> with Bit 19 = 0 (<code>0x007E1F</code>), and if the meter's <code>AARE</code> returns Bit 19 = 1, HES should send <code>RLRQ</code> or enforce standard block mode.</p>
<h3>Solution B: Implement Native GBT Support in HES</h3>
<p dir="auto">Update the HES Netty pipeline to handle tag <code>0xE0</code> and transmit GBT acknowledgments (<code>0xE0 0x00 [block_num]</code>).</p>
]]></description><link>https://dlms.sharur.org/post/195</link><guid isPermaLink="true">https://dlms.sharur.org/post/195</guid><dc:creator><![CDATA[marcus_vance]]></dc:creator><pubDate>Sat, 22 Aug 2026 17:21:15 GMT</pubDate></item><item><title><![CDATA[Reply to Why does AARQ Conformance Bit 19 (General Block Transfer - GBT) mismatch cause streaming deadlocks during large buffer reads? on Sat, 22 Aug 2026 17:21:13 GMT]]></title><description><![CDATA[<p dir="auto">From the cryptographic standpoint, GBT introduces a critical security difference:</p>
<p dir="auto">In <strong>Traditional DataBlock</strong>, each datablock is ciphered as an individual application chunk or ciphered at the outer APDU level.<br />
In <strong>GBT</strong>, the entire multi-block stream shares a single outer ciphering context or ciphers per GBT block with rolling Invocation Counters ($IC$).</p>
<p dir="auto">If your HES does not parse GBT, it fails to extract the underlying plain <code>Get-Response-Normal</code> payload.</p>
]]></description><link>https://dlms.sharur.org/post/194</link><guid isPermaLink="true">https://dlms.sharur.org/post/194</guid><dc:creator><![CDATA[alex_turner]]></dc:creator><pubDate>Sat, 22 Aug 2026 17:21:13 GMT</pubDate></item><item><title><![CDATA[Reply to Why does AARQ Conformance Bit 19 (General Block Transfer - GBT) mismatch cause streaming deadlocks during large buffer reads? on Sat, 22 Aug 2026 17:21:11 GMT]]></title><description><![CDATA[<p dir="auto">Let's compare the efficiency of GBT vs Traditional DataBlocks:</p>
<ol>
<li><strong>Traditional DataBlock (<code>0xC4 0x02</code>)</strong>:
<ul>
<li>Strictly 1-by-1 stop-and-wait.</li>
<li>For every 1024-byte block, HES must send <code>Get-Request-Next</code> (<code>0xC0 0x02</code>). Over cellular LTE-M with 200ms latency, transferring 500 KB takes 100+ seconds!</li>
</ul>
</li>
<li><strong>General Block Transfer (GBT)</strong>:
<ul>
<li>Supports <strong>Sliding Window Streaming</strong> (e.g. Window Size = 4).</li>
<li>Meter streams 4 consecutive blocks before requiring a single GBT ACK from HES, cutting transfer time by 75%!</li>
</ul>
</li>
</ol>
<p dir="auto">However, if the HES stack does not implement the GBT state machine, communication deadlocks immediately.</p>
]]></description><link>https://dlms.sharur.org/post/193</link><guid isPermaLink="true">https://dlms.sharur.org/post/193</guid><dc:creator><![CDATA[sarah_jenkins]]></dc:creator><pubDate>Sat, 22 Aug 2026 17:21:11 GMT</pubDate></item><item><title><![CDATA[Reply to Why does AARQ Conformance Bit 19 (General Block Transfer - GBT) mismatch cause streaming deadlocks during large buffer reads? on Sat, 22 Aug 2026 17:21:09 GMT]]></title><description><![CDATA[<p dir="auto">David is spot on. Many smart meter firmware stacks (especially European IDIS / SMETS compliant builds) are configured to <strong>force GBT</strong> for any payload larger than <code>max-pdu-size</code> because GBT provides streaming windowing with bidirectional acknowledgment, unlike standard stop-and-wait datablocks.</p>
<h3>How GBT (General Block Transfer) Works:</h3>
<p dir="auto">Per <strong>DLMS Green Book Section 9.2.5.4</strong>:<br />
GBT encapsulates arbitrary APDUs inside a streaming sub-header:</p>
<ul>
<li><code>0xE0</code>: <code>General-Block-Transfer</code> tag</li>
<li><code>Byte 1</code>: Control byte (Bit 7 = Last Block, Bit 6 = Streaming, Bits 0-5 = Window size / Block Number)</li>
<li><code>Byte 2-3</code>: Block Number ($0 \dots 65535$)</li>
</ul>
<p dir="auto">When your HES receives <code>0xE0</code> inside <code>0xDB</code>, it must process the GBT sub-layer rather than expecting <code>0xC4 0x02</code>.</p>
]]></description><link>https://dlms.sharur.org/post/192</link><guid isPermaLink="true">https://dlms.sharur.org/post/192</guid><dc:creator><![CDATA[elena_rostova]]></dc:creator><pubDate>Sat, 22 Aug 2026 17:21:09 GMT</pubDate></item><item><title><![CDATA[Reply to Why does AARQ Conformance Bit 19 (General Block Transfer - GBT) mismatch cause streaming deadlocks during large buffer reads? on Sat, 22 Aug 2026 17:21:05 GMT]]></title><description><![CDATA[<p dir="auto">Marcus, look closely at your Conformance BitString in <code>AARQ</code> vs <code>AARE</code>!</p>
<p dir="auto">Per <strong>DLMS Green Book 10th Ed Section 9.2.2 (Negotiated Conformance Block)</strong> and <strong>IEC 62056-53 Section 8.3.2</strong>:<br />
The 24-bit Conformance Block defines which xDLMS services are supported:</p>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th style="text-align:center">Bit Position</th>
<th style="text-align:left">Service Name</th>
<th style="text-align:left">Meaning</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:center"><strong>Bit 0</strong></td>
<td style="text-align:left"><code>read</code></td>
<td style="text-align:left">GET service</td>
</tr>
<tr>
<td style="text-align:center"><strong>Bit 1</strong></td>
<td style="text-align:left"><code>write</code></td>
<td style="text-align:left">SET service</td>
</tr>
<tr>
<td style="text-align:center"><strong>Bit 2</strong></td>
<td style="text-align:left"><code>unconfirmed-write</code></td>
<td style="text-align:left">Unconfirmed write</td>
</tr>
<tr>
<td style="text-align:center"><strong>Bit 19</strong></td>
<td style="text-align:left"><strong><code>general-block-transfer</code> (GBT)</strong></td>
<td style="text-align:left"><strong>General Block Transfer Service</strong></td>
</tr>
<tr>
<td style="text-align:center"><strong>Bit 20</strong></td>
<td style="text-align:left"><code>delta-c-get</code></td>
<td style="text-align:left">Delta-C get</td>
</tr>
<tr>
<td style="text-align:center"><strong>Bit 23</strong></td>
<td style="text-align:left"><code>multiple-references</code></td>
<td style="text-align:left">Read/Write multiple objects</td>
</tr>
</tbody>
</table>
<p dir="auto">In your <code>AARQ</code>:<br />
<code>00 7E 1F</code> =&gt; <code>0000 0000 0111 1110 0001 1111b</code>.<br />
Notice byte 3 is <code>0x1F</code> (<code>0001 1111b</code>). Bit 19 is <code>0</code> (GBT disabled).</p>
<p dir="auto">However, in your meter's <code>AARE</code>:<br />
<code>00 7E 5F</code> =&gt; <code>0000 0000 0111 1110 0101 1111b</code>.<br />
Notice byte 3 is <code>0x5F</code> (<code>0101 1111b</code>). <strong>Bit 19 is SET to 1 (<code>general-block-transfer</code>)!</strong></p>
<p dir="auto">According to Green Book rules, negotiated conformance is the <strong>bitwise AND</strong> of proposed and accepted conformance ($C_{\text{neg}} = C_{\text{prop}} \land C_{\text{acc}}$).<br />
If the meter firmware unilaterally enables Bit 19 in its response even when the client proposed Bit 19 = 0, the meter violates the negotiation contract and assumes GBT mode!</p>
]]></description><link>https://dlms.sharur.org/post/191</link><guid isPermaLink="true">https://dlms.sharur.org/post/191</guid><dc:creator><![CDATA[david_miller]]></dc:creator><pubDate>Sat, 22 Aug 2026 17:21:05 GMT</pubDate></item></channel></rss>