开云体育

Date

Re: KISSPORT #### does not override 8001

 

I bumped into this when trying to run two separate instances of direwolf. One for VHF and one for HF. In that case I would see a collision on port 8001. After digging around a bit I found that the way to turn off the 8001 default is to set KISSPORT 0 before any other KISSPORT settings in the config.?

I also proposed a code change to the KISSPORT default behavior here.
https://github.com/wb2osz/direwolf/pull/333


Re: KISSPORT #### does not override 8001

 

开云体育


Hello Roger,

Ok.. and btw, I've created a Github issue to track this issue for you:

??


--David
KI6ZHD
??

On 07/07/2021 06:29 PM, Roger wrote:

Thanks, David
I did revert to 1.6 stable version and all is well.? Just thought I'd give the new beta a spin-
Appreciate your reply and confirmation.
Roger,
N1XP

On 7/7/21 1:49 PM, David Ranch wrote:

Hello Roger,

I just tested it and I see what you're seeing.? Ultimately, this seems to be a bug with v1.7 so unless you specifically need the BETA v1.7 release, please use the released v1.6 version.


--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf DEVELOPMENT version 1.7 A (Jul? 7 2021)
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8001 ...? <---------------------------------
Ready to accept KISS TCP client application 0 on port 8004 ...
--

Here is a confirmation of the open ports:
--
$ sudo lsof -nPi | grep direwolf
direwolf? 792?? root??? 3u? IPv4? 18033????? 0t0? TCP *:8003 (LISTEN)
direwolf? 792?? root??? 7u? IPv4? 20010????? 0t0? TCP *:8001 (LISTEN)? <----------------
direwolf? 792?? root??? 9u? IPv4? 18035????? 0t0? TCP *:8004 (LISTEN)?
--


This seems like this is a bug introduced in Direwolf v1.7 as I don't see this behavior with Direwolf v1.6:

--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf version 1.6
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8004 ...? <--------------------
--


--David
KI6ZHD



On 07/05/2021 06:28 AM, Roger wrote:

New install of Direwolf dev1.7 does not allow changing KISSPORT? FROM 8001.
My CONF file, direwolf.conf:
? ADEVICE plughw:1,0
? ACHANNELS 1
? CHANNEL 0
? MYCALL N1XP
? MODEM 1200
? AGWPORT 8003
? KISSPORT 8004

When direwolf is executed the following appears:

Dire Wolf DEVELOPMENT version 1.7 A (Jul? 4 2021)
Includes optional support for:? cm108-ptt

Reading config file dwuhf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate / 3.
Note: PTT not configured for channel 0. (Ignore this if using VOX.)
Ready to accept AGW client application 0 on port 8005 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept KISS TCP client application 0 on port 8004 ...

Why is KISSPORT 8001 still appearing??? It seems that 8001 is hard coded into the binary - or am I doing something wrong?
Suggestions and help, please
Roger, N1XP





Re: KISSPORT #### does not override 8001

 

In addition, I connected both TCP ports using APRSIS32
[0L] KB8RCO-2>APWW11,WIDE1-1,WIDE2-1:@173559h4209.35N/08346.30W1 EXPERIMENTATION
[1L] KB8RCO-2>APWW11,WIDE1-1,WIDE2-1:@173559h4209.35N/08346.30W1 EXPERIMENTATION
[0L] KB8RCO-2>APWW11,WIDE1-1,WIDE2-1:@173559h4209.35N/08346.30W1 EXPERIMENTATION
[0L] KB8RCO-3>APDW17:!4209.35N008346.30W-Saline MI Testing Ch0
[1L] KB8RCO-4>APDW17:!4209.35N108346.30W-Saline MI Testing Ch1?

I enabled 3 RF ports (8001, 8010, 8011) and opened log files for each.
There is a delay between 8001 opening and 8010 and 8011 opening - which implies my theory is correct.
Although it opens a TCP port and the port is there (available), APRSIS32 does not appear to do anything with 8001.
When APRSIS32 beacons, there appears 2x the message for [0L] implying it sends on 8001 and then again on 8010.

Robert Giuliano
KB8RCO



On Thursday, July 8, 2021, 1:01:28 PM EDT, Rob Giuliano <kb8rco@...> wrote:


I just compiled V1.7 and tried to change the TCP KISS port.
As stated, the 'default' port does not change, however when specifying a port, it looked like this:
Dire Wolf DEVELOPMENT version 1.7 A (Jul? 8 2021)
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept AGW client application 0 on port 8010 ...
Ready to accept KISS TCP client application 0 on port 8011 (radio channel 0) ...

