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

[jmkristian]

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:

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 4d2d814.

[jmkristian]

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

[mfncooper]

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]

In addition to QtTermTCP, AGWTermtcp:

... and EasyTerm:

... 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 cae4680.