[nos-bbs] AXUI mode not showing all incoming UI frames

[Michael Curry]

I've been collecting some data on this issue, and have formed a hypothesis:

The only received UI frames that make it into the AXUI window are those
that have either:

a) No digis in their unproto path, or,
b) For each digi in the unproto path, that digi's H bit is set

Or, to put it the other way around, a UI-frame packet does NOT make it into
the AXUI window if its unproto path contains any digi's that haven't yet
digipeated that packet.

In my area (Northern CA), there are a few stations that regularly send out
their beacons to chains of digipeaters. I can see their packets arriving in
the AX.25 trace file as they reach digis in that chain that my station can
hear. If the last digi in the packet's unproto path also happens to be one
that my station can hear, that final copy of the packet shows up in the
AXUI window; otherwise it does not. There are a couple of stations in
particular who configure their beacons' unproto paths to end at digis that
I can't hear, and their packets never show up in my AXUI window.

As noted earlier, on nights when a net is running, AXUI misses quite a few
more packets, and I believe this happens because each station configures
his unproto path to start at a point on the digi chain that can hear his
station best, and thus his unproto path may or may not end at a digipeater
that I can hear. I can only hear a couple of the digis out of the overall
population that net participants use, and the participants are pretty much
all over the northern half of the state. So for an arbitrary participating
station, there is a greater likelihood that the final digi will be one that
I can't hear than one that I can.

(BTW, quite a few of these stations use unproto paths that are 8 elements
long. I was getting a lot of "bad header!" errors in the trace file, until
I dug into the code and discovered that MAXDIGIS was set to 7. This
problem, at least, went away when I changed it to 8 and rebuilt my JNOS.)

Anyway, I've lately been digging around in ax25.c to try to figure out what
would account for the behavior I'm seeing, but I keep getting lost in the
logic flow. Maiko, because you're much more familiar with that code, maybe
you can see quickly what's going on.

Meanwhile, I'll let you know if I see any counterexamples that bust my
hypothesis. :-)

Thanks,

Michael KI6TYV
-- 
This cat is pushing a watermelon out of a lake. Your argument is invalid.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20120528/c3042cb7/attachment.html>