So it appears you can assign the new port by radio channel.
Both appeared to be active, so it appears the issue is with the generic port being set to the default and not re-assigned.

So I went with
? KISSPORT 8010 0
? KISSPORT 8011 1
And 3 KISS TCP ports were open:
Ready to accept KISS TCP client application 0 on port 8001
Ready to accept AGW client application 0 on port 8000
Ready to accept KISS TCP client application 0 on port 8010 (radio channel 0)

Ready to accept KISS TCP client application 0 on port 8011 (radio channel 1)
So it looks to me like the default KISS TCP port is being opened before the config file is read with the information needed to open it, so a default port is always opened.

Robert Giuliano
KB8RCO



On Wednesday, July 7, 2021, 9:29:55 PM EDT, Roger <roger@...> wrote:


Thanks, David
I did revert to 1.6 stable version and all is well.? Just thought I'd give the new beta a spin-
Appreciate your reply and confirmation.
Roger,
N1XP

On 7/7/21 1:49 PM, David Ranch wrote:

Hello Roger,

I just tested it and I see what you're seeing.? Ultimately, this seems to be a bug with v1.7 so unless you specifically need the BETA v1.7 release, please use the released v1.6 version.


--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf DEVELOPMENT version 1.7 A (Jul? 7 2021)
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8001 ...? <---------------------------------
Ready to accept KISS TCP client application 0 on port 8004 ...
--

Here is a confirmation of the open ports:
--
$ sudo lsof -nPi | grep direwolf
direwolf? 792?? root??? 3u? IPv4? 18033????? 0t0? TCP *:8003 (LISTEN)
direwolf? 792?? root??? 7u? IPv4? 20010????? 0t0? TCP *:8001 (LISTEN)? <----------------
direwolf? 792?? root??? 9u? IPv4? 18035????? 0t0? TCP *:8004 (LISTEN)?
--


This seems like this is a bug introduced in Direwolf v1.7 as I don't see this behavior with Direwolf v1.6:

--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf version 1.6
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8004 ...? <--------------------
--


--David
KI6ZHD



On 07/05/2021 06:28 AM, Roger wrote:

New install of Direwolf dev1.7 does not allow changing KISSPORT? FROM 8001.
My CONF file, direwolf.conf:
? ADEVICE plughw:1,0
? ACHANNELS 1
? CHANNEL 0
? MYCALL N1XP
? MODEM 1200
? AGWPORT 8003
? KISSPORT 8004

When direwolf is executed the following appears:

Dire Wolf DEVELOPMENT version 1.7 A (Jul? 4 2021)
Includes optional support for:? cm108-ptt

Reading config file dwuhf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate / 3.
Note: PTT not configured for channel 0. (Ignore this if using VOX.)
Ready to accept AGW client application 0 on port 8005 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept KISS TCP client application 0 on port 8004 ...

Why is KISSPORT 8001 still appearing??? It seems that 8001 is hard coded into the binary - or am I doing something wrong?
Suggestions and help, please
Roger, N1XP




Re: KISSPORT #### does not override 8001

 

I just compiled V1.7 and tried to change the TCP KISS port.
As stated, the 'default' port does not change, however when specifying a port, it looked like this:
Dire Wolf DEVELOPMENT version 1.7 A (Jul? 8 2021)
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept AGW client application 0 on port 8010 ...
Ready to accept KISS TCP client application 0 on port 8011 (radio channel 0) ...

So it appears you can assign the new port by radio channel.
Both appeared to be active, so it appears the issue is with the generic port being set to the default and not re-assigned.

So I went with
? KISSPORT 8010 0
? KISSPORT 8011 1
And 3 KISS TCP ports were open:
Ready to accept KISS TCP client application 0 on port 8001
Ready to accept AGW client application 0 on port 8000
Ready to accept KISS TCP client application 0 on port 8010 (radio channel 0)

Ready to accept KISS TCP client application 0 on port 8011 (radio channel 1)
So it looks to me like the default KISS TCP port is being opened before the config file is read with the information needed to open it, so a default port is always opened.

Robert Giuliano
KB8RCO



On Wednesday, July 7, 2021, 9:29:55 PM EDT, Roger <roger@...> wrote:


Thanks, David
I did revert to 1.6 stable version and all is well.? Just thought I'd give the new beta a spin-
Appreciate your reply and confirmation.
Roger,
N1XP

On 7/7/21 1:49 PM, David Ranch wrote:

Hello Roger,

I just tested it and I see what you're seeing.? Ultimately, this seems to be a bug with v1.7 so unless you specifically need the BETA v1.7 release, please use the released v1.6 version.


