simtrace2-host-0.9.1.tar.bz2 does not compile because
this file is missing. Add it to EXTRA_DIST.
make all-recursive
make[1]: Entering directory '/build/simtrace2/src/simtrace2-0.9.1'
Making all in include
make[2]: Entering directory '/build/simtrace2/src/simtrace2-0.9.1/include'
make[2]: *** No rule to make target 'osmocom/simtrace2/version.h.tpl',
needed by 'osmocom/simtrace2/version.h'. Stop.
make[2]: Leaving directory '/build/simtrace2/src/simtrace2-0.9.1/include'
make[1]: *** [Makefile:452: all-recursive] Error 1
make[1]: Leaving directory '/build/simtrace2/src/simtrace2-0.9.1'
make: *** [Makefile:376: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...
Change-Id: I8c50c8df012b2b7eb5ee6046f14ccc4d2c07194e
Fixes: d0ad985e ("Generate a version.h file")
The old osmo_apdu_segment_in() could not parse GP GET DATA correctly
and will fail when parsing a GP GET DATA case 2 with an Le != 0.
Related: SYS#8147
Change-Id: Id5642cb76da4fcbcdd318d41691415781bf0bc50
Ensure the libosmocore version doesn't move while building
firmwares which are published.
This improve reproducible builds.
Change-Id: I753d634674f76c50e1a9cf67e5adc43201d54f0c
osmo_apdu_segment_in() doesn't have the context of the previous APDU,
for nearly all calls this is fine, except for GP GET DATA, which can be
a case 2 or case 4 APDU.
GP GET DATA defines the Le field as 0x00 which is used by osmo_apdu_segment_in
to detect if it is a case 2 or case 4.
However a card can respond with the SW 6cXX, which means the previous
command must be resend with a Le field XX, which got misinterpreted by
the osmo_apdu_segment_in() as a case 4 resulting in a timeout waiting for
more data.
Modem <-> Card
81cadf2000 ->
<- 6c0b
81cadf200b ->
-- Simtrace waits for more data because it wrongly decodes it as APDU case 4
instead of case 2.
Related: SYS#8147
Change-Id: Ie238662e7e6a10dd4283ede0c8d8d73bc375c247
tx_cfg->features is logged before the memcpy() that fills it.
Looks like no one is using config.ac --enable-sanitize?
Change-Id: Id8369d312c8600ba9eea80c8f7782f196d7e20d1
7816-3 8.1/8.2.1 allow TS plus 32 bytes.
atr_i is a byte count, not an index, process_byte_atr() guards its own
store with the same condition before incrementing, so atr_i reaches 33.
Change-Id: Ic8398cbefc0b522946b6470fd0268fa70662dab1
(~g_tpdu.packet[1]) == byte can never be true.
Unary ~ applies the integer promotions first,
so for tpdu INS = 0xA4 lhs should be 0x5B but as int
it gets zero extended to at least 16 bits and then flipped,
so it is 0xFFFFFF5B = -165, byte promotes to 0..255.
The ack was therefore dead code -> fallthrough to SW1
branch, fails 0x6x/0x9x test, TPDU gets flagged
SNIFF_DATA_FLAG_ERROR_MALFORMED from what I can tell.
But I am losing track of all these arcane issues to be honest.
Narrow the complement back to 8 bits.
Fyi this is unrelated to signedness and not specific to ARM.
Change-Id: I800f50ef35356429d07aa685ea919e70ec34946e
add_tpdu_byte() accumulates bytes received from the reader, but passes
reader_to_card = 0, but ISO 7816-3 10.3.2 says P3 == 0 means 256 not 0
Only reachable with P3 == 0 in a receive data phase, but
simtrace2-cardem-pcsc only requests PB_AND_RX when there is command data.
Fix this anyway.
Change-Id: I0fa4741bc1293549816595e6b4e8af9e22bcfbc1
cardem:
- dispatch_usb_command_cardem() appends to uart_tx_queue from the main loop
- tx_byte_tpdu() dequeues from the USART IRQ handler @ NVIC prio 0
card_handle_reset() has the same issue, drains queue and
frees uart_tx_msg from main loop while the ISR may own them.
All of this needs protection against the irq.
Needs a fixed llist_add_tail_irqsafe(), which called __enable_irq() instead of
restoring the saved PRIMASK for some unknown reason?!?!?!?
Change-Id: I7d9cdcc56263b27dfd4649dfb1da1d67761ee923
ISO 7816-3 section 10.2 defines WT = WI x 960 x Fi/f seconds,
store as etu, etu = Fi / (D x f) seconds, so the Fi cancels,
but the D does not:
WT [etu] = WI x 960 x D
cemu dropped both (?!) -> WI x 960.
The old comment explains why Fi can be dropped, which is right, but
what about Di ?!
sniffer gets it right (wt_wi * 960UL * wt_d), so the two state machines
disagreed here again, by up to a factor of 64???!!?!!?
This was fixed in osmo-ccid-firmware in 066489d in 2020 but not ported
to st2.
Additionally the waiting time was only recalculated at the end of the ATR,
where D is still 1 by definition, so a PPS increasing D reprogrammed the
baud rate but left the waiting time untouched??!
etu duration shrinks with D by the same factor, wall clock WT is
independent of D, which is the whole point.
The old code decreased the waiting time by a factor of D:
after a PPS to D=8 the card emitted its NULL procedure byte at ~0.09s
instead of ~0.71s with a reader deadline of ~1.43s,
and the inactivity timeout fires 8x too early, which probably led to
unexplained wtime_exp errors.
Update wt when WI becomes known (end of ATR) and
where D changes (after the PPS response) + tests.
Change-Id: I4263176d6073029d01f9ff5b11a6311617956af6
US_FIDI_FI_DI_RATIO_Msk is 0x7ff,
cemu rejected >= 0x400 in emu_update_fidi() and masked with 0x3ff
in card_emu_uart_update_fidi(), but update_fidi() used by
the sniffer already used 0x7ff.
-> ratios 1024..2047 are unusable in cemu, which is the entire upper
half of ISO 7816-3 Table 7 at Di=1.
A reader trying one of those in a PPS gets the proposal echoed and
accepted, after which the card keeps transmitting at the old rate.
FI_DI_RATIO is clock periods per bit -> larger ratio is a SLOWER link.
The old check rejected slow values but accepted Fi=372/Di=64, ratio 5 !?
Unify and use the register mask (= shifed by 0 so usable as value) and
reject ratios that do not fit rather than truncating to garbage dividers.
Change-Id: I6211dd5be7c5c5d2150af2aa37a403b33e6d340d
iso7816_3_compute_fd_ratio() multiplied F by D for every d_index >= 8,
presumably because the upper half of ISO 7816-3 Table 8 encodes 1/D.
But 7816-3 2006 and 1997 differ!
That assumption is only true for the range 1010..1111, which in the
2006 version is RFU. Indices 1000 and 1001 are Di = 12 and Di = 20,
see iso7816_3_di_table[].
So right now Fi=372/Di=12 -> 372 * 12 = 4464 instead of 372 / 12 =
31.
In the cemu value is rejected in emu_update_fidi()
and the old baud rate is silently kept.
In the sniffer update_fidi() programs US_FIDI as
4464 & 0x7ff = 368, which is garbage.
Use F/D for indices 1..9 and keep the legacy 1/D reading only for the RFU
range, where we cant really do anything useful anyway.
Change-Id: I44d6451d8b04aea2b0db7291b06a812afe84e52f
libnewlib-arm-none-eabi has been removed in debian unstable, build the
firmware with picolibc instead.
Fixes: OS#7017
Change-Id: If136397b71435ea0850002ef6406067962e8d4d7
Add api call osmo_st2_cardem_request_config2(struct cardemu_usb_msg_config *)
which contains a full cardemu_usb_msg_config.
Related: SYS#6946
Change-Id: Iacde63e667472a85a5f18cb4ca99dcfa1a84dd59
The sim presence pin allows the simtrace2 to inform the modem
about the presence of the simcard. On a generic simcard slot a
button is pressed by the simcard which generate a high or low voltage level.
Even though there are specifications of minipcie or ngff defining this signal, certain
modems behave different.
Certain modems require different signals from the specification.
Extend the usb protocol to set the behaviour at runtime.
Related: SYS#6946
Change-Id: I77118114ba873fdf0778137402888b40f2442456
Set CFLAGS on top of the Makefile, to avoid using the distribution's
default CFLAGS. In debian testing and unstable, -fcf-protection was
recently added to the default CFLAGS, but it cannot be used with the
cross compiler:
[COMPILING libosmocore/source/backtrace.c]
cc1: error: '-fcf-protection=full' is not supported for this target
make[2]: *** [Makefile:270: obj/simtrace/flash_backtrace.o] Error 1
Change-Id: I5f7cd0402f9bb85dd600204fdf8855773ddbeb70
At the moment only APDUs are logged to GSMTAP. It is not uncommon that a
card is resetted by the UE multiple times during normal operation. When
the trace lacks the reset events (ATR) it becomes difficult to follow in
which state the card actually is. Let't mark reset events by sending the
ATR via GSMTAP (like simtrace2_sniff already does it)
Related: OS#6094
Change-Id: I6b4d82b6ee369c95eeca8f7d59478452395fbe54
Move the logic down to where make gets called, so we don't need the
variable. Print whether we use CLANG or GCC.
Don't put /opt/llvm-arm/bin infront of PATH unless building with CLANG.
Right now it doesn't seem to have e.g. an override for gcc, but the
files in that path may change when we update
LLVM-embedded-toolchain-for-Arm.
Related: OS#6026
Change-Id: Id768e0dbed9265f042b942e6699683723ca40a7c
Set --no-parallel, as in v10 debhelper defaults to parallel building.
This is apparently not supported by simtrace2's Makefile, it leads to
multiple non-trivial build errors. In contrib/jenkins.sh we also don't
build multiple firmwares in parallel.
Related: OS#5958
Related: https://manpages.debian.org/testing/debhelper/debhelper-compat-upgrade-checklist.7.en.html
Change-Id: I49fcc4fe9d3e795f8c3514d35ff3e2beca2917d1
The Makefile already runs autoreconf -fi in the "utils" target:
utils:
(cd host && \
autoreconf -fi && \
./configure --prefix=/usr --disable-werror && \
make)
The override is not useful, as it leads to debhelper running autoreconf
as well, but without running ./configure and make in the host directory
afterwards. So autoreconf just runs twice.
I've also considered to change debian/rules to only run the "fw"
target, and not the "utils" target of the Makefile. But that only makes
it more complex, as debhelper would then need to run make twice, once in
the root directory (as "make fw"), and once in the host directory. We
would need to add several lines to debian/rules to do effectively the
same thing.
Make this change now, as "cd host && dh_autoreconf" doesn't work with
debhelper compat level v10 anymore (--sourcedir could be used instead,
but as mentioned above, it's not useful).
Related: OS#5958
Change-Id: I12f379b4ec2de6adc86557d89319ab1d04ed5e73
* Fix UTF-8 encoding. This caused the endianness check to fail, which
reads all .c and .h files.
* Add .checkpatch.conf to skip linting for:
firmware/atmel_softpack_libraries
Change-Id: Ibb2e42e9b4307275a33e4000c201847a6bd60137
Vadim Yanitskiy