Poor reception/transmission

[derfloh]

I've been playing around with my Hotel Door (seems to be a Messerschmitt Classic 3 in the mifare version) and after countless hours of wondering what magic cards Messerschmitt is using, because the cards are identifying as MF Ultralight, but the Chameleon can't sniff anything or when emulating a MF Ultralight I didn't even see read requests....

It took me quite a while to notice, that I have to hold the Chameleon in a very specific angle in a very specific distance to get some data with sniffing. In emulation mode I saw some traffic, but in 30 minutes waving the Chameleon in various speeds, angles, directions&distances at the door, I managed to open it only once (so I know it does work... but not reproducible).

I also noticed that when I use my usb dongle (scl3711) I have to be careful with the Chameleon as well. It mustn't be too close, or it would not be recognized. And it happens quite often, that a "nfc-list" lists 2 (identical) tags.

So, as the noob I am... I'm wondering if

• That's an issue "by design"? (Laws of Physics are a b*tch?)
• My device is faulty?
• The readers are stupid?

And if that can be improved somehow? (There's a u-fl-r-smt connector.. can it be used out-of-the-box?)

[aleksil]

I can confirm having the same issues. Using the Mifare Classic Toolkit on my phone (Sony Xperia Z5) I can sometimes read the emulated mifare classic card, but most of the time i just get an infinite loop of "tag lost/new tag" sounds. Sometimes it will read some sectors, but randomly fail to read others.

Proper card readers that only check the UID usually work. Readers that authenticate with the card and read contents have never worked for me.

[david-oswald]

We've actually tested full card readouts both with several phones and different types of readers and tried to optimize it as much as possible - including the SCL3711. Do you have a look to determine at which step it fails?

[derfloh]

So, I don't have any problems with the card if I place it correctly (For example I noticed that it works great if i place the 'empty dummy end' of the chameleon directly on the SCL3711, so that the coil is next to the dongle... if i place the middle of the coil/chameleon on the dongle it doesn't work at all)

So, although it's not like with real Tags that I can drop on the dongle in any position as I want, it's ok for me in that use case.
For "real" use cases, like the hotel door it's simply not acceptable (in the sense of I don't want to do it.. not in the blaming sense ;) ) to have to figure out how to place the chameleon to get a result.

I'll check it later, but what I remember from yesterday was the following:

1. 05976 ms < +5976 ms>:CODEC RX (1 bytes) [26]
2. 05976 ms < +0 ms>:GENERIC (0 bytes) []
3. 05976 ms < +0 ms>:CODEC TX (2 bytes) [4400]
4. 05976 ms < +0 ms>:CODEC RX (2 bytes) [9320]
5. 05976 ms < +0 ms>:GENERIC (0 bytes) []
6. ....

If I placed the chameleon correctly, I see the "26" arriving and transmission of the 4400.. Then purely based on luck (or if my hand holding the chameleon hasn't shaken too much) I'll receive the 9320..
Sometimes it goes a couple of steps further but often communication breaks during the first steps..

Could it be that the Door reader (which is battery powered..) is simply "not strong enough"? (Which is probably a stupid question, because there should be specificiations for that in the ISO I guess...?)

Edit: In case you're wondering why that "Generic" shows up in my logs - I've added a LogEntry at the beginning of MifareUltralightAppProcess as first step in seeing what happens where

[derfloh]

As a follow up to my observations with a SCL3711:

I've "destroyed" my Ultralight Application by putting the following at the start of MifareUltralightAppProcess:

    uint16_t alevel = AntennaLevelGet();
    LogEntry(LOG_INFO_GENERIC,&alevel,sizeof(uint16_t));

    Buffer[0] = NAK_INVALID_ARG;
    return NAK_FRAME_SIZE;

And then started to watch the live logs when I issue a nfc-list on the SCL3711:

20042 ms <+20042 ms>:CODEC RX (1 bytes) [26]
20042 ms < +0 ms>:GENERIC (2 bytes) [RSSI (1957,)]
20042 ms < +0 ms>:CODEC TX (1 bytes) [00]
20043 ms < +1 ms>:CODEC RX (1 bytes) [26]
20043 ms < +0 ms>:GENERIC (2 bytes) [RSSI (1992,)]
20043 ms < +0 ms>:CODEC TX (1 bytes) [00]
20043 ms < +0 ms>:CODEC RX (1 bytes) [26]
20043 ms < +0 ms>:GENERIC (2 bytes) [RSSI (2062,)]
20043 ms < +0 ms>:CODEC TX (1 bytes) [00]

This is pretty much expected... The chameleon was held with it's center ~5cm above the dongle.

If I move the chameleon closer (the following log was from ~1cm) i get surprising results:

19236 ms <+19236 ms>:CODEC RX (1 bytes) [85]
19236 ms < +0 ms>:GENERIC (2 bytes) [RSSI (6539,)]
19237 ms < +1 ms>:CODEC TX (1 bytes) [00]
19241 ms < +4 ms>:CODEC RX (1 bytes) [85]
19241 ms < +0 ms>:GENERIC (2 bytes) [RSSI (6656,)]
19241 ms < +0 ms>:CODEC TX (1 bytes) [00]
19245 ms < +4 ms>:CODEC RX (1 bytes) [85]
19245 ms < +0 ms>:GENERIC (2 bytes) [RSSI (6492,)]
19245 ms < +0 ms>:CODEC TX (1 bytes) [00]

(I occasionally also see the 'normal 3 times 0x26 blocks' at that distance)

And I've also seen stuff like this:

46233 ms <+46233 ms>:CODEC RX (2 bytes) [9f21]
46233 ms < +0 ms>:GENERIC (2 bytes) [RSSI (2742,)]
46233 ms < +0 ms>:CODEC TX (1 bytes) [00]
46237 ms < +4 ms>:CODEC RX (2 bytes) [3314]
46237 ms < +0 ms>:GENERIC (2 bytes) [RSSI (2707,)]
46237 ms < +0 ms>:CODEC TX (1 bytes) [00]
46242 ms < +5 ms>:CODEC RX (2 bytes) [3502]
46242 ms < +0 ms>:GENERIC (2 bytes) [RSSI (2941,)]
46242 ms < +0 ms>:CODEC TX (1 bytes) [00]

But that's not very common (I would simply ignore it..)
The "0x85 instead of 0x26" is easily reproducible though.

Any clues where to dive into?

Edit: Ofc I wouldn't have to "destroy" my Ultralight for that... The Card in Sniffer mode would have been enough (I've just checked it and basically got the same results)... I just didn't think of that possibility ;)

[david-oswald]

Thanks for the data. There is some tradeoffs between good reading range and emulation range in the Chameleon, which Timo can better explain, so he'll get back.

[doegox]

@derfloh about the emulation problem with the hotel door you mentioned initially, you may check if it gets better now that the fix for issue #46 has been merged.

[derfloh]

@doegox I haven't tried the new firmware yet, but on Sunday I had a try with one where I merged your PR for #46 . The result was the same, since communication either breaks at REQA or SELECT for me, so HALT isn't an issue there :(

[twiddern]

Is it now working @derfloh? With #ea9938b a new firmware was released which seems to be working much better :) See also #83

[derfloh]

@twiddern I couldn't test it yet, since I'm not booking that hotel anymore. At the one where I'm now usually staying the chameleon is working ;)

[geo-rg]

@derfloh Do you think your problem is solved or should we leave this issue open?