--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf DEVELOPMENT version 1.7 A (Jul? 7 2021)
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8001 ...? <---------------------------------
Ready to accept KISS TCP client application 0 on port 8004 ...
--

Here is a confirmation of the open ports:
--
$ sudo lsof -nPi | grep direwolf
direwolf? 792?? root??? 3u? IPv4? 18033????? 0t0? TCP *:8003 (LISTEN)
direwolf? 792?? root??? 7u? IPv4? 20010????? 0t0? TCP *:8001 (LISTEN)? <----------------
direwolf? 792?? root??? 9u? IPv4? 18035????? 0t0? TCP *:8004 (LISTEN)?
--


This seems like this is a bug introduced in Direwolf v1.7 as I don't see this behavior with Direwolf v1.6:

--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf version 1.6
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8004 ...? <--------------------
--


--David
KI6ZHD



On 07/05/2021 06:28 AM, Roger wrote:

New install of Direwolf dev1.7 does not allow changing KISSPORT? FROM 8001.
My CONF file, direwolf.conf:
? ADEVICE plughw:1,0
? ACHANNELS 1
? CHANNEL 0
? MYCALL N1XP
? MODEM 1200
? AGWPORT 8003
? KISSPORT 8004

When direwolf is executed the following appears:

Dire Wolf DEVELOPMENT version 1.7 A (Jul? 4 2021)
Includes optional support for:? cm108-ptt

Reading config file dwuhf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate / 3.
Note: PTT not configured for channel 0. (Ignore this if using VOX.)
Ready to accept AGW client application 0 on port 8005 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept KISS TCP client application 0 on port 8004 ...

Why is KISSPORT 8001 still appearing??? It seems that 8001 is hard coded into the binary - or am I doing something wrong?
Suggestions and help, please
Roger, N1XP




Re: KISSPORT #### does not override 8001

 

开云体育

Thanks, David
I did revert to 1.6 stable version and all is well.? Just thought I'd give the new beta a spin-
Appreciate your reply and confirmation.
Roger,
N1XP

On 7/7/21 1:49 PM, David Ranch wrote:


Hello Roger,

I just tested it and I see what you're seeing.? Ultimately, this seems to be a bug with v1.7 so unless you specifically need the BETA v1.7 release, please use the released v1.6 version.


--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf DEVELOPMENT version 1.7 A (Jul? 7 2021)
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8001 ...? <---------------------------------
Ready to accept KISS TCP client application 0 on port 8004 ...
--

Here is a confirmation of the open ports:
--
$ sudo lsof -nPi | grep direwolf
direwolf? 792?? root??? 3u? IPv4? 18033????? 0t0? TCP *:8003 (LISTEN)
direwolf? 792?? root??? 7u? IPv4? 20010????? 0t0? TCP *:8001 (LISTEN)? <----------------
direwolf? 792?? root??? 9u? IPv4? 18035????? 0t0? TCP *:8004 (LISTEN)?
--


This seems like this is a bug introduced in Direwolf v1.7 as I don't see this behavior with Direwolf v1.6:

--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf version 1.6
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8004 ...? <--------------------
--


--David
KI6ZHD



On 07/05/2021 06:28 AM, Roger wrote:

New install of Direwolf dev1.7 does not allow changing KISSPORT? FROM 8001.
My CONF file, direwolf.conf:
? ADEVICE plughw:1,0
? ACHANNELS 1
? CHANNEL 0
? MYCALL N1XP
? MODEM 1200
? AGWPORT 8003
? KISSPORT 8004

When direwolf is executed the following appears:

Dire Wolf DEVELOPMENT version 1.7 A (Jul? 4 2021)
Includes optional support for:? cm108-ptt

Reading config file dwuhf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate / 3.
Note: PTT not configured for channel 0. (Ignore this if using VOX.)
Ready to accept AGW client application 0 on port 8005 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept KISS TCP client application 0 on port 8004 ...

Why is KISSPORT 8001 still appearing??? It seems that 8001 is hard coded into the binary - or am I doing something wrong?
Suggestions and help, please
Roger, N1XP




TNC exporter: metrics collection and visualization for direwolf

Ross Young
 

Hi direwolf community,
I'd like to introduce my open source project, , which provides a legible, information-dense and customizable interface to view and analyze TNC activity over time. It is a prometheus exporter and grafana dashboard for direwolf (and other software TNCs) that collects packet metrics using the AGW or KISS TCP/IP interfaces. Please see the project's README file for additional information about requirements, installation, configuration etc. TNC exporter is released under the MIT license.

