Is there a flag or setting to enable packets that are being transmitted by Direwolf to be read by the KISS terminal?

I had been using DW 1.6 and recently compiled 1.7 on Raspbian.

My use case is that my digipeater and igate reside on the same machine as the APRSPH bot, which I modified on top of IORETH - https://github.com/jangelor/ioreth - to act as an automated NET and message handling system - .

It works OK when packets are heard from RF, since IORETH connects via KISS. However, when packets come in from APRS-IS, IORETH is not able to read them because KISS does not display them.

The only way for IORETH to read the packets is when other stations digipeat them and it appears on the KISS terminal.

I have a vague recollection (but not 100% sure) of sent packets being included in KISS when I was still running Direwolf from an OSX machine, but since I moved my digipeater to Raspberry Pi, it was no longer the case.

So far my temporary workaround is to turn off my igate and just use direwolf as a digipeater and KISS terminal for IORETH. But it sometimes misses messages being sent from APRS-IS, as it now depends on other digipeaters/igates in my vicinity.

Any leads would be appreciated.

开云体育

Hello Angelo,

Is there a flag or setting to enable packets that are being transmitted by Direwolf to be read by the KISS terminal?

It's not very clear to me what you mean by "KISS terminal".? Are you asking if a packet comes via the APRS-IS TCP connection, you would want that packet to be sent out on all KISS interfaces as well?? If so, I'm not aware of Direwolf supporting such a feature but you might consider modifying Direwolf's source code yourself to support this odd functionality.? Alternatively, I vaguely remember seeing some Linux native user-based programs supporting replication of KISS frames across all interfaces ( KISS MUX: ) but to use it, I believe that would mean you would need to stop using APRS-IS within Direwolf and you would need to do all this with external Linux programs that natively support Linux's AX.25 stack.

Good luck with your project

--David
KI6ZHD

Some time ago I requested the APRS-IS traffic be available over TCP-KISS port.
That was implemented in V1.7C, and you can assign the port in the configuration file:
NOTE:? Traffic was (assumed still 'is') unidirectional - internet to client ONLY.

Is that what you are asking about?
-----
Rob KB8RCO

开云体育

Thanks for that Rob.? I vaguely remember this one but it's not documented anywhere other so I kept my mouth shut. :-)? I now see it in the DEV branch's source code but there is no real description of what this is in the Git commit log either.? If this user has a RF channel configured via direwolf.conf "CHANNEL 0", to forward any IGATE heard trafficthat way, would configure "IChannel 0" here?? Do you know if specifying MULTIPLE destination channels is possible here?

--David
KI6ZHD

wb2osz kind of coded it up in a day or so for me as a special request for balloon tracking.??
I only attached 1 KISS device (an APRS client), so can't say whether it would send to all attached devices - but would assume so.
Again - unidirectional!

I am actually going to track a special balloon tonight for the University of Michigan aerospace department (graduate student project).
I will give it a try and see if multiple attached KISS clients get the data.
This is what it looked like in 'my app' - tracking balloon callsign KE8PTV-11?(falling)?- last year.


The KF6RFX-15 (rising)?was another one of the balloons we were tracking.? There were 5 total, but only 3 in the air at once.
We could (of course) only point at 1 of them at a time.? We switch to the 'next landing' balloon for recovery.
-----
Rob KB8RCO

As I reread David's question, I am a little confused.
? ?>??If this user has a RF channel configured via direwolf.conf "CHANNEL 0", to forward any IGATE heard trafficthat way, would configure "IChannel 0" here?
If you configure ICHANNEL 0, I would assume that would cause an error. The other option would be the data from the soundcard would be 'muted' and the data from APRS-IS would be sent as TCP/IP KISS on 'stream 0'
Again, the concept of ICHANNEL was listeing to APRS-IS and sending the packets out to attached clients over KISS over TCP/IP

I will use my balloon tracking configuration file to explain.
? ? ADEVICE0? - null? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? # RTL_FM feed audio in through standard input, 'listen only'
? ? ACHANNEL 1
? ? CHANNEL 0
? ? MYCALL KB8RCO-2
? ? MODEM 1200
#? MODEM 9600

# ? CHANNEL 1? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? # Not used as Device 0 only has 1 channel

