开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. Yaac-Users
  2. Messages
Expanded Topics Messages Polls
Date
JSSC on M1

 

Hi Andrew,
What JSSC are you using. Is it the one at


Carl.
Re: YAAC on Mac mini M1 ?

 

Just so you know, there are many users using YAAC on the Raspberry Pi computers (which are also ARM processors), but these are running Linux, not Mac OS X, so there are differences in the native libraries.

________________________________________
From: [email protected] <[email protected]> on behalf of Andrew P. <andrewemt@...>
Sent: Friday, January 7, 2022 11:28 AM
To: [email protected]
Subject: Re: [yaac-users] YAAC on Mac mini M1 ?

The primary issue with the Mac Mini is the native libraries for the serial port Java library (JSSC) used by YAAC. If you can get a Java runtime for your operating system and CPU hardware, most of YAAC will work. However, the JSSC library won't load if it can't find a matching native library in the JSSC distribution, so any of the ports using a physical serial port (such as Serial_TNC, Serial_GPS, Serial_Weather) won't work.

If you install the JSSC library version for your operating system on your system, it may work. YAAC looks for an O/S provided native JSSC library before falling back to the versions shipped with YAAC.

Hope this helps.

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of Nita WA4VQW <wa4vqw@...>
Sent: Friday, January 7, 2022 10:48 AM
To: [email protected]
Subject: [yaac-users] YAAC on Mac mini M1 ?

The ka2ddo web page for YAAC suggests that it will only run on x86 based OS X. Is this due to the situation concerning a JRE, or is there some other issue holding it back ?

I currently have a Mac mini M1 with a TAPRN 9600 TNC plugged into a USB port. While I don't have a proper APRS client on it. I can run screen and capture all the radio traffic as it is being seen. So that data path from the radio to the TNC to the Mac mini is all functional. I'm currently downloading an Azul ARM64 JRE to see how useful that might be.

73
Re: YAAC & triggered beacons

 

Hi Andrew,

I'll take a look into that. Winters are long here, so I've been thinking about other potential data sources (other than weather) that might be interesting to xmit through APRS. I'm aware of lightning and geiger counter maps that have crowd-sourced data. I think these just go directly to their aggregating servers via TCP/IP, no radio involved.

Having YAAC work off a file wouldn't be necessary, it would be easy enough to implement the nc method if I got the packet format correct. Then a person could issue a cron job or whatever other method they wanted to call a script around nc to assemble and transmit the packet.

73, KD0KZE / Paul

On 1/6/22 15:27, Andrew P. wrote:
Not exactly in the way I'm guessing you're thinking of.
The ExternalMessageSource port type was created for exactly the reason you're talking about: so an arbitrary message can be sent through the application at any time. However, it doesn't create the message; the external application has to compose the APRS packet. I once thought about adding macro support so you could send a position message and have various parameters (latitude, longitude, timestamp, etc.) be plugged in on-the-fly from the YAAC configuration and runtime state, but there never was enough demand for more functionality there (and enough other places in the code that did have demands) that I never got around to it.
The problem with reading a file is that you can't asynchronously detect when the file has been changed. I'm not particularly thrilled with the WXNOW.TXT port driver, because it has to poll the file every few seconds to see if it has been changed, which isn't the most efficient way to do things. And there's no platform-portable way (other than network sockets) to poke the YAAC application from outside the application to tell it to do something programmatically.
Thankfully, someone wrote the NetCat command (sometimes called nc or ncat) which provides the relay between network sockets and files or shell scripts, so if you wanted to copy a file containing a packet into YAAC, you could use the 'nc' command to copy it to the External Message Source listening socket, which would cause the message to be transmitted.
Hope that helps.
Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Paul Bramscher
Sent: Wednesday, January 5, 2022 9:36 PM
Greetings Andrew,
I'm wondering whether YAAC is capable of being programmatically
"triggered" to send a beacon, and whether it can read the contents of a
file as its message.
I see some reference in the docs
() but I
don't know if that's quite what I'm looking for. It would be
interesting if there was a sort of API such that we might provide a
beacon message and a command to transmit on-demand.
I don't have a particular use-case, but it seems that a number of
possibilities might exist (Linux user here).
73, KD0KZE / Paul
Re: next beta build#168 of YAAC, created 2022-Jan-06

 