I built this in my spare time over the past few months, mostly because it was an interesting challenge dealing with several technologies I wanted to learn more about. Despite this, I have tried to make it a fully featured, decently documented piece of software that is of use to packet radio operators, particularly folks who would like to track ongoing usage of infrastructure such as digipeaters and iGates. I still have some additional features planned (namely Mic-E and compressed position report parsing) but at this point I think it's quite useful and want to get the word out. I'm looking forward to hearing if folks here find it a good addition to their shack, and I'm happy to provide support or answer questions.

Bug reports, suggestions and code contributions are welcome, through the github repo linked above or directly via email if you prefer.

Ross KJ7GES


option digipeater no work in mi direwolf

 

Hello, I compiled on a raspberry pi zero W direwolf 1.6 as indicated in the manual, my intention is to configure an aprs repeter (digipeater).

The problem is that when I turn on a handheld radio with aprs and it sends its beacom, direwolf if it hears it but does not broadcast the information, when I see the linux shell it says that it does but in reality it does not send it to the radio, it even see on the radio that it is connected to the raspberry that changes the display light because the ptt is activated, but it is as if it does not send the audio, only repeater, because when it sends the audio of the direwolf beacom it does it well.

If I activate the igate direwolf option, it registers the data from the handheld radio on the internet without problem and I see it in aprs.fi.

This in my understanding is that if it is receiving the packets from the handheld radio well.
xe1gnu-1 is direwolf and xe1gnu-7 is other radio

I compiled it wrong ?.
Do I get a package on the raspberry?
Any configuration problems?
I have 7 days on that and I have no idea where you could see the problem.

Thank you and 73 from xe1gnu is an important project for my SOTA activity.


this is my configuration.

ADEVICE? plughw:2,0
CHANNEL 0
MYCALL XE1GNU-1
MODEM 1200
PTT GPIO 25
AGWPORT 8000
KISSPORT 8001
PBEACON delay=1 ?every=5 overlay=S symbol="digi" lat=19^28.025N long=099^6.383438W power=25 height=20 gain=4 comment="Iniciando" via=WIDE1-1,WIDE2-1
DIGIPEAT 0 0 ^WIDE[3-7]-[1-7]$|^TEST$ ^WIDE[12]-[12]$ TRACE


TTPOINT ?B01 ?37^55.37N ?81^7.86W
TTPOINT ?B7495088 ?42.605237 ?-71.34456
TTPOINT ?B934 ?42.605237 ?-71.34456
TTPOINT B901 ?42.661279 ?-71.364452
TTPOINT B902 ?42.660411 ?-71.364419
TTPOINT B903 ?42.659046 ?-71.364452
TTPOINT B904 ?42.657578 ?-71.364602
TTVECTOR ?B5bbbddd ?37^55.37N ?81^7.86W ?0.01 ?mi
TTGRID ??Byyyxxx ???37^50.00N ?81^00.00W ?37^59.99N ?81^09.99W
TTUTM ?B6xxxyyy ?19T ?10 ?300000 ?4720000
TTCORRAL ??37^55.50N ?81^7.00W ?0^0.02N
TTMACRO ?xx1yy ?B9xx*AB166*AA2B4C5B3B0A1yy
TTMACRO ?xx2yy ?B9xx*AB170*AA3C4C7C3B0A2yy
TTMACRO ?xxyyy ?B9xx*AB180*AA3A6C4A0Ayyy
TTMACRO ?z ?Cz

this is the sell

direwolf -t 2
Dire Wolf version 1.6
Includes optional support for: ?cm108-ptt

