-={ lundi, 06 juin 2016, 08:12:57 +0000 }=-

Hey Red!

Type 2 pkt header has 18 fields, the most interesting being the last which
contains 20 ascii nulls - as if there aren't already too many nulls some of
which are supposed to be delimiters.  That insanity aside, a simple 'tail
-c 20 <<< $pktHeader | tr -d \0' call will only produce output if
indeed the $pktHeader (the first 58 bytes of a raw pkt) is not the
so-called 'fill' field.  If it is then a not call (!) to 'if' will reveal a
type 2 pkt header.

  if [ ! "$(tail -c 20 <<< $pktHeader | tr -d \0)" ]; then
    echo "Type 2 pkt header"
  fi

A type 2.2 pkt header - which is clearly the winner for cutting down cpu
cycles and producing the least amount of useless output - has an eight byte
fill field (ascii nulls) at offset 8 (zero based) and following the same
logic as the type 2 then this does work;

  if [ ! "$(cut -c 9-16 <<< $pktHeader | tr -d \0)" ]; then
    echo "Type 2.2 pkt header"
  fi

Note that 'cut' and counts the first byte as 1 instead of 0, thus the '-c 9-16' part.

As for type 2+, I don't see anything unique other than to say if it fails
the type 2 and 2.2 tests then it must be a type 2+.

A purely bash-ist idea for those that might believe that fidonet pkt
headers have something in them worth jumping through hoops for.  This sysop
thinks not but had some fun toying around with the idea and thought it
might be fruitful to someone.  Probably not but what the heck.

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 4.3.42(1)-release (x86_64-atom-linux-gnu)