Proxmark RDV2 sometimes unresponsive

kchung · 2016-05-05 02:13:11

So I purchased a Proxmark RDV2 from Elechouse and it works alright except it intermittedly appears to "disconnect" and it will take multiple submissions of a command or even a removal and reinsertion of the device to get it to respond to a command.

Is this something that's a problem with my device or is there something that I can do?

iceman · 2016-05-05 07:40:33

Could be your usb cable or
you are using a usb3.0 port, the PM3 doesn't seem to like that or
you are not on a high power usb 2.0 port..

If you would elaborate more exactly when you are experiencing it would help out to pinpoint the cause.

And do open an issue on GitHub

kchung · 2016-05-05 15:57:56

Hmm I believe I have tried a few cables but I have been using a USB 3.0 port recently. I also don't think I was using a powered USB 2.0 port. Just what was on my desktop.

I did some playing around yesterday and flashed v2.5.0 from here: http://proxmark.org/forum/viewtopic.php?id=1562 and the issue persisted but I noticed that the Windows GUI app was much more consistent and reliable. Where the CLI would start to be unresponsive after perhaps 3 commands, the GUI app worked consistently in my testing.

I've been working from a Windows VM in VMWare Fusion., I'm not sure if that would cause an issue.

iceman · 2016-05-05 16:59:54

@Asper's pre compiled binaries hasn't been updated for a while.

I would download the latest source from Github, either a release or the code. Compile & Flash it.
There is a chance that the GUI is not in sync with the remakes of the commands.

kchung · 2016-05-05 17:15:03

I actually did build from master and tried to flash it. It was successfully flashed but I was unable to read cards. The command would just wait for a response and the PM3 light wouldn't turn on nor would the client get a response.

I just went back to 2.5.0 since it was able to read a card.

iceman · 2016-05-05 17:28:55

It would still more helpful if you posted which commands and the output from them.

Like for instance, if it is a iso14443a tag it needs some distance between antenna and tag to work properly..

osys · 2016-05-05 17:41:53

Just try to flash the latest pm3 git head for the testing.
Your PM3 RDV 2.0 should be ok using quite short usb cable attached to USB2.0 port using Linux of course.

kchung · 2016-05-06 02:56:22

I got an example of me entering commands into the 2.5.0 client and only intermittedly getting responses.

http://i.imgur.com/rx9Lc5k.png

The setup is a 3" USB cable connected the PM3 and just the LF antennae plugged in.

iceman · 2016-05-06 06:47:33

Running my fork, shouldn't be different for 'lf hid' commands, both LF SEARCH / LF HID FSKDEMOD works.

I suggest you recompile and flash again. After that I would start looking at LF commands to verify lF works at all.

pm3 ~/client$ proxmark3.exe com3
Prox/RFID mark3 RFID instrument
bootrom: /-suspect 2015-11-19 10:08:02
os: iceman/-suspect 2016-05-05 20:30:54
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2015/11/ 2 at  9: 8: 8

