[Xastir-dev] message bugs?

[Curt, WE7U]

On Mon, 24 Jan 2005, Chris Bell wrote:

> 1. If I leave the PATH box blank, I am not sure WHAT it uses... the
> view-incoming-data window claims it is sending with the path of
> "TCPIP*", and I never saw a digipeat.

I was in a quandary about how best to represent the outgoing
packets.  I wanted to show in that dialog that something was getting
transmitted, but I didn't want to put multiple transmit strings in
there, once for each interface.  I chose to put a fairly generic
path in there and just issue one string to that dialog for each
transmit.

If the users would like something different, let's hear about it.
We could easily put a transmit string there for each interface.
Having the transmit strings in that dialog at all is a fairly new
tweak.  I figured there might be some code changes to that before it
settles down.

Often while mobile you'll want to have RELAY in there as the first
digi.  I use RELAY,WIDE2-2.  It helps you a great deal while mobile.


> Now that I am back home, I can
> sit in the driveway and see what is actually being sent.  By looking
> at the code, it looks like it should be using the igate-to-RF path set
> in the interface, (which I had blank).

It will send to whatever are in the Path 1/2/3 boxes, in round-robin
fashion.  If any of those are blank, they are skipped in the
rotation.  If all three are blank it resorts to a hard-coded
"WIDE,WIDE2-2" path (interface.c:select_unproto_path).


> I did change the path box to read "wide2-2", and it picked it up
> immediately (even though the view window still reports "TCPIP*") and
> got a digi, and the ack, and confirmation OK message.

I was thinking about putting something like "<PATH>" (literally
those exact characters) instead of "TCPIP*", to show that the path
changes based on interface, but I figured that'd be even more
confusing.


> 2. When using the EMAIL service, the ack and the OK message come from
> WU2Z, and not from "EMAIL", so we never clear the outgoing message.
> [This has been a problem forever.]  Fortunately, we now have the
> cancel button so we can kill it.  Should we match up the ack with the
> counter we sent out, ignoring the to/from calls, and not care that we
> might be getting spoofed [intentionally or otherwise] ?  I would hate
> to add a special case that "EMAIL" ignores the returning from
> call... but otherwise we never stop txing.

Perhaps for this one special case it might be ok to match on that.
Another similar case is that some software/radios out there can send
an ack if the call matches but the SSID does not, so that they can
pick up their mail from whatever station they're currently using.
Perhaps we could add that capability as well.  It's on the feature
request list.


> And speaking of the view-incoming window...
>
> The view-incoming data window also reports that I am transmitting my
> dozen or so objects/items that I have (basically waypoints) at random
> times (one or two at a time), also with the supposed path of "TCPIP*",
> even though I have the global interface/disable-tx-objects-items
> selected.

I don't think it is actually transmitting, but it's worth checking
on.  Add this to the bug list.


The times aren't exactly random, but they are spread out a bit and
the rate does decay now.  They distribute nicely so-as not to hog
the channel.


> It does not show anything when I transmit a posit... I only know when
> I get a digipeat back.  It would be nice to know how often I am
> sending stuff out, and via which of the configured paths, (I have
> wide2-2 and relay,wide set) so I have a better understanding of what
> is working and what is not.
>
> I am looking into several other issues I was having on my own.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"