Proxmark3 community

Research, development and trades concerning the powerful Proxmark3 device.

Remember; sharing is caring. Bring something back to the community.


"Learn the tools of the trade the hard way." +Fravia

You are not logged in.

Announcement

Time changes and with it the technology
Proxmark3 @ discord

Users of this forum, please be aware that information stored on this site is not private.

#1 2020-07-14 17:13:09

Rosco
Contributor
Registered: 2019-12-10
Posts: 43

Problem with blueshark BT add-on in LF mode

Hello,

My Proxmark is a PM3-RDV4. I have a problem with the blueshark bluetooth add-on. I did a git pull today (14/07/2020) so the source tree is up to date, recompiled everything (make clean then make all) with PLATFORM_EXTRAS=BTADDON uncommented in Makefile.platform, then pm3-flash-all. No error, no issues, everything works fine with the USB cable (/dev/ttyACM0).

When I connect through bluetooth however (/dev/rfcomm0), things seem to work well with any command that doesn't transfer tons of data (hw tune, hf search...) but I get many error messages with commands that do - typically lf commands:

[fpc] pm3 --> [#] Error in frame reception: -8 PM3_EIO
[!] ⚠️  Received packet frame without postamble
[!] ⚠️  Received packet frame preamble too short: 1/10
[!] ⚠️  Received packet OLD frame with payload too short? 39/534
[!] ⚠️  Received packet OLD frame with payload too short? 31/534

[fpc] pm3 --> lf search

[!] ⚠️  Received packet OLD frame with payload too short? 234/534
[!] ⚠️  Received packet OLD frame with payload too short? 117/534
[!] ⚠️  Received packet OLD frame with payload too short? 117/534
[!] ⚠️  Received packet OLD frame with payload too short? 117/534
[!] ⚠️  Received packet OLD frame with payload too short? 117/534
[!] ⚠️  Received packet OLD frame with payload too short? 117/534
[!] ⚠️  Received packet OLD frame with payload too short? 244/534
[!] ⚠️  Received packet OLD frame with payload too short? 117/534
[=] Waiting for a response from the Proxmark3...
[=] You can cancel this operation by pressing the pm3 button
[!] ⚠️  Received packet OLD frame with payload too short? 117/534
[!] ⚠️  Received packet OLD frame with payload too short? 117/534
[!] ⚠️  Received packet OLD frame with payload too short? 117/534
[!] ⚠️  Received packet OLD frame with payload too short? 244/534
[!] ⚠️  Received packet OLD frame with payload too short? 244/534
[!] ⚠️  Received packet OLD frame with payload too short? 117/534
[!] ⚠️  Received packet OLD frame with payload too short? 130/534
[-] ⛔ Timed out while trying to download data from device
[!] ⚠️  timeout while waiting for reply.
[-] ⛔ Data in Graphbuffer was too small.

Any idea what I'm doing wrong?

Last edited by Rosco (2020-07-14 17:14:24)

Offline

#2 2020-07-14 18:07:35

iceman
Administrator
Registered: 2013-04-25
Posts: 9,538
Website

Re: Problem with blueshark BT add-on in LF mode

Its changes in stack/bigbuff that is causing it to mess up.
Try the release instead,  it should be good.

Checkout or copy the zip.
https://github.com/RfidResearchGroup/pr … ag/v4.9237

Offline

#3 2020-07-14 18:53:12

Rosco
Contributor
Registered: 2019-12-10
Posts: 43

Re: Problem with blueshark BT add-on in LF mode

Damn... That's a bit of a setback.

Anyhow, no joy:

[ CLIENT ]
  client: RRG/Iceman/HEAD/v4.9237 2020-07-14 20:39:48
  compiled with GCC 7.5.0 OS:Linux ARCH:x86_64

[ PROXMARK3 RDV4 ]
  external flash:                  present
  smartcard reader:                present

[ PROXMARK3 RDV4 Extras ]
  FPC USART for BT add-on support: present

[ ARM ]
  bootrom: RRG/Iceman/HEAD/v4.9237 2020-07-14 20:41:30
       os: RRG/Iceman/HEAD/v4.9237 2020-07-14 20:41:53
  compiled with GCC 6.3.1 20170620

[ FPGA ]
  LF image built for 2s30vq100 on 2020-02-22 at 12:51:14
  HF image built for 2s30vq100 on 2020-01-12 at 15:31:16

[ Hardware ]
  --= uC: AT91SAM7S512 Rev A
  --= Embedded Processor: ARM7TDMI
  --= Nonvolatile Program Memory Size: 512K bytes, Used: 292479 bytes (56%) Free: 231809 bytes (44%)
  --= Second Nonvolatile Program Memory Size: None
  --= Internal SRAM Size: 64K bytes
  --= Architecture Identifier: AT91SAM7Sxx Series
  --= Nonvolatile Program Memory Type: Embedded Flash Memory


#db# Error in frame reception: -8 PM3_EIO
[!] ⚠️  Received packet OLD frame with payload too short? 0/534
[!] ⚠️  Received packet frame preamble too short: 1/10
[!] ⚠️  Received packet OLD frame with payload too short? 32/534

I think I'll just stick to the master and use BT only for HF stuff. I actually need the latest FDX-B changes - I was hoping to use the Proxmark wirelessly to scan hard-to-read Destron Fearing implants but... looks like it ain't gonna happen.

Offline

#4 2020-07-14 19:26:41

Rosco
Contributor
Registered: 2019-12-10
Posts: 43

Re: Problem with blueshark BT add-on in LF mode

Meh.. Actually it gives errors all the time, not just in LF mode.

Blueshark sadly goes to the drawer sad

Last edited by Rosco (2020-07-14 19:26:55)

Offline

#5 2020-07-14 19:40:10

iceman
Administrator
Registered: 2013-04-25
Posts: 9,538
Website

Re: Problem with blueshark BT add-on in LF mode

Let me see that output from

hw status

And are you using the white dongle?  or builtin BT?
Did you configure the speed correct for the com port?

https://github.com/RfidResearchGroup/pr … ther-notes

Offline

#6 2020-07-15 01:20:08

Rosco
Contributor
Registered: 2019-12-10
Posts: 43

Re: Problem with blueshark BT add-on in LF mode

iceman wrote:

And are you using the white dongle?  or builtin BT?
Did you configure the speed correct for the com port?

I use my laptop's builtin BT.
I did set the baudrate - although I didn't think I'd have to do it manually. Doesn't the client set it when it opens the device?

$ stty -F /dev/rfcomm0 115200 cs8 -cstopb -parenb raw -echo -echoe -echok
$ stty -F /dev/rfcomm0
speed 115200 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel
-opost
-isig -icanon -echo -echoe -echok
iceman wrote:

Let me see that output from

hw status

Here's the entire log. I start the client and do nothing, then errors come in at random. But it works in-between the errors. It's almost as if the "line" was noisy and spurrious data was coming through. It's the same with the bleeding edge code as with v4.9237 incidentally:

$ proxmark3 /dev/rfcomm0
[=] Session log /home/ppc/.proxmark3/logs/log_20200715.txt
[+] loaded from JSON file /home/ppc/.proxmark3/preferences.json
[=] Using UART port /dev/rfcomm0
[=] Communicating with PM3 over FPC UART
[=] PM3 UART serial baudrate: 115200



  ██████╗ ███╗   ███╗█████╗ 
  ██╔══██╗████╗ ████║╚═══██╗
  ██████╔╝██╔████╔██║ ████╔╝
  ██╔═══╝ ██║╚██╔╝██║ ╚══██╗
  ██║     ██║ ╚═╝ ██║█████╔╝     ❄️  iceman@icesql.net
  ╚═╝     ╚═╝     ╚═╝╚════╝    bleeding edge ☕

  https://github.com/rfidresearchgroup/proxmark3/


 [ Proxmark3 RFID instrument ]

 [ CLIENT ]
  client: RRG/Iceman/master/v4.9237-607-g3a39a9b6-dirty-unclean 2020-07-14 18:34:52
  compiled with GCC 7.5.0 OS:Linux ARCH:x86_64

 [ PROXMARK3 RDV4 ]
  external flash:                  present
  smartcard reader:                present

 [ PROXMARK3 RDV4 Extras ]
  FPC USART for BT add-on support: present

 [ ARM ]
  bootrom: RRG/Iceman/master/v4.9237-607-g3a39a9b6-dirty-unclean 2020-07-14 18:35:49
       os: RRG/Iceman/master/v4.9237-607-g3a39a9b6-dirty-unclean 2020-07-14 18:36:21
  compiled with GCC 6.3.1 20170620

 [ FPGA ]
  LF image built for 2s30vq100 on 2020-02-22 at 12:51:14
  HF image built for 2s30vq100 on 2020-01-12 at 15:31:16

 [ Hardware ]
  --= uC: AT91SAM7S512 Rev A
  --= Embedded Processor: ARM7TDMI
  --= Nonvolatile Program Memory Size: 512K bytes, Used: 263136 bytes (50%) Free: 261152 bytes (50%)
  --= Second Nonvolatile Program Memory Size: None
  --= Internal SRAM Size: 64K bytes
  --= Architecture Identifier: AT91SAM7Sxx Series
  --= Nonvolatile Program Memory Type: Embedded Flash Memory


[fpc] pm3 --> [!] ⚠️  Received packet frame preamble too short: 1/10
[!] ⚠️  Received packet OLD frame with payload too short? 0/534
[!] ⚠️  Received packet OLD frame with payload too short? 35/534
[!] ⚠️  Received packet frame without postamble
hw status
[#] Memory
[#]   BigBuf_size.............39976
[#]   Available memory........39920
[#] Tracing
[#]   tracing ................1
[#]   traceLen ...............0
[#] Current FPGA image
[#]   mode.................... HF image built for 2s30vq100 on 2020-01-12 at 15:31:16
[#] Flash memory
[#]   Baudrate................24 MHz
[#]   Init....................OK
[#]   Memory size.............2 mbits / 256 kb
[#]   Unique ID...............0xD5690C23DF07772A
[#] Smart card module (ISO 7816)
[#]   version.................v3.10
[#] 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 Sampling Stack
[#]   Max stack usage.........4096 / 8480 bytes
[#] 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 |N/A | N/A | N/A | N/A | N/A | N/A | N/A | 
[#]               leading zero |N/A | N/A | N/A | N/A | N/A | N/A | N/A | 
[#]    1 of 4 coding reference |N/A | N/A | N/A | N/A | N/A | N/A | N/A | 
[#] 
[#] Transfer Speed
[#]   Sending packets to client...
[#]   Time elapsed............544ms
[#]   Bytes transferred.......6144
[#]   Transfer Speed PM3 -> Client = 11294 bytes/s
[#] Various
[#]   Max stack usage.........4096 / 8480 bytes
[#]   DBGLEVEL................1
[#]   ToSendMax...............-1
[#]   ToSendBit...............0
[#]   ToSend BUFFERSIZE.......2308
[#]   Slow clock..............32653 Hz
[#] Installed StandAlone Mode
[#]   HF - Reading Visa cards & Emulating a Visa MSD Transaction(ISO14443) - (Salvador Mendoza)
[#] Flash memory dictionary loaded

Last edited by Rosco (2020-07-15 01:40:19)

Offline

#7 2020-07-15 01:31:30

Rosco
Contributor
Registered: 2019-12-10
Posts: 43

Re: Problem with blueshark BT add-on in LF mode

Quick update: I'm doing some tests - binding and releasing rfcomm0 while leaving the client running, then reconnecting within the client, and I'm seeing the client getting backlogged data from the previous connection after reconnecting.

Like for instance I try to read an EM tag. It fails. I release rfcomm0, bind it again, connect the client with "hw connect p /dev/rfcomm0" then do a "lf search" and it reports the EM that's not on the Proxmark anymore.

Not sure if that helps.

Quick update #2: if I start the client and wait long enough for all the errors to go through - i.e. flush the buffer essentially - then it works perfectly afterwards.

Last edited by Rosco (2020-07-15 01:54:54)

Offline

#8 2020-07-15 02:26:23

Rosco
Contributor
Registered: 2019-12-10
Posts: 43

Re: Problem with blueshark BT add-on in LF mode

Oh God... Nevermind, I found the problem: the stupid modem manager process was messing with the connection.

Strange, I was 200% certain I had uninstalled that damn thing a long time ago - if only to avoid bricking my Proxmark when flashing it. So it's come back to haunt me.

Anyway, unless I'm claiming victory too early, it looks like the problem is solved.

Sorry for the trouble man. Thank you for your help!

Offline

#9 2020-07-15 09:56:49

iceman
Administrator
Registered: 2013-04-25
Posts: 9,538
Website

Re: Problem with blueshark BT add-on in LF mode

I was a bit worried there.  We gotten most bugs out of the FPC comms,  its just a very slow connection.  115200 baud vs 4-6mbits over usb.

You got luckily you didint brick your Proxmark3 if the modemmanager was spooking around,  well if it did you would have found out much earlier...  The better of two evils?

Offline

#10 2020-07-15 14:55:16

Rosco
Contributor
Registered: 2019-12-10
Posts: 43

Re: Problem with blueshark BT add-on in LF mode

Lucky yes, but not blind luck either: I always check that /dev/ttyACM0 is up and no process name containing "modem" is running before flashing my PM3. But yeah, if it was there, it could've happened.

Apparently, it was only called by the bluetooth manager. And from what I can work out, the deb package got reinstalled as a dependency when I switched bluetooth manager a few weeks ago.

What a scourge. Who the hell uses a modem in 2020? Gee...

Offline

Board footer

Powered by FluxBB