Reading config file direwolf.conf
Audio device for both receive and transmit: plughw:2,0 ?(channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8000 ...
Ready to accept KISS TCP client application 0 on port 8001 ...

[0L] XE1GNU-1>APDW16,WIDE1-1,WIDE2-1:!1928.03NS09906.38W#PHG5140Iniciando

XE1GNU-7 audio level = 105(55/32) ??[NONE] ??__||||||_
[0.4] XE1GNU-7>Q9RX0S,WIDE1-1,WIDE2-1:`<0x7f>^C<0x1c><0x1f>SP\`"L6}HG-UV98 2736.8Km 9.1V ?31.5C ?782.1hPa S05
MIC-E, Parking, Mic-Emsg, In Service
N 19 28.0300, W 099 06.3900, 0 MPH, course 355, alt 7267 ft
HG-UV98 2736.8Km 9.1V ?31.5C ?782.1hPa S05
[0H] XE1GNU-7>Q9RX0S,XE1GNU-1*,WIDE2-1:`<0x7f>^C<0x1c><0x1f>SP\`"L6}HG-UV98 2736.8Km 9.1V ?31.5C ?782.1hPa S05


GPIO permission denied, udev racing

 

This bug was supposedly fixed in direwolf 1.6 by adding 250ms before gpio initialization.??
I'm still observing it on a raspberry pi zero.? Does anyone have a workaround or defensive
code/patch to make direwolf more deterministic?? ?I just upped the wait to 500ms to see
if that helps, in ptt.c.

this is rare, but it still happens,

pi@gtown:~ $ tail -f /run/direwolf.log 
Audio device for both receive and transmit: plughw:0,0  (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
You don't have the necessary permission to access GPIO.
There are three different solutions: 
 1. Run as root. (not recommended)
 2. If operating system has 'gpio' group, add your user id to it.
 3. Configure your user id for sudo without a password.
?


Re: KISSPORT #### does not override 8001

 

开云体育


Hello Roger,

I just tested it and I see what you're seeing.? Ultimately, this seems to be a bug with v1.7 so unless you specifically need the BETA v1.7 release, please use the released v1.6 version.


--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf DEVELOPMENT version 1.7 A (Jul? 7 2021)
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8001 ...? <---------------------------------
Ready to accept KISS TCP client application 0 on port 8004 ...
--

Here is a confirmation of the open ports:
--
$ sudo lsof -nPi | grep direwolf
direwolf? 792?? root??? 3u? IPv4? 18033????? 0t0? TCP *:8003 (LISTEN)
direwolf? 792?? root??? 7u? IPv4? 20010????? 0t0? TCP *:8001 (LISTEN)? <----------------
direwolf? 792?? root??? 9u? IPv4? 18035????? 0t0? TCP *:8004 (LISTEN)?
--


This seems like this is a bug introduced in Direwolf v1.7 as I don't see this behavior with Direwolf v1.6:

--
$ sudo direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf
Dire Wolf version 1.6
Includes optional support for:? gpsd cm108-ptt

Reading config file /etc/ax25/direwolf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, E+, 44100 sample rate / 3.
Ready to accept AGW client application 0 on port 8003 ...
Ready to accept KISS TCP client application 0 on port 8004 ...? <--------------------
--


--David
KI6ZHD



On 07/05/2021 06:28 AM, Roger wrote:

New install of Direwolf dev1.7 does not allow changing KISSPORT? FROM 8001.
My CONF file, direwolf.conf:
? ADEVICE plughw:1,0
? ACHANNELS 1
? CHANNEL 0
? MYCALL N1XP
? MODEM 1200
? AGWPORT 8003
? KISSPORT 8004

When direwolf is executed the following appears:

Dire Wolf DEVELOPMENT version 1.7 A (Jul? 4 2021)
Includes optional support for:? cm108-ptt

Reading config file dwuhf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate / 3.
Note: PTT not configured for channel 0. (Ignore this if using VOX.)
Ready to accept AGW client application 0 on port 8005 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept KISS TCP client application 0 on port 8004 ...

Why is KISSPORT 8001 still appearing??? It seems that 8001 is hard coded into the binary - or am I doing something wrong?
Suggestions and help, please
Roger, N1XP



Re: Using GPIO pins on other SBCs

 

The numbering system is typically done through libraries.
I would assumevthat since you are usjng something other than a Pi, you are compiling Direwolf on that device.? This could/should have a cross? reference.
This site:
implies you can use the wiringpi library is used for such things.

I would give it a try with the normal designation and use a DMV to check that the proper pin is doing what you expect.

Personally, I'd go with a Pi.


On Tue, Jul 6, 2021 at 18:40, Ian (Benny) Bennett
<ibennett@...> wrote:
Thanks Robert,
??? The information you quote is specific to the RPI and I want to use the "GPIO" config command on a
Odroid-C4 (another SBC; see and
).
??? The GPIO 17 command refers to the numbering used on the RPI. i.e GPIO 17 is pin 11 on the 40 pin
header.
??? The Odroid-C4 refers to its I/O pins as GPIOX.x (where x is a number). As an example, pin 11 on the
C4's 40-pin header is referred to as GPIOX.3
??? What I need to understand is how direwolf maps the GPIO config commands to the hardware. There has
to be an OS intermediary that does this; I just need to find out what that is and adjust it to suit
the C4.
??? Regards,

Ian

On 6/7/21 10:43 pm, Rob Giuliano via groups.io wrote:
> Found more information in the manual at:
>
> Section 9.2.12 (Page 78 & 79)
> TXINH GPIO 17
> TXINH GPIO -17
> As with PTT, minus in front of the GPIO number means invert the signal.
>
> Robert Giuliano
> KB8RCO
>
>
>
> On Tuesday, July 6, 2021, 8:16:45 AM EDT, Rob Giuliano <kb8rco@...> wrote:
>
>
> If you look through the direwolf.conf file (example file) you will find examples of how to assign
> functions to pins.
> In each case, there is an example for a serial port and one for GPIO.
> Examples:
> #PTT GPIO 25
>? ??? #DCD GPIO 24
> The number is the GPIO designation (not a pin number)I can't say anything about TX INHIBIT.
> I've only seen it mentioned in the discussions
>
> Robert Giuliano
> KB8RCO
>
>
>
> On Tuesday, July 6, 2021, 4:16:33 AM EDT, Ian (Benny) Bennett <ibennett@...> wrote:
>
>
> Evening all,
>? ??? I've been reading through the direwolf RPI doco, specifically interested in the use of the GPIO
> pins for PTT, TX INHIBIT and DCD.
>? ??? I'm planning on using a different SBC (Odroid-C4) which also has exposed GPIO pins (via a 40 pin
> header) and runs (Ubuntu) Linux.
>? ??? I'm keen to understand how direwolf identifies the RPI GPIO pins so I can (hopefully) adjust the
> numbering to suit the C4.
>? ??? I did find a "wiringpi" library for the C4 but I can't find any reference to that in the direwolf
> documentation.
>? ??? I'd give it a try but the C4's are "out of stock" until mid-August, so I'm trying to get a head
> start by asking here.
>? ??? Thanks in advance.
>
> Ian
> VK1IAN
>
>
>
>
>
>






Re: Using GPIO pins on other SBCs

 

Thanks Robert,
The information you quote is specific to the RPI and I want to use the "GPIO" config command on a Odroid-C4 (another SBC; see and ).
The GPIO 17 command refers to the numbering used on the RPI. i.e GPIO 17 is pin 11 on the 40 pin header.
The Odroid-C4 refers to its I/O pins as GPIOX.x (where x is a number). As an example, pin 11 on the C4's 40-pin header is referred to as GPIOX.3
What I need to understand is how direwolf maps the GPIO config commands to the hardware. There has to be an OS intermediary that does this; I just need to find out what that is and adjust it to suit the C4.
Regards,

Ian

On 6/7/21 10:43 pm, Rob Giuliano via groups.io wrote:
Found more information in the manual at:
Section 9.2.12 (Page 78 & 79)
TXINH GPIO 17
TXINH GPIO -17
As with PTT, minus in front of the GPIO number means invert the signal.
Robert Giuliano
KB8RCO
On Tuesday, July 6, 2021, 8:16:45 AM EDT, Rob Giuliano <kb8rco@...> wrote:
If you look through the direwolf.conf file (example file) you will find examples of how to assign functions to pins.
In each case, there is an example for a serial port and one for GPIO.
Examples:
#PTT GPIO 25
??? #DCD GPIO 24
The number is the GPIO designation (not a pin number)I can't say anything about TX INHIBIT.
I've only seen it mentioned in the discussions
Robert Giuliano
KB8RCO
On Tuesday, July 6, 2021, 4:16:33 AM EDT, Ian (Benny) Bennett <ibennett@...> wrote:
Evening all,
??? I've been reading through the direwolf RPI doco, specifically interested in the use of the GPIO
pins for PTT, TX INHIBIT and DCD.
??? I'm planning on using a different SBC (Odroid-C4) which also has exposed GPIO pins (via a 40 pin
header) and runs (Ubuntu) Linux.
??? I'm keen to understand how direwolf identifies the RPI GPIO pins so I can (hopefully) adjust the
numbering to suit the C4.
??? I did find a "wiringpi" library for the C4 but I can't find any reference to that in the direwolf
documentation.
??? I'd give it a try but the C4's are "out of stock" until mid-August, so I'm trying to get a head
start by asking here.
??? Thanks in advance.
Ian
VK1IAN


Re: Using GPIO pins on other SBCs

 

Ian, I use a GPIO pin to disable the transmitter. My Igates are at VHF contest sites, and the APRS frequency is close enough to the frequencies used for contesting to interfere with contesting. So I needed a clean way to disable the transmitter.

A webpage I found that discribed simple GPIO control is below. I then wrote bash shell scripts to control a GPIO line. Those scripts are then called through an "at" command to flip the pin to off before and then back on after the contest. The script to turn it on is also run at boot as it powers up disabled. My transmit key circuit is a combination of a pnp and npn transistors so it can be inhibited.

Direwolf has no idea the transmitter is off. I also use GPIO to key the transmitter, as others have already detailed.

Reference page:


Jim Bacher, WB8VSU
wb8vsu@...
On Jul 6, 2021, at 4:16 AM, "Ian (Benny) Bennett" <ibennett@...> wrote:

Evening all,
I've been reading through the direwolf RPI doco, specifically interested in the use of the GPIO
pins for PTT, TX INHIBIT and DCD.
I'm planning on using a different SBC (Odroid-C4) which also has exposed GPIO pins (via a 40 pin
header) and runs (Ubuntu) Linux.
I'm keen to understand how direwolf identifies the RPI GPIO pins so I can (hopefully) adjust the
numbering to suit the C4.
I did find a "wiringpi" library for the C4 but I can't find any reference to that in the direwolf
documentation.
I'd give it a try but the C4's are "out of stock" until mid-August, so I'm trying to get a head
start by asking here.
Thanks in advance.

Ian
VK1IAN






Re: Using GPIO pins on other SBCs

 

Found more information in the manual at:
Section 9.2.12 (Page 78 & 79)
??? TXINH GPIO 17
? TXINH GPIO -17
As with PTT, minus in front of the GPIO number means invert the signal.

Robert Giuliano
KB8RCO



On Tuesday, July 6, 2021, 8:16:45 AM EDT, Rob Giuliano <kb8rco@...> wrote:


If you look through the direwolf.conf file (example file) you will find examples of how to assign functions to pins.
In each case, there is an example for a serial port and one for GPIO.
Examples:
??? #PTT GPIO 25
??? #DCD GPIO 24
The number is the GPIO designation (not a pin number)I can't say anything about TX INHIBIT.
I've only seen it mentioned in the discussions

Robert Giuliano
KB8RCO



On Tuesday, July 6, 2021, 4:16:33 AM EDT, Ian (Benny) Bennett <ibennett@...> wrote:


Evening all,
??? I've been reading through the direwolf RPI doco, specifically interested in the use of the GPIO
pins for PTT, TX INHIBIT and DCD.
??? I'm planning on using a different SBC (Odroid-C4) which also has exposed GPIO pins (via a 40 pin
header) and runs (Ubuntu) Linux.
??? I'm keen to understand how direwolf identifies the RPI GPIO pins so I can (hopefully) adjust the
numbering to suit the C4.
??? I did find a "wiringpi" library for the C4 but I can't find any reference to that in the direwolf
documentation.
??? I'd give it a try but the C4's are "out of stock" until mid-August, so I'm trying to get a head
start by asking here.
??? Thanks in advance.

Ian
VK1IAN






Re: Using GPIO pins on other SBCs

 

If you look through the direwolf.conf file (example file) you will find examples of how to assign functions to pins.
In each case, there is an example for a serial port and one for GPIO.
Examples:
??? #PTT GPIO 25
??? #DCD GPIO 24
The number is the GPIO designation (not a pin number)I can't say anything about TX INHIBIT.
I've only seen it mentioned in the discussions

Robert Giuliano
KB8RCO



On Tuesday, July 6, 2021, 4:16:33 AM EDT, Ian (Benny) Bennett <ibennett@...> wrote:


Evening all,
??? I've been reading through the direwolf RPI doco, specifically interested in the use of the GPIO
pins for PTT, TX INHIBIT and DCD.
??? I'm planning on using a different SBC (Odroid-C4) which also has exposed GPIO pins (via a 40 pin
header) and runs (Ubuntu) Linux.
??? I'm keen to understand how direwolf identifies the RPI GPIO pins so I can (hopefully) adjust the
numbering to suit the C4.
??? I did find a "wiringpi" library for the C4 but I can't find any reference to that in the direwolf
documentation.
??? I'd give it a try but the C4's are "out of stock" until mid-August, so I'm trying to get a head
start by asking here.
??? Thanks in advance.

Ian
VK1IAN






Using GPIO pins on other SBCs

 

Evening all,
I've been reading through the direwolf RPI doco, specifically interested in the use of the GPIO pins for PTT, TX INHIBIT and DCD.
I'm planning on using a different SBC (Odroid-C4) which also has exposed GPIO pins (via a 40 pin header) and runs (Ubuntu) Linux.
I'm keen to understand how direwolf identifies the RPI GPIO pins so I can (hopefully) adjust the numbering to suit the C4.
I did find a "wiringpi" library for the C4 but I can't find any reference to that in the direwolf documentation.
I'd give it a try but the C4's are "out of stock" until mid-August, so I'm trying to get a head start by asking here.
Thanks in advance.

Ian
VK1IAN


Re: USB audio problems; need recovery help

 

开云体育

Sleeve, Shield, regardless.? The way the mechanical attachment of a shielded (sleeved, if you will) cable to the connector nearly demands (and certainly benefits from) the shield being placed in the strain relief crimp at the tail of the connector, with the wires internal to the cable's shield routed to the T and R's.? Swapping the roles of the lower R and the S, retaining S=Ground, would accomplish the same shorting of mike to ground, since the TRRS and TRS (and even TS) plugs are all the same length.

I understand that it's the "standard" for many devices, but still believe it was done wrong.? According to at least some "MP3 Players" (remember them?) got it right.? I have my suspicions on why their "standard" didn't stick...

Greg? KO6TH


Rob Giuliano via groups.io wrote:

TRRS is not Tip-Ring-Ring-SHIELD, but Tip-Ring-Ring-SLEEVE.

On most devices, the Sleeve is the mic input.? This allows for it to be compatible between headsets with a mic and without a mic.? Those without a mic will typically short the Sleeve (mic) to ground and indicate to the device that no mic is present.

This is true in most current laptops that have switched to the TRRS connector, as well as most tablets and cell phones.

Robert Giuliano
KB8RCO



On Monday, July 5, 2021, 5:28:03 PM EDT, Greg D <ko6th.greg@...> wrote:


I hope so, too.? It may be a while; the problem appears to have "gone away" since rebuilding the interface cable, but I've saved the instructions in a text file on the Pi's desktop in case it "comes back" at a most inopportune moment.

Thanks for the help!

Greg? KO6TH

p.s.? Note to the folks coming up with connector pinouts:? When you see "Shield" in a TRRS connector's description, please connect it to the Shield, not the Mike-In!


Michael - NA7Q wrote:
Just restore. You don't even need to reboot unless something is messed up with the system.

I'd like to hear your results! Hopefully it works out!



Re: USB audio problems; need recovery help

 

TRRS is not Tip-Ring-Ring-SHIELD, but Tip-Ring-Ring-SLEEVE.

On most devices, the Sleeve is the mic input.? This allows for it to be compatible between headsets with a mic and without a mic.? Those without a mic will typically short the Sleeve (mic) to ground and indicate to the device that no mic is present.

This is true in most current laptops that have switched to the TRRS connector, as well as most tablets and cell phones.

Robert Giuliano
KB8RCO



On Monday, July 5, 2021, 5:28:03 PM EDT, Greg D <ko6th.greg@...> wrote:


I hope so, too.? It may be a while; the problem appears to have "gone away" since rebuilding the interface cable, but I've saved the instructions in a text file on the Pi's desktop in case it "comes back" at a most inopportune moment.

Thanks for the help!

Greg? KO6TH

p.s.? Note to the folks coming up with connector pinouts:? When you see "Shield" in a TRRS connector's description, please connect it to the Shield, not the Mike-In!


Michael - NA7Q wrote:

Just restore. You don't even need to reboot unless something is messed up with the system.

I'd like to hear your results! Hopefully it works out!


Re: USB audio problems; need recovery help

 

开云体育

I hope so, too.? It may be a while; the problem appears to have "gone away" since rebuilding the interface cable, but I've saved the instructions in a text file on the Pi's desktop in case it "comes back" at a most inopportune moment.

Thanks for the help!

Greg? KO6TH

p.s.? Note to the folks coming up with connector pinouts:? When you see "Shield" in a TRRS connector's description, please connect it to the Shield, not the Mike-In!


Michael - NA7Q wrote:

Just restore. You don't even need to reboot unless something is messed up with the system.

I'd like to hear your results! Hopefully it works out!


Re: USB audio problems; need recovery help

 

Just restore. You don't even need to reboot unless something is messed up with the system.

I'd like to hear your results! Hopefully it works out!


KISSPORT #### does not override 8001

 

New install of Direwolf dev1.7 does not allow changing KISSPORT? FROM 8001.
My CONF file, direwolf.conf:
? ADEVICE plughw:1,0
? ACHANNELS 1
? CHANNEL 0
? MYCALL N1XP
? MODEM 1200
? AGWPORT 8003
? KISSPORT 8004

When direwolf is executed the following appears:

Dire Wolf DEVELOPMENT version 1.7 A (Jul? 4 2021)
Includes optional support for:? cm108-ptt

Reading config file dwuhf.conf
Audio device for both receive and transmit: plughw:1,0? (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate / 3.
Note: PTT not configured for channel 0. (Ignore this if using VOX.)
Ready to accept AGW client application 0 on port 8005 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
Ready to accept KISS TCP client application 0 on port 8004 ...

Why is KISSPORT 8001 still appearing??? It seems that 8001 is hard coded into the binary - or am I doing something wrong?
Suggestions and help, please
Roger, N1XP