This issue has been here awhile, but anytime one or more links are down, the links web page shows only one or two available links out of the six I have. ?Right now it shows two active links, but showing links on the node terminal, shows five active links. ?Does this happen for others?

Current running pilinbpq 6.0.24.71 but the issue has been there for at least 6.0.24.30

?

Jim KI0BK

The issue with BPQ seems to be not the 'defaulting to IPv4' but that outgoing telnet to IPv6 fails to connect at all both in the latest stable and beta versions and
this while IPv4 and IPv6 are both enabled for the telnet port, see below.

--

I tested outgoing telnet from the BPQ node to a tcp port what can only handle IPv6 as I have a 6tunnel for IPv6 to Xnet, what is a IPv4 only program.
6tunnel converts here a IPv6 input at tcp port 24 to IPv4 at tcp port 23 what connects to Xnet.

BPQ

po
BPQTOK:VE3TOK-12} Ports
? 1 Kiss Link to Kernel
? 2 Kiss Link to (X)net
? 3 Telnet Server
? 4 AX/IP/UDP
attach 3
BPQTOK:VE3TOK-12} Ok
c linux.ve3mch.ampr.org 24
*** Failed to Connect

linux.ve3mch.ampr.org resolves both to an IPv4 and IPV6 address. I tested this from the latest stable BPQ version as well as from the latest beta version
and both are failing with outgoing telnet over IPv6. Both IPv4 and IPv6 are enabled for the telnet port in BPQ with,

? IPV6=1
? IPV4=1

From the linux shell to proof that IPv6 really works at port 24

# telnet linux.ve3mch.ampr.org 24
Trying 2001:470:1d:138::1...
Connected to linux.ve3mch.ampr.org.
Escape character is '^]'.
(X)NET 1.39 @ VE3MCH-8 on LINUX: PSE enter Your callsign to login.

Login:

With IPv4 from the shell to Xnet at port 24

telnet -4 linux.ve3mch.ampr.org 24
Trying 44.135.85.151...
telnet: Unable to connect to remote host: Connection refused

What is as expected.

Regards,

Boudewijn VE3TOK



On 5/17/25 15:36, Boudewijn (Bob) Tenty VE3TOK wrote:

Oops, the last line should be read as 'and when not possible fall back to IPv4 -'

On 5/17/25 15:27, Boudewijn (Bob) Tenty VE3TOK wrote:

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

Oops, the last line should be read as 'and when not possible fall back to IPv4 -'

On 5/17/25 15:27, Boudewijn (Bob) Tenty VE3TOK wrote:

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

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