aes - WM-Bus extended layer decoding -

i trying decrypt wm-bus telegram kamstrup multical21 in c1 mode extended link layer.
payload ell info following:
23 44 2d 2c 45 45 71 63 1b 16 8d 20 6a 31 fb 7c 20 39 a3 79 60 4b 90 bd fc 8d d8 cb 18 ce 77 dc 41 ce 8c

analysing ci = 8d found there ell following data:
ci (1 byte) cc(1 byte) acc(1 byte) sn(4 bytes) crc(2 bytes) 8d 20 6a 31 fb 7c 20 39 a3

the documentation says buffer should decrypted shall contain crc ell, i.e:
39 a3 79 60 4b 90 bd fc 8d d8 cb 18 ce 77 dc 41 ce 8c

i have got aes key manufacturer:
b9 7a 6d 4e c2 74 a4 6d 87 0e 31 27 d9 a0 af 63

initialization vector ell shall be:
m-field a-field cc-field sn-field fn bc 2d 2c 45 45 71 63 1b 16 20 31 fb 7c 20 00 00 00

after decrypting, following result:
08 3a 5f ce b2 8d 51 97 94 a2 5b fb 61 ab 2e c0 e4 20 c8 2a 43 ff 3a 75 6f 93 d0 ac 8c 79 b7 a1

since there no 2f 2f in beginning, wrong! can me , tell have done wrong? in advance.

i had in latest kamstrup docs ("wireless m-bus communication kamstrup water meters - multical® 21 , flowiq® water meters mode c1 according en 13757-4:2013")

when decrypt packet find: 25877968217e8e01000000000000000000

firstly, seems kamstrup decrypted packets not start 2f 2f.

the first 2 bytes of decrypted packet supposedly plcrc (i can't confirm right - don't have immediate access standard defines crc polynomial algorithm), , next byte 79, means compact frame, next 4 bytes 2 more crcs, , next 2 bytes 0100 info, manufacturer specific , don't know how interpret yet.

this meter r type 1, right? (on face place, "con.:" parameter's 3rd last digit should 1) format [info][volume][target volume] - 2 bytes, 4 bytes, 4 bytes - kind of assume that, since packet compact packet, don't actual format long packet have, e.g. number of decimals - you'd need - values zeroes? decimals doesn't matter. (the 'long' packet of course every 6th packet or so?)

the iv is: 2d2c454571631b162031fb7c20000000 same yours.

the encrypted packet use is: 39a379604b90bdfcbe8dd8cb18ce77dc41 exclude ce , 8c had on yours? when put them in, decrypted packet becomes: 25877968217e8e01000000000000000000bb49 pretty same packet more crc stuff @ back, suspect, not decrypt, since result different?

ok, maybe use aes/cbc/nopadding, in openmuc.

kamstrup uses aes/ctr/nopadding. how don't have decrypt multiples of 16 byte blocks? way looks in java code follows: cipher cipher = cipher.getinstance("aes/ctr/nopadding");