[net.ham-radio.packet] Wiretap paper, TNC bugs

clements@bbnccq (11/07/85)

From: Bob Clements <clements@bbnccq.ARPA>
Dave,

I finally got around to actually reading your Wiretap paper all
the way through.  Thanks for posting it.  It's a good first
real experiment on a subject that lots of us have thought about
but never actually done.

Another item for your list of "problems" with the approach
would be buggy nodes. These can give you false connectivity
info in your tables.

A couple examples:

The GLB TNC (in at least some software versions) decides to
digipeat frames that were not addressed to it or through it.  A
guess is that if it has a number of frames in its processing
queue, and it finds one that it should digipeat, it just
digipeats the whole list.  Exact bug not known, but something
like that. So you would hear a frame that appeared to be from a
station you might not really be able to hear. The W1MX
digipeater, on a nice tall building at MIT, does this.

Also, the TAPR TNC-1 sends out frames to people it was not in
contact with under some circumstances. One I have seen on the
screen (using the WA8DED monitoring features) goes like this:

    W1AAA is connected to W1ZZZ.
    W1AAA disconnects by sending DISC.
    W1ZZZ sends UA to W1AAA, but it doesn't get there for one
    reason or another.
    W1ZZZ thinks he is disconnected.

    A packet goes by from W1BBB to W1CCC via W1DDD, W1EEE.
    [This one may have to be a non-info frame; I'm not sure.]
    W1ZZZ hears it go by.

    W1AAA retries the DISC which he didn't hear acknowledged.
    W1ZZZ, a buggy TNC-1, never in contact with or addressed
    by W1CCC, sends a DM to W1CCC via W1DDD, W1EEE!!!


Well, it's just a hobby.

73,
Bob,        ARPAnet: clements@bbn
K1BC        Usenet:  {decvax, ihnp4, linus, ...}!bbncca!clements