Closed spp2000 closed 10 months ago
can confirm there's still an issue
I took more than 10 traces and I can confirm that, in my case, the communication restarts always and only after those commands during the waiting loops. fdt is always about 1600 when the issue occurs, but there is no rule as to when this happens: it can happen after 2, 30, 50, 70, 200 loops indifferently.
Ultra Vs Rev.G Rev.G fdt never drops (like Ultra in the pictures above) and are much longer
With 2.0 it seems to work @spp2000 can you check on your readers?
EDIT: works on all readers I have, and even better than previous patches (distance is no longer a problem)
aaaand it's broken again
For me nothing has changed since the last time the emulation was improved. The readers that worked continue to work, while the one that was ko remained ko. What problem do you experience?
remember my "problematic" Salto modular XS reader? with the original V2 (2 weeks ago) it was working without issue. I have updated today to the latest and reader won't work again with it.
really no idea what the issue might be.
@mitmarcus After tracing with SPP2000, we have finally resolved two bugs that affect the simulation of 14a and mf1. You can update to the latest build version to test whether they have solved your problem at the same time. I think this is a high probability.
An OEM access control system, in addition to simply controlling access, also allows you to perform a series of operations from the terminal (queries, etc.). To do this, the tag must be left on the reader in order to keep the session open.
Analyzing 3 traces I noticed that, after the first authentication, the system waits for instructions by executing a loop of two
READBLOCK
: it continuously asks forAUTH-B(12)
-READBLOCK(12)
-READBLOCK(13)
(see pictures).With Ultra (latest fw) the initial authentication works fine but, during the wait/loops, every 2 seconds (more or less) the communication stops and starts again from the beginning, therefore prevents me from continuing with the next operations.
For the 3 traces acquired we observe that:
AUTH-B(12)
is shorter than the previous (about 1600 Vs 3000) -> collision?READBLOCK (13)
are shorter than the previous (about 1600 Vs 5200) -> collision? Then we have a new ANTICOLL, etc...I can't acquire more time with pm3, but from the terminal I see that this behavior repeats continuously after about 2 seconds.
Given that this behavior does not seem exactly systematic, I will try to take other traces to have a minimum of statistics on this behavior, if it can be useful. Thank you traceman ;)
Trace n.1
Trace n.2
Trace n.3