Issue 427 - callsign order for AGW protocol 'Y'.

This commit is contained in:
wb2osz 2023-05-04 18:56:09 +01:00
parent 5fb4081c86
commit 8000e46c02
1 changed files with 67 additions and 9 deletions

View File

@ -1,7 +1,7 @@
//
// This file is part of Dire Wolf, an amateur radio packet TNC.
//
// Copyright (C) 2016, 2017, 2018 John Langner, WB2OSZ
// Copyright (C) 2016, 2017, 2018, 2023 John Langner, WB2OSZ
//
// This program is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
@ -1580,13 +1580,49 @@ void dl_unregister_callsign (dlq_item_t *E)
* - Incoming connected data, from application still in the queue.
* - I frames which have been transmitted but not yet acknowledged.
*
* Confusion: https://github.com/wb2osz/direwolf/issues/427
*
* There are different, inconsistent versions of the protocol spec.
*
* One of them simply has:
*
* CallFrom is our call
* CallTo is the call of the other station
*
* A more detailed version has the same thing in the table of fields:
*
* CallFrom 10 bytes Our CallSign
* CallTo 10 bytes Other CallSign
*
* (My first implementation went with that.)
*
* HOWEVER, shortly after that, is contradictory information:
*
* Careful must be exercised to fill correctly both the CallFrom
* and CallTo fields to match the ones of an existing connection,
* otherwise AGWPE wont return any information at all from this query.
*
* The order of the CallFrom and CallTo is not trivial, it should
* reflect the order used to start the connection, so
*
* * If we started the connection CallFrom=US and CallTo=THEM
* * If the other end started the connection CallFrom=THEM and CallTo=US
*
* This seems to make everything unnecessarily more complicated.
* We should only care about the stream going from the local station to the
* remote station. Why would it matter who reqested the link? The state
* machine doesn't even contain this information so the TNC doesn't know.
* The client app interface needs to behave differently for the two cases.
*
* The new code, below, May 2023, should handle both of those cases.
*
*------------------------------------------------------------------------------*/
void dl_outstanding_frames_request (dlq_item_t *E)
{
ax25_dlsm_t *S;
int ok_to_create = 0; // must exist already.
const int ok_to_create = 0; // must exist already.
int reversed_addrs = 0;
if (s_debug_client_app) {
text_color_set(DW_COLOR_DEBUG);
@ -1594,13 +1630,29 @@ void dl_outstanding_frames_request (dlq_item_t *E)
}
S = get_link_handle (E->addrs, E->num_addr, E->chan, E->client, ok_to_create);
if (S != NULL) {
int reversed_addrs = 1;
}
else {
// Try swapping the addresses.
// this is communicating with the client app, not over the air,
// so we don't need to worry about digipeaters.
if (S == NULL) {
char swapped[AX25_MAX_REPEATERS][AX25_MAX_ADDR_LEN];
memset (swapped, 0, sizeof(swapped));
strlcpy (swapped[PEERCALL], E->addrs[OWNCALL], sizeof(swapped[PEERCALL]));
strlcpy (swapped[OWNCALL], E->addrs[PEERCALL], sizeof(swapped[OWNCALL]));
S = get_link_handle (swapped, E->num_addr, E->chan, E->client, ok_to_create);
if (S != NULL) {
int reversed_addrs = 1;
}
else {
text_color_set(DW_COLOR_ERROR);
dw_printf ("Can't get outstanding frames for %s -> %s, chan %d\n", E->addrs[OWNCALL], E->addrs[PEERCALL], E->chan);
server_outstanding_frames_reply (E->chan, E->client, E->addrs[OWNCALL], E->addrs[PEERCALL], 0);
return;
}
}
// Add up these
//
@ -1628,7 +1680,13 @@ void dl_outstanding_frames_request (dlq_item_t *E)
}
}
if (reversed_addrs) {
// Other end initiated the link.
server_outstanding_frames_reply (S->chan, S->client, S->addrs[PEERCALL], S->addrs[OWNCALL], count1 + count2);
}
else {
server_outstanding_frames_reply (S->chan, S->client, S->addrs[OWNCALL], S->addrs[PEERCALL], count1 + count2);
}
} // end dl_outstanding_frames_request