My IGate works fine and shows RF as well as TCP/IP stations on the map, until... if for some reason my Internet goes down for a brief period. After the connection comes back, YAAC only seems to receive packets from the RF side, not from the APRS-IS side. My ability to send to the APRS-IS restores without a problem.
When connecting a second station out in the field and using a WiFi hotspot, I never see TCP/IP packets from the APRS-IS, though I can send to APRS-IS just fine. I have made sure that the computer is in the DMZ for the hotspot.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note that the APRS-IS backbone servers will not send any APRS packets to a client unless:
1. the packets are messages addressed to a station that the client has forwarded to the backbone (Rx I-gating), or are position reports for stations that have just sent such messages.
2. the filter expression specified for the client connection would have included the packet.
So, if your APRS-IS connection bounces, the new connection won't know about any of your RF-local stations (and therefore won't forward for them) until the next time you forward packets about them to the Internet.
Note that YAAC does automatically generate a default filter expression only for configurations that only have an APRS-IS connection but no RF connection. Adding an RF connection after the APRS-IS connection would not automatically clear the default filter expression until the next time the APRS-IS connection is established (i.e., after a connection loss). So, if your configuration contains both an APRS-IS and RF port configuration, but the RF port is either initially disabled, or happens to be the second port (such that it would not exist yet when the first APRS-IS port is initially opened during startup), it is possible that YAAC would create the default filter expression for the initial opening of APRS-IS, but not do so for the second opening.
Note that creating the default filter expression in this case is a bug; not having the default filter for re-connect is the correct behavior. If you always want a filter expression to force you to receive APRS-IS packets that wouldn't be Tx I-gated by your station, you should explicitly specify the filter expression rather than depending on intermittent faulty behavior of defaults.
Hope this helps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not sure I explained it correctly. Ops normal, I see TCP/IP APRS stations on my screen. These are not RF stations. They are things like people using APRS on their phones, some objects, and some weather stations. An example is KG5EO. They show up fine unless for some reason I temporarily lose my internet connection. After the internet connection is restored, I no longer get anything from APRS-IS about these stations -- they no longer show up in my Raw Packets list even though I can watch on aprs.fi and see when they send new TCP/IP beacons. The only way to get them to start showing again is to close and restart YAAC, though occasionally I have had to restart more than once to get them back.
Nothing to do with the RF port -- that part works fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not sure I am explaining correctly. Ops normal: I see stations on YAAC that are TCP/IP only, not RF. These are things like people using APRS on a phone, some objects, and some weather stations. An example is KG5EO. These show up fine until I have a temporary Internet disruption. After the Internet connection is restored, I no longer receive anything for these TCP/IP stations from APRS-IS, at least nothing shows for them in my Raw Packets view, even though I can watch on aprs.fi and see that they sent a TCP/IP beacon. The only way to restore them is to close and restart YAAC, though occasionally this has to be done twice to start seeing them again.
Nothing to do with the RF side, that part seems to work fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The issue here is that you are assuming the default filter YAAC introduces for APRS-IS connections when there is no RF connections is the standard behavior. It is not; it is merely a convenience for new users to ensure they see something when they start YAAC up the first time. It is recommended that, if you want a filter on the APRS-IS connection, you should always specify it explicitly yourself, to ensure you receive the data you want to receive, instead of what the YAAC author guessed you might want to receive. The reason that there is no default filter for I-gate-configured installations is because anyone running an I-gate is presumed to be sufficiently advanced as to be able to specify what they want, and a normal unattended I-gate deployment wouldn't want extra packets anyway.
In short, I really need to fix the YAAC startup logic so it doesn't bring up APRS-IS connections until any available RF connections are started first, to ensure the default filter logic is consistently invoked.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK. I think I am tracking what you are saying. So when the APRS-IS connection is lost, if there is no defined filter, when it comes back YAAC applies a different filter to the APRS-IS port than it had on start up. So defining something as simple as m/150 in the APRS-IS port will stop that behavior?
I had never applied a filter on the APRS-IS port in the past as I never seemed to be swamped by TCP-IP traffic. I had looked at filter expressions, but whatever the default action was on start-up seemed to work fine, so I left it alone.
Last edit: John 2015-10-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My IGate works fine and shows RF as well as TCP/IP stations on the map, until... if for some reason my Internet goes down for a brief period. After the connection comes back, YAAC only seems to receive packets from the RF side, not from the APRS-IS side. My ability to send to the APRS-IS restores without a problem.
When connecting a second station out in the field and using a WiFi hotspot, I never see TCP/IP packets from the APRS-IS, though I can send to APRS-IS just fine. I have made sure that the computer is in the DMZ for the hotspot.
Note that the APRS-IS backbone servers will not send any APRS packets to a client unless:
1. the packets are messages addressed to a station that the client has forwarded to the backbone (Rx I-gating), or are position reports for stations that have just sent such messages.
2. the filter expression specified for the client connection would have included the packet.
So, if your APRS-IS connection bounces, the new connection won't know about any of your RF-local stations (and therefore won't forward for them) until the next time you forward packets about them to the Internet.
Note that YAAC does automatically generate a default filter expression only for configurations that only have an APRS-IS connection but no RF connection. Adding an RF connection after the APRS-IS connection would not automatically clear the default filter expression until the next time the APRS-IS connection is established (i.e., after a connection loss). So, if your configuration contains both an APRS-IS and RF port configuration, but the RF port is either initially disabled, or happens to be the second port (such that it would not exist yet when the first APRS-IS port is initially opened during startup), it is possible that YAAC would create the default filter expression for the initial opening of APRS-IS, but not do so for the second opening.
Note that creating the default filter expression in this case is a bug; not having the default filter for re-connect is the correct behavior. If you always want a filter expression to force you to receive APRS-IS packets that wouldn't be Tx I-gated by your station, you should explicitly specify the filter expression rather than depending on intermittent faulty behavior of defaults.
Hope this helps.
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Not sure I explained it correctly. Ops normal, I see TCP/IP APRS stations on my screen. These are not RF stations. They are things like people using APRS on their phones, some objects, and some weather stations. An example is KG5EO. They show up fine unless for some reason I temporarily lose my internet connection. After the internet connection is restored, I no longer get anything from APRS-IS about these stations -- they no longer show up in my Raw Packets list even though I can watch on aprs.fi and see when they send new TCP/IP beacons. The only way to get them to start showing again is to close and restart YAAC, though occasionally I have had to restart more than once to get them back.
Nothing to do with the RF port -- that part works fine.
Not sure I am explaining correctly. Ops normal: I see stations on YAAC that are TCP/IP only, not RF. These are things like people using APRS on a phone, some objects, and some weather stations. An example is KG5EO. These show up fine until I have a temporary Internet disruption. After the Internet connection is restored, I no longer receive anything for these TCP/IP stations from APRS-IS, at least nothing shows for them in my Raw Packets view, even though I can watch on aprs.fi and see that they sent a TCP/IP beacon. The only way to restore them is to close and restart YAAC, though occasionally this has to be done twice to start seeing them again.
Nothing to do with the RF side, that part seems to work fine.
The issue here is that you are assuming the default filter YAAC introduces for APRS-IS connections when there is no RF connections is the standard behavior. It is not; it is merely a convenience for new users to ensure they see something when they start YAAC up the first time. It is recommended that, if you want a filter on the APRS-IS connection, you should always specify it explicitly yourself, to ensure you receive the data you want to receive, instead of what the YAAC author guessed you might want to receive. The reason that there is no default filter for I-gate-configured installations is because anyone running an I-gate is presumed to be sufficiently advanced as to be able to specify what they want, and a normal unattended I-gate deployment wouldn't want extra packets anyway.
In short, I really need to fix the YAAC startup logic so it doesn't bring up APRS-IS connections until any available RF connections are started first, to ensure the default filter logic is consistently invoked.
OK. I think I am tracking what you are saying. So when the APRS-IS connection is lost, if there is no defined filter, when it comes back YAAC applies a different filter to the APRS-IS port than it had on start up. So defining something as simple as m/150 in the APRS-IS port will stop that behavior?
I had never applied a filter on the APRS-IS port in the past as I never seemed to be swamped by TCP-IP traffic. I had looked at filter expressions, but whatever the default action was on start-up seemed to work fine, so I left it alone.
Last edit: John 2015-10-11
That is correct. You should always explicitly specify the filter you want, as I might change the default filter at any time.