Wireshark ax25 dissector

Wireshark ax25 dissector

[Dennis Boone]

Folks,

I'm having trouble getting Wireshark's ax25 dissector to process
callsign filters properly.  I can't get _anything_ to match.  I've tried
expressions like:

    ax25.src ~ "KB8ZQZ"
    ax25.src ~ "KB8ZQZ-0"
    ax25.src ~ KB8ZQZ
    ax25.src ~ KB8ZQZ-0

and the equivalents with ax25.dst.  I've tried various callsigns which
are in the capture file I'm examining.  The source and destination
columns in the packet browser are filled in rationally.

debian sid
wireshark 3.6.2-1
5.16.0-1-amd64 #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09) x86_64
GNU/Linux

Does anyone know of something different I should be doing?  A known bug?

Thanks,

de KB8ZQZ

Re: Wireshark ax25 dissector

[David Ranch]

Hello Denis,

I have Wireshark 3.2.3 on Ubuntu 20.04 decoding packets on the ax0 
interface and while the ax25_nol3 dissector seems to work ok, the 
standard ax25.src dissector doesn't seem to work for me either. Might be 
worth doing a bug search to see if this is something already known or 
create a new issue if none are found.

--David
KI6ZHD


On 03/01/2022 09:33 AM, Dennis Boone wrote:
> Folks,
>
> I'm having trouble getting Wireshark's ax25 dissector to process
> callsign filters properly.  I can't get _anything_ to match.  I've tried
> expressions like:
>
>      ax25.src ~ "KB8ZQZ"
>      ax25.src ~ "KB8ZQZ-0"
>      ax25.src ~ KB8ZQZ
>      ax25.src ~ KB8ZQZ-0
>
> and the equivalents with ax25.dst.  I've tried various callsigns which
> are in the capture file I'm examining.  The source and destination
> columns in the packet browser are filled in rationally.
>
> debian sid
> wireshark 3.6.2-1
> 5.16.0-1-amd64 #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09) x86_64
> GNU/Linux
>
> Does anyone know of something different I should be doing?  A known bug?
>
> Thanks,
>
> de KB8ZQZ

Re: Wireshark ax25 dissector

[Dennis Boone]

 > I have Wireshark 3.2.3 on Ubuntu 20.04 decoding packets on the ax0
 > interface and while the ax25_nol3 dissector seems to work ok, the
 > standard ax25.src dissector doesn't seem to work for me either. Might
 > be worth doing a bug search to see if this is something already known
 > or create a new issue if none are found.

David,

Thanks for the confirmation.  I can't find a relevant bug in their
gitlab tracker, so have opened one.

https://gitlab.com/wireshark/wireshark/-/issues/17973

De

Re: Wireshark ax25 dissector

[Richard Stearn]

Dennis Boone wrote:

> I'm having trouble getting Wireshark's ax25 dissector to process
> callsign filters properly.  I can't get _anything_ to match.  I've tried
> expressions like:

The ax25 dissector never had the ability to filter on a callsign in the form 
<CALL>-<SSID> it has always used the builtin filter primitives.

See "man wireshark-filter"

So to filter on KB8ZQZ you would use:

	ax25.src[0:6] == 97:85:71:B5:A3:B5

to filter on the source address or

	ax25.dst[0:6] == 97:85:71:B5:A3:B5

You can find the hexadecimal in the AX.25 line in brackets after the
callsign.

So it is not a bug per se.  More of the point at which I had to abandon
development due to ill health.

-- 
Regards
	Richard

Re: Wireshark ax25 dissector

[David Ranch]

Hello Richard,

Ah... I think I understand now and this more of an AX-IP filter and not 
a standard AX.25 callsign filter.  I guess the more appropriate filter 
name should be "ax25.srcmac"?

--David
KI6ZHD


On 03/02/2022 07:00 AM, Richard Stearn wrote:
> Dennis Boone wrote:
>
>> I'm having trouble getting Wireshark's ax25 dissector to process
>> callsign filters properly.  I can't get _anything_ to match. I've tried
>> expressions like:
>
> The ax25 dissector never had the ability to filter on a callsign in 
> the form <CALL>-<SSID> it has always used the builtin filter primitives.
>
> See "man wireshark-filter"
>
> So to filter on KB8ZQZ you would use:
>
>     ax25.src[0:6] == 97:85:71:B5:A3:B5
>
> to filter on the source address or
>
>     ax25.dst[0:6] == 97:85:71:B5:A3:B5
>
> You can find the hexadecimal in the AX.25 line in brackets after the
> callsign.
>
> So it is not a bug per se.  More of the point at which I had to abandon
> development due to ill health.
>

Re: Wireshark ax25 dissector

[Richard Stearn]

David Ranch wrote:
> 
> Hello Richard,
> 
> Ah... I think I understand now and this more of an AX-IP filter and not 
> a standard AX.25 callsign filter.  I guess the more appropriate filter 
> name should be "ax25.srcmac"?

It is applying the filter to the ax25.src fields but the callsign parser that 
should convert an ax25 callsign to the bit pattern for comparison is incomplete
so only a hexadecimal comparison field can be used.

in epan/ftypes/ftype-bytes.c the following function in incomplete:

static gboolean
ax25_from_unparsed(fvalue_t *fv, const char *s, gboolean allow_partial_value, 
LogFunc logfunc)
{
         /*
          * Don't log a message if this fails; we'll try looking it
          * up as another way if it does, and if that fails,
          * we'll log a message.
          */
         if (bytes_from_unparsed(fv, s, TRUE, NULL)) {
                 if (fv->value.bytes->len > FT_AX25_ADDR_LEN) {
                         logfunc("\"%s\" contains too many bytes to be a valid 
AX.25 address.",
                             s);
                         return FALSE;
                 }
                 else if (fv->value.bytes->len < FT_AX25_ADDR_LEN && 
!allow_partial_value) {
                         logfunc("\"%s\" contains too few bytes to be a valid 
AX.25 address.",
                             s);
                         return 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;
}


-- 
Regards
	Richard