Bug #5714
open
update_record_decoded does not use real record length when writing EF.MSISDN
Added by CHV over 1 year ago.
Updated 7 months ago.
Description
I'm using old regular cards for testing.
Class EF_MSISDN, method _encode_record_hex always assumes a rec_len of 15 which results in misaligned/invalid data if the real record length is different.
The encoded msisdn must always use the last 14 bytes in the record. This can only be achieved when the real record length is used.
Example:
select MF/ADF.USIM/EF.MSISDN
update_record_decoded 1 {"msisdn":"+491234567890"}
read_record_decoded 1
read_record 1
This may also concern updating EF.ADN records.
- Category set to pySim libraries
- Assignee set to chrysn
chrysn, would you mind looking into this? Thanks!
- Description updated (diff)
- Assignee changed from chrysn to dexter
- Status changed from New to In Progress
- % Done changed from 0 to 10
I think the problem here really is that there is only a minimum length specified by the spec. The spec explicitly allows to use larger record length. I have seen this also with other files while scrolling through the spec (51.011). I think with this in mind we have implemented our class LinFixedEF so that it knows a minimum_length and a recommended_length. However, as far as I can see the recommended_length does not make much sense, after all, its just a recommendation that may or may not be implemented in the card that we are currently working with.
I think what we really need is an information about from which side the data should be padded with 0xff in case the encoded data is shorter than the actual record length. In most cases adding padding on the right side is the only meaningful option, but in the case of EF.MSISDN, padding from the left side would be correct. So, all we need to do is to add a flag to the class model that tells where padding should be added and pass this information down to update_record in commands.py so that it can pad the record correctly.
A testvector:
update_record_decoded 1 {"msisdn":[1,3,"12345678901234567890"]}
expected: ffffffffffffffffffffffffffffffffffffffff0bb121436587092143658709ffff
got: ff0bb121436587092143658709ffffffffffffffffffffffffffffffffffffffffff
On Wed, Sep 06, 2023 at 03:33:32PM +0000, dexter wrote:
I think what we really need is an information about from which side the data should be padded with 0xff in case the encoded data is shorter than the actual record length. In most cases adding padding on the right side is the only meaningful option, but in the case of EF.MSISDN, padding from the left side would be correct. So, all we need to do is to add a flag to the class model that tells where padding should be added and pass this information down to update_record in commands.py so that it can pad the record correctly.
sounds good. Probably best to make that flag optional, so that we only have to specify it in those few cases where padding on the left side is correct (without touching definitions of all other classes). The actual padding code can then use hasattr() to determine if that flag/attribute/class variable is actually set or not.
- % Done changed from 10 to 90
- Status changed from In Progress to Stalled
The patch above now got merged, which means that the problem is technically fixed. But there is still one open question: As we now the reason why the records are larger than the spec defines is that the additional free space is intended to be used as so called "Alpha Identifier" this is basically a string of text that says something like "Your Number: ". The question is now, whether the use of an Alpha Identifier is compatible with our leftpad-approach.
Since everything now works it is not pressing to answer this remaining question. For now we can consider the problem as fixed and set the ticket to stalled.
If you want to go with Alpha Identifiers, see TS 131 102, 4.2.26: EF_MSISDN.
The length of the Alpha identifier is not fixed, it depends on the actual EF's record size which varies between different SIM.
One record of EF.MSISDN consists of:
x bytes Alpha Identifier;
1 byte length of number;
1 byte TON an NPI;
10 bytes dialling number;
1 byte Capability/Configuration 2 identifier;
1 byte Extension5 Record Identifier.
So there are x = (record size - 14) bytes available for the Alpha Identifier.
Padding of Alpha Identifier and dialling number is mandatory.
The structure of DF.TELECOM/EF.ADN is very similar.
Also available in: Atom
PDF
