AGW 'Y' frame call from/to NOT reversed for inbound connections

[martinhpedersen]

According to my protocol reference AGWPE TCP/IP API Tutorial by Ing. Pedro E. Colla (LU7DID) and George Rossopoulos (SV2AGW), when requesting outstanding frames for a connection (the 'Y' frame):

Careful must be exercised to fill correctly both the CallFrom and CallTo fields to match the ones of an existing connection, otherwise AGWPE won’t 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

Please refer to the ‘C’ frame sent by AGWPE upon connection to understand how to identify who initiated a connection.

When implementing this behavior (the way interpret it), I get an error on inbound connections in the Direwolf log output indicating that no matching connection was found: Can't get outstanding frames for %s -> %s, chan %d.

This seems to be discussed in the source code, but there is no apparent conclusion. So I guess the initial question to be answered is, what's the correct behavior? What do other AGW clients and/or servers expect "in the wild"?

Thanks!

[ac2cz]

This may not be connected, but querying AGW y frames also does not work as expected. If you start to stream frames to Direwolf and poll y, then Direwolf reports 0 frames in the queue for quite some time until it suddenly reports 40 or more. So there is a delay and this can not be reliably used to throttle frames sent to the TNC.

I'm using a version built from the master branch, but the code in this section looks the same in dev.

[martinhpedersen]

@ac2cz - I also noticed that. I concluded that the current implementation of the y frame is unreliable and not suitable for rate limiting.

[martinhpedersen]

@wb2osz - Have you had a chance to look into this (Y frame to/from order) yet? I think it's important to fix this, or at least document the behavior and figure out how clients can implement this while still being compatible with other implementations.

[martinhpedersen]

I just did a quick test with QtSoundModem. Seems like it's implemented the same way as Direwolf.

[wb2osz]

I'm looking into this.

[wb2osz]

The dev branch should be able to take either callsign order now.

73,
John WB2OSZ