Will be nice if we can manually set a station, so in a new blacklist that we still get Igate and not digipeat, like a WX station that send every 2 minutes packets in wide1-1,wide2-1.

Sorry I’m French and technical in English is hard for me.

Ve2pcq



Le ven. 7 janv. 2022 à 13:09, Andrew P. <andrewemt@...> a écrit?:
Let me make sure I understand your request correctly. You want a per-callsign blacklist that only applies to digipeating, but to not Tx I-gating? Or are you looking for throttling on specific callsigns (regardless of what packets they send), so they can't abuse the digi by making minor modifications to their packets to bypass the duplicate checking in the digipeater logic?

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Pascal Charette
Sent: Friday, January 7, 2022 12:58 PM

I know that I have already asked for that option without success, but it will be very nice here on my digipeater that has a very big coverage that is able to gate a specific station on RF, but not allow it to retransmit on RF side. Because some stations are not using the recommended? delay between packets. And with a Retransmit Black list, it will decrease the number of packets in my location. I think VE2PCQ-3 has the biggest coverage of all Québec.

Thanks
Pascal, ve2pcq
Re: next beta build#168 of YAAC, created 2022-Jan-06

 

Let me make sure I understand your request correctly. You want a per-callsign blacklist that only applies to digipeating, but to not Tx I-gating? Or are you looking for throttling on specific callsigns (regardless of what packets they send), so they can't abuse the digi by making minor modifications to their packets to bypass the duplicate checking in the digipeater logic?

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Pascal Charette
Sent: Friday, January 7, 2022 12:58 PM

I know that I have already asked for that option without success, but it will be very nice here on my digipeater that has a very big coverage that is able to gate a specific station on RF, but not allow it to retransmit on RF side. Because some stations are not using the recommended delay between packets. And with a Retransmit Black list, it will decrease the number of packets in my location. I think VE2PCQ-3 has the biggest coverage of all Québec.

Thanks
Pascal, ve2pcq
Re: next beta build#168 of YAAC, created 2022-Jan-06

 

I know that I have already asked for that option without success, but it will be very nice here on my digipeater?that has a very big coverage?that is able to gate a specific station?on RF, but not allow it to retransmit on RF side. Because some stations are not using the recommended? delay between packets. And with a Retransmit Black list, it will decrease?the number of packets in my location. I think VE2PCQ-3 has the biggest coverage of all Québec.



Thanks
Pascal, ve2pcq


Le?jeu. 6 janv. 2022 à?22:52, Andrew P. <andrewemt@...> a écrit?:
next beta build#168 of YAAC ("Yet Another APRS Client"), created 2022-Jan-06

downloadable from
? ? ? ? ? ? ? ?or

changes and updates include:
1. fix Locate->Station so it can locate Objects with mixed-case or lowercase
? ? ?object names.
2. fix popup menu "View Station on Radio" so if record is picked from a table
? ? ?showing individual packets (instead of just the station as a whole),
? ? ?show that packet. Selecting a station or object on the map view or a table
? ? ?view where the records are for different stations still shows the most
? ? ?recent packet from that station or about that object.
3. block Tx I-gating of self-addressed text messages (such as telemetry
? ? ?interpretation messages from a station sending telemetry).
4. change Tx I-gating RF header to be the sender and destination of the
? ? ?APRS-IS sourced packet, with the I-gate station callsign in the RF digipeat
? ? ?alias set as an already-digipeated digipeater (with any WIDEn-N alias
? ? ?after that unused). This undoes a change from build#146.
5. when right-clicking on a single station object's history of raw packets,
? ? ?allow the popup menu for all types, not just objects.
6. fix connection-lost reconnection logic in AGWPE port driver.
7. fix DNS-SD service discovery logic to wait a maximum of 5 seconds for an
? ? answer before giving up.
8. fix timestamps of dynamic objects so they advance as the objects move.
9. fix speed column on dynamic objects table to be in configured distance
? ? units instead of locked into statute miles per hour.
10. fix NullPointerException problem with dynamic object table bearing
? ? ?column editor.
11. fix NullPointerException problem with loading route files.
12. fix editor for Dynamic Object table's route name column so the blank
? ? ?route name (no route) is the same height as the named routes' names.
13. recompile the dnsjava library with Java 8 to stop the
? ? ?UnsupportedClassVersionExceptions when somone tries to open the
? ? ?AGWPE or KISS-over-TCP port editors with Java 8.




