[aprssig] Careless AX.25 encoding in APRS messages

[Matti Aarnio]

I am probably only one interested enough in some deep esoteric
details of the radio link-level protocol used by the APRS to
even look into this...

On AX.25 destination address part the SSID byte should have
its three top bits with value: 111,  and on source address
part those same bits should be: 011.  AX.25 v2.2 specification
chapter 6.1.2  - UI frames are sent as "commands".

These are received from radio at my home near Helsinki in OH land.
Most frames flying around in here are with proper SSID byte bits,
but my aprx does analyze things in deep detail, and in sufficiently
high debug mode it prints out suspicuous details like these.

To protect the innocent users, I show TNC2 dump order of SSID
bytes on SOURCE and on DESTINATION bytes (which is reverse of
what is really in the AX.25 packet):

  USER>APN391 SSID-bytes: 60,60
  USER>APND0Z SSID-bytes: e0,60
  USER>APOT21 SSID-bytes: e0,e0
  USER>APOTC1 SSID-bytes: f2,e0
  USER>APX195 SSID-bytes: 60,60
  USER>APZMDR SSID-bytes: 60,60
  USER>APZMER SSID-bytes: 70,60
  USER>BEACON SSID-bytes: 60,60
  USER>UIDIGI SSID-bytes: 61,80
  USER>VP1W43 SSID-bytes: f2,60
  USER>VP1W68 SSID-bytes: f2,60
  USER>VP1W75 SSID-bytes: f2,60
  USER>VP1W82 SSID-bytes: f2,60
  USER>VP1W83 SSID-bytes: f2,60
  USER>VP1W89 SSID-bytes: f2,60
  USER>VP1W98 SSID-bytes: f2,60
  USER>VP1X31 SSID-bytes: f2,60
  USER>VP1X35 SSID-bytes: f2,60
  USER>VP1Y27 SSID-bytes: f2,60
  USER>VP2P29 SSID-bytes: f2,60
  USER>VP2Q41 SSID-bytes: f2,60
  USER>VP2R53 SSID-bytes: f2,60
  USER>VP2S66 SSID-bytes: f2,60
  USER>VP2T73 SSID-bytes: f2,60
  USER>VP2V81 SSID-bytes: f2,60
  USER>VP2W26 SSID-bytes: f2,60
  USER>VP2W35 SSID-bytes: f2,60
  USER>VPQP17 SSID-bytes: e0,60

So, OpenTrackers have it wrong, only destination should have
bits "111", source has bits "011".

APZMDR refers to Finnish HamDR devices, myself or Hessu will fix
that software..  (Destination puts wrong top bits on ssid byte.)

Then UIDIGI...  Dead (sources unavailable, development stopped)
software really should not be used...

APN391, APND0Z, APX195, APZMER, VP***  are unknown to me.

That BEACON is on -- I am unsure of what software, but I do know
its maintainer.  I will have a chat in the evening with him.


I do feel like Protocol Conformance Police every now and then, but
how little people do observe problems with wrong values in these
bits does tell that they are usually ignored by  a) digipeaters,
b) igates  --  and for interoperability reasons they must continue
to be ignored.  If somebody really would pay attention on those
bits, interoperability failure would be immediately obvious...

Nevertheless, wrong bits should never be sent out, but they must
be tolerated to be received.     As much as I would like to be 
nasty and require strict conformance....  if all MDR and OT users
in Helsinki and Tampere areas all the sudden would not get their
positions relayed to APRSIS or digipeated at all, that would not
be a very positive thing either.

  73 de Matti, OH2MQK