search

RfidResearchGroup / proxmark3

Iceman Fork - Proxmark3
http://www.icedev.se
GNU General Public License v3.0
4k stars 1.05k forks source link

TRACKING: ⚠ Received packet OLD frame with payload too short? 470/534 #1917

Closed henrygab closed 1 year ago

henrygab commented 1 year ago

If you experience this issue on a Seven build (v4.16717 or higher), please feel free to open a new issue and reference this one. INFORMATION to ensure is included:

Describe the bug

When flashing the PM3, approximately 1/4 of the time the first attempt to flash the device fails with the above error. When this occurs, that particular flash attempt will stall (waiting for PM3 response?). However, a second attempt to flash will work.

Currently marked as "TRACKING", as the root cause is unknown, and may be related to use of virtualization (VirtualBox filter + USBIPD), as it appears to only occur during flashing, and thus re-enumeration of the device may play a part.

If you have seen this issue under a non-virtualized environment (even if rarely), please add in the comments below.

Steps To Reproduce

  1. Install Windows 11 + WSL2 + Kali distribution
  2. Follow WSL2 installation instructions
  3. Plug the Proxmark3 device into the computer
  4. In Windows, use usbipd to auto-attach the PM3 to the kali-linux distribution a. usbipd list -- to discover the BUSID of the Proxmark3 device (e.g., 7-2) b. usbipd wsl attach --busid 7-2 --distribution kali-linux --auto-attach -- to continuously re-attach the PM3 while that command runs
  5. Build & install firmware: clear; make clean && make -j && ./pm3-flash-all
  6. Optionally make changes to source, repeat step 5.

Expected behavior

When flashing, after causing the PM3 to reboot to the bootloader, the device automatically re-appears and flashing of the firmware image occurs.

Actual behavior

Approximately one time of every four, the flashing process gets "stuck", after printing the following error message to the screen: ⚠ Received packet OLD frame with payload too short? 470/534

Desktop Information

hw version

``` [usb] pm3 --> hw version [ Proxmark3 RFID instrument ] [ CLIENT ] Iceman/serial_from_flash_uniqueid/v4.16191-67-...-unclean 2023-02-18 11:12:22 f1bf40008 compiled with............. GCC 12.2.0 platform.................. Linux / x86_64 Readline support.......... present QT GUI support............ present native BT support......... present Python script support..... present Lua SWIG support.......... present Python SWIG support....... present [ PROXMARK3 ] firmware.................. PM3 GENERIC external flash............ present [ ARM ] bootrom: Iceman/serial_from_flash_uniqueid/v4.16191-67-...-unclean 2023-02-18 11:12:17 f1bf40008 os: Iceman/serial_from_flash_uniqueid/v4.16191-67-...-unclean 2023-02-18 11:12:27 f1bf40008 compiled with GCC 12.2.1 20221205 [ FPGA ] LF image 2s30vq100 2022-03-23 17:21:05 HF image 2s30vq100 2022-03-23 17:21:16 HF FeliCa image 2s30vq100 2022-03-23 17:21:27 HF 15 image 2s30vq100 2022-03-23 17:21:38 [ Hardware ] --= uC: AT91SAM7S512 Rev A --= Embedded Processor: ARM7TDMI --= Internal SRAM size: 64K bytes --= Architecture identifier: AT91SAM7Sxx Series --= Embedded flash memory 512K bytes ( 65% used ) ```

hw status