uC: AT91SAM7S512 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 512K bytes. Used: 214717 bytes (41%). Free: 309571 bytes (59%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
pm3 --> lf se
Reading 30000 bytes from device memory

Data fetched
Samples @ 8 bits/smpl, decimation 1:1
NOTE: some demods output possible binary
  if it finds something that looks like a tag
False Positives ARE possible


Checking for known tags:

HID Prox TAG ID: 2006ec0c86 (1603) - Format Len: 26bit - FC: 118 - Card: 1603

Valid HID Prox ID Found!
pm3 --> lf hid fskdemod
#db# TAG ID: 2006ec0c86 (1603) - Format Len: 26bit - FC: 118 - Card: 1603
#db# TAG ID: 2006ec0c86 (1603) - Format Len: 26bit - FC: 118 - Card: 1603
#db# TAG ID: 2006ec0c86 (1603) - Format Len: 26bit - FC: 118 - Card: 1603
#db# TAG ID: 2006ec0c86 (1603) - Format Len: 26bit - FC: 118 - Card: 1603
#db# TAG ID: 2006ec0c86 (1603) - Format Len: 26bit - FC: 118 - Card: 1603
#db# TAG ID: 2006ec0c86 (1603) - Format Len: 26bit - FC: 118 - Card: 1603
#db# TAG ID: 2006ec0c86 (1603) - Format Len: 26bit - FC: 118 - Card: 1603
#db# TAG ID: 2006ec0c86 (1603) - Format Len: 26bit - FC: 118 - Card: 1603
#db# Stopped
pm3 -->

kchung · 2016-05-06 18:21:34

I've been able to call lf hid fskdemod and lf hid clone successfully but the issue is that successful responses are intermittent.

But I do realize the problem could be the virtual machine. I will test on my own and report back when I have new results.

iceman · 2016-05-06 18:23:13

try the "hw status" command

kchung · 2016-05-06 18:25:51

I've tried hw status as well and when it returns information it reports that the PM3 is operating fine. I can get screenshots of that later in day.

What is most puzzling is that I can run a command in the CLI and not get a response but then go to the GUI and receive responses consistently. Even if the GUI simply shells out to the CLI app there seems to be something different making it more stable for me.

iceman · 2016-05-06 18:40:18

I don't think you can have the GUI open at the same time as the CLI. They both locks down the comport and only one can win...

kchung · 2016-05-06 18:41:40

I didn't have them running at the same time. I would shut down one before switching to the other. But whereas I would receive a response perhaps 20% of the time in the CLI, the GUI would work 100%.

ntk · 2016-05-06 18:51:38

Would a trace intensiver setting via different debug level reveal behaviour of PM3 in lower layers? If put PM3 in debugger or on JTAG, the stability difference of operation in CLI or GUI environment could be found, ot not?

iceman · 2016-05-06 18:57:54

It just doesn't make sense. the GUI uses the CLI underneath. So the CLI should work just as, if it works with the GUI.

kchung · 2016-05-06 20:52:38

i'm just as confused but I do have a good feeling that it is timing with the VM that is my underlying issue. With the original PM3 that I used prior it was using the libusb driver which I was able to use in a VM.

This newer serial interface is faster but perhaps it requires very specific timing?

When I start the CLI interface I do so using the Go batch script provided which just calls "proxmark COM5". Should I be using the MinGW provided interface instead?

I also went ahead and decompiled the GUI app and it appears to make a new process which it puts into a thread with the CLI process and hooks STDIN and STDOUT. Relevant C# code: http://pastebin.com/DWLaitnM

kchung · 2016-05-06 20:54:09

I realize the full source could be a little better: http://pastebin.com/gG3cV5Er

Perhaps the while loop polls the device in a way that keeps it alive?

iceman · 2016-05-06 21:05:08

Dont think so, it just spawns a process running the cli..
when u run "hw status" there is a line saying how fast the usb transfer is. What does it say?
Try it in CLI and GUI..

ntk · 2016-05-06 21:27:39

kchung wrote:

When I start the CLI interface I do so using the Go batch script provided which just calls "proxmark COM5". Should I be using the MinGW provided interface instead?

Hummm the way you ask about terminal raises concern, maybe that is the cause of the instability in your CLI env
I don't now how setting for the VM.

But, In window I use minGW too; after build && flash in the main directory (proxmark-master) If want to use GUI, I have already a shortcut link to the GUI tool inside the client directory.

If I use CLI, from the MinGW terminal I MUST have to go inside the client directory then fire up the proxmark.exe. In this way I am sure the only proxmark.exe runs is the one I just re-built, and it commiliton image just has been flashed into the board.

I am not sure but positive if tweaking around a little bit, I could run proxmark from "My documents" directory too... but which proxmark.exe ...

kchung · 2016-05-06 22:01:32

Here is the hw status output from the CLI: http://pastebin.com/370GC2Qn
Here is a picture of the hw status output from the GUI: http://i.imgur.com/fbG4jpl.png

You can see the failure of the first attempt in the CLI and you can also see the CLI in the background of the GUI screenshot.

kchung · 2016-05-06 22:06:43

Here is a screenshot showing multiple attempts of "lf hid fskdemod" before I receive any indication that the command has succeeded. In addition the LED on the PM3 does not turn on indicating that it is reading. http://imgur.com/sUDPfJW

Here is a screenshot showing me using the GUI and it running successfully and reading cards: http://i.imgur.com/bJRLOSz.png

To be clear, I am able to read cards in CLI mode but the command is so inconsistent that it becomes difficult to do the fskdemod and then the clone.

iceman · 2016-05-06 22:08:30

You are running on Aspers pre-compiled binaries.. ok.

And your transfer speed is the same for CLI & GUI.

Let me guess,
When you run the GUI you it together with the version you found.
and when you run CLI, you start i from the proxspace environment?

Can you make sure, that you run same client / fullimage from the latest source on GitHub and see if the error is still there?

kchung · 2016-05-06 22:11:54

I run the CLI from the folder where the Proxmark Tool is included (the unpackaged version of Aspers rar files). I do not run the CLI from Proxspace and Proxspace isn't even on this virtual machine.

Everything I just ran is from the 2.5.0 folder from Asper.

iceman · 2016-05-06 22:22:58

Since you on the pre-compiled binaries, I can't help you anymore.

kchung · 2016-05-07 03:55:27

I was able to successfully run the PM3 on a host computer running the drivers. My inclination is to say that it is a timing issue due to the serial driver. And I was able to successfully run the PM3 running an older firmware because of the reliability of the USB protocol.

I can only assume that the GUI added some sort of delay to make the timing line up properly or something similar.

https://cloud.githubusercontent.com/assets/166333/15089919/f7ba38b4-13dd-11e6-9567-a917acf69d92.PNG

iceman · 2016-05-07 07:38:55

You mean you went back and flashed the old HID-based firmware? Which revision did you revert back to?

kchung · 2016-05-07 15:34:02

I was using only what was provided by Asper in his precompiled firmware.

iceman · 2016-05-08 14:55:23

So you used the CDC version the whole time.

[edit]make post clearer

kchung · 2016-05-09 01:11:55

I don't understand what you're getting at. I already said in this thread that I've been using the firmware provided by Asper which is recent enough that it is the CDC version.

Of course I've been using it the whole time. I only said I wasn't using it when I was using a different proxmark with a different firmware awhile ago.

ntk · 2016-05-17 14:45:32

@Kchung

sometimes words is not enough, if you give more details by
- giving OS version
- using "hw version" to tell about firmware in the PM3
- take a picture of your hw configuration
- screenshot of the log when it failed due to instability

then it would be easier for iceman, who is very experienced and also a very supportive expert

Sorting bluescreen, instability, "deathwish" of PM3 (yes, PM3 could turn vegetative state too, just in a blink like that) is like doing homocide forensic work. Just saying "pls come, I see a man with an axe and lot of blood" is not enough, scientist must have all details much as possible at one point, then they can help, the last thing they want in their job is: Starting to guess.

I hope you know what I mean.

Last edited by ntk (2016-05-17 14:47:29)

Apt-Get · 2016-05-21 23:54:47

if you are trying to run a windows VM with the pm3v2 you will have issues.. dont bother. Its the way vm handles the usb.. Use your OSX dude its way better than windows unless you need graphs. but even then you can still run the GUI in your VM with no issues. but you are correct the CLI does not work.. its Fusion, not your PM3..

Follow the Wiki on OSX.. I recently updated it.

Last edited by Apt-Get (2016-05-22 00:07:46)

kchung · 2016-05-28 22:16:29

Thanks for the input Apt-Get, it's much appreciated.

So far I've just been using the GUI but I may run the PM3 in OSX if that proves to be too cumbersome.

Apt-Get · 2016-06-01 22:49:48

you need the CLI if you really want to work with tags.

Proxmark3 community

Announcement

#1 2016-05-05 02:13:11

Proxmark RDV2 sometimes unresponsive

#2 2016-05-05 07:40:33

Re: Proxmark RDV2 sometimes unresponsive

#3 2016-05-05 15:57:56

Re: Proxmark RDV2 sometimes unresponsive

#4 2016-05-05 16:59:54

Re: Proxmark RDV2 sometimes unresponsive

#5 2016-05-05 17:15:03

Re: Proxmark RDV2 sometimes unresponsive

#6 2016-05-05 17:28:55

Re: Proxmark RDV2 sometimes unresponsive

#7 2016-05-05 17:41:53

Re: Proxmark RDV2 sometimes unresponsive

#8 2016-05-06 02:56:22

Re: Proxmark RDV2 sometimes unresponsive

#9 2016-05-06 06:47:33

Re: Proxmark RDV2 sometimes unresponsive

#10 2016-05-06 18:21:34

Re: Proxmark RDV2 sometimes unresponsive

#11 2016-05-06 18:23:13

Re: Proxmark RDV2 sometimes unresponsive

#12 2016-05-06 18:25:51

Re: Proxmark RDV2 sometimes unresponsive

#13 2016-05-06 18:40:18

Re: Proxmark RDV2 sometimes unresponsive

#14 2016-05-06 18:41:40

Re: Proxmark RDV2 sometimes unresponsive

#15 2016-05-06 18:51:38

Re: Proxmark RDV2 sometimes unresponsive

#16 2016-05-06 18:57:54

Re: Proxmark RDV2 sometimes unresponsive

#17 2016-05-06 20:52:38

Re: Proxmark RDV2 sometimes unresponsive

#18 2016-05-06 20:54:09

Re: Proxmark RDV2 sometimes unresponsive

#19 2016-05-06 21:05:08

Re: Proxmark RDV2 sometimes unresponsive

#20 2016-05-06 21:27:39

Re: Proxmark RDV2 sometimes unresponsive

#21 2016-05-06 22:01:32

Re: Proxmark RDV2 sometimes unresponsive

#22 2016-05-06 22:06:43

Re: Proxmark RDV2 sometimes unresponsive

#23 2016-05-06 22:08:30

Re: Proxmark RDV2 sometimes unresponsive

#24 2016-05-06 22:11:54

Re: Proxmark RDV2 sometimes unresponsive

#25 2016-05-06 22:22:58

Re: Proxmark RDV2 sometimes unresponsive

#26 2016-05-07 03:55:27

Re: Proxmark RDV2 sometimes unresponsive

#27 2016-05-07 07:38:55

Re: Proxmark RDV2 sometimes unresponsive

#28 2016-05-07 15:34:02

Re: Proxmark RDV2 sometimes unresponsive

#29 2016-05-08 14:55:23

Re: Proxmark RDV2 sometimes unresponsive

#30 2016-05-09 01:11:55

Re: Proxmark RDV2 sometimes unresponsive

#31 2016-05-17 14:45:32

Re: Proxmark RDV2 sometimes unresponsive

#32 2016-05-21 23:54:47

Re: Proxmark RDV2 sometimes unresponsive

#33 2016-05-28 22:16:29

Re: Proxmark RDV2 sometimes unresponsive

#34 2016-06-01 22:49:48

Re: Proxmark RDV2 sometimes unresponsive

Board footer