search

wb2osz / direwolf

Dire Wolf is a software "soundcard" AX.25 packet modem/TNC and APRS encoder/decoder. It can be used stand-alone to observe APRS traffic, as a tracker, digipeater, APRStt gateway, or Internet Gateway (IGate). For more information, look at the bottom 1/4 of this page and in https://github.com/wb2osz/direwolf/blob/dev/doc/README.md
GNU General Public License v2.0
1.51k stars 299 forks source link

ACHANNELS 1 hides a channel of the next device (still) #515

Open jmkristian opened 4 months ago

jmkristian commented 4 months ago

This follows on to issue #510. If I configure two mono devices, like this:

ADEVICE plughw:CARD=Digirig,DEV=0
ACHANNELS 1
ADEVICE1 plughw:CARD=DRA,DEV=0
ACHANNELS 1

... the second device isn't visible to AGW clients. For example, QtTermTCP shows:

2mono

It appears the second AGW port represents the second device, but actually it corresponds to channel 1. An AGW client can't use this port, as shown in the attached log. mono2.log

In this case, either Direwolf should map the second AGW port to channel 2, or the 'G' response should identify three AGW ports (representing channels 0, 1 and 2). I would prefer the former; that is, AGW ports don't map to invalid channels.

I built direwolf on Ubuntu 22.04.3 from the dev branch commit 4d2d814ee.

jmkristian commented 3 weeks ago

(bump) Any idea if/when/how this might be resolved?

mfncooper commented 3 weeks ago

There is a bug in QtTermTCP whereby it ignores the port numbers provided by the AGWPE server in its 'G' frame response, and instead bases the port numbers on their indexes in the provided list of ports. The screenshot shows Port1 and Port3 presented to the user, which should correspond to AGWPE ports 0 and 2 when parsed correctly. However, QtTermTCP assumes that the first two AGWPE ports will be 0 and 1, based on their position in the list of ports. This is why you are seeing QtTermTCP attempt to use AGWPE port 1 instead of AGWPE port 2 when Port3 is selected.

QtTermTCP needs to be parsing the port info strings provided by the AGWPE server, and obtaining the correct port numbers from those strings, instead of making assumptions about them being consecutive.

I don't believe there's a Direwolf issue here.

jmkristian commented 3 weeks ago

In addition to QtTermTCP, AGWTermtcp:

agwTermTcp

... and EasyTerm:

EasyTerm49

... both consider port numbers to be offsets in the list of ports in a 'G' response (not something parsed from the descriptions). They both attempt to connect via port 1, when the user selects the second port in the list. The attempt fails, since channel 1 is invalid. port1.txt

It seems impractical to change all three clients (and perhaps more) to behave differently.

I used Windows 8.1 and Direwolf built from the dev branch commit cae46801c4b50df4c.