? ? CHANNEL 2
? ? MYCALL KB8RCO-3
? ? MODEM 1200
#? MODEM 9600

In the picture that was previously posted, you see "CH ##:" which indicates which KISS stream identifier the data came in on.
? ? ? CH? 0 -> RTL dongle => Direwolf => 'my antenna pointing client' (picture is that output)
? ? ? CH? 1 -> no data because ADEVICE0 only has 1 channel
? ? ? CH? 2 -> Sound card => Direwolf => 'my antenna pointing client' (picture is that output)
? ? ? CH? 3 -> no data because ADEVICE1 only has 1 channel
? ? ? CH 15 -> APRS-IS => Direwolf => my 'antenna pointing client' (picture is that output)
? ? ? ? ? ? ? ? ? ? ? NOTE: nothing into CH 15 is going.? That is actually handled by the IGATE function of Direwolf.
? ? ? ? ? ? ? ? ? ? ? Any attached client would send on channel 0 (not capable), or Channel 2.
Now add a second APRS 'client2' that attaches to Direwolf:
? ? ? CH? 0 -> RTL dongle => Direwolf => client2
? ? ? CH? 1 -> no data because ADEVICE0 only has 1 channel
? ? ? CH? 2 -> Sound card => Direwolf => client2
? ? ? CH? 3 -> no data because ADEVICE1 only has 1 channel
? ? ? CH 15 -> APRS-IS => Direwolf => client2
? ? ? ? ? ? ? ? ? ? ? NOTE: nothing?into?CH 15 is going.? That is actually handled by the IGATE function of Direwolf.
? ? ? ? ? ? ? ? ? ? ? Any attached client would send on channel 0 (not capable), or Channel 2.
When client2 transmits, Direwolf receives the requests and acts on it accordingly.?
I am pretty sure that if client 2 sends (say a position) the packet to Direwolf, that will be sent out according to the Direwolf configuration (any TX available port).
? ?In the example above, that would be CH0 (to null device), CH3 (plughw), and APRS-IS (since it is configured).?
? ?Since CH 15 is redundant with APRS-IS, there is no need to send it over CH 15.? It would be a duplicate.
Same with 'my antenna pointing client' sending packets.
-----
Rob KB8RCO

Hi Rob and David,

Thank you for the discussions and the advice. Adding IChannel 15 seems to work. I am still monitoring my logs and kissutil to see if has unwanted results. But so far, attached clients are now able to read packets received via igate.

Should you wish to check out the application I am developing and maintaining, I would be happy to share -- .

Cheers,

angelo

I have a follow-up question.

Is it normal for packets sent via KISS TNC to not be gated from KISS (RF) to APRS-IS?

As per my experience, packets need to be gated by OTHER digipeaters, but not necessarily my own.

Is there a flag or setting to tell direwolf to gate packets sent by applications via KISS TNC into its own igate? I could not seem to find any in the documentation.

开云体育

Hello,

Is it normal for packets sent via KISS TNC to not be gated from KISS (RF) to APRS-IS?

That depends on your Direwolf's configuration specifically around 1) did you first beacon your station's position (PBEACON sendto=IG)? and 2) what are your APRS filters (IGFILTER).? The Direwolf User Guide section 9.10 gives a good overview of all this.

--David
KI6ZHD

As per my experience, packets need to be gated by OTHER digipeaters, but not necessarily my own.

Is there a flag or setting to tell direwolf to gate packets sent by applications via KISS TNC into its own igate? I could not seem to find any in the documentation.

Hi David,

Thanks for the reply. To answer your question, (1) yes my station's position is beaconed to both RF and IG.

As for (2), I don't understand -- I thought that IGFILTER is supposed to define the additional packets to retrieve from APRS-IS and not the other way around.

I have basically observed that packets sent by clients using KISS TCP are not injected into IS from my own direwolf even if they were also sent via RF by my own station. Thus, they are only gated when received by other igates. Any other packets received via RF are gated.

Is this normal behavior?

By defining Ichannel 15 as per the previous messages, KISS clients are now able to read everything received via APRS-IS. I also need direwolf to send to APRS-IS all packets sent by KISS TCP clients.