How to identify different types of MIFARE Ultralight tags?
In document AN10834 Ultralight and Ultralight C differ by the answer from "Auth". What is this "Auth"? There is no description of this function in the datasheets to the chips.
I noticed that Ultralight C and EV1 support GET_VERSION (60h), I sent this request to EV1 card, it does not return anything to me.
In order to distinguish MIFARE Ultralight, Ultralight C, Ultralight EV1, and NTAG tags, you would first send a GET_VERSION command:
> 60
If this command succeeds, you know that the tag is an EV1 (or later) tag (e.g. MIFARE Ultralight EV1 or NTAG21x). You can, thus, narrow down the specific tag type by analyzing the resonse to the GET_VERSION command. This will reveal the product type (NTAG or Ultralight EV1) as well as product subtype, product version and storage size (which allows you to determine the exact chip type). See Distinguish NTAG213 from MF0ICU2 for a list of example product identification values.
If the GET_VERSION command fails, you can assume that it is a first generation tag (MIFARE Ultralight, Ultralight C, NTAG203). You can, thus, narrow down the specific tag type by sending an AUTHENTICATE (part 1) command:
> 1A 00
If this command succeeds, you know that the tag is MIFARE Ultralight C.
If this command fails, you can assume that the tag is either Ultralight or NTAG203. In order to distinguish between MIFARE Ultralight and NTAG203, you can try to read pages that do not exist on Ultralight (e.g. read page 41):
> 30 29
Related
The Botan crypto library has only a very limited support for the X.509 extension CRLDistributionPoint and actually throws an exception, if any of the "advanced" attributes of the extension are set which are not expected by Botan.
Hence, I try to patch the decoding of this extension, but I have a problem to correctly determine the type of the encoded objects based on the tags. Either this is an oversight in the specification for this extension (I doubt it) or I am subject to a fundamental misunderstanding of the encoding/decoding rules.
Here are the relevant parts of the specification
CertificateExtensions {joint-iso-itu-t ds(5) module(1)
certificateExtensions(26) 5} DEFINITIONS IMPLICIT TAGS
CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
DistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
reasons [1] ReasonFlags OPTIONAL,
cRLIssuer [2] GeneralNames OPTIONAL
}
DistributionPointName ::= CHOICE {
fullName [0] GeneralNames,
nameRelativeToCRLIssuer [1] RelativeDistinguishedName
}
The modules uses implicit tagging by default. In the following this will be important. A DistributionPoint is a SEQUENCE where all attributes are optional. The first optional attribute distributionPoint has the type tag 0 and is of type DistributionPointName. In turn, DistributionPointName is a CHOICE with possible choices which are either tag 0 (if GeneralNames is chosen) or tag 1 (if RelativeDistinguishedName is chosen).
According to my understanding, in case of implicit tagging a CHOICE type is encoded using the tag of the chosen type. In other words, a CHOICE type is not "nested" somehow but encoded on the same level on which the CHOICE type is used. But DistributionPointName has already been given the tag 0.
The specific question is: How is a DistributionPoint encoded, if nameRelativeToCRLIssuer (tag 1) is chosen as the choice for DistributionPointName without triggering a clash with tag 1 of the reasons attribute?
Here is an illustration of my problem:
30 // Type tag for outer SEQUENCE, DistributionPoint starts here
ll // Length of SEQUENCE, omitted here for editorial purposes
+--> 00 vs 01 // Type tag for distributionPoint
| // At first glance, 00 according to SEQUENCE definition for OPTIONAL DistributionPointName,
| // but maybe 01 if RelativeDistinguishedName is the selected CHOICE
| kk // Length of RelativeDistinguishedName, omitted here for editorial purposes
| vv // Encoding of RelativeDistinguishedName begins
| vv
| vv // Encoding of RelativeDistinguishedName ends, accordingly to length kk
+--> 01 // Type tag for OPTIONAL ReasonsFlags
jj // Length of ReasonsFlags
ww // Encoding of ReasonsFlags begins
ww
ww // Encoding of ReasonsFlags ends, accordingly to length jj
// Encoding of DistributionPoint ends, too, accordingly to length ll
In line three, the type tag should be 00 to indicate that the OPTIONAL DistributionPointName exists. This also avoids a clash with the type tag 01 in line 8 for the OPTIONAL ReasonFlags.
However, in line three, the type tag should also indicate which type has been chosen for DistributionPointName. :-(
According to my understanding, in case of implicit tagging a CHOICE
type is encoded using the tag of the chosen type. In other words, a
CHOICE type is not "nested" somehow but encoded on the same level on
which the CHOICE type is used. But DistributionPointName has already
been given the tag 0.
I'm afraid this is the opposite: CHOICE tagging is always explicit whatever the default tagging ...
In the X.680 document, there is following note
The tagging construction specifies explicit tagging if any of the following holds:
c) the "Tag Type" alternative is used and the value of "TagDefault" for
the module is IMPLICIT TAGS or AUTOMATIC TAGS, but the type defined by
"Type" is an untagged choice type, an untagged open type, or an
untagged "DummyReference" (see Rec. ITU-T X.683 | ISO/IEC 8824-4,
8.3).
So, if RelativeDistinguishedName is chosen, distributionPoint component tagging will be 0 (distributionPoint) and then 1 (RelativeDistinguishedName)
The reason for this is that CHOICE does not have a UNIVERSAL tag
I try to display a message that contains the number inserted in the question, for example when user inserts a number of 12 digits I want to display that 12 digits and a text.
Until now:
I created an Entity with pattern (/d{12}) named #ticket_number
An Intent named #myTicket that has as example #ticket_number
Dialog that triggers when #myTicket | #ticket_number and has on context TicketNumer "<?#ticket_number.literal?>" and display a message as follows "Do you want to get info for ticket $ticketnumber ?".
The problem is that when I try it the Intent result is irrelevant, the message looks ok but I need to match the Intent. What could I do?
Can you share a picture of your node? There is no need that you match the intent; as indicating the ticket number alone, should not be an intent itself, but the entity. I'd remove the #myTicket | part of the node. And the condition should not include an OR; otherwise, if #myTicket triggers the node, and there is no ticket number, the response would fail.
As mentioned in the IBM documentation
it is not yet possible to use pattern entity in Intents.
Currently, you can only directly reference synonym entities that you
define (pattern values are ignored). You cannot use system entities.
I am developing embedded firmware to communicate with the Multi-Tech's MTSMC-H5 GPRS Modem. I am unclear the use of AT+CGDCONT command. In the H5 modem's Reference Guide, it states the command format is
>AT+CGDCONT=[<cid>[,<PDP_type>[,<APN>[,<PDP_addr>[,<d_comp>
>[,<h_comp>[,<pd1>[,…[,pdN]]]]]]]]]
>...
><APN> Access Point Name. String parameter that is a logical name used to select the
>GGSN or the external packet data network. If the value is empty (“”) or omitted,
>3GPP TS 27.007 AT COMMANDS then the subscription value is requested.
>...
What effect would that be if I leave the APN field blank? It seems I can connect to the cell network while leaving the APN field blank. I tried several SIM cards and they all seem to work without specifying the APN field. However, I'd like to know for sure that what I do is appropriate. Because I have very limited UI capability (no real keypad on the device that the modem is attached to), it is highly desirable if an end user does not have to enter any APN information.
The APN was probably stored on the SIMs that you used. In most cases, it will be OK as you found out. There are a few edge cases where you might run into problems, such as an APN changing (rare), or arrangements between individual operators, or between operators and certain customers.
Even these cases can be mitigated by some operators as they automatically correct a wrong APN (APN redirection).
Note that this is not behaviour that is mandatory under the 3GPP standards, so it may vary from operator to operator.
I'm developing a system including NFC tags and Android phone , using unique ID of NFC tags .
But don't know what is the differences between 4 types NFC tag .
I've found this :
"NFC-compatible tags can be of the following technologies/standards
and each of them has a different notion of ID:
NFC Tag1 : Topaz/Jewel
NFC Tag2 : Mifare UL (ISO14443A-3)
NFC Tag3 : JIS X 6319-4 (FeliCa)
NFC Tag4 : ISO14443-4A or ISO14443-4B tag
There is also an unofficial support of the Mifare Classic cards as NFC tags.
And each of them define some identification number.
Topaz/jewel has a 4-byte ID
Mifare UL has a 7-byte UID
Mifare Classic has a 4 or 7-byte UID
FeliCa has a 8-byte ID
ISO14443-4A has a 4, 7 or 11-byte UID
ISO14443-4B has a 4-byte PUPI
Do some tests with nfc-list, you'll see what comes out depending on the used tag.
And for code, see code of nfc-list.c how IDs are retrieved and displayed."
Is that true and is thera anything else ?
Can you help me ?
Read more about nfc tags with these links.
http://www.nfc.cc/technology/nfc-tag-types/
http://www.radio-electronics.com/info/wireless/nfc/near-field-communications-tags-types.php
Type 1: Tag is based on ISO/IEC 14443A. This tag type is read
and re-write capable. The memory of the tags can be write protected.
Memory size can be between 96 bytes and 2 Kbytes. Communication Speed
with the tag is 106 kbit/sec. Example: Innovision Topaz
Type 2: Tag is based on ISO/IEC 14443A. This tag type is read and
re-write capable. The memory of the tags can be write protected.
Memory size can be between 48 bytes and 2 Kbytes. Communication Speed
with the tag is 106 kbit/sec. Example: NXP Mifare Ultralight, NXP
Mifare Ultralight
Type 3: Tag is based on the Japanese Industrial Standard (JIS) X
6319-4. This tag type is pre-configured at manufacture to be either
read and re-writable, or read-only. Memory size can be up to 1 Mbyte.
Communication Speed with the tag is 212 kbit/sec. Example: Sony Felica
Type 4: is fully compatible with the ISO/IEC 14443 (A \& B) standard
series. This tag type is pre-configured at manufacture to be either
read and re-writable, or read-only. Memory size can be up to 32
KBytes; For the communication with tags APDUs according to ISO 7816-4
can be used. Communication speed with the tag is 106 kbit/sec.
Example: NXP DESfire, NXP SmartMX with JCOP.)
Further more information about UID tag size and other specification details are contain with this link.
https://www.tagnfc.com/en/info/11-nfc-tags-specs
Just some bits for your consideration:
Topaz / Juwel tags from Broadcom (previously Innovision) are getting very to hard to find. It seems Broadcom is no longer supporting them.
The Mifare Classic are not included in the NFC standard. Devices with the protocol stack from NXP (all up to Android 4.1x) do support them anyway, so they are popular, because of their large memory. But since Android 4.2 (e.g. Nexus 4 or Nexus 10) the NFC stack is from Broadcom and the Mifare classic ist not supported anymore.
Felica tags are often hard to find.
So the safe route are tags with Mifare UL or NXP Ntag chips.
http://developers.facebook.com/docs/internationalization/ says "Facebook locales follow ISO language and country codes respectively, concatenated by an underscore.".
So would it accept "en" or is it mandatory to include "en-us" "en-gb" etc?
(I have some auto-detected languages where only the language, not the region, is known.)
Yes, you must use the ll_CC format. If you can't figure out which region the language belongs to, you can make an educated guess. See what regions are avaiable for that language by taking a look at the Translation XML file. You can even parse this at run-time if that works for your application.