Messages: When sending messages back and forth, numerous times I have noticed that the message is resent even though ACKs have been sent and received... sometimes several minutes later. I am using YAAC, others are using APRSISCE. Is this an overall APRS problem? Is there anything that can be done about resending messages even though the ACK has been sent?
Group messaging: Playing around with group messaging. I added a custom group on my HT (VX8GR) and under YAAC - General Parameters. When I send from my HT, do I have to do something to say this is a group, or do I just send to that name just like it was a callsign?
When I just send it from the HT, I see the message in YAAC when I View - Messages - Show Raw Messages, but only if I check the Show every message box. It doesn't show anywhere else.
When I try to send to a group from YAAC, the group addresses do not show as a valid "station" in the message drop down, so I tried typing in the custom group name, but when I try to send the message, I am prompted for a password for "key store". If I hit "OK", I get an error pop-up, but the message is sent and my HT receives it as a group message. If I hit "Cancel", I get no error and the HT receives the message as a group message.
I just want to send an RF only message to others in my ARES group or special event group. Am I going about this the wrong way?
Objects. Objects appear to be working correctly in the latest releases (Yay!), however, after I uncheck the "Object active (not "killed")" box and the kill messages have been sent, if I close YAAC and re-open it, even days later, the objects suddenly get re-transmitted and/as killed again and show up on aprs.fi and on my HT. What is the correct procedure for killing an object so this won't happen?
Thanks for the great work and awesome product!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried to fix the object persistence in beta52. Let me know if you find any further difficulties with it.
Re: resending of already-acknowledged messages: per chance, was the re-send via a digipeater (in particular, a Kamtronics digipeater)? some models of Kamtronics digipeaters have been known to delay digipeating messages for several minutes, so it might have sat on a message that was acknowledged via another path. The View->Messages->Outgoing Messages view shows the last time each message was actually transmitted by YAAC, so you can tell whether the extra message copy is from YAAC or a digipeater. Not much can be done about the Kamtronics digis except to replace them with another brand of digipeater.
Re: sending to groups: you are doing the right thing, assuming you not only entered the group name, but also clicked the enabled checkbox. Another bug to fix, regarding adding enabled user-entered group names to the candidate message destination drop-down.
Re: the keystore password prompt: have you created any secret keys for message signing, or have you imported your ARRL Logbook of the World key and certificate for use with the SSL-APRS-IS port driver? If so, YAAC may ask you for the keystore password so it can extract the appropriate keys to sign any outgoing messages that may need signatures. I'll check to make sure YAAC isn't being over-aggressive about deciding it needs to open the keystore (in particular, if you haven't created any secret/symmetric keys for message signing and you're not using SSL, there is no reason for YAAC to open the keystore).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been trying investigate if the resends are a digipeater issue and have advised the others participating in our experimenting to reduce digipeating by either going direct or just WIDE1-1, not WIDE1-1, WIDE2-1. There are several of us using Kantronics, others are using Dire Wolf or other TNCs/packet engines. Since it seems to happen to all of us, it may be the digipeating.
I have no secret keys. And can I even use such keys over the air? Pretty sure SSL isn't allowed over the air as it is a form of encryption.
I am still having one object that is causing me problems, but I am pretty sure it is something I did.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Re: keys: YAAC uses keys and certificates only for authentication, not for content concealment by encryption. This allows you to legally use SSL over HamNet (for example) to authenticate to the APRS-IS backbone (the YAAC SSL implementation is locked to the null [non-encrypting] cipher only). The secret/symmetric keys are so you can attach an authenticating signature to messages you are sending to one or more other stations you share the key with. It does not encrypt the message contents. Public/private key pairs could have been used for message signing, except that the signature alone would be longer than the maximum allowed length of an APRS message packet.
FCC regulations permit the use of authentication codes over RF to control access. For example, you don't want every yahoo in the area to be able to take over control of the local repeater, so there are command codes that are kept secret by the repeater owners.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have the same problem (on beta55) with messages being resend although acknowledge is received by the destination station. I am pretty sure for that because digis do not send ACKs.
73
Apostolos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note: digis aren't supposed to send acks; only the destination receiving station is supposed to send the ack, and the ack has to make it all the way back through the digis to the originator to tell the originator that the message got through.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you are still having the problem with beta116, could you please send me the AX25xmit and AX25rcvd log files for a day when you saw this problem. Something within a week, so I can look it up on APRS-IS to get a cross-check of the messages.
I need to confirm that your copy of YAAC is actually receiving the acknowledge messages, and that they match up with your transmitted messages (i.e., the message IDs didn't get mangled, and you actually sent a message ID on your text messages).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Messages: When sending messages back and forth, numerous times I have noticed that the message is resent even though ACKs have been sent and received... sometimes several minutes later. I am using YAAC, others are using APRSISCE. Is this an overall APRS problem? Is there anything that can be done about resending messages even though the ACK has been sent?
Group messaging: Playing around with group messaging. I added a custom group on my HT (VX8GR) and under YAAC - General Parameters. When I send from my HT, do I have to do something to say this is a group, or do I just send to that name just like it was a callsign?
When I just send it from the HT, I see the message in YAAC when I View - Messages - Show Raw Messages, but only if I check the Show every message box. It doesn't show anywhere else.
When I try to send to a group from YAAC, the group addresses do not show as a valid "station" in the message drop down, so I tried typing in the custom group name, but when I try to send the message, I am prompted for a password for "key store". If I hit "OK", I get an error pop-up, but the message is sent and my HT receives it as a group message. If I hit "Cancel", I get no error and the HT receives the message as a group message.
I just want to send an RF only message to others in my ARES group or special event group. Am I going about this the wrong way?
Objects. Objects appear to be working correctly in the latest releases (Yay!), however, after I uncheck the "Object active (not "killed")" box and the kill messages have been sent, if I close YAAC and re-open it, even days later, the objects suddenly get re-transmitted and/as killed again and show up on aprs.fi and on my HT. What is the correct procedure for killing an object so this won't happen?
Thanks for the great work and awesome product!
Oops... looks like you may have fixed the object persistence thing in beta52, I just did the upgrade to that.
I tried to fix the object persistence in beta52. Let me know if you find any further difficulties with it.
Re: resending of already-acknowledged messages: per chance, was the re-send via a digipeater (in particular, a Kamtronics digipeater)? some models of Kamtronics digipeaters have been known to delay digipeating messages for several minutes, so it might have sat on a message that was acknowledged via another path. The View->Messages->Outgoing Messages view shows the last time each message was actually transmitted by YAAC, so you can tell whether the extra message copy is from YAAC or a digipeater. Not much can be done about the Kamtronics digis except to replace them with another brand of digipeater.
Re: sending to groups: you are doing the right thing, assuming you not only entered the group name, but also clicked the enabled checkbox. Another bug to fix, regarding adding enabled user-entered group names to the candidate message destination drop-down.
Re: the keystore password prompt: have you created any secret keys for message signing, or have you imported your ARRL Logbook of the World key and certificate for use with the SSL-APRS-IS port driver? If so, YAAC may ask you for the keystore password so it can extract the appropriate keys to sign any outgoing messages that may need signatures. I'll check to make sure YAAC isn't being over-aggressive about deciding it needs to open the keystore (in particular, if you haven't created any secret/symmetric keys for message signing and you're not using SSL, there is no reason for YAAC to open the keystore).
I have been trying investigate if the resends are a digipeater issue and have advised the others participating in our experimenting to reduce digipeating by either going direct or just WIDE1-1, not WIDE1-1, WIDE2-1. There are several of us using Kantronics, others are using Dire Wolf or other TNCs/packet engines. Since it seems to happen to all of us, it may be the digipeating.
I have no secret keys. And can I even use such keys over the air? Pretty sure SSL isn't allowed over the air as it is a form of encryption.
I am still having one object that is causing me problems, but I am pretty sure it is something I did.
Good luck with diagnosing any digipeater issues.
Re: keys: YAAC uses keys and certificates only for authentication, not for content concealment by encryption. This allows you to legally use SSL over HamNet (for example) to authenticate to the APRS-IS backbone (the YAAC SSL implementation is locked to the null [non-encrypting] cipher only). The secret/symmetric keys are so you can attach an authenticating signature to messages you are sending to one or more other stations you share the key with. It does not encrypt the message contents. Public/private key pairs could have been used for message signing, except that the signature alone would be longer than the maximum allowed length of an APRS message packet.
FCC regulations permit the use of authentication codes over RF to control access. For example, you don't want every yahoo in the area to be able to take over control of the local repeater, so there are command codes that are kept secret by the repeater owners.
Hello all,
I have the same problem (on beta55) with messages being resend although acknowledge is received by the destination station. I am pretty sure for that because digis do not send ACKs.
73
Apostolos
Note: digis aren't supposed to send acks; only the destination receiving station is supposed to send the ack, and the ack has to make it all the way back through the digis to the originator to tell the originator that the message got through.
The problem of re-sending acknowledged messages over and over again is still present on beta 114
If you are still having the problem with beta116, could you please send me the AX25xmit and AX25rcvd log files for a day when you saw this problem. Something within a week, so I can look it up on APRS-IS to get a cross-check of the messages.
I need to confirm that your copy of YAAC is actually receiving the acknowledge messages, and that they match up with your transmitted messages (i.e., the message IDs didn't get mangled, and you actually sent a message ID on your text messages).
Hello Andrew,
I still have the problem with beta119. Where can I sent you the logfiles?
73
I found another bug regarding processing message acknowledgements. This bug is fixed in build 120,