WX3IN1 209.jpg

Re: YAAC on Mac mini M1 ?

 

The primary issue with the Mac Mini is the native libraries for the serial port Java library (JSSC) used by YAAC. If you can get a Java runtime for your operating system and CPU hardware, most of YAAC will work. However, the JSSC library won't load if it can't find a matching native library in the JSSC distribution, so any of the ports using a physical serial port (such as Serial_TNC, Serial_GPS, Serial_Weather) won't work.

If you install the JSSC library version for your operating system on your system, it may work. YAAC looks for an O/S provided native JSSC library before falling back to the versions shipped with YAAC.

Hope this helps.

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of Nita WA4VQW <wa4vqw@...>
Sent: Friday, January 7, 2022 10:48 AM
To: [email protected]
Subject: [yaac-users] YAAC on Mac mini M1 ?

The ka2ddo web page for YAAC suggests that it will only run on x86 based OS X. Is this due to the situation concerning a JRE, or is there some other issue holding it back ?

I currently have a Mac mini M1 with a TAPRN 9600 TNC plugged into a USB port. While I don't have a proper APRS client on it. I can run screen and capture all the radio traffic as it is being seen. So that data path from the radio to the TNC to the Mac mini is all functional. I'm currently downloading an Azul ARM64 JRE to see how useful that might be.

73
YAAC on Mac mini M1 ?

 

The ka2ddo web page for YAAC suggests that it will only run on x86 based OS X. Is this due to the situation concerning a JRE, or is there some other issue holding it back ?

I currently have a Mac mini M1 with a TAPRN 9600 TNC plugged into a USB port. While I don't have a proper APRS client on it. I can run screen and capture all the radio traffic as it is being seen. So that data path from the radio to the TNC to the Mac mini is all functional. I'm currently downloading an Azul ARM64 JRE to see how useful that might be.

73
next beta build#168 of YAAC, created 2022-Jan-06

 

next beta build#168 of YAAC ("Yet Another APRS Client"), created 2022-Jan-06

downloadable from
or

changes and updates include:
1. fix Locate->Station so it can locate Objects with mixed-case or lowercase
object names.
2. fix popup menu "View Station on Radio" so if record is picked from a table
showing individual packets (instead of just the station as a whole),
show that packet. Selecting a station or object on the map view or a table
view where the records are for different stations still shows the most
recent packet from that station or about that object.
3. block Tx I-gating of self-addressed text messages (such as telemetry
interpretation messages from a station sending telemetry).
4. change Tx I-gating RF header to be the sender and destination of the
APRS-IS sourced packet, with the I-gate station callsign in the RF digipeat
alias set as an already-digipeated digipeater (with any WIDEn-N alias
after that unused). This undoes a change from build#146.
5. when right-clicking on a single station object's history of raw packets,
allow the popup menu for all types, not just objects.
6. fix connection-lost reconnection logic in AGWPE port driver.
7. fix DNS-SD service discovery logic to wait a maximum of 5 seconds for an
answer before giving up.
8. fix timestamps of dynamic objects so they advance as the objects move.
9. fix speed column on dynamic objects table to be in configured distance
units instead of locked into statute miles per hour.
10. fix NullPointerException problem with dynamic object table bearing
column editor.
11. fix NullPointerException problem with loading route files.
12. fix editor for Dynamic Object table's route name column so the blank
route name (no route) is the same height as the named routes' names.
13. recompile the dnsjava library with Java 8 to stop the
UnsupportedClassVersionExceptions when somone tries to open the
AGWPE or KISS-over-TCP port editors with Java 8.
Re: YAAC & triggered beacons

 

Not exactly in the way I'm guessing you're thinking of.

The ExternalMessageSource port type was created for exactly the reason you're talking about: so an arbitrary message can be sent through the application at any time. However, it doesn't create the message; the external application has to compose the APRS packet. I once thought about adding macro support so you could send a position message and have various parameters (latitude, longitude, timestamp, etc.) be plugged in on-the-fly from the YAAC configuration and runtime state, but there never was enough demand for more functionality there (and enough other places in the code that did have demands) that I never got around to it.

