problem with SFI and a cots UE #21
Description
Hello,
I'm using onomondo-uicc with a cots UE (quectel rm500). I run onomondo-uicc on an stm32 board and use a sim cable to connect to the cots UE. (This will be released as free software at some point in time, I need to finish and polish things first.)
What I see is that the quectel module calls READ BINARY with an SFI that is not interpreted correctly by onomondo-uicc.
Below is an archive with some runs for your inspection.
The txt files are logs printed by onomondo-uicc. Using UART facility of the stm32 board, minicom is used on my linux-based computer to capture and record those logs. The pcap files are generated using a custom program that parses the txt file to extract data and format it as expected by pcap file format.
To collect logs, I run "AT+CFUN=1,1", then wait for the logs to stop scrolling, then run "AT+CFUN=0". There is no gNB running, so no connection attempt (and no security computations).
The run "default-atr" is using the files as they are in the repository. Using wireshark, you can look at READ BINARY after VERIFY CHV (packet 41). We see SFI=03. If you search for "SFI" in the txt log, you see this:
SFI DEBUG resolved SFI=03 to FID=6fe3 using lookup file /3f00/7ff0/5f100001
This does not align with ETSI TS 31.102 4.2.91 where SFI for 6fe3 is specified as 1e, not 03. 03 is for 6fad (see ETSI TS 31.102 4.2.18).
I am not super specialist here, so that's why I open an issue an don't propose directly a PR.
But if I set the content of "/3f00/7ff0/5f100001" as:
6fb76f056fad6f386f566f786f076f086f096f606f7e6f736f7b6f486f5b6f5c6f616f316f626f806f816f4f6f066fe46fc56fc66fcd6f396fd96fe3ffff
which is aligned with ETSI TS 31.102 Annex H, then things work better. It's not super good, I still get some reset triggered by the quectel module, I did not analyse why (see default-atr-new-5f100001.txt and default-atr-new-5f100001.run2.txt).
If I use a simpler ATR (see simpler-atr.txt) then things work much better. In this ATR I simply don't support SFI and the quectel does not use SFI as we can see in the pcap and the txt (searching for SFI returns nothing in the txt).
I can provide more information if you need.
For a solution (because there is a bug, the quectel module expects a given file with its READ BINARY and onomondo-uicc returns the content of another file), I can propose to change the content of "/3f00/7ff0/5f100001".
First problem is: I don't know why you use non-standard values.
Second problem: there are some BER-TLV "88" in some .def files, which also are not standard, so I would need to change there as well. But then, again, I don't know why/how you populated the values there.
Another solution could be to change the ATR, but maybe you need the specific value you use because some tools/devices you use require it and don't parse the actual content of the ATR.