binary scan format 8-bit character code (c) in TCL - tcl

Question

I am confused about the binary scan of types "c", as it is said that "c" refers to 8 bit character code. I have the following code to be maintained
puts ""
set b_val2 "0000021002020a042845245d868a8d9900081b000315aef0010c105d39b4f7c9a083a65e7d000306140508063024"
set msg2 [binary format H* $b_val2]
set msg2 [string range $msg2 1 end]
while {[binary scan $msg2 cc id2 len2] == 2} {
puts ""
#puts "SECOND ID is $id2 and SECOND LENGTH is $len2"
set id2 [expr {$id2 & 0xff}]
set len2 [expr {$len2 & 0xff}]
set val2 [string range $msg2 2 [expr {1+$len2}]]
switch -exact -- $id2 {
0 {
puts ""
if {$val2 == "\x10\x04"} {
puts "val is found for 04 "
} elseif {$val2 == "\x10\x02"} {
puts "ID is found for 02! CORRECT "
} else {
puts "not supported"
}
}
}
}
the idea is to take the value of "10 02" from the given hex. and this code work just fine until I Change the given Input of b_val as
00021002020903e845245ca0d29858081c00031ef7c001106d3931e7d3414e6d3df26831030614051608045c22
for the first given hex code "len" is "3" and it parses the binary correctly, but for the second hex Input, the "len2" is 16, hence parsing the wrong bytes.
I read that the binary scan cc will give back two variable of type 8 bit character code, but the above failure does not make any sense to me at all, as what i understand that what is the previous author tries to aim with the above code (expecially the set val2 where it tries to take the range) and why it fails for the second input

Answer 1

For starters: your code snippet never modifies msg2 within the while loop, so the scan returns the same result every loop, and you have an infinite loop. I tossed a break in to only loop once, but that leaves me uncertain I have the right behavior.
That said, the obvious issue is that when you go from your original message to the replacement, you've dropped the first byte (value of 00). Starting with line 2 (ignoring blank lines), where you set
set b_val2 "0000021002020a..."
let's parse by hand. Line 3 converts it to hex, and line 4 drops the first byte so that we start with a string of bytes with hex values of \x00 \x02 \x10 \x02 \x02 \x0a .... The binary scan on line 5 sets id2 to the first byte and len2 to the second byte; line 10 sets val2 to a string with values \x10 \x02, which matches your criteria. Success.
Now reparse with input of
set b_val2 "00021002020903e84..."
from your second input line. Again, the first byte is DISCARDED on line 4, leaving you with \x02 \x10 \x02 \x02 \x09 \x03.... Line 5 sets id2 to 2 and len2 to \x10, or decimal 16, which is what you see. That means val2 is very different from what you expected, but that's due to you dropping a byte from your input.
Byte parsers are EXTREMELY sensitive to initial position in the string. Once you mess that up, you'd better have a robust resynchronization mechanism or it's all over bar the shouting. This is one major reason that wire protocols are difficult. :)