The problem with reading a file is that you can't asynchronously detect when the file has been changed. I'm not particularly thrilled with the WXNOW.TXT port driver, because it has to poll the file every few seconds to see if it has been changed, which isn't the most efficient way to do things. And there's no platform-portable way (other than network sockets) to poke the YAAC application from outside the application to tell it to do something programmatically.

Thankfully, someone wrote the NetCat command (sometimes called nc or ncat) which provides the relay between network sockets and files or shell scripts, so if you wanted to copy a file containing a packet into YAAC, you could use the 'nc' command to copy it to the External Message Source listening socket, which would cause the message to be transmitted.

Hope that helps.

Andrew, KA2DDO
author of YAAC
________________________________________
From: [email protected] <[email protected]> on behalf of Paul Bramscher
Sent: Wednesday, January 5, 2022 9:36 PM

Greetings Andrew,

I'm wondering whether YAAC is capable of being programmatically
"triggered" to send a beacon, and whether it can read the contents of a
file as its message.

I see some reference in the docs
() but I
don't know if that's quite what I'm looking for. It would be
interesting if there was a sort of API such that we might provide a
beacon message and a command to transmit on-demand.

I don't have a particular use-case, but it seems that a number of
possibilities might exist (Linux user here).

73, KD0KZE / Paul
YAAC & triggered beacons

 

Greetings Andrew,

I'm wondering whether YAAC is capable of being programmatically "triggered" to send a beacon, and whether it can read the contents of a file as its message.

I see some reference in the docs () but I don't know if that's quite what I'm looking for. It would be interesting if there was a sort of API such that we might provide a beacon message and a command to transmit on-demand.

I don't have a particular use-case, but it seems that a number of possibilities might exist (Linux user here).

73, KD0KZE / Paul
Re: [bug] Same message received from different sender.

 

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Saturday, January 1st, 2022 at 12:46, Andrew P. <andrewemt@...> wrote:

OK, finally got this figured out.

It seems a long time ago in build#146, I thought I was fixing a bug with station identification for Tx I-gating, and I fixed it wrong. You are seeing the results of this, because of the callsign change in the Tx I-gate transmission, which is getting echoed back to you by a local RF digipeater (K3NAL-1 in your sample log below), so it does look like a transmission from a different originating station (i.e., originated by your I-gate WG3K-15).

I will be fixing this in the first build of the New Year.
Great, glad you were able to find the problem.

73,
Eric WG3K
Re: [bug] Same message received from different sender.

 

OK, finally got this figured out.

It seems a long time ago in build#146, I thought I was fixing a bug with station identification for Tx I-gating, and I fixed it wrong. You are seeing the results of this, because of the callsign change in the Tx I-gate transmission, which is getting echoed back to you by a local RF digipeater (K3NAL-1 in your sample log below), so it does look like a transmission from a different originating station (i.e., originated by your I-gate WG3K-15).

I will be fixing this in the first build of the New Year.

Andrew, KA2DDO

________________________________________
From: [email protected] <[email protected]> on behalf of Eric H. Christensen via groups.io <eric@...>
Sent: Saturday, December 18, 2021 11:14 PM
To: [email protected]
Subject: Re: [yaac-users] [bug] Same message received from different sender.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, December 18th, 2021 at 20:18, Eric H. Christensen via groups.io <eric@...> wrote:

Another bug I have found. When I receive a message that goes through my gateway the first message shows as received from the originating station (in this case N8VNR) and subsequent messages are shown as received from my gateway (WG3K-15).
Just grabbed the received packets from the log. It looks like YAAC might not be handling third-party packets appropriately? I have no idea why these packets are coming in as third-party packets when the initial packet comes in normally, but I'd think that YAAC should be able to handle them properly.