``` [usb] pm3 --> hw status [#] Memory [#] BigBuf_size............. 40696 [#] Available memory........ 40696 [#] Tracing [#] tracing ................ 1 [#] traceLen ............... 0 [#] Current FPGA image [#] mode.................... HF image 2s30vq100 2022-03-23 17:21:16 [#] Flash memory [#] Baudrate................ 24 MHz [#] Init.................... OK [#] Device ID............... --> Unknown <-- [#] Unique ID (be).......... 0x**************** [#] Unique ID (le).......... 0x**************** [#] LF Sampling config [#] [q] divisor............. 95 ( 125.00 kHz ) [#] [b] bits per sample..... 8 [#] [d] decimation.......... 1 [#] [a] averaging........... yes [#] [t] trigger threshold... 0 [#] [s] samples to skip..... 0 [#] [#] LF T55XX config [#] [r] [a] [b] [c] [d] [e] [f] [g] [#] mode |start|write|write|write| read|write|write [#] | gap | gap | 0 | 1 | gap | 2 | 3 [#] ---------------------------+-----+-----+-----+-----+-----+-----+------ [#] fixed bit length (default) | 29 | 17 | 15 | 47 | 15 | N/A | N/A | [#] long leading reference | 29 | 17 | 15 | 47 | 15 | N/A | N/A | [#] leading zero | 29 | 17 | 15 | 40 | 15 | N/A | N/A | [#] 1 of 4 coding reference | 29 | 17 | 15 | 31 | 15 | 47 | 63 | [#] [#] HF 14a config [#] [a] Anticol override.... std ( follow standard ) [#] [b] BCC override........ std ( follow standard ) [#] [2] CL2 override........ std ( follow standard ) [#] [3] CL3 override........ std ( follow standard ) [#] [r] RATS override....... std ( follow standard ) [#] Transfer Speed [#] Sending packets to client... [#] Time elapsed................... 500ms [#] Bytes transferred.............. 266752 [#] Transfer Speed PM3 -> Client... 533504 bytes/s [#] Various [#] Max stack usage......... 4088 / 8480 bytes [#] Debug log level......... 1 ( error ) [#] ToSendMax............... -1 [#] ToSend BUFFERSIZE....... 2308 [#] Slow clock.............. 31821 Hz [#] Installed StandAlone Mode [#] No standalone mode present [#] Flash memory dictionary loaded [#] ```

data tune

``` [usb] pm3 --> data tune [=] ---------- Reminder ------------------------ [=] `hw tune` doesn't actively tune your antennas, [=] it's only informative. [=] Measuring antenna characteristics, please wait... 🕛 9 [=] ---------- LF Antenna ---------- [+] LF antenna: 26.06 V - 125.00 kHz [+] LF antenna: 17.09 V - 134.83 kHz [+] LF optimal: 27.82 V - 120.00 kHz [+] Approx. Q factor (*): 6.9 by frequency bandwidth measurement [+] Approx. Q factor (*): 8.1 by peak voltage measurement [+] LF antenna is OK [=] ---------- HF Antenna ---------- [+] HF antenna: 14.20 V - 13.56 MHz [+] Approx. Q factor (*): 4.1 by peak voltage measurement [+] HF antenna is OK (*) Q factor must be measured without tag on the antenna [+] Displaying LF tuning graph. Divisor 88 (blue) is 134.83 kHz, 95 (red) is 125.00 kHz. ```

Additional context

This is not a new issue (at least 3 months old). I add this as a tracking issue, so others who occasionally hit this can find this report, and add their information in comments. Active triage is not expected at this time.

phaseloop commented 1 year ago

If it helps - I'm having similar issues with VirtualBox, it seems that Windows first assigns USB driver to Proxmark in bootloader mode, which seem to start some kind of bootloader watchdog (?), then Windows disconnects the device and passes control to VM. It takes some time for Linux to assign again the driver and pm3 to detect device. Then shortly after flashing starts (or often even before) proxmark reboots back to normal mode. Sometimes It helps to manually enter bootloader using a button.

I haven't looked into bootloader - I need to buy a debug interface - but if there is a timeout/watchdog there, it definitely needs a longer value.

henrygab commented 1 year ago

[EDIT -- see update for additional requirements ... basically, build must be configured with flash memory support (default for RDV4)]

Are you using release binaries, or building firmware from the depot?

If building your firmware, have you updated the bootloader since #1914 was merged?

To detect: Run hw status, and look for Unique ID (be)........ or Unique ID ......

If it's missing the (be), then it's older ... the lack of serial number can cause delays when plugging it in, or when the device resets.

If it shows the `(be)` with a 256-bit value, then you should likely update the bootloader.

