get_ax25_name() is *NOT* the right routine to use to translate a

human-readable representing an AX.25 subaddress (e.g. "KA9Q-01") into
the binary form of an AX.25 address, because what it does is translate
the binary form of an AX.25 address to the human-readable form!

We currently have no routine that does the right thing and, even if we
did, given that some bits in the AX.25 subaddress format are used for
purposes other than representing the call sign and substation ID, so the
matching routines for AX.25 addresses need to ignore certain bits.

For now, we just remove the call to get_ax25_name() (which squelches the
pointer-signedness warning that made me look at this code, and find the
problem, in the first place) and replace it with a comment discussing
the problem and a failure.

The other pointer-signedness warning brought up a question of what to do
with G_REGEX_RAW in the g_regex_match_full() call; it didn't bring up an
immediately obvious *answer*, so we throw a cast at the warning and add
another comment.  (We fix up alignment while we're at it.)

svn path=/trunk/; revision=50106

diff --git a/epan/ftypes/ftype-bytes.c b/epan/ftypes/ftype-bytes.c
index 9a0bd552db6f3e5ebb9a5b402f4923b4dfe90e0c..5e7b558ec9051eccc70b2a958d1e3b37a7c52c3d 100644 (file)
--- a/epan/ftypes/ftype-bytes.c
+++ b/epan/ftypes/ftype-bytes.c
@@ -217,8 +217,6 @@ bytes_from_unparsed(fvalue_t *fv, char *s, gboolean allow_partial_value _U_, Log
 static gboolean
 ax25_from_unparsed(fvalue_t *fv, char *s, gboolean allow_partial_value, LogFunc logfunc)
 {
-       gchar   *mac;
-
        /*
         * Don't log a message if this fails; we'll try looking it
         * up as another way if it does, and if that fails,
@@ -239,15 +237,39 @@ ax25_from_unparsed(fvalue_t *fv, char *s, gboolean allow_partial_value, LogFunc
                return TRUE;
        }
 
-       mac = get_ax25_name(s);
-       if (!mac) {
-               logfunc("\"%s\" is not a valid AX.25 address.",
-                   s);
-               return FALSE;
-       }
-
-       ax25_fvalue_set(fv, mac, FALSE);
-       return TRUE;
+       /*
+        * XXX - what needs to be done here is something such as:
+        *
+        * Look for a "-" in the string.
+        *
+        * If we find it, make sure that there are 1-6 alphanumeric
+        * ASCII characters before it, and that there are 2 decimal
+        * digits after it, from 00 to 15; if we don't find it, make
+        * sure that there are 1-6 alphanumeric ASCII characters
+        * in the string.
+        *
+        * If so, make the first 6 octets of the address the ASCII
+        * characters, with lower-case letters mapped to upper-case
+        * letters, shifted left by 1 bit, padded to 6 octets with
+        * spaces, also shifted left by 1 bit, and, if we found a
+        * "-", convert what's after it to a number and make the 7th
+        * octet the number, shifted left by 1 bit, otherwise make the
+        * 7th octet zero.
+        *
+        * We should also change all the comparison functions for
+        * AX.25 addresses check the upper 7 bits of all but the last
+        * octet of the address, ignoring the "end of address" bit,
+        * and compare only the 4 bits above the low-order bit for
+        * the last octet, ignoring the "end of address" bit and
+        * various reserved bits and bits used for other purposes.
+        *
+        * See section 3.12 "Address-Field Encoding" of the AX.25
+        * spec and
+        *
+        *      http://www.itu.int/ITU-R/terrestrial/docs/fixedmobile/fxm-art19-sec3.pdf
+        */
+       logfunc("\"%s\" is not a valid AX.25 address.", s);
+       return FALSE;
 }
 
 static gboolean
@@ -485,12 +507,36 @@ cmp_matches(const fvalue_t *fv_a, const fvalue_t *fv_b)
        if (! regex) {
                return FALSE;
        }
+       /*
+        * XXX - do we want G_REGEX_RAW or not?
+        *
+        * If we're matching against a string, we don't want it (and
+        * we want the string value encoded in UTF-8 - and, if it can't
+        * be converted to UTF-8, because it's in a character encoding
+        * that doesn't map every possible byte sequence to Unicode (and
+        * that includes strings that are supposed to be in UTF-8 but
+        * that contain invalid UTF-8 sequences!), treat the match as
+        * failing.
+        *
+        * If we're matching against binary data, and matching a binary
+        * pattern (e.g. "0xfa, 3 or more 0xff, and 0x37, in order"),
+        * we'd want G_REGEX_RAW. If we're matching a text pattern,
+        * it's not clear *what* the right thing to do is - if they're
+        * matching against a pattern containing non-ASCII characters,
+        * they might want it to match in whatever encoding the binary
+        * data is, but Wireshark might not have a clue what that
+        * encoding is.  In addition, it's not clear how to tell
+        * whether a pattern is "binary" or not, short of having
+        * a different (non-PCRE) syntax for binary patterns.
+        *
+        * So we don't use G_REGEX_RAW for now.
+        */
        return g_regex_match_full(
                regex,                  /* Compiled PCRE */
-               a->data,                /* The data to check for the pattern... */
-               (int)a->len,    /* ... and its length */
-               0,                              /* Start offset within data */
-               (GRegexMatchFlags)0,                            /* GRegexMatchFlags */
+               (char *)a->data,        /* The data to check for the pattern... */
+               (int)a->len,            /* ... and its length */
+               0,                      /* Start offset within data */
+               (GRegexMatchFlags)0,    /* GRegexMatchFlags */
                NULL,                   /* We are not interested in the match information */
                NULL                    /* We don't want error information */
                );