Presently running version 6.0.24.71 and IPv4 / IPv6 enabled as usual here.

What I see with forwarding to hostnames who resolves to both IPv4 and IPv6 addresses BPQ defaults to IPv4 forwarding.
I believe that this was not always the case with older releases and that BPQ was using the Linux / Windows convention, that is try IPv6 first
and when not possible fall back to IPv6 -

Regards,

Boudewijn, VE3TOK

There is nothing permanent except change
Heraclitus

John,

Few days ago I spent some time in comparing behaviour of SCS Dragon vs. KAM XL controller by using QtTerm and then by using minicom terminal: For example, SCS driver allows a sysop to initiate an outgoing Pactor call to the other station, and do it repeatedly, like this:

att <portnum>
c <callsign>
...
...
...
(If the call fails or finishes, it returns 'Disconnected', and then the user can reconnect to the node and repeat the commands above. No problem with that.)

Then I tested the same by using minicom terminal (Linux):

c <callsign>
...
...
...
(If the call fails, it returns ***STDBY>>, followed by a cmd:? So the user can reinitiate the connection command immediately. That's fine.)


In opposite to that, KAM XL behaves differently (by using minicom). For example, to initiate an outgoing G-tor link:

gtor <callsign>
...
...
...
(If the call fails, it returns "<GTOR STANDBY>" and *remains* in that mode. Any subsequent attempt to initiate an outgoing call does not return anything, as well as after sending a carriage return or else. The only way to get cmd:? prompt is to send Ctrl-C [plus] X. That brings back cmd:? prompt, and another outgoing link request can be done, for example:

pactor <callsign>
...
...
...
(If that one attempt also fails, the user can send again Ctrl-C [plus] X. That brings back cmd:

Then I tried the same operation in QtTerm:

att <portnum>
gtor <callsign>
...
...
...
(If the call fails, it does not return anything. A subsequent outgoing call returns "input ignored", and the only cure is to disconnect or send a carriage return, and then reconnect once again:

att <portnum>
pactor <callsign>
...
...
...


I did not have time to try Ctrl-C [plus] X within QtTerm. But in any case it might be of use to investigate whether forwarding scripts can accommodate sending commands such as Ctrl-C [plus] X, particularly in coordination with 'else' statements. That means for example if a user wants to use KAM XL to initiate connection by G-tor at first, and if that fails to try it by Pactor, etc ...

Any opinion?

Misko YT7MPB


On 4/29/25 4:33 PM, Misko YT7MPB via groups.io wrote:

John,

Some more from today ...

SIGSEGV Received
./linbpq(+0x112e85)[0x54ce85]
linux-gate.so.1(__kernel_sigreturn+0x0)[0xb7f13564]
./linbpq(+0x8ea71)[0x4c8a71]
./linbpq(+0x8eb18)[0x4c8b18]
./linbpq(+0x8eb18)[0x4c8b18]
./linbpq(+0x8ea36)[0x4c8a36]
./linbpq(+0x8d72e)[0x4c772e]
./linbpq(+0xca4a2)[0x5044a2]
./linbpq(+0xcd77b)[0x50777b]
./linbpq(main+0x1895)[0x54edde]
ham@localhost:~/linbpq$ addr2line -e linbpq +0x112e85 0x54ce85 0xb7f13564 +0x8ea71 0x4c8a71 +0x8eb18 0x4c8b18 +0x8eb18 0x4c8b18 +0x8ea36 0x4c8a36 +0x8d72e 0x4c772e +0xca4a2 0x5044a2 +0xcd77b 0x50777b main+0x1895 0x54edde
/mnt/Source/bpq32/CommonSource/LinBPQ.c:394
??:0
??:0
/mnt/Source/bpq32/CommonSource/KAMPactor.c:807
??:0
/mnt/Source/bpq32/CommonSource/KAMPactor.c:829
??:0
/mnt/Source/bpq32/CommonSource/KAMPactor.c:829
??:0
/mnt/Source/bpq32/CommonSource/KAMPactor.c:790
??:0
/mnt/Source/bpq32/CommonSource/KAMPactor.c:339
??:0
/mnt/Source/bpq32/CommonSource/cMain.c:505
??:0
/mnt/Source/bpq32/CommonSource/cMain.c:2062
??:0
??:0
??:0
ham@localhost:~/linbpq$

John,
Some more from today ...
SIGSEGV Received
./linbpq(+0x112e85)[0x54ce85]
linux-gate.so.1(__kernel_sigreturn+0x0)[0xb7f13564]
./linbpq(+0x8ea71)[0x4c8a71]
./linbpq(+0x8eb18)[0x4c8b18]
./linbpq(+0x8eb18)[0x4c8b18]
./linbpq(+0x8ea36)[0x4c8a36]
./linbpq(+0x8d72e)[0x4c772e]
./linbpq(+0xca4a2)[0x5044a2]
./linbpq(+0xcd77b)[0x50777b]
./linbpq(main+0x1895)[0x54edde]
ham@localhost:~/linbpq$ addr2line -e linbpq +0x112e85 0x54ce85 0xb7f13564 +0x8ea71 0x4c8a71 +0x8eb18 0x4c8b18 +0x8eb18 0x4c8b18 +0x8ea36 0x4c8a36 +0x8d72e 0x4c772e +0xca4a2 0x5044a2 +0xcd77b 0x50777b main+0x1895 0x54edde
/mnt/Source/bpq32/CommonSource/LinBPQ.c:394
??:0
??:0
/mnt/Source/bpq32/CommonSource/KAMPactor.c:807
??:0
/mnt/Source/bpq32/CommonSource/KAMPactor.c:829
??:0
/mnt/Source/bpq32/CommonSource/KAMPactor.c:829
??:0
/mnt/Source/bpq32/CommonSource/KAMPactor.c:790
??:0
/mnt/Source/bpq32/CommonSource/KAMPactor.c:339
??:0
/mnt/Source/bpq32/CommonSource/cMain.c:505
??:0
/mnt/Source/bpq32/CommonSource/cMain.c:2062
??:0
??:0
??:0
ham@localhost:~/linbpq$

BPQ32.dll (in BPQ32.zip) and BPQMail.exe are in my Beta download. There isn't an Installer.

73,
John

On 16/05/2025 14:31, Angelo Glorioso via groups.io wrote:

HI John,

?Is there an official release for windows???

Angelo

---------------------------------------------------------
If you don't ask, you will never know!!

---

From: [email protected] <[email protected]> on behalf of John G8BPQ via groups.io <john.wiseman@...>
Sent: Friday, May 16, 2025 8:22 AM
To: [email protected] <[email protected]>
Subject: [bpq32] New Version .71

?

> I've uploaded new versions (6.0.24.71) to my Beta area and github.

This should fix a problem with connects to the BBS causing a crash in
some circumstances.

There have also been a number of fixes to the INP3 code, so it you are
using INP3 please check that it is still behaving as expected.

73, John

HI John,

?Is there an official release for windows???

Angelo

---------------------------------------------------------
If you don't ask, you will never know!!

---

From: [email protected] <[email protected]> on behalf of John G8BPQ via groups.io <john.wiseman@...>
Sent: Friday, May 16, 2025 8:22 AM
To: [email protected] <[email protected]>
Subject: [bpq32] New Version .71

?

> I've uploaded new versions (6.0.24.71) to my Beta area and github.

This should fix a problem with connects to the BBS causing a crash in
some circumstances.

There have also been a number of fixes to the INP3 code, so it you are
using INP3 please check that it is still behaving as expected.

73, John

Ok, so off on another fine tuning adventure -

?

As it deals with aprs, does btext and btinterval play into the config?

?

PORT
?PORTNUM=3
?ID=QtSM APRS
?TYPE=ASYNC
?PROTOCOL=KISS
?IPADDR=127.0.0.1
?TCPPORT=8001
?;BCALL=W9JUN-10
?;UNPROTO=APBPQ1
?;DIGIFLAG=1?
?CHANNEL=A
?MAXFRAME=4
?FULLDUP=0
?FRACK=4000
?RESPTIME=3000
?RETRIES=4
?PACLEN=128 ? ?
?TXDELAY=500
?TXTAIL=50?
?PERSIST=63
?SLOTTIME=100
?ENDPORT

Change to zero.

73, John

On 15/05/2025 17:25, Don via groups.io wrote:

It's set to 1, John

Sent with secure email.

On Thursday, May 15th, 2025 at 11:50 AM, John G8BPQ via groups.io <john.wiseman@...> wrote:

I'm not clear what you are saying.

Is it your station call that always appears via tcp?

If so, do you have BeacontoIS=0 in your BPQ APRS Config? If not, you are sending your beacon to the APRS-IS server directly over TCP and that will always arrive before a packet is received via RF.

73, John

On 14/05/2025 13:47, Don via groups.io wrote:

Good evening

Enjoying trying to get linbpq setup for aprs -

Currently the only path I see on aprs.fi is tcpip. However, if I run Direwolf alone, I get an RF path frequently.

I have digimap setup, and the aprs path is wide2-1, as well.

It's set to 1, John

Sent with secure email.

On Thursday, May 15th, 2025 at 11:50 AM, John G8BPQ via groups.io <john.wiseman@...> wrote:

I'm not clear what you are saying.

Is it your station call that always appears via tcp?

If so, do you have BeacontoIS=0 in your BPQ APRS Config? If not, you are sending your beacon to the APRS-IS server directly over TCP and that will always arrive before a packet is received via RF.

73, John

On 14/05/2025 13:47, Don via groups.io wrote:

Good evening

Enjoying trying to get linbpq setup for aprs -

Currently the only path I see on aprs.fi is tcpip. However, if I run Direwolf alone, I get an RF path frequently.

I have digimap setup, and the aprs path is wide2-1, as well.

I'm not clear what you are saying.

Is it your station call that always appears via tcp?

If so, do you have BeacontoIS=0 in your BPQ APRS Config? If not, you are sending your beacon to the APRS-IS server directly over TCP and that will always arrive before a packet is received via RF.

73, John

On 14/05/2025 13:47, Don via groups.io wrote:

Good evening

Enjoying trying to get linbpq setup for aprs -

Currently the only path I see on aprs.fi is tcpip. However, if I run Direwolf alone, I get an RF path frequently.

I have digimap setup, and the aprs path is wide2-1, as well.

Well John - this new executable crashes on connect to the BBS alias.? ran it twice to be sure then did a debug capture and put the whole mess into a new file (attached).

--

Charlie (N4NVD)