[aprssig] AX25 / KISS questions

[Kenneth Finnegan]

On Fri, Jun 9, 2017 at 3:24 PM, John Langner WB2OSZ <wb2osz at comcast.net>
 wrote:

> The AX.25 spec says this about the "C" bits in the destination and source
> addresses.  Section 6.1.2, figure 6.1.
> [...snip...]

After spending a lot of time studying the AX.25 spec, I think "command"
> would be correct.  The state diagrams, in the back, indicate that a UI
> frame
> that is not a "command" is an error.  APRS is built on top of AX.25 so we
> would expect it to follow the same rules unless explicitly mentioned
> otherwise.
>
>
> We can have philosophical discussions about what they "should" be but the
> reality is that we find all 4 combinations being used.
>
> Any implementation should simply ignore them for incoming frames.


For reference, since APRS is more based on AX.25 v2.0, the same figure is
in section 2.4.1.2 in that document.

Agreed; since at the AX.25 level everything is UI beacon frames, I vote for
the commad flag.

Begin spec proposal:
All APRS AX.25 frames SHOULD use the 'command' C bits - 0 in the source
callsign and 1 in the destination (TNC ID) callsign.
All APRS stations MUST ignore all incoming C bits, as the fields are
deprecated.
End spec proposal

--
Kenneth Finnegan, W6KWF
http://blog.thelifeofkenneth.com/

On Fri, Jun 9, 2017 at 3:24 PM, John Langner WB2OSZ <wb2osz at comcast.net>
wrote:

> The AX.25 spec says this about the "C" bits in the destination and source
> addresses.  Section 6.1.2, figure 6.1.
>
> Frame Type        Dest.SSID C-Bit   Source SSID C-Bit
> ---------------   ---------------   -----------------
> Previous versions        0                0
> Command (V.2.X)          1                0
> Response (V.2.X)         0                1
> Previous versions        1                1
>
> The two "C" bits must be the opposite of each other.  This is very
> important
> for the traditional "connected" mode.
>
> I could find no mention of these two bits in the APRS protocol spec or
> other
> literature.
>
> After spending a lot of time studying the AX.25 spec, I think "command"
> would be correct.  The state diagrams, in the back, indicate that a UI
> frame
> that is not a "command" is an error.  APRS is built on top of AX.25 so we
> would expect it to follow the same rules unless explicitly mentioned
> otherwise.
>
> When this question came up before, I hacked together something to observe
> what is actually used in practice.
>
> Source C   Dest C   meaning, examples.
> --------   ------   ------------------
>
>    0      0       (previous versions)   WXtrac, APRS+SA, KPC-3, Tiny Track,
> Xastir
>    0      1       (command)   Uidigi, UIview, APRSISCE, APRSdroid
>    1      0       (response)  Kenwood, Yaesu, APRSISCE
>    1      1       (previous versions)   OpenTrack
>
>
> We can have philosophical discussions about what they "should" be but the
> reality is that we find all 4 combinations being used.
>
> Any implementation should simply ignore them for incoming frames.
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20170609/bab36fbd/attachment.html>