Why should you update the bootloader in this case? The firmware is enumerating the device with a unique ID, which is great for keeping the com port the same even when plugging it into different ports, and makes enumeration much faster (at least on Windows). However, unless you've also updated the bootloader, the bootloader is still enumerating the device **_without_** a serial number. This may cause it to look like two different devices are being swapped on that USB port... depending on whether the normal firmware or the bootloader is active at time of USB device enumeration. So... if your device shows as supporting flash, make sure you build and update the bootloader (with FLASH support enabled) at least once, if you're using post-Nitride (or building firmware yourself).

phaseloop commented 1 year ago

I'll check and let you know :). Thanks for info.

phaseloop commented 1 year ago

ok, it seems I always use 'pm3-flash-all' and update bootloader, but I don't see "Unique (...)" string anywhere.

On the other hand - I've noticed that without USB Hub, flashing is more reliable when it comes to pm3 detection. Not great still, but better.

henrygab commented 1 year ago

ok, it seems I always use 'pm3-flash-all' and update bootloader, but I don't see "Unique (...)" string anywhere.

On the other hand - I've noticed that without USB Hub, flashing is more reliable when it comes to pm3 detection. Not great still, but better.

I failed to mention one other requirement to get the improved USB enumeration. Your device must have flash memory, and the build must be configured to use the flash memory. For RDV4, this is enabled automatically. If you have a different device, such as some of the PM3 Easy boards, then you must edit Makefile.platform to include the line:

PLATFORM_EXTRAS=FLASH
How this changes the compiled code... (click to expand)

Setting the above in `Makefile.platform` will end up defining the compilation flag `WITH_FLASH`. https://github.com/RfidResearchGroup/proxmark3/blob/2010d10f81b0b07d30413222415c2364523da5d5/common_arm/Makefile.hal#L115-L119 This not only enables a ton of extra functionality, but also uses the flash as the source of a unique serial number that is used for USB enumeration. This change affects both the bootloader and on-device firmware: https://github.com/RfidResearchGroup/proxmark3/blob/2010d10f81b0b07d30413222415c2364523da5d5/bootrom/bootrom.c#L225-L232 https://github.com/RfidResearchGroup/proxmark3/blob/2010d10f81b0b07d30413222415c2364523da5d5/armsrc/appmain.c#L2725-L2734

After you flash the above (via `pm3-flash-all`, for example), you should have the USB serial number populated. There's always some risk with changes to / programming the bootloader, so ensure you have a way to unbrick if the bootloader fails for any reason (failed or interrupted flash, solar flare, code crashing, etc.).
wh201906 commented 1 year ago

Hi. I got the same prompt Received packet OLD frame with payload too short when playing with the communication timeout. Does this bug still occurs in v4.16717? It has been months since you open this issue and the code of USB enumeration has been changed a bit.(c738d2cddb5a377e38b005c9ceed2d1fc650c9f2) You mentioned that it might be related to the enumeration so the bug might disappears after that. If it still happens, you can try to increase the communication timeout in the code. I only saw this prompt when the timeout is too short for a bad communication. https://github.com/RfidResearchGroup/proxmark3/blob/5de6fa443c343fb5c492cfe3e1daebd5e7cab964/include/pm3_cmd.h#L818

iceman1001 commented 1 year ago

@wh201906 did your PR regarding TestProxmark fix this issue?

wh201906 commented 1 year ago

For my case the Received packet OLD frame with payload too short doesn't show up anymore, but I'm not sure if it fixes this issue. It seems that this issue occurs with the USB connection, but I didn't touch the timeout of it in my PR so I guess it was not fixed. Maybe @henrygab need to change the timeout of USB connection to test it.

iceman1001 commented 1 year ago

Yeah, could be.

Thanks for the other fix :)

henrygab commented 1 year ago

I see this issue only with older builds. My devices all have flash, and thus all expose the serial number in the USB descriptor. Unless someone experiences this issue running a Seven build, I think it's safe to close this... it can always be found via search. I will update the first post to reflect this thought.