开云体育

Hello Rory,

If I'm reading you correctly, you got UZ70HO Soundmodem for Windows to key up your radio but you've been unable to get Direwolf for Windows to key up the radio?? What is the "PTT" line configured to in your direwolf.conf file?? The syntax should look like:

?? # Per Direwolf User Guide section 9.2.9.4
?? # Hamlib 3.x style for IC7100
?? # Change COM3 to be the correct serial port per Windows Device Manager
?? PTT RIG 370 COM3


Btw, doing a search on the Direwolf email list archives for "IC7100 Windows" gave hits like:

?? #Newer style using Direwolf's native CAT support
??

?? #Using the older style solution of using the CAT7200 intermediate program
?? /g/direwolf/topic/34951885


You also should be able to assert PTT using the secondary serial port presented by the Icom IC7100 which is a bit simpler than using CAT command.? The solution choice is yours.

--David
KI6ZHD

Hi all,
????? Thanking in advance for the solution needed.? This is a Win10, with ic7100 working with lots of other software.? Even soundmodem regarding transmit.? But I need Direwolf for receieve diagnosis.? But to trigger my Winlink server in packet, direwolf wont get the radio into Tx mode.? I tried PTT CAT9 (-rts|rts) (-dts|dts) combinations, or so I think I did.? What else am i missing.? Thank you.

73? Rory? W4RJG

--

开云体育

Hello Christopher,

Are talking about AXIP tunnels coming from say the AMPR 44.x.x.x network??? If so, those tunnels would either terminate as a tunl interface on the Linux host *or* get forwarded and terminate on a tun host within JNOS.? Direwolf has no understanding of the data payload that has been encapsulated in a KISS frame other than into it's native AX.25 engine for classic AX.25 Packet or AX.25+APRS payloads.

--David
KI6ZHD

FIXED IT! I used the LAN address instead of the Linux 44-net address
and magic happened.

Thanks,

On Mon, Nov 14, 2022 at 1:50 PM Christopher Maness via groups.io
<christopher.maness@...> wrote:

Yes, I can telnet both directions from Linux->JNOS and visa-versa.
Direwolf does in asense encap KISS of TCP/IP. When I look at the JNOS
log I get a connection error, so not sure. I can try to see if I can
connect to telnetd from JNOS using its LAN address instead of the
44-net address. I am not sure if that port is only bound to that LAN
address only.

On Mon, Nov 14, 2022 at 11:46 AM David Ranch
<direwolf-groupsio@...> wrote:

Hello Christopher,

Your question really doesn't have anything to do with Direwolf (Direwolf doesn't do any form of IP routing, AXIP encapsulation, etc). Regardless, I'll chime in a few thoughts:

- You're email doesn't give much detail here but how are you connecting your "host" to "JNOS"? Are you using a TUN interface? If so, can the Linux side telnet to the JNOS IP?

- If you're also looking to forward IP traffic external from the Linux host to the JNOS host, have you:

- Have you created the required static routes on both the Linux side and the JNOS side to know about those subnets
- enabling IP forwarding on the Linux
- Do have a firewall installed on the Linux side? If so, have you created forwarding rules and creating traffic rules to allow this TCP traffic ?

I would recommend to move this discussion to the JNOS email list which has people who can better help you:



--David
KI6ZHD


On 11/14/2022 11:33 AM, Christopher Maness wrote:

I am doing TCP forwarding from the host to a JNOS instance that has
its own IP address. JNOS does not seem to be connecting as expected.
I there a specific permission that I need to allow connections from
something other than localhost? I don't see that option in the config
file.

--
Thanks,
Chris Maness

--
Thanks,
Chris Maness

Yes, I can telnet both directions from Linux->JNOS and visa-versa.
Direwolf does in asense encap KISS of TCP/IP. When I look at the JNOS
log I get a connection error, so not sure. I can try to see if I can
connect to telnetd from JNOS using its LAN address instead of the
44-net address. I am not sure if that port is only bound to that LAN
address only.

On Mon, Nov 14, 2022 at 11:46 AM David Ranch
<direwolf-groupsio@...> wrote:

Hello Christopher,

Your question really doesn't have anything to do with Direwolf (Direwolf doesn't do any form of IP routing, AXIP encapsulation, etc). Regardless, I'll chime in a few thoughts:

- You're email doesn't give much detail here but how are you connecting your "host" to "JNOS"? Are you using a TUN interface? If so, can the Linux side telnet to the JNOS IP?

- If you're also looking to forward IP traffic external from the Linux host to the JNOS host, have you:

- Have you created the required static routes on both the Linux side and the JNOS side to know about those subnets
- enabling IP forwarding on the Linux
- Do have a firewall installed on the Linux side? If so, have you created forwarding rules and creating traffic rules to allow this TCP traffic ?