N8VNR>APJYC1:N8VNR>APJYC1,TCPIP*,qAC,T2ALBERTA::WG3K :ooh, I see it acked now. and your test.{C000b
WG3K-15>APMI06:WG3K-15>APMI06,K3NAL-1,WIDE2*,qAR,WG3K-15:}N8VNR>APJYC1,TCPIP,WG3K-15*::WG3K :ooh, I see it acked now. and your test.{C000b
N8VNR>APJYC1:N8VNR>APJYC1,TCPIP*,qAC,T2ALBERTA::WG3K :ackC0007
WG3K-15>APMI06:WG3K-15>APMI06,K3NAL-1,WIDE2*,qAR,WG3K-15:}N8VNR>APJYC1,TCPIP,WG3K-15*::WG3K :ackC0007
N8VNR>APJYC1:N8VNR>APJYC1,TCPIP*,qAC,T2ALBERTA::WG3K :and now the chat is doing the dupe thing{C000c
WG3K-15>APMI06:WG3K-15>APMI06,K3NAL-1,WIDE2*,qAR,WG3K-15:}N8VNR>APJYC1,TCPIP,WG3K-15*::WG3K :and now the chat is doing the dupe thing{C000c
null>APJYC1,WIDE2-2::N8VNR :The dupe thing?{C0008
N8VNR>APJYC1:N8VNR>APJYC1,TCPIP*,qAC,T2ALBERTA::WG3K :ackC0008
WG3K-15>APMI06:WG3K-15>APMI06,K3NAL-1,WIDE2*,qAR,WG3K-15:}N8VNR>APJYC1,TCPIP,WG3K-15*::WG3K :ooh, I see it acked now. and your test.{C000b
WG3K>APJYC1:WG3K>APJYC1,K3NAL-1*,WIDE2-1,qAO,WG3K,qAR,WG3K-15::N8VNR :The dupe thing?{C0008
WG3K-15>APMI06:WG3K-15>APMI06,K3NAL-1,WIDE2*,qAR,WG3K-15:}N8VNR>APJYC1,TCPIP,WG3K-15*::WG3K :ackC0008
WG3K-15>APMI06:WG3K-15>APMI06,K3NAL-1,WIDE2*,qAR,WG3K-15:}N8VNR>APJYC1,TCPIP,WG3K-15*::WG3K :and now the chat is doing the dupe thing{C000c
WG3K-15>APMI06:WG3K-15>APMI06,K3NAL-1,WIDE2*,qAR,WG3K-15:}N8VNR>APJYC1,TCPIP,WG3K-15*::WG3K :ooh, I see it acked now. and your test.{C000b
null>APJYC1,WIDE2-2::N8VNR :I'm not sure why I'm showing up as qAO which should be a rx-only{C0009
N8VNR>APJYC1:N8VNR>APJYC1,TCPIP*,qAC,T2ALBERTA::WG3K :ackC0009
WG3K>APJYC1:WG3K>APJYC1,K3NAL-1*,WIDE2-1,qAO,WG3K,qAR,WG3K-15::N8VNR :I'm not sure why I'm showing up as qAO which should be a rx-only{C0009
WG3K-15>APMI06:WG3K-15>APMI06,K3NAL-1,WIDE2*,qAR,WG3K-15:}N8VNR>APJYC1,TCPIP,WG3K-15*::WG3K :ackC0009
WG3K-15>APMI06:WG3K-15>APMI06,K3NAL-1,WIDE2*,qAR,WG3K-15:}N8VNR>APJYC1,TCPIP,WG3K-15*::WG3K :and now the chat is doing the dupe thing{C000c
null>APJYC1,WIDE2-2::N8VNR :i-gate. Just verified my settings... Should be bidirectional.{C000a
N8VNR>APJYC1:N8VNR>APJYC1,TCPIP*,qAC,T2ALBERTA::WG3K :ackC000a
WG3K>APJYC1:WG3K>APJYC1,K3NAL-1*,WIDE2-1,qAO,WG3K,qAR,WG3K-15::N8VNR :i-gate. Just verified my settings... Should be bidirectional.{C000a

73,
Eric WG3K
Re: null pointer exception when configuring AGWPE port

 

Thank you for finding this bug that was introduced in build#166. Annoyingly enough, it only affects re-connects to AGWPE (or compatible) software modems, but it is an issue on all platforms. I have a fix, for the next build, which should come out within the next couple of days. I don't think I'll get it done this year (not with less than an hour and a half left to go through the release process) :-) so you'll have to wait until next year for it.

Happy New Year!

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of Bill AA6BD <bill@...>
Sent: Thursday, December 30, 2021 11:58 AM
To: [email protected]
Subject: [yaac-users] null pointer exception when configuring AGWPE port

I am running on Bullseye on a Raspberry Pi 4. I had run this same image on a Pi 3 but was having some trouble with the HDMI display on the Pi 3. Configuration:
YAAC 1.0-beta167
Dire Wolf 1.6
Pi USB connected to an DRA-30 and then to an IC-7100

When I start YAAC, the configured ports are GPS, IP, and RF.
I tried to edit the RF port to enable transmitting. When I click Transmit: Enable, then Save, nothing happens. Then I click Cancel.
The RF port is shown as greyed out.
When I click the RF port again, I get an error message, about a null pointer exception, and I have attached a log file and configuration file.
Re: null pointer exception when configuring AGWPE port

 

As suggested, I installed JRE 11 on Windows, and I am seeing the same behavior there.

--Bill AA6BD
null pointer exception when configuring AGWPE port

 

I am running on Bullseye on a Raspberry Pi 4.? I had run this same image on a Pi 3 but was having some trouble with the HDMI display on the Pi 3.? Configuration:
YAAC 1.0-beta167
Dire Wolf 1.6
Pi USB connected to an DRA-30 and then to an IC-7100

When I start YAAC, the configured ports are GPS, IP, and RF.
I tried to edit the RF port to enable transmitting.? When I click Transmit: Enable, then Save, nothing happens.? Then I click Cancel.
The RF port is shown as greyed out.
When I click the RF port again, I get an error message, about a null pointer exception, and I have attached a log file and configuration file.
?

YAAC-Config-2021-12-30.xml
YAAC-Config-2021-12-30.xml
YAAC.out
YAAC.out

Re: Announcements

 

Oops, missed one thing. It is possible to suppress any form of announcement of receipt of a message addressed to your station, from the expert-mode Configuration dialog's Behavior tab. The very first control on that panel is the somewhat mislabeled "Beep if an alert message is received" checkbox. If that is unchecked, no sound effects (default or Sounds plugin) will happen. The Message window will still pop to the foreground, however.

________________________________________
From: [email protected] <[email protected]> on behalf of Andrew P.
Sent: Tuesday, December 28, 2021 2:03 PM

Hmphf.... this didn't get posted to the list, so I'll send it again (sorry for the duplicate, Michael).
------
Do you have the Sounds plugin installed? If so, do you have a sound effect or speech configured for Messages To You?

Alternatively, if the message is addressed to you, are you seeing the Messages window popping forwards when such a message arrives? The default Java AWT Toolkit beep() method isn't very reliable, but (assuming you haven't disabled system alert sounds in your operating system), you should also get a beep when a message is addressed to your station, assuming you haven't overridden that behavior with the Sounds plugin.

Those are the ways YAAC informs you in real-time that a message addressed to your callsign-SSID has arrived. Note this doesn't match just on your callsign; each callsign-SSID combination is treated uniquely.

Hope this helps.

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of Michael WA7SKG <wa7skg@...>
Sent: Friday, December 24, 2021 3:42 PM
To: [email protected]
Subject: [yaac-users] Announcements

My biggest problem with this stuff is, I set it up, then promptly forget
everything about it.

I thought there was some kind of announcement or bell or something that
sounded when I received a message to me via APRS. I just happened to
look at the screen and realized there was a whole pile of messages that
came in yesterday. I don't know if it is because they are old, but they
are all very dim in the message list, so I didn't see them at first.

Anyhow, not I cannot find where I set up the announcements that I had an
incoming message. Can somebody remind me where that is? Or is my memory
so faulty it doesn't really exist?

Thanks.

Merry Christmas

--
73,
Michael WA7SKG

"Any day you do not learn one new thing is a wasted day."
Re: Announcements

 

Hmphf.... this didn't get posted to the list, so I'll send it again (sorry for the duplicate, Michael).
------
Do you have the Sounds plugin installed? If so, do you have a sound effect or speech configured for Messages To You?

Alternatively, if the message is addressed to you, are you seeing the Messages window popping forwards when such a message arrives? The default Java AWT Toolkit beep() method isn't very reliable, but (assuming you haven't disabled system alert sounds in your operating system), you should also get a beep when a message is addressed to your station, assuming you haven't overridden that behavior with the Sounds plugin.

Those are the ways YAAC informs you in real-time that a message addressed to your callsign-SSID has arrived. Note this doesn't match just on your callsign; each callsign-SSID combination is treated uniquely.

Hope this helps.

Andrew, KA2DDO
author of YAAC

________________________________________
From: [email protected] <[email protected]> on behalf of Michael WA7SKG <wa7skg@...>
Sent: Friday, December 24, 2021 3:42 PM
To: [email protected]
Subject: [yaac-users] Announcements

My biggest problem with this stuff is, I set it up, then promptly forget
everything about it.

I thought there was some kind of announcement or bell or something that
sounded when I received a message to me via APRS. I just happened to
look at the screen and realized there was a whole pile of messages that
came in yesterday. I don't know if it is because they are old, but they
are all very dim in the message list, so I didn't see them at first.

Anyhow, not I cannot find where I set up the announcements that I had an
incoming message. Can somebody remind me where that is? Or is my memory
so faulty it doesn't really exist?

Thanks.

Merry Christmas

--
73,
Michael WA7SKG

"Any day you do not learn one new thing is a wasted day."
Re: Log4J - presume you've been asked this...

 

Excellent, thanks!

Happy Holidays,

Greg KO6TH


Andrew P. wrote:

YAAC doesn't use Log4J. Its logging is very simple and uses plain System.out.println() Java calls, with standard output duplicated to the YAAC.out rolling log file. The dnsjava library does use SLF4J, but it is not invoked with logging enabled, and this library is only used to configure and initialize AGWPE and KISS-over-TCP ports (and for no other purpose within YAAC).

So YAAC users should be safe from the Log4J vulnerability.

Andrew, KA2DDO
author of YAAC
________________________________________
From: Greg D <ko6th.greg@...>
Sent: Thursday, December 23, 2021 1:40 AM
To: Andrew P.
Subject: Log4J - presume you've been asked this...

Hi Andrew,

I'm guessing you've already been asked this, so apologies in advance. A
quick search didn't turn up anything.

There's been a lot of discussion very recently about the Log4J logging
utility, and the vulnerability that it presents. It's certainly a long
shot, but does YAAC use it for its logging? If so, I wonder if a
carefully crafted packet might be used to trigger an attack on a station.

I'm looking into the possibility of rebuilding my ham station, moving
from a PC to a Raspberry Pi for the 24x7 APRS stuff so that I don't have
to leave the PC running all the time. YAAC is the obvious application
to host that station (moving from the current APRSIS32). It would be on
the home network, inside the firewall, so I'm just being (perhaps
overly) careful.

Thanks,

Greg KO6TH
Re: Log4J - presume you've been asked this...

 

YAAC doesn't use Log4J. Its logging is very simple and uses plain System.out.println() Java calls, with standard output duplicated to the YAAC.out rolling log file. The dnsjava library does use SLF4J, but it is not invoked with logging enabled, and this library is only used to configure and initialize AGWPE and KISS-over-TCP ports (and for no other purpose within YAAC).

So YAAC users should be safe from the Log4J vulnerability.

Andrew, KA2DDO
author of YAAC
________________________________________
From: Greg D <ko6th.greg@...>
Sent: Thursday, December 23, 2021 1:40 AM
To: Andrew P.
Subject: Log4J - presume you've been asked this...

Hi Andrew,

I'm guessing you've already been asked this, so apologies in advance. A
quick search didn't turn up anything.

There's been a lot of discussion very recently about the Log4J logging
utility, and the vulnerability that it presents. It's certainly a long
shot, but does YAAC use it for its logging? If so, I wonder if a
carefully crafted packet might be used to trigger an attack on a station.

I'm looking into the possibility of rebuilding my ham station, moving
from a PC to a Raspberry Pi for the 24x7 APRS stuff so that I don't have
to leave the PC running all the time. YAAC is the obvious application
to host that station (moving from the current APRSIS32). It would be on
the home network, inside the firewall, so I'm just being (perhaps
overly) careful.

Thanks,

Greg KO6TH
1541 - 1560 of 2833