Topics

ARDOPc logging to the wrong file descriptor?


Martin Hebnes Pedersen
 

Hello,

please see the below forwarded message. I've received several reports from Pat users experiencing an issue where [ConReq...]" lines somehow ends up being transmitted over the air by ARDOPc.

Last report was received today by Ugo Poddine. Ugo have been discussing this issue with HB9AK sysop HB9AUR. The user is running ARDOP TNC_1.0.2.5l-BPQ and the HB9AK node is running BPQ32 (unknown ARDOP version).

Any ideas as to why these lines end up being transmitted over the air? As mentioned in the email below, I doubt Pat is responsible for these issues since "ConReq" lines are generated by ARDOPc for logging and (AFAIK) is not part of the ARDOP host interface protocol nor B2F.

Thanks!

-- 
73 de LA5NTA/Martin

---------- Forwarded message ----------
From: Martin Hebnes Pedersen <...>
Date: 2017-07-13 9:42 GMT+02:00
Subject: ARDOPc logging to the wrong file descriptor?
To: john...@...


Hi John,

I'm addressing you directly this time because I'm fairly certain that you are the right person to contact regarding this. I you rather prefer I address the ardop developers list, please let me know and I will send a new email.

The first report I got of this issue was on the pat-users mailing list (https://groups.google.com/forum/#!topic/pat-users/bhbv-_jJh2k).

What we are experiencing is that Pat is receiving some data frames containing "[ConReq500M: KB3OMM > AB3XYZ]" strings. They are encapsulated as regular ARDOP data frames in the host<->tnc connection, but they obiously should not be there as they are not valid B2F protocol sentences. I've searched through the codebase of Pat and cannot find any code constructing a string containing "ConReq", so I suspect the strings are injected by ARDOPc either in the sending or receiving station.

The connecting station (A) and the listening station (B) both run ARDOPc+Pat and it seems like a prerequisite is that B first receives a connect frame it does not answer (either because listen is disabled or the dialed callsign is not B). It is the RX station that receives the invalid data [ConReq... after answering the second call (addressed to the correct callsign with listener enabled).

The result is that station B sees the mangled data as an invalid handshare, and sends the message "*** Bad SID line: [ConReq..." back over the air to A and then closes the connection.

Any ideas? Could it be the case that ARDOPc is logging to the wrong file descriptor or something like that?

Thanks!

--
Martin - LA5NTA



John G8BPQ
 

ARDOP sends Con Req frames that aren't for your call to the host as "ARQ" type frames in the form "[ConReq500: G8XXX > G8YYY].  I can't see how these whould be transmitted on air, but if the application doesn't process received frames when not it a session they could get prepended to the actual session data.

73,

John G8BPQ


On 30/04/2018 16:18, Martin Hebnes Pedersen wrote:
Hello,

please see the below forwarded message. I've received several reports from Pat users experiencing an issue where [ConReq...]" lines somehow ends up being transmitted over the air by ARDOPc.

Last report was received today by Ugo Poddine. Ugo have been discussing this issue with HB9AK sysop HB9AUR. The user is running ARDOP TNC_1.0.2.5l-BPQ and the HB9AK node is running BPQ32 (unknown ARDOP version).

Any ideas as to why these lines end up being transmitted over the air? As mentioned in the email below, I doubt Pat is responsible for these issues since "ConReq" lines are generated by ARDOPc for logging and (AFAIK) is not part of the ARDOP host interface protocol nor B2F.

Thanks!

-- 
73 de LA5NTA/Martin

---------- Forwarded message ----------
From: Martin Hebnes Pedersen <...>
Date: 2017-07-13 9:42 GMT+02:00
Subject: ARDOPc logging to the wrong file descriptor?
To: john...@...


Hi John,

I'm addressing you directly this time because I'm fairly certain that you are the right person to contact regarding this. I you rather prefer I address the ardop developers list, please let me know and I will send a new email.

The first report I got of this issue was on the pat-users mailing list (https://groups.google.com/forum/#!topic/pat-users/bhbv-_jJh2k).

What we are experiencing is that Pat is receiving some data frames containing "[ConReq500M: KB3OMM > AB3XYZ]" strings. They are encapsulated as regular ARDOP data frames in the host<->tnc connection, but they obiously should not be there as they are not valid B2F protocol sentences. I've searched through the codebase of Pat and cannot find any code constructing a string containing "ConReq", so I suspect the strings are injected by ARDOPc either in the sending or receiving station.

The connecting station (A) and the listening station (B) both run ARDOPc+Pat and it seems like a prerequisite is that B first receives a connect frame it does not answer (either because listen is disabled or the dialed callsign is not B). It is the RX station that receives the invalid data [ConReq... after answering the second call (addressed to the correct callsign with listener enabled).

The result is that station B sees the mangled data as an invalid handshare, and sends the message "*** Bad SID line: [ConReq..." back over the air to A and then closes the connection.

Any ideas? Could it be the case that ARDOPc is logging to the wrong file descriptor or something like that?

Thanks!

--
Martin - LA5NTA




Martin
 

So when ARDOPc receives a ConReq, it sends it to the host (PAT). But since the host has no session open, it probably does not read this string in the buffer. Once a new session is established, PAT reads the buffer and gets this ConReq. As it expects something else, it interprets it as an error and says "*** Bad SID line:ConReq2000M: ...".
Just a guess

By the way: WL Express is also known to have problems with buffers not cleared properly when a new session starts. The effects are a little different.

Martin HB9AUR


Martin Hebnes Pedersen
 

Hi John, thanks for coming back to me. I would also like to invite Rick to join in on this discussion.

If I understand you correctly, ARDOPc is sending non-ARQ data masked as ARQ frames (when the TNC is idle). Any reason why these are not sent as «asynchronous TNC commands» (C frames)?

The host protocol specification states: «”ARQ” indicates this is data received from a connected (ARQ) session and should be error free.».

As I see it, ARDOPc is in clear violation of this promise by sending data which have not been «received from a connected (ARQ) session».

Granted, the above quote is from an old copy of the host interface specification. The «_ARDOP TNC Interface Spec.pdf» is missing from the files section of developers@ardop.groups.io. Instead, a different document «Host Interface Spec for WL2K supported Protocols_TNCs.pdf» have appeared. However, this document does not describe how the "TCPIP Interface» encapsulates data (ARQ/IDF/FEC) frames at all(?). The only mention of ARQ frames is in Appendix A (Serial Interface Protocol), and even this does not provide much detail of what to expect regarding ARQ frames except for «Received Data from TNC». The degradation of documentation is unfortunate, but I guess that is separate concern.

Unfortunately, incompatibility issues is a recurring problem with both ARDOPc and ARDOP_WIN. I am sorry if this seems a bit harsh, but the fact is that the «host interface protocol» has been a pain to work with due to all the unexpected changes to both the specification and the TNC implementations. I’ve spent countless hours debugging and fixing issues caused by changes to the host protocol in the last two years. I am starting to loose hope that I will ever be able to provide stable support for ARDOP in Pat. Don’t get me wrong, I highly appreciate your projects and all the work you've but into ARDOP, but I can’t justify spending this much time fixing errors due to unnecessary breaking API changes… It is not sustainable in the long run… and it gets even worse when the changes are implemented in violation of the protocol specification.

I kindly ask you both to start working closer with us regarding any changes that may affect the host applications, and particularly changes that may break backwards compatibility and/or the current protocol specification. The majority of ARDOP users are Winlink users, and they expect the system to be reliable. The only way to ensure reliable operation in an ecosystem consisting of many software applications is to have stable APIs. I must ask you to please keep the host interface stable, so we can provide the stability the users expect. I sincerely hope both you and Rick will take this into account the next time you are considering to change the behavior of the TNCs host interfaces. Maybe you could let me and other host application developers know in advance, and provide us with pre-release builds so that we can verify backwards compatibility? It’s just a thought.

Now, back to resolving this particular issue. Do you agree with my conclusion that ARDOPc is in violation of the host interface protocol by sending this data as ARQ frames? If so, would you be willing to change this behavior in an upcoming release?

FYI, here is a list of prior Pat issues related to ARDOP host interface protocol changes and inconsistencies:
November 2017: https://github.com/la5nta/pat/issues/108 (ARDOP v1.0.2.5 changes)
Februar 2017: https://github.com/la5nta/wl2k-go/commit/9365c18 (IDF format differ between ARDOPc and ARDOP_WIN)
December 2016: Re-introduction of command acknowledgements with v0.9
November 2016: https://github.com/la5nta/wl2k-go/issues/45 (Removal of command acknowledgements)
September 2016: https://github.com/la5nta/pat/issues/60 (ARDOP v0.6 changes - introduces a separate TCP port for the ARQ data stream)
August 2016: https://github.com/la5nta/pat/issues/55 (not really a change - only wrongfully posted update to the documentation)


— 
73 de LA5NTA/Martin

30. apr. 2018 kl. 18:12 skrev John Wiseman <john.wiseman@...>:

ARDOP sends Con Req frames that aren't for your call to the host as "ARQ" type frames in the form "[ConReq500: G8XXX > G8YYY].  I can't see how these whould be transmitted on air, but if the application doesn't process received frames when not it a session they could get prepended to the actual session data.

73,

John G8BPQ


On 30/04/2018 16:18, Martin Hebnes Pedersen wrote:
Hello,

please see the below forwarded message. I've received several reports from Pat users experiencing an issue where [ConReq...]" lines somehow ends up being transmitted over the air by ARDOPc.

Last report was received today by Ugo Poddine. Ugo have been discussing this issue with HB9AK sysop HB9AUR. The user is running ARDOP TNC_1.0.2.5l-BPQ and the HB9AK node is running BPQ32 (unknown ARDOP version).

Any ideas as to why these lines end up being transmitted over the air? As mentioned in the email below, I doubt Pat is responsible for these issues since "ConReq" lines are generated by ARDOPc for logging and (AFAIK) is not part of the ARDOP host interface protocol nor B2F.

Thanks!

-- 
73 de LA5NTA/Martin

---------- Forwarded message ----------
From: Martin Hebnes Pedersen <...>
Date: 2017-07-13 9:42 GMT+02:00
Subject: ARDOPc logging to the wrong file descriptor?
To: john...@...


Hi John,

I'm addressing you directly this time because I'm fairly certain that you are the right person to contact regarding this. I you rather prefer I address the ardop developers list, please let me know and I will send a new email.

The first report I got of this issue was on the pat-users mailing list (https://groups.google.com/forum/#!topic/pat-users/bhbv-_jJh2k).

What we are experiencing is that Pat is receiving some data frames containing "[ConReq500M: KB3OMM > AB3XYZ]" strings. They are encapsulated as regular ARDOP data frames in the host<->tnc connection, but they obiously should not be there as they are not valid B2F protocol sentences. I've searched through the codebase of Pat and cannot find any code constructing a string containing "ConReq", so I suspect the strings are injected by ARDOPc either in the sending or receiving station.

The connecting station (A) and the listening station (B) both run ARDOPc+Pat and it seems like a prerequisite is that B first receives a connect frame it does not answer (either because listen is disabled or the dialed callsign is not B). It is the RX station that receives the invalid data [ConReq... after answering the second call (addressed to the correct callsign with listener enabled).

The result is that station B sees the mangled data as an invalid handshare, and sends the message "*** Bad SID line: [ConReq..." back over the air to A and then closes the connection.

Any ideas? Could it be the case that ARDOPc is logging to the wrong file descriptor or something like that?

Thanks!

--
Martin - LA5NTA





Martin Hebnes Pedersen
 

30. apr. 2018 kl. 18:44 skrev Martin <martin@...>:

So when ARDOPc receives a ConReq, it sends it to the host (PAT). But since the host has no session open, it probably does not read this string in the buffer. Once a new session is established, PAT reads the buffer and gets this ConReq. As it expects something else, it interprets it as an error and says "*** Bad SID line:ConReq2000M: ...".
Just a guess

Hi Martin,

Yes, you are absolutely correct. The ARDOPc «host library» pushes all incoming ARQ frames onto a ARQ (connection) buffer, and this buffer is what Pat reads expecting only B2F (winlink) traffic. The buffer is not cleared before each ARQ session, and this is why Pat is seeing «ConReq2000M» instead of a valid FBB SID.

A workaround could be to reset the buffer before each new conn session, but it really should not be necessary according to the host interface protocol specification as I understand it.

PS: Thanks for helping Ugo with debugging. It really helped me understand the problem better!

— 
73 de LA5NTA/Martin


Martin Hebnes Pedersen
 

On Mon, Apr 30, 2018 at 03:12 pm, Martin Hebnes Pedersen wrote:
The ARDOPc «host library»
I'm sorry, that should be "The ARDOP host library". It's a library written for me to interface Go applications (Pat) with ARDOP TNCs.

-- 
Martin


Bob NW8L
 

>The ARDOPc «host library» pushes all incoming ARQ frames onto a ARQ (connection) buffer

Yes, CONREQ* frames appear in the data channel with the ARQ label, but I observed that behavior from the beginning when developing ARIM. I'm surprised it wasn't reported to you earlier, because any CONREQ frames heard on the channel will be passed along to the host program, presumably for informational purposes. The solution for me was simple: don't start accepting ARQ frames into data buffers until the session is established (CONNECT async response), and stop when the session ends (NEWSTATE DISC or DISCONNECTED async response). Call it "defensive programming". I didn't worry about whether that behavior conflicted with the spec because the TNC design was in "beta" status and I considered the spec to be a work in progress too. However, I did notice that the text in section 7.0 of the old Host Interface Spec for the ARDOP TNC doc describing "Data transfer" doesn't appear in the new ARDOP Protocol Native TNC Commands doc, but thought it was because the document scope was restricted in keeping with the new title.

I expect instability in the host API during the early stages of development when lessons learned need to be incorporated into the design in an iterative manner. I'm confident it will stabilize soon enough; what's important is for ARDOP to reach its full potential even at the price of some growing pains in the process.

73,
Bob NW8L


John G8BPQ
 

Martin,

The ConReq frames are intended to be presented to the user as a form of monitoring, so I think it makes sense to send them on the data connection, along with ID frames and monitored data. They will only be sent when in DISC state. There is an Interface command "MONITOR" which disables this. I'm sorry to say this didn't work in ardopc, but this morning I've uploaded versions of ardopc that fixes this.

Last year the interface spec was split into two parts, the "Host Interface for WL2K supported Protocols", which details the communications level interface (TCP Ports, Serial Interface Protocol, frame structures etc), which as the name implies is common to a number of protocols (WINMOR, ARDOP, VARA), and an ARDOP specific section giving message formats etc. The latter document seems to be missing and perhaps Rick could upload it.

I understand the frustration when things change, but I don't think it is unreasonable to make changes during the development phase of a project.

Just to clarify responsibilities, the design and reference implementation are Ricks. Any incompatibility between ardop_win and ardopc is my fault.

73, John



On 30/04/2018 22:59, Martin Hebnes Pedersen wrote:
Hi John, thanks for coming back to me. I would also like to invite Rick to join in on this discussion.

If I understand you correctly, ARDOPc is sending non-ARQ data masked as ARQ frames (when the TNC is idle). Any reason why these are not sent as «asynchronous TNC commands» (C frames)?

The host protocol specification states: «”ARQ” indicates this is data received from a connected (ARQ) session and should be error free.».

As I see it, ARDOPc is in clear violation of this promise by sending data which have not been «received from a connected (ARQ) session».

Granted, the above quote is from an old copy of the host interface specification. The «_ARDOP TNC Interface Spec.pdf» is missing from the files section of developers@ardop.groups.io. Instead, a different document «Host Interface Spec for WL2K supported Protocols_TNCs.pdf» have appeared. However, this document does not describe how the "TCPIP Interface» encapsulates data (ARQ/IDF/FEC) frames at all(?). The only mention of ARQ frames is in Appendix A (Serial Interface Protocol), and even this does not provide much detail of what to expect regarding ARQ frames except for «Received Data from TNC». The degradation of documentation is unfortunate, but I guess that is separate concern.

Unfortunately, incompatibility issues is a recurring problem with both ARDOPc and ARDOP_WIN. I am sorry if this seems a bit harsh, but the fact is that the «host interface protocol» has been a pain to work with due to all the unexpected changes to both the specification and the TNC implementations. I’ve spent countless hours debugging and fixing issues caused by changes to the host protocol in the last two years. I am starting to loose hope that I will ever be able to provide stable support for ARDOP in Pat. Don’t get me wrong, I highly appreciate your projects and all the work you've but into ARDOP, but I can’t justify spending this much time fixing errors due to unnecessary breaking API changes… It is not sustainable in the long run… and it gets even worse when the changes are implemented in violation of the protocol specification.

I kindly ask you both to start working closer with us regarding any changes that may affect the host applications, and particularly changes that may break backwards compatibility and/or the current protocol specification. The majority of ARDOP users are Winlink users, and they expect the system to be reliable. The only way to ensure reliable operation in an ecosystem consisting of many software applications is to have stable APIs. I must ask you to please keep the host interface stable, so we can provide the stability the users expect. I sincerely hope both you and Rick will take this into account the next time you are considering to change the behavior of the TNCs host interfaces. Maybe you could let me and other host application developers know in advance, and provide us with pre-release builds so that we can verify backwards compatibility? It’s just a thought.

Now, back to resolving this particular issue. Do you agree with my conclusion that ARDOPc is in violation of the host interface protocol by sending this data as ARQ frames? If so, would you be willing to change this behavior in an upcoming release?

FYI, here is a list of prior Pat issues related to ARDOP host interface protocol changes and inconsistencies:
November 2017: https://github.com/la5nta/pat/issues/108 (ARDOP v1.0.2.5 changes)
Februar 2017: https://github.com/la5nta/wl2k-go/commit/9365c18 (IDF format differ between ARDOPc and ARDOP_WIN)
December 2016: Re-introduction of command acknowledgements with v0.9
November 2016: https://github.com/la5nta/wl2k-go/issues/45 (Removal of command acknowledgements)
September 2016: https://github.com/la5nta/pat/issues/60 (ARDOP v0.6 changes - introduces a separate TCP port for the ARQ data stream)
August 2016: https://github.com/la5nta/pat/issues/55 (not really a change - only wrongfully posted update to the documentation)


— 
73 de LA5NTA/Martin

30. apr. 2018 kl. 18:12 skrev John Wiseman <john.wiseman@...>:

ARDOP sends Con Req frames that aren't for your call to the host as "ARQ" type frames in the form "[ConReq500: G8XXX > G8YYY].  I can't see how these whould be transmitted on air, but if the application doesn't process received frames when not it a session they could get prepended to the actual session data.

73,

John G8BPQ


On 30/04/2018 16:18, Martin Hebnes Pedersen wrote:
Hello,

please see the below forwarded message. I've received several reports from Pat users experiencing an issue where [ConReq...]" lines somehow ends up being transmitted over the air by ARDOPc.

Last report was received today by Ugo Poddine. Ugo have been discussing this issue with HB9AK sysop HB9AUR. The user is running ARDOP TNC_1.0.2.5l-BPQ and the HB9AK node is running BPQ32 (unknown ARDOP version).

Any ideas as to why these lines end up being transmitted over the air? As mentioned in the email below, I doubt Pat is responsible for these issues since "ConReq" lines are generated by ARDOPc for logging and (AFAIK) is not part of the ARDOP host interface protocol nor B2F.

Thanks!

-- 
73 de LA5NTA/Martin

---------- Forwarded message ----------
From: Martin Hebnes Pedersen <...>
Date: 2017-07-13 9:42 GMT+02:00
Subject: ARDOPc logging to the wrong file descriptor?
To: john...@...


Hi John,

I'm addressing you directly this time because I'm fairly certain that you are the right person to contact regarding this. I you rather prefer I address the ardop developers list, please let me know and I will send a new email.

The first report I got of this issue was on the pat-users mailing list (https://groups.google.com/forum/#!topic/pat-users/bhbv-_jJh2k).

What we are experiencing is that Pat is receiving some data frames containing "[ConReq500M: KB3OMM > AB3XYZ]" strings. They are encapsulated as regular ARDOP data frames in the host<->tnc connection, but they obiously should not be there as they are not valid B2F protocol sentences. I've searched through the codebase of Pat and cannot find any code constructing a string containing "ConReq", so I suspect the strings are injected by ARDOPc either in the sending or receiving station.

The connecting station (A) and the listening station (B) both run ARDOPc+Pat and it seems like a prerequisite is that B first receives a connect frame it does not answer (either because listen is disabled or the dialed callsign is not B). It is the RX station that receives the invalid data [ConReq... after answering the second call (addressed to the correct callsign with listener enabled).

The result is that station B sees the mangled data as an invalid handshare, and sends the message "*** Bad SID line: [ConReq..." back over the air to A and then closes the connection.

Any ideas? Could it be the case that ARDOPc is logging to the wrong file descriptor or something like that?

Thanks!

--
Martin - LA5NTA






Martin Hebnes Pedersen
 

Thanks for the reply John, I appreciate your time.

I understand that we see things differently with regards to compatibility guarantees and API stability. I am all for rapid development and I really want to see ARDOP progress and evolve. But I was expecting the API to be stable after the v1 release as per semantic versioning and versioning best practice. I realize that this assumption was probably wrong, and I will take this under advisement. Still, I hope that you will try to maintain backwards compatibility whenever possible.

For the sake of argument, I'm going to continue with another quote from my copy of "_ARDOP TNC Interface Spec.pdf":
> ”FEC” indicates this is data received from an unconnected session ( a monitored FEC or monitored ARQ frame) and should be error free.

As I understand this statement, I believe the correct frame type would be FEC, even for data related to monitored ARQ sessions.

Based on the two statements I have highlighted, I would still argue that ARDOPc is violating the specification by sending this data as ARQ frames.

> The “d:” identifies this as a data frame from the TNC. ”ARQ” indicates this is data received from a connected (ARQ) session and should be error free. ”FEC” indicates this is data received from an unconnected session ( a monitored FEC or monitored ARQ frame) and should be error free.

It would be very interesting to know how ardop_win encapsulates monitored FAC/ARQ data.

Either way, it would really help alot if you could update ARDOPc to stop sending this data as ARQ frames, so I am asking you kindly to consider this. If you believe it is a bad idea to send it as FEC frames, then maybe you could consider introducing a new asynchronous command for this? I believe either of the two options would be valid according to the specification, but the latter would probably be safest in terms of backwards compatibility.

Thank you for your time.

-- 
73 de LA5NTA/Martin


John G8BPQ
 

Ok, Martin.

I'm not aware of any API changes since 1.0 was released.

I can't change how this works - all I do is follow Rick's code. I expect he
will comment on this at some point. ARDOP_WIN does the same as I do (though
didn’t have the bug in the MONITOR command that I have now fixed).

If it was my choice I’d change the specification document, as I believe how
it works is logical, but as I say it isn’t my decision.

As I mentioned in my last message, these is a command to disable these
monitoring messages. All you have to is to send the command "MONITOR FALSE"
during initialisation (and if you are using ardopc make sure you have the
latest code.

73,
John



________________________________________
From: developers@ardop.groups.io [mailto:developers@ardop.groups.io] On
Behalf Of Martin Hebnes Pedersen
Sent: 01 May 2018 18:58
To: developers@ardop.groups.io
Subject: Re: [ardop_developers] ARDOPc logging to the wrong file descriptor?

Thanks for the reply John, I appreciate your time.

I understand that we see things differently with regards to compatibility
guarantees and API stability. I am all for rapid development and I really
want to see ARDOP progress and evolve. But I was expecting the API to be
stable after the v1 release as per semantic versioning and versioning best
practice. I realize that this assumption was probably wrong, and I will take
this under advisement. Still, I hope that you will try to maintain backwards
compatibility whenever possible.

For the sake of argument, I'm going to continue with another quote from my
copy of "_ARDOP TNC Interface Spec.pdf":
 ”FEC” indicates this is data received from an unconnected session ( a
monitored FEC or monitored ARQ frame) and should be error free.

As I understand this statement, I believe the correct frame type would be
FEC, even for data related to monitored ARQ sessions.

Based on the two statements I have highlighted, I would still argue that
ARDOPc is violating the specification by sending this data as ARQ frames.

The “d:” identifies this as a data frame from the TNC. ”ARQ” indicates
this is data received from a connected (ARQ) session and should be error
free. ”FEC” indicates this is data received from an unconnected session ( a
monitored FEC or monitored ARQ frame) and should be error free.

It would be very interesting to know how ardop_win encapsulates monitored
FAC/ARQ data.

Either way, it would really help alot if you could update ARDOPc to stop
sending this data as ARQ frames, so I am asking you kindly to consider this.
If you believe it is a bad idea to send it as FEC frames, then maybe you
could consider introducing a new asynchronous command for this? I believe
either of the two options would be valid according to the specification, but
the latter would probably be safest in terms of backwards compatibility.

Thank you for your time.

-- 
73 de LA5NTA/Martin


Martin Hebnes Pedersen
 

On Tue, May 1, 2018 at 12:04 pm, John Wiseman wrote:
I'm not aware of any API changes since 1.0 was released.
Neither am I, but I got the impression from your reply that I could expect that to happen. I apologize if I misunderstood you.

I can't change how this works - all I do is follow Rick's code. I expect he
will comment on this at some point. ARDOP_WIN does the same as I do (though
didn’t have the bug in the MONITOR command that I have now fixed).
I see. I will await Rick's comment on the issue before deciding how to handle it.


If it was my choice I’d change the specification document, as I believe how
it works is logical, but as I say it isn’t my decision.
If the behaviour was introduced before the v1 release, then I guess it would be more appropriate to update the specification than to alter the implementations. My main concern is to get some clarification and to ensure that we all agree on the protocol details. I also believe the specification document should be accurate, so that future new developers don't have to spend time on unnecessary debugging.

As I mentioned in my last message, these is a command to disable these
monitoring messages. All you have to is to send the command "MONITOR FALSE"
during initialisation (and if you are using ardopc make sure you have the
latest code.

Yes, thank you for pointing this out to me and for releasing a fix regarding handling of this commmand in ARDOPc.

However, I hope you can appreciate my motivation for addressing issues with protocol ambiguities and/or specification violations. It is rarely as easy as applying a trivial patch. I have to debug, talk to users, find a solution, build binaries and packages for all platforms, write a release changelog, announcement email and publish the release. I will probably also keep answering emails from Pat users that have not yet upgraded to the latest release, at least for a couple of months. All this takes time, time that I could be spent implementing new features instead of fixing up protocol incompatibilities that I have very little control over.

Thank you again for discussing this with me. I will wait for Rick's comment/proposal on how to proceed.

-- 
73 de LA5NTA / Martin


Martin Hebnes Pedersen
 

Bumping this thread.

I would appreciate a comment from Rick regarding this. Should the interface specification be updated (and affected host applications), or is this a bug in ARDOPc and ARDOP_WIN?


Martin Hebnes Pedersen
 

Please consider responding. I would really like to get this issue resolved for the users.

My question; There is a discrepancy between ARDOPc/ARDOP_Win and the host interface specification. As a result, Pat is not fully compatible with the current ARDOP v1 releases.
What do we change? The interface spesification and affected host application(s)? ARDOPc, ARDOP_WIN (and other TNC implementations)?

John; Maybe you can ask Rick to have a look at this thread please?

Thank you!

-- 
73 de LA5NTA/Martin


John G8BPQ
 

As I have said before, the software is working as intended. Sending CONREQ
reports as “ARQ” messages on the data session when there isn’t an active ARQ
session isn’t documented and should be.

73,
John G8BPQ

________________________________________
From: developers@ardop.groups.io [mailto:developers@ardop.groups.io] On
Behalf Of Martin Hebnes Pedersen
Sent: 28 May 2018 08:11
To: developers@ardop.groups.io
Subject: Re: [ardop_developers] ARDOPc logging to the wrong file descriptor?

Please consider responding. I would really like to get this issue resolved
for the users.

My question; There is a discrepancy between ARDOPc/ARDOP_Win and the host
interface specification. As a result, Pat is not fully compatible with the
current ARDOP v1 releases.
What do we change? The interface spesification and affected host
application(s)? ARDOPc, ARDOP_WIN (and other TNC implementations)?

John; Maybe you can ask Rick to have a look at this thread please?

Thank you!

-- 
73 de LA5NTA/Martin


Martin Hebnes Pedersen
 

Thanks for coming back to me again John.

I was under the impression that it was not up to you how the host interface work, and that it was unclear whether or not the specification should be updated.

I can't change how this works - all I do is follow Rick's code. I expect he will comment on this at some point. ARDOP_WIN does the same as I do (though didn’t have the bug in the MONITOR command that I have now fixed). If it was my choice I’d change the specification document, as I believe how it works is logical, but as I say it isn’t my decision. 
I was hoping for a comment from Rick on the matter, as you implied. Anyway, I will update Pat to handle these ARQ frames as you have described them. Hopefully, the host API specification will be updated accordingly.

Thank you again for getting back to me.

-- 
73 de LA5NTA/Martin