I would recommend to move this discussion to the JNOS email list which has people who can better help you:



--David
KI6ZHD


On 11/14/2022 11:33 AM, Christopher Maness wrote:

I am doing TCP forwarding from the host to a JNOS instance that has
its own IP address. JNOS does not seem to be connecting as expected.
I there a specific permission that I need to allow connections from
something other than localhost? I don't see that option in the config
file.

--
Thanks,
Chris Maness

开云体育

Hello Christopher,

Your question really doesn't have anything to do with Direwolf (Direwolf doesn't do any form of IP routing, AXIP encapsulation, etc).? Regardless, I'll chime in a few thoughts:

?? - You're email doesn't give much detail here but how are you connecting your "host" to "JNOS"?? Are you using a TUN interface?? If so, can the Linux side telnet to the JNOS IP??

?? - If you're also looking to forward IP traffic external from the Linux host to the JNOS host, have you:

? ? ? - Have you created the required static routes on both the Linux side and the JNOS side to know about those subnets
? ? ? - enabling IP forwarding on the Linux
? ? ? - Do have a firewall installed on the Linux side?? If so, have you created forwarding rules and creating traffic rules to allow this TCP traffic ?

I would recommend to move this discussion to the JNOS email list which has people who can better help you:

??

--David
KI6ZHD

I am doing TCP forwarding from the host to a JNOS instance that has
its own IP address. JNOS does not seem to be connecting as expected.
I there a specific permission that I need to allow connections from
something other than localhost? I don't see that option in the config
file.

--
Thanks,
Chris Maness

开云体育

Hello Robert,

So would your setup be something like:

?? Satgate direwolf --> Radio #1 --> 145.825Mhz

?? Terrestrial APRS Direwolf w/ Igate --> Radio #2 --> 144.390Mhz

?? Classic packet Direwolf --> Radio #3 --> maybe 145.050 Mhz


One instance of Direwolf could probably be made to support this but I believe there might be some leakage of other packet traffic into the APRS Igate connection which isn't ideal.? One benefit of a single instance of Direwolf is that you can use a sound device that has stereo playback AND stereo input for running two channels as you cannot easily share one sound device across two instances of Direwolf.? On the down side, it should also be known that with only a single Direwolf instance running multiple radios, Direwolf it serially cycles through servicing each radio one at a time so that can introduce some minor delays.?

Considering all this, I personally would recommend your option #2 of setup three instances of DIrewolf with three different sound devices on one machine/VM.? This will offer the most flexibility, performance, simplicity, and optimized efficiency.

--David
KI6ZHD

I want to setup a server to do the following: SATGate for APRS, an I -Gate for land APRS, and an AX.25 packet node with all using direwolf.

I see three possible ways to do this.

1. Trying to use one instance of direwolf to run all the services.

2. Trying to run three instances of direwolf each running a service.

3. Running each service on it's own virtual machine.

Any suggestions on which of the three to use?

Thanks
--
Robert

W9RWB
WRPH745

Hi,

It has not been for lack of trying, but after more than 20 attempts I have to conclude that I cannot reproduce the problems at all. I tried 12 times with logging enabled and then continued without logging, just in case enabling logging changes the behavior in some way. I did all that with the exact same configuration and the exact same equipment. In fact, in order to preserve the original configuration I did not use the LOGDIR directive in the config file but instead started direwolf 1.7 with the following command line:
./direwolf -l /tmp/direwolf -T "%F_%T" 2>&1 | tee -a /tmp/direwolf/console.log
(in order to have both the direwolf logs as well as the console output with timestamps).

I did however notice that this laptop (an older Dell Latitude with Core2Duo cpu) was at times cpu bound during the testing. This isn't DireWolfs fault, as the % of cpu allocated to DireWolf was mostly around 5% and rarely above 10% of one cpu core. One cpu core spent 100% on running the windows OS with the client application (Outpost PM) inside a vmware VM which meant that everything else (including DireWolf) was sharing the other cpu core (hyper-threading is disabled). CPU frequency scaling (Intel SpeedStep) was active and I could see both cores rising from 800MHz at idle to 2535MHz during testing. CPU temperature rose very quickly from 35C to 75C and therefore heat could have played a role in those previous failures as well (I'm not sure whether there was any frequency down scaling because of temperature, if so it wasn't logged).

vvv
My conclusion is that the previously observed problems are not due to any software defects in DireWolf but due to insufficient cpu resources on a computer that is being asked to perform timing-sensitive digital signal processing,
^^^

For those interested here is a more detailed description of the two DireWolf "hangs" observed originally (unfortunately without any logging enabled in DireWolf at the time). There was however logging enabled on the JNOS BBS server side and on the Outpost PM client side. In addition I was monitoring the tests on a second packet station (however also without logging). I did the same test against 3 different local BBS, of which the first of the tests was successful.

