shashank created CAMEL-25318:
--------------------------------
Summary: camel-smpp - an 8-bit message is split by its length in
characters, not bytes, and a message one segment past 255 gets the segment
count 0
Key: CAMEL-25318
URL: https://issues.apache.org/jira/browse/CAMEL-25318
Project: Camel
Issue Type: Bug
Components: camel-smpp
Reporter: shashank
*1. Split decision.* {{SmppSmCommand.splitBody}} sends the bytes of
{{getShortMessage(message)}} (for an 8-bit alphabet the body as {{byte[]}}),
but {{createSplitter}} creates the 8-bit splitter with
{{message.getBody(String.class).length()}}. An 8-bit short message holds 140
octets, and the splitter compares that length with 140. When the bytes decode
(exchange charset, UTF-8 by default) to fewer characters than there are bytes,
the message is not split and one short message of more than 140 octets is sent:
non-ASCII text with an 8-bit alphabet, or binary data that contains valid UTF-8
sequences (for example 150 bytes that decode to 50 characters). This needs the
8-bit alphabet in the {{CamelSmppAlphabet}} or {{CamelSmppDataCoding}} header
(the body is then sent as {{byte[]}}), or an 8-bit alphabet on the endpoint
together with a multi-byte {{encoding}} such as UTF-8; with the 8-bit alphabet
on the endpoint and the default {{encoding}} ISO-8859-1, characters and bytes
agree.
*2. Segment count.* {{SmppSplitter.split}} applies the limit of 255 segments
before it counts the last partial segment:
{code:java}
int segmentNum = message.length / segmentLength;
if (segmentNum > MAX_SEG_COUNT) { segmentNum = MAX_SEG_COUNT; messageLength =
segmentNum * segmentLength; }
if ((messageLength % segmentLength) > 0) { segmentNum++; }
{code}
A message of 255 full segments and a few more bytes is split into 256 segments,
and {{(byte) 256}} = 0 is written as the total in every UDH; longer messages
are truncated to 255 segments as intended. With the fix such a message is
truncated to 255 segments too (with the default {{ALLOW}} policy the bytes
after the 255th segment are dropped, as for every longer message today).
h3. Reproduction
New {{SmppSplitBodyTest}} ({{splitBody}} of {{SmppSubmitSmCommand}}): 150 bytes
of binary data and 100 characters of {{é}} (200 bytes) with {{ALPHA_8_BIT}}
come back as one segment ({{expected: <2> but was: <1>}}), and 255 * 134 + 1
bytes as 256 segments ({{expected: <255> but was: <256>}}); 140 bytes unsplit
is the control. Two runs on main.
h3. Proposed fix
Create the 8-bit splitter with the length of the encoded message; count the
partial segment before applying the 255 limit. Messages whose characters and
bytes agree (ASCII, ISO-8859-1 in an ISO-8859-1 exchange) and messages of at
most 255 segments are split as before. Module: 141 tests pass.
Found with a Lean 4 model of the split decision and the segment arithmetic:
"every short message has at most 140 octets and there are at most 255 segments"
fails on main ({{main_oversize}}, {{main_euros}}, {{main_256_8bit}},
{{main_256_default}}) and is proved for the fix ({{fix_fits}}, {{fix_le_255}},
{{fix_covers_8bit}}); the fix equals main whenever main stays within 255
segments ({{fix_eq_main_8bit}}, {{fix_eq_main_default}}).
Affected: 4.14.x, 4.18.x and main (same code for years).
Duplicate check (2026-10-04): JIRA component camel-smpp with split / splitter /
segment (CAMEL-8013, CAMEL-8116, CAMEL-16134, CAMEL-4086), "Smpp8BitSplitter":
none on this. GitHub pull requests "smpp split": none.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
