Open iceman1001 opened 5 years ago
Relates to doegox/proxmark-internal#90 doegox/proxmark-internal#96 and doegox/proxmark-internal#76
Not the only issue but USB comm can interrupt sim and hook again because sim looks for BUTTON and usb_poll_validate_length(). So at least we also need to check for USART data to allow sim to be interrupted.
Edit: done
chicken & egg:
Other possibilities:
We still need to smooth all scenarii but for info with last commits now the original use case is working if we change the MF_DBGLEVEL:
[usb] pm3 --> hf mf dbg 0
#db# Debug level: 0
[usb] pm3 --> hf mf sim u 11223344
[=] Mifare | 4 byte UID 11 22 33 44
[=] Options [ numreads: 0, flags: 2 (0x02) ]
#db# 4B UID: 11223344
Unplugging USB without quitting client
[!] Communicating with Proxmark3 device failed
[=] Running in OFFLINE mode. Use "hw connect" to reconnect
[offline] pm3 --> hw connect p /dev/rfcomm0
Port:: /dev/rfcomm0 Baud:: 115200
[=] Using UART port /dev/rfcomm0
[=] Communicating with PM3 over FPC UART
[=] PM3 UART serial baudrate: 115200
[fpc] pm3 --> hw ping
[=] Ping sent
[+] Ping response received
hf mf dbg 0, and sim still pushes messages.
#db# 4B UID: 11223344
The idea should also be that once the client connects to device again,
the debug messages from standalone mode should start sending again.
Hard to keep track of all use-cases
yeah but that #db# 4B UID
comes immediately before you get a chance to pull USB so that's fine ;)
It should be guarded by MF_DBG_LEVEL > 0... :) It shouldn't always print.
true
use case scenario,