And what about the 3600 bit modem? 3600 may be a good option sometimes when the radio won't work at 4800.? Research needs to be done.
|
Re: Linux AX.25 stack now toxic for connected packet connections with Ubuntu 20.04 / 5.8.0-44-generic #50
Hello Basil,
I am NOT seeing your described symptom on various (7) Raspberry
Pis running the Linux AX.25 stack with Winlink, APRS &
Chattervox at 1200 & 9600 baud.
My hardware is mainly RPi 4's and sound cards using direwolf.
The issue here is *connected* AX.25 session so your Winlink
connections would be impacted.? APRS would not be impacted since
it's unconnected traffic and still works fine.
The two kernels I am using from the Raspberry Pi
Foundation (raspbian):
Linux test119022321 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT
2020 armv7l GNU/Linux
Linux pi400 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021
armv7l GNU/Linux
The way the Canonical backports fixes into older kernels is
difficult to track and they aren't dating things in the changelog
but I see this
????
(posted 2021-02-04)
--
? * Focal update: v5.4.55 upstream stable release (LP: #1890343)
??? - AX.25: Fix out-of-bounds read in ax25_connect()
??? - AX.25: Prevent out-of-bounds read in ax25_sendmsg()
??? ...
??? - AX.25: Prevent integer overflows in connect and sendmsg
--
? * Focal update: v5.4.44 upstream stable release (LP: #1881927)
??? - ax25: fix setsockopt(SO_BINDTODEVICE)
--
What TNC device are you using?
/Basil N7NIX
On this system, it's a D710 in KISS mode connected to a Lenovo T470
(i7-7600U with 16GB RAM) running 64bit Ubuntu 20.04.? I'm 99.9% sure
that if I switched away from a serial attached hardware TNC to a
software-based TNC like Direwolf, I would still see the issue.? I've
done more testing with reverting the kernel to older versions but
the ones I've tested so far still fail as well:
? 5.8.0-44 : BAD
? 5.8.0-43 : BAD
? 5.8.0-41 : BAD
? ..
? 5.8.0-36 : BAD
? ..
? 5.4.0-66 : BAD
? ..
? 5.4.0-42 : BAD
It's clear that my mistake is that after Canonical pushes a new
kernel version and I apply it, I should reboot then test things to
KNOW if the AX25 stack has been impacted.? I skipped a few reboot
cycles as different kernels were installed so I really don't know
where to start.? Even then, I'm thinking this issue might be more of
a libc interface issue or something else since going way back to
5.4.0-42 dated 2020-07-10 is seeing the same issue.
?? root@hampacket3:/var/log/apt# dpkg -l | grep -e libc6 -e
linux-libc
?? ii? libc6:amd64???????????????????????????????
2.31-0ubuntu9.2?????????????????????? amd64??????? GNU C Library:
Shared libraries
?? ii? libc6-dbg:amd64???????????????????????????
2.31-0ubuntu9.2?????????????????????? amd64??????? GNU C Library:
detached debugging symbols
?? ii? libc6-dev:amd64???????????????????????????
2.31-0ubuntu9.2?????????????????????? amd64??????? GNU C Library:
Development Libraries and Header Files
?? ii? linux-libc-dev:amd64??????????????????????
5.4.0-66.74?????????????????????????? amd64??????? Linux Kernel
Headers for development
That libc6 was installed on "2021-01-28"
It's frustrating as I have no clue where to start as the machine
just locks up and doesn't give any hint of where to start
troubleshooting.? Could be an 64bit thing.? Could be an SMP thing.?
Dunno,
--David
KI6ZHD
|
On Sun, Mar 7, 2021 at 08:48 AM, kt67 wrote:
And what about the 3600 bit modem?
That should have been 4800 bit modem.
|
I would like to add a 2nd port (on 440Mhz) at a local mtn. top node--
As I have users that use UZ7HO I would like to be compatible for them.
I see there are (2) 2400 modes--A and B in UZ7HO. From the Direwolf
side of things, which would be better?(line of sight links)
Has anyone tested in real world links?
And what about the 3600 bit modem?
Thoughts?
Oh --also-- the radios I am using DO NOT have the 9600 HS ports
so any mode would need to go thru the MIC connector.
(old public safety radios)
Tnx de Trip - KT4WO
|
Re: Linux AX.25 stack now toxic for connected packet connections with Ubuntu 20.04 / 5.8.0-44-generic #50
I am NOT seeing your described symptom on various (7) Raspberry Pis
running the Linux AX.25 stack with Winlink, APRS & Chattervox at 1200 & 9600 baud.
My hardware is mainly RPi 4's and sound cards using direwolf.
I do NOT use Linpac or Gnome3
The two kernels I am using from the Raspberry Pi Foundation (raspbian):
Linux test119022321 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux
Linux pi400 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021 armv7l GNU/Linux
What TNC device are you using?
/Basil N7NIX
|
Linux AX.25 stack now toxic for connected packet connections with Ubuntu 20.04 / 5.8.0-44-generic #50
Hello Everyone,
I wanted to check with the larger community to see if others are
experiencing system crashes when making connected AX.25 sessions.?
I have confirmed that this is NOT an RFI thing and sending
unconnected (UI) transmissions (beacons) small or large is fine,
and even initiating the beginning of connected session to a
non-existent remote station callsign is OK with axcall, linpac,
etc.? The issue is that once a valid AX.25 connection is
established, I begin to receive data from the remote station and
then seemingly when my station is to send an ACK packet, the
machine locks hard.? No segmentation failure, no kernel panic, the
Gnome3 display stays up but the screen no longer updates , nothing in the logs and even
stops pinging from a different machine on the LAN.? The machine is 100% crashed and this
is 100% reproducible.
Is anyone else seeing this?
?? $ uname -a
?? Linux hampacket3 5.8.0-44-generic #50~20.04.1-Ubuntu
SMP Wed Feb 10 21:07:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
--David
KI6ZHD
|
Hello John,
Thank you for the details.? Very interesting and the link
is an interesting read.
Guess I should chime in since much of the reasoning
for WinRPR and TeensyTNC existing is due in part to my plea to
SCS to not have Robust Packet die on the vine after the demise
of the most excellent Tracker TNC DSP.? Word leaked out after a
productive summer 2020 effort from SCS folks with some of us
testing their beta releases leading to this post.
Considering that this VAPN web page still mentions that the WinRPR
software is essentially a proprietary SCS product (of sorts), I bet
that kills any hope to add any support into Direwolf.
One thing the existence?of WinRPR does reveal is the DSP techniques used in the encoding and decoding of Robust Packet mode don't require a dedicated DSP that was the case for quite some time.? Following are references to tests performed seven years ago to see it more in action... Apparently the sudden appearance of WinRPR caused West Mountain to opine a couple weeks ago... I haven't had time to watch this one yet, but it's on my playlist.
The existence of WinRPR gives hope that the modem
portion can be segregated in such a way to port into something
like DireWolf in time. This would be quite spectacular.
I disagree.? Until SCS releases some form of a specification
documents with clear license that's compatible with say GPL, Apache,
etc. with releasing any liability to any developer, I doubt any
support will ever happen.
Poor wording on my part.? I was referring more to the technical possibility (portability of DSP routines) rather than legality.? As for the latter, there may well be a time soon when Robust Packet (RP or RPR) is given away as it may not be an important part of the regular SCS products goals (Pactor, etc.) given they stopped production of the DSP Tracker DSP TNC that prominently features Robust Packet.
Note both WinRPR and TeensyTNC are basically the same thing
under the hood to include...
- HF Packet Modem (300 AFSK)
- Robust Packet 300
- Robust Packet 600
- 1200 AFSK
- 9600 FSK
- Full AX.25 stack in the form of the WA8DED "TheFirmware"
- really nice to access any TNC command via Escape
sequence.
WinRPR adds?graphical displays to the mix.? Teensy is
just a virtual serial port to the basic TNC.
This last line is confusing to me.? As I understand say the G8BPQ
Teensy TNC project supporting classic packet as well as ARDOP is a
*complete* TNC.? That effort in the TNC is not "just a virtual
serial port".? Is this WinRPR + Teensy components BOTH required for
a working RPR solution?
Moniker collision.? TeensyTNC in the current context refers to porting the routines that's in the hardware product "SCS Tracker DPS TNC" into a Teensy Microcontroller with Analog IO daughter board.? This won't be the last Teensy TNC project to come along I'm sure as the Teensy system works remarkably well for this.? Since I'm driving the nomenclature, I may well change the name of the Teensy thing to something else... Perhaps TeensyRPRTNC, but that detracts from all the other traditional modes it can do.? I'll fix this in time. ?
WinRPR has become quite popular in the small RPR community
and provides a free way for third party monitoring a
proprietary mode... solving one legal issue.
Is this a receive only solution today or can it also transmit?
WinRPR is a full "soft" TNC that can transmit and receive. ? ? I do
know of the SCS PMON Raspberry Pi image to do monitoring only for
Pactor traffic but it doesn't seem to support RPR:
??
I knew of the Windows version, but didn't realize they released the R-Pi version.? As for Pactor stuff... yeah, boy oh boy.? I was part of that kerfuffle as well...
?
Anyway, that's enough for now, but wanted to explain what
is really going on in the RPR world.
Seems very interesting to me as I love everything packet yet I'm
surprised I never heard of this WinRPR effort.
It was an unpublished?work in progress over the 2020 summer (post the demise of the Tracker TNC hardware product)... alpha testing a gaga.? ?It would have remained that way if one of the beta testers didn't leak the news last fall.? So no surprise you didn't hear about it. ? Maybe the reason for
that is that I don't do Windows anything whenever possible.? I guess
I'll need to add myself to the discussion to see what's
really going on
The robust-packet is the most logical place.? Most folks do APRS with RPR, but many of us use it with connected mode for our BBS ops. ? but I still don't see why WB2OSZ would want to try
adding RPR support into Direwolf when this is still seemingly
proprietary and probably patented.
Fair enough.? When I first encouraged not letting RPR die on the vine, DireWolf was my exemplar of modem/TNC software.? No cumbersome windows, just a good, solid logging display of what's happening. I use DireWolf quite a bit and especially enjoy the error mitigation therein.? So... The DSP Tracker DSP TNC equiv. was what I hoped for, however the SCS programmer's allure of windows overtook my simplistic desires so most of the effort went into the GUI of what you see in WinRPR complete with spectrum display, console and MHEARD?windows... all nice, but fluff.? SCS really really really loves spectrum displays.? Oh well.? It works and does seem to be easy for folks to get up and running quick.
The version for the Teensy microcontroller is much more my style with minimalist approach that gives the traditional WA8DED prompt of a hardware TNC.? Note both WinRPR and the Teensy are two functional things: modem code and TheFirmware AX.25 code.
We may well find Robust Packet open source at some point and be able to shoehorn it into other things like DireWolf with its own AX.25 stack.? That's my dream as Robust Packet is very much a modern logical replacement for HF Packet given it's AX.25 style, FEC, 8 subtones and tailored design for HF radio circuits.
Time will tell.
73 John, kx4o
|
Hello John,
Thank you for the details.? Very interesting and the vapn.org link
is an interesting read.
Guess I should chime in since much of the reasoning
for WinRPR and TeensyTNC existing is due in part to my plea to
SCS to not have Robust Packet die on the vine after the demise
of the most excellent Tracker TNC DSP.? Word leaked out after a
productive summer 2020 effort from SCS folks with some of us
testing their beta releases leading to this post.
Considering that this VAPN web page still mentions that the WinRPR
software is essentially a proprietary SCS product (of sorts), I bet
that kills any hope to add any support into Direwolf.
The existence of WinRPR gives hope that the modem
portion can be segregated in such a way to port into something
like DireWolf in time. This would be quite spectacular.
I disagree.? Until SCS releases some form of a specification
documents with clear license that's compatible with say GPL, Apache,
etc. with releasing any liability to any developer, I doubt any
support will ever happen.
Note both WinRPR and TeensyTNC are basically the same thing
under the hood to include...
- HF Packet Modem (300 AFSK)
- Robust Packet 300
- Robust Packet 600
- 1200 AFSK
- 9600 FSK
- Full AX.25 stack in the form of the WA8DED "TheFirmware"
- really nice to access any TNC command via Escape
sequence.
WinRPR adds?graphical displays to the mix.? Teensy is
just a virtual serial port to the basic TNC.
This last line is confusing to me.? As I understand say the G8BPQ
Teensy TNC project supporting classic packet as well as ARDOP is a
*complete* TNC.? That effort in the TNC is not "just a virtual
serial port".? Is this WinRPR + Teensy components BOTH required for
a working RPR solution?
WinRPR has become quite popular in the small RPR community
and provides a free way for third party monitoring a
proprietary mode... solving one legal issue.
Is this a receive only solution today or can it also transmit?? I do
know of the SCS PMON Raspberry Pi image to do monitoring only for
Pactor traffic but it doesn't seem to support RPR:
??
Anyway, that's enough for now, but wanted to explain what
is really going on in the RPR world.
Seems very interesting to me as I love everything packet yet I'm
surprised I never heard of this WinRPR effort.? Maybe the reason for
that is that I don't do Windows anything whenever possible.? I guess
I'll need to add myself to the groups.io discussion to see what's
really going on but I still don't see why WB2OSZ would want to try
adding RPR support into Direwolf when this is still seemingly
proprietary and probably patented.
--David
KI6ZHD
|
Please do not hijack email threads for new topics.?
Please re-post your email with a new, relevant subject.
--David
KI6ZHD
On 03/04/2021 10:46 AM, N1JUR, Eric
Pfeifer wrote:
toggle quoted message
Show quoted text
All,
?
Hello all I am embarking out on setting up
a iGATE for my local area and have setup Direwolf per the
myriad of videos and resources.
?
I have two questions hopefully someone can
answer
?
- In the dw
log I see the following “red” message “ Tx iGATE: Already
transmitted maximum of 6 packets in 1 minute.” How do I
resolve that issue and what option is causing that. As I
want to be a “good steward” and not flood the network.
- From my
mobile rig ftm300dr I don’t see my igate advertising or
“beaconing” back. What settings am I missing to get this
setup?
?
Thanks & 73,
?
N1JUR
?
?
Eric Pfeifer
General Manager |
RightPath Companies LLC |
M: 603.233.0088 |
P:866.833.0055 | E:
eric@...
22 Greeley Street
?Building 3 Suite 30 Merrimack, NH
Book a meeting
with me anytime! Check my availability here
?
?
Hello Mario,
I had to do some Googling for "Teensy RPR TNC" but it seems
this is a good starting point.? Yes?
??
??
I understand Robust Packet available from SCS is proprietary
and patented.? The world of reverse engineering can make
somethings legal but depends on the country.? Do you have any
details there?? Also, do you know if the team doing the
reverse engineering is documenting the entire effort?? Without
that, it would be very difficult to implement anything without
having someone reverse engineer their embedded processor code
into something that would run in say Direwolf.
--David
KI6ZHD
On 03/03/2021 07:21 AM, Mario Roessler,
DH5YM wrote:
With the Teensy RPR TNC shortwave AX25
becomes some more traction again maybe.
Is there any plan to integrate RPR into Direwolf as well? It
would probably be some nice feature to monitor RPR APRS with
Openwebrx for example.
?
|
Hi David and John,
David, sorry for throwing you into cold water with respect to RPR. John, many thanks for the background. It helps a lot in understanding what is going on.
But you are right with respect to the license question. I did not notice that all this development of the modem is still in the hands of SCS. Unfortunately there is no real license information for WinRPR other than the statement that it is only free for amateur use.
Without having it as a kind of open standard it is unlikely to have any implementation apart from WinRPR and the Teensy TNC. But maybe its worth to keep an eye on how the situation evolves.
Thank you for the discussion!
Mario
|
Guess I should chime in since much of the reasoning for WinRPR and TeensyTNC existing is due in part to my plea to SCS to not have Robust Packet die on the vine after the demise of the most excellent Tracker TNC DSP.? Word leaked out after a productive summer 2020 effort from SCS folks with some of us testing their beta releases leading to this post...
??
It is my sincere dream for the Robust Packet mode to be added to something like DireWolf as yet another mode.? It's a proven performer on HF radio circuits albeit at relatively slow data rates.? At 500 Hz width, it's reasonably neighborly.
From?..
The existence of WinRPR gives hope that the modem portion can be segregated in such a way to port into something like DireWolf in time. This would be quite spectacular.
Note both WinRPR and TeensyTNC are basically the same thing under the hood to include... - HF Packet Modem (300 AFSK)
- Robust Packet 300
- Robust Packet 600
- 1200 AFSK
- 9600 FSK
- Full AX.25 stack in the form of the WA8DED "TheFirmware" - really nice to access any TNC command via Escape sequence.
WinRPR adds?graphical displays to the mix.? Teensy is just a virtual serial port to the basic TNC.
WinRPR has become quite popular in the small RPR community and provides a free way for third party monitoring a proprietary mode... solving one legal issue.
Anyway, that's enough for now, but wanted to explain what is really going on in the RPR world.
73 John, kx4o
Hello Mario,
I had to do some Googling for "Teensy RPR TNC" but it seems this is
a good starting point.? Yes?
??
??
I understand Robust Packet available from SCS is proprietary and
patented.? The world of reverse engineering can make somethings
legal but depends on the country.? Do you have any details there??
Also, do you know if the team doing the reverse engineering is
documenting the entire effort?? Without that, it would be very
difficult to implement anything without having someone reverse
engineer their embedded processor code into something that would run
in say Direwolf.
--David
KI6ZHD
On 03/03/2021 07:21 AM, Mario Roessler,
DH5YM wrote:
With the Teensy RPR TNC shortwave AX25 becomes some
more traction again maybe.
Is there any plan to integrate RPR into Direwolf as well? It would
probably be some nice feature to monitor RPR APRS with Openwebrx
for example.
|
All,
?
Hello all I am embarking out on setting up a iGATE for my local area and have setup Direwolf per the myriad of videos and resources.
?
I have two questions hopefully someone can answer
?
- In the dw log I see the following “red” message “ Tx iGATE: Already transmitted maximum of 6 packets in 1 minute.” How do I resolve that issue and what option is causing that. As I
want to be a “good steward” and not flood the network.
- From my mobile rig ftm300dr I don’t see my igate advertising or “beaconing” back. What settings am I missing to get this setup?
?
Thanks & 73,
?
N1JUR
?
?
Eric Pfeifer
General Manager | RightPath Companies LLC |
M: 603.233.0088 |
P:866.833.0055 | E:
eric@...
22 Greeley Street ?Building 3 Suite 30 Merrimack, NH
Book a meeting with me anytime! Check my availability here
?
?
Hello Mario,
I had to do some Googling for "Teensy RPR TNC" but it seems this is a good starting point.? Yes?
??
??
I understand Robust Packet available from SCS is proprietary and patented.? The world of reverse engineering can make somethings legal but depends on the country.? Do you have any details there?? Also, do you know if the team doing the reverse engineering is
documenting the entire effort?? Without that, it would be very difficult to implement anything without having someone reverse engineer their embedded processor code into something that would run in say Direwolf.
--David
KI6ZHD
toggle quoted message
Show quoted text
On 03/03/2021 07:21 AM, Mario Roessler, DH5YM wrote:
With the Teensy RPR TNC shortwave AX25 becomes some more traction again maybe.
Is there any plan to integrate RPR into Direwolf as well? It would probably be some nice feature to monitor RPR APRS with Openwebrx for example.
?
|
Hello Mario,
I had to do some Googling for "Teensy RPR TNC" but it seems this is
a good starting point.? Yes?
??
??
I understand Robust Packet available from SCS is proprietary and
patented.? The world of reverse engineering can make somethings
legal but depends on the country.? Do you have any details there??
Also, do you know if the team doing the reverse engineering is
documenting the entire effort?? Without that, it would be very
difficult to implement anything without having someone reverse
engineer their embedded processor code into something that would run
in say Direwolf.
--David
KI6ZHD
On 03/03/2021 07:21 AM, Mario Roessler,
DH5YM wrote:
toggle quoted message
Show quoted text
With the Teensy RPR TNC shortwave AX25 becomes some
more traction again maybe.
Is there any plan to integrate RPR into Direwolf as well? It would
probably be some nice feature to monitor RPR APRS with Openwebrx
for example.
|
With the Teensy RPR TNC shortwave AX25 becomes some more traction again maybe.
Is there any plan to integrate RPR into Direwolf as well? It would probably be some nice feature to monitor RPR APRS with Openwebrx for example.
|
Re: 1.7 Beta version for Windoz with CM119 support?
Please see the Direwolf archives for this.? It's a
known issue on the Windows side:
??
/g/direwolf/message/4644?p=,,,20,0,0,0::Created,,CM119+PTT,20,2,0,78512914
--David
KI6ZHD
On 02/26/2021 04:54 PM, Arnold Harding
- KQ6DI wrote:
toggle quoted message
Show quoted text
Is there a
Direwolf Beta version 1.7 for Windows available that has
support for the CM119 PTT?
I know it's Beta,
and I know I could probably figure out how to compile it, but
I thought I'd ask.
(If it's
available, at least I wouldn't be creating additional problems
by compiling wrong.)
Arnold, KQ6DI
|
Re: INTERNAL ERROR? select_t1_value
Here's a longer, complete log (with nothing snipped out), showing several connection attempts with different digipeater paths. The radio was turned off, so nothing was received. All connections were from the same client (Outpost PMM); the only difference is the digipeater paths. It seems noteworthy that only one of the three connections resulted in the ominous message.
toggle quoted message
Show quoted text
On Tue, Mar 2, 2021 at 03:49 PM, David Ranch wrote:
please send the FULL output of Direwolf from it's very initial startup until the initial connection is made to the remote BBS.
|
Re: INTERNAL ERROR? select_t1_value
Hello John,
Per the comments in
, please send the FULL output of Direwolf from it's very initial
startup until the initial connection is made to the remote BBS.
--David
KI6ZHD
On 03/02/2021 03:28 PM, John Kristian
wrote:
toggle quoted message
Show quoted text
Direwolf logs an ominous message:
INTERNAL
ERROR? Stream 0: select_t1_value, rc = 2, t1 remaining =
-999.000, old srt = 15.000, new srt = 15.000, Extreme new
t1v = 30.500
... when attempting to
connect via two digipeaters, immediately before retransmitting
SABM. Excerpts from a log are attached.
This isn't really a problem, David Ranch.
|
INTERNAL ERROR? select_t1_value
Direwolf logs an ominous message:
INTERNAL ERROR? Stream 0: select_t1_value, rc = 2, t1 remaining = -999.000, old srt = 15.000, new srt = 15.000, Extreme new t1v = 30.500
... when attempting to connect via two digipeaters, immediately before retransmitting SABM. Excerpts from a log are attached.
This isn't really a problem, David Ranch.
|
Re: EAS SAME to APRS Message Converter
Okay, so I think I'm maybe figuring this out.... Presuming Kissutil has to be running as a service so that it is checking the /dev/shm/TQ and /dev/shm/RQ directories... and I can start kissutil and specify that it should connect to a specific host....?
So... I've got direwolf with my SDR and eas2aprs running on 192.168.1.2
and I've got my digipeater running on 192.168.1.10
So if on 192.168.1.2 I run kissutil with -h 192.168.1.10 -p 8001 if I'm understanding correctly, then kissutil should see the eas2aprs messages in the /dev/shm/TQ directory, and send them to direwolf on 192.168.1.10.... correct?
My only problem now is..... I don't see it actually successfully connecting to direwolf on 192.168.1.10 (I do have the KISSPORT 8001 parameter in the config)
|
Re: EAS SAME to APRS Message Converter
so, I've got this basically setup.... But I'm running into a couple issues due to some unique things about my setup.
Ideally, I'd like to run my RTL-SDR on a different machine from the one on which I run Direwolf... primarily because my APRS digipeater is fully solar/battery powered, so power consumption is a concern... second reason, by RTL-SDR doesn't have a TXCO, so running it outside in the weatherproof enclosure won't lend itself well due to the temperature variations...?
Do you know if Direwolf can get the signal via rtl_tcp instead of rtl_fm.... if I setup an rtl_tcp server inside the house where the climate is a bit more stable...
My other thought was simply setting up the /dev/shm/TQ and /dev/shm/RQ directories to point to a network share... and run another instance of direwolf on the indoor pc for the sole purpose of receiving and processing the EAS/SAME signal, and basicaly both instances, the indoor, and the outdoor, would use the same network share for the RQ and TQ directories.
Unfortunately, neither method has been successful... any suggestions?? ?Can I tell Direwolf to look to a specific directory for the /TQ and /RQ directories, or does it just default to /dev/shm/TQ and /dev/shm/RQ and not changeable???
|
Basil Gunn
John Kristian
John Tetreault (WA1OKB)