In the second test (different BBS) DireWolf appeared to have great difficulties in hearing the JNOS BBS (despite having the taller, better antenna and better radio) while the 2nd monitoring packet station could hear and decode all the transmissions fine. Early on it did a couple of REJ rejects within 2 seconds of a JNOS BBS transmission but subsequently the BBS would send 2 packets (maxframe = 2) and then wait for 15 seconds for an acknowledgement from DireWolf that didn't come. It would then send a RR (receive ready) with P poll flag to which DireWolf would reply with another RR with F final flag acknowledging neither or at most the first of the two packets. After every burst of 2 packets from the BBS that was a (strange to me) message about something being invalid on the DireWolf console but unfortunately I don't remember exactly what it said (and don't want to mislead anybody by guessing) and failed to take a screenshot at the time. However I do remember that it was the same message every time.
This would continue for some time until the BBS disconnected the session due to too many retries at 18:20:45. At that point I restarted DireWolf and tried again (to the same BBS) starting at 18:25:31 and the restart of the test was successful (no more packet rejects and no more need for polling for overdue acknowledgements, in fact no retransmissions at all). During the entire period (the initially failing test and the restart of it) the BBS did not log any other user activity and I didn't hear anything interfering on the monitoring packet station either.

The third test (yet another BBS) failed in a completely different way. At 19:14:31 the JNOS BBS sends the last two packets (maxframe = 2) that are actually delivered to the Outpost PM client. At 19:14:36 DireWolf acknowledges those two packets with a RR response and the BBS sends the next two packets at 19:14:37 which DireWolf acknowledges at 19:14:43 but the content of those packets does not arrive at the Outpost PM client (connected over the AGWPE port). This continues (JNOS sending 2 packets, DIreWolf acknowledging those packets but no data arriving at the Outpost PM client application) until the entire message was sent from the BBS with the final acknowledgment from DireWolf at 19:14:58. Since the Outpost PM client did not receive the complete message it never continues (killing the current message, read request for the next message, etc,) and at 19:16:56 the JNOS BBS ends the connection due to a 2 minute session timeout timer.

Thanks
Thomas
KK6FPP

yeah, I've got that RTL running on an old Rasp Pi but that was sort of what I wanted to do, but with this better FunCube Pro + SDR. The first issue I found was the drivers for that FunCube Pro + SDR were not supporting the architecture of the old Rasp Pi I had. I wanted to find some command line like?

rtl_fm -f 144.39M -o 4 - | direwolf -n 1 -r 24000 -b 16 -?

command, but on windows and for the FunCube Pro + SDR.

thank you all for your suggestions and help, sorry I didn't reply earlier. Hurricane Nicole kept me busy these last 24 hours or so.
73 DE KK4YEL?

?

开云体育

开云体育

Hello Kevin,

You must have some form of SDR program to initialize your specific hardware, process the incoming I/Q signals, and demodulate the signal.? So YES, you need an (some) form of SDR program.? That said.. there are ways to simplify but I'm not aware of "how" simple that can be done in Windows.? Per the comment from John WB2OSZ (author of Direwolf), you favorite SDR program might support sending the demodulated audio via a network connection.? That will help avoid the virtual audio cable mess.? What SDR program do you normally use?

Alternatively, if you're willing to use Linux, you can use the light weight STDIN approach.? For example, here is an example using an inexpensive RTL SDR, the very light weight rtl_fm SDR program, and Direwolf:

??

I have to imagine that the FunCube+ and SDRPlay-DX units have some form of a light weight SDR program offering but you'll have to research that.

--David
KI6ZHD

"gqrx" can send received audio as a UDP stream.
Details are in the Dire Wolf User Guide.

If someone knows of a network audio application to output the audio over UDP, that would be even more ideal.
Then you could use Direwolf UDP input rather than standard input / output.
The only one I found was RTL_FM_VLC.
Has anyone used that?

-----
Rob KB8RCO

On Tue, Nov 8, 2022 at 09:16 PM, z_ kevino wrote:

i've got both a Funcube Pro+ and an SDRplay dx. Is there any way to tell direwolf (windows) to get the SDR to simply demodulate FM on 144.390 and pass this into direwolf?

You will always need some kind of SDR application as a go between of the RTL dongle and Direwolf.
So, best guess at the "lightest" SDR application" would be RTL_FM on a command line (section 9.1.6.2 of the manual)
? ? ?rtl_fm -f 144.39M -o 4 - | direwolf -n 1 -r 24000 -b 16 -
Then use standard input as the means of getting the audio to direwolf with a config file like:
This works well since you probably are not changing any frequencies or other settings on the RTL

-----
Rob KB8RCO

Mike, I know it is an old post, but did you ever use your D710 and RPi for the iGateway? I am interested in doing the same, and was wondering if you were successful ?