¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

linbpq reconnection bug / misconfiguration / misunderstanding ?


 

Hi All
?
Last night I was experimenting with someone locally who was trying to connect to my LinBPQ? node and had some software issues their side which revealed some weird behaviour within BPQ. I'm not sure if this is a bug, misconfiguration or misunderstanding.
?
To replicate I'm using LinBPQ as the node (2E0SIP), and for the user / client (M6IJY) I'm using a Kenwood TH-D7 with built in TNC. I've pasted the logs from Dire Wolf to show the raw packets.
?
First off, the user connects to the LinBPQ node and enters INFO. Everything works as expected, the user connects, can enter commands, and receives the expected output:
?
M6IJY audio level = 51(27/17)? ?[NONE]? ?_|||||||_
[0.4 09:44:48] M6IJY>2E0SIP:(SABM cmd, p=1)
[0L 09:44:49] 2E0SIP>M6IJY:(UA res, f=1)
[0L 09:44:49] 2E0SIP>M6IJY:(I cmd, n(s)=0, n(r)=0, p=1, pid=0xf0)Welcome to 2E0SIP's Test Packet Node. <0x0d>Type INFO for information or<0x0d>? for list of available commands.<0x0d>
?
M6IJY audio level = 51(26/18)? ?[NONE]? ?__||||||_
[0.4 09:44:51] M6IJY>2E0SIP:(RR res, n(r)=1, f=1)
?
M6IJY audio level = 50(26/18)? ?[NONE]? ?_||||||__
[0.3 09:44:56] M6IJY>2E0SIP:(I cmd, n(s)=0, n(r)=1, p=1, pid=0xf0)INFO<0x0d>
[0L 09:44:56] 2E0SIP>M6IJY:(RR res, n(r)=1, f=1)
[0L 09:44:56] 2E0SIP>M6IJY:(I cmd, n(s)=1, n(r)=1, p=0, pid=0xf0)2E0SIP} A Test Packet Node. Not much to see here, but type <0x0d>SYSCHAT to enter a 1:1 chat with the SYSOP, 2E0SIP<0x0d><0x0d>Location: IO91SP
[0L 09:44:57] 2E0SIP>M6IJY:(I cmd, n(s)=2, n(r)=1, p=1, pid=0xf0)<0x0d>Contact: matthew@...<0x0d>Web: packet.oarc.uk<0x0d><0x0d>
?
M6IJY audio level = 50(26/18)? ?[NONE]? ?_|||||||_
[0.4 09:44:59] M6IJY>2E0SIP:(RR res, n(r)=3, f=1)
?
?
Then if I force the user to think it has disconnected without actually sending a disconnect command to the node, then connect again, things go haywire. In my case I simulate this by resetting the user side TNC so it forgets its in a connected state. Then connect again.
?
When the user connects the node responds with its CTEXT, but all subsequent commands are acknowledged(?) with an RR response, but don't otherwise respond as expected:
?
M6IJY audio level = 50(26/18)? ?[NONE]? ?__||||||_
[0.4 09:46:15] M6IJY>2E0SIP:(SABM cmd, p=1)
[0L 09:46:16] 2E0SIP>M6IJY:(UA res, f=1)
[0L 09:46:16] 2E0SIP>M6IJY:(I cmd, n(s)=0, n(r)=0, p=1, pid=0xf0)Welcome to 2E0SIP's Test Packet Node. <0x0d>Type INFO for information or<0x0d>? for list of available commands.<0x0d>
?
M6IJY audio level = 51(26/18)? ?[NONE]? ?__|||||__
[0.4 09:46:18] M6IJY>2E0SIP:(RR res, n(r)=1, f=1)
?
M6IJY audio level = 50(26/18)? ?[NONE]? ?_|||||||_
[0.4 09:46:28] M6IJY>2E0SIP:(I cmd, n(s)=0, n(r)=1, p=1, pid=0xf0)INFO<0x0d>
[0L 09:46:28] 2E0SIP>M6IJY:(RR res, n(r)=1, f=1)
?
M6IJY audio level = 50(26/18)? ?[NONE]? ?_|||||||_
[0.4 09:46:34] M6IJY>2E0SIP:(I cmd, n(s)=1, n(r)=1, p=1, pid=0xf0)?<0x0d>
[0L 09:46:35] 2E0SIP>M6IJY:(RR res, n(r)=2, f=1)
?
M6IJY audio level = 51(27/18)? ?[NONE]? ?_|||||||_
[0.4 09:46:40] M6IJY>2E0SIP:(I cmd, n(s)=2, n(r)=1, p=1, pid=0xf0)INFO<0x0d>
[0L 09:46:41] 2E0SIP>M6IJY:(RR res, n(r)=3, f=1
?
Things then remain in this broken state until I issue a DISCONNECT command. Subsequent reconnects then work as expected, assuming they're cleanly disconnected.
?
Does anyone have any ideas or suggestions?
?
Thanks
Matthew


 

Hi all,

Any thoughts on this?

Thanks
Matthew
2E0SIP


 

Unfortunately this is continuing to cause some issues, both in terms of users connecting and also BBS to BBS connections which just hang on occasion.

Is someone able to confirm if they see the same behaviour? The method used to demonstrate this issue is in the original post.

Thanks
Matthew
2E0SIP


 

I see the same behaviour.? Traces below are from linbpq running on Ubuntu as G6FJI and a Tiny-2 TNC running as G6FJI-3

>>> Connect from TNC with "c g6fji"
?
10:27:03R G6FJI-3>G6FJI Port=1 <C C P>
10:27:03T G6FJI>G6FJI-3 Port=1 <UA R F>
10:27:09R G6FJI-3>G6FJI Port=1 <I C P S0 R0>:
?
10:27:09T G6FJI>G6FJI-3 Port=1 <RR R F R1>
10:27:10T G6FJI>G6FJI-3 Port=1 <I C P S0 R1>:
ABNGDN:G6FJI} BBS CHAT HARS PADDLE WX CONNECT BYE INFO NODES PORTS ROUTES USERS MHEARD
10:27:12R G6FJI-3>G6FJI Port=1 <RR R F R1>
?
>>> Power cycle TNC; Connect with "c g6fji"
?
10:27:32R G6FJI-3>G6FJI Port=1 <C C P>
10:27:32T G6FJI>G6FJI-3 Port=1 <UA R F>
10:27:37R G6FJI-3>G6FJI Port=1 <I C P S0 R0>:
?
10:27:37T G6FJI>G6FJI-3 Port=1 <RR R F R1>
10:27:42R G6FJI-3>G6FJI Port=1 <I C P S1 R0>:
?
10:27:42T G6FJI>G6FJI-3 Port=1 <RR R F R2>
?
>>> On TNC, Ctrl-C then DISC
?
10:27:48R G6FJI-3>G6FJI Port=1 <D C P>
10:27:48T G6FJI>G6FJI-3 Port=1 <UA R F>
?
>>> Connect from TNC again
?
10:27:55R G6FJI-3>G6FJI Port=1 <C C P>
10:27:55T G6FJI>G6FJI-3 Port=1 <UA R F>
10:27:59R G6FJI-3>G6FJI Port=1 <I C P S0 R0>:
?
10:27:59T G6FJI>G6FJI-3 Port=1 <RR R F R1>
10:27:59T G6FJI>G6FJI-3 Port=1 <I C P S0 R1>:
ABNGDN:G6FJI} BBS CHAT HARS PADDLE WX CONNECT BYE INFO NODES PORTS ROUTES USERS MHEARD
10:28:01R G6FJI-3>G6FJI Port=1 <RR R F R1>
10:28:04R G6FJI-3>G6FJI Port=1 <I C P S1 R1>:
bye
10:28:04T G6FJI>G6FJI-3 Port=1 <RR R F R2>
10:28:04T G6FJI>G6FJI-3 Port=1 <D C P>
10:28:06R G6FJI-3>G6FJI Port=1 <UA R F>
?


 

Hi all,

If it¡¯s not clear to anyone reading, I have ¡ª-commented¡ª- where it looks like it is going wrong and what should be expected as normal behaviour.


Connect from TNC with "c g6fji"
?
10:27:03R G6FJI-3>G6FJI Port=1 <C C P>
10:27:03T G6FJI>G6FJI-3 Port=1 <UA R F>
10:27:09R G6FJI-3>G6FJI Port=1 <I C P S0 R0>:
?
10:27:09T G6FJI>G6FJI-3 Port=1 <RR R F R1>
10:27:10T G6FJI>G6FJI-3 Port=1 <I C P S0 R1>:
ABNGDN:G6FJI} BBS CHAT HARS PADDLE WX CONNECT BYE INFO NODES PORTS ROUTES USERS MHEARD
10:27:12R G6FJI-3>G6FJI Port=1 <RR R F R1>
?
?Power cycle TNC; Connect with "c g6fji"
?

10:27:32R G6FJI-3>G6FJI Port=1 <C C P>

¡ªSABM- THIS MAY BE EXPECTED TO RESET THE OLD LINK¡ª

?

10:27:32T G6FJI>G6FJI-3 Port=1 <UA R F>

¡ª- ANTICIPATED BEHAVIOUR: A FRESH CONNECTION. NODE IS ONLY AWARE THAT PACKETS ARE NO LONGER IN SEQUENCE, SEQUENCE HAS BEEN INTERRUPTED¡ª

(Eventually this should force the node to send a DISC to the client, given enough time for the timeout to occur, but does it?)

10:27:37R G6FJI-3>G6FJI Port=1 <I C P S0 R0>:
?
10:27:37T G6FJI>G6FJI-3 Port=1 <RR R F R1>
10:27:42R G6FJI-3>G6FJI Port=1 <I C P S1 R0>:
?

10:27:42T G6FJI>G6FJI-3 Port=1 <RR R F R2>

¡ª-STATE APPEARS TO BE STUCK ¡ª-

?
?On TNC, Ctrl-C then DISC
?

10:27:48R G6FJI-3>G6FJI Port=1 <D C P>

¡ª-DISC- THIS SUCCESSFULLY ABORTS THE CONNECTION. ¡ª

10:27:48T G6FJI>G6FJI-3 Port=1 <UA R F>

¡ªDISC ACKED¡ª?

?Connect from TNC again

¡ª-±·°¿¸é²Ñ´¡³¢¡ª

?
10:27:55R G6FJI-3>G6FJI Port=1 <C C P>
10:27:55T G6FJI>G6FJI-3 Port=1 <UA R F>
10:27:59R G6FJI-3>G6FJI Port=1 <I C P S0 R0>:
?
10:27:59T G6FJI>G6FJI-3 Port=1 <RR R F R1>
10:27:59T G6FJI>G6FJI-3 Port=1 <I C P S0 R1>:
ABNGDN:G6FJI} BBS CHAT HARS PADDLE WX CONNECT BYE INFO NODES PORTS ROUTES USERS MHEARD
10:28:01R G6FJI-3>G6FJI Port=1 <RR R F R1>
10:28:04R G6FJI-3>G6FJI Port=1 <I C P S1 R1>:
bye
10:28:04T G6FJI>G6FJI-3 Port=1 <RR R F R2>
10:28:04T G6FJI>G6FJI-3 Port=1 <D C P>
10:28:06R G6FJI-3>G6FJI Port=1 <UA R F>

73
Red


 

¿ªÔÆÌåÓý

It looks like packets are being acked normally, but not passed to the command handler. I'll look into it

73,
John


On 24/04/2023 19:37, PacketCat Red PE1RRR wrote:

Hi all,

If it¡¯s not clear to anyone reading, I have ¡ª-commented¡ª- where it looks like it is going wrong and what should be expected as normal behaviour.


Connect from TNC with "c g6fji"
?
10:27:03R G6FJI-3>G6FJI Port=1 <C C P>
10:27:03T G6FJI>G6FJI-3 Port=1 <UA R F>
10:27:09R G6FJI-3>G6FJI Port=1 <I C P S0 R0>:
?
10:27:09T G6FJI>G6FJI-3 Port=1 <RR R F R1>
10:27:10T G6FJI>G6FJI-3 Port=1 <I C P S0 R1>:
ABNGDN:G6FJI} BBS CHAT HARS PADDLE WX CONNECT BYE INFO NODES PORTS ROUTES USERS MHEARD
10:27:12R G6FJI-3>G6FJI Port=1 <RR R F R1>
?
?Power cycle TNC; Connect with "c g6fji"
?

10:27:32R G6FJI-3>G6FJI Port=1 <C C P>

¡ªSABM- THIS MAY BE EXPECTED TO RESET THE OLD LINK¡ª

?

10:27:32T G6FJI>G6FJI-3 Port=1 <UA R F>

¡ª- ANTICIPATED BEHAVIOUR: A FRESH CONNECTION. NODE IS ONLY AWARE THAT PACKETS ARE NO LONGER IN SEQUENCE, SEQUENCE HAS BEEN INTERRUPTED¡ª

(Eventually this should force the node to send a DISC to the client, given enough time for the timeout to occur, but does it?)

10:27:37R G6FJI-3>G6FJI Port=1 <I C P S0 R0>:
?
10:27:37T G6FJI>G6FJI-3 Port=1 <RR R F R1>
10:27:42R G6FJI-3>G6FJI Port=1 <I C P S1 R0>:
?

10:27:42T G6FJI>G6FJI-3 Port=1 <RR R F R2>

¡ª-STATE APPEARS TO BE STUCK ¡ª-

?
?On TNC, Ctrl-C then DISC
?

10:27:48R G6FJI-3>G6FJI Port=1 <D C P>

¡ª-DISC- THIS SUCCESSFULLY ABORTS THE CONNECTION. ¡ª

10:27:48T G6FJI>G6FJI-3 Port=1 <UA R F>

¡ªDISC ACKED¡ª?

?Connect from TNC again

¡ª-±·°¿¸é²Ñ´¡³¢¡ª

?
10:27:55R G6FJI-3>G6FJI Port=1 <C C P>
10:27:55T G6FJI>G6FJI-3 Port=1 <UA R F>
10:27:59R G6FJI-3>G6FJI Port=1 <I C P S0 R0>:
?
10:27:59T G6FJI>G6FJI-3 Port=1 <RR R F R1>
10:27:59T G6FJI>G6FJI-3 Port=1 <I C P S0 R1>:
ABNGDN:G6FJI} BBS CHAT HARS PADDLE WX CONNECT BYE INFO NODES PORTS ROUTES USERS MHEARD
10:28:01R G6FJI-3>G6FJI Port=1 <RR R F R1>
10:28:04R G6FJI-3>G6FJI Port=1 <I C P S1 R1>:
bye
10:28:04T G6FJI>G6FJI-3 Port=1 <RR R F R2>
10:28:04T G6FJI>G6FJI-3 Port=1 <D C P>
10:28:06R G6FJI-3>G6FJI Port=1 <UA R F>

73
Red


 

Hi John,

Did you have chance to look at this one?

Thanks
Matthew
2E0SIP


 

Hey John, did you manage to look into this at all please?

Best wishes
Tom


 

¿ªÔÆÌåÓý

Sorry, no. It slipped my mind. I'll see if I can recreate it.

73,
John


On 25/05/2023 16:14, Tom M0LTE wrote:

Hey John, did you manage to look into this at all please?

Best wishes
Tom


 

¿ªÔÆÌåÓý

The latest version in My Beta area (6.0.23.71) should fix this.

73,
John

On 21/03/2023 11:20, Matthew 2E0SIP wrote:

Hi All
?
Last night I was experimenting with someone locally who was trying to connect to my LinBPQ? node and had some software issues their side which revealed some weird behaviour within BPQ. I'm not sure if this is a bug, misconfiguration or misunderstanding.
?
To replicate I'm using LinBPQ as the node (2E0SIP), and for the user / client (M6IJY) I'm using a Kenwood TH-D7 with built in TNC. I've pasted the logs from Dire Wolf to show the raw packets.
?
First off, the user connects to the LinBPQ node and enters INFO. Everything works as expected, the user connects, can enter commands, and receives the expected output:
?
M6IJY audio level = 51(27/17)? ?[NONE]? ?_|||||||_
[0.4 09:44:48] M6IJY>2E0SIP:(SABM cmd, p=1)
[0L 09:44:49] 2E0SIP>M6IJY:(UA res, f=1)
[0L 09:44:49] 2E0SIP>M6IJY:(I cmd, n(s)=0, n(r)=0, p=1, pid=0xf0)Welcome to 2E0SIP's Test Packet Node. <0x0d>Type INFO for information or<0x0d>? for list of available commands.<0x0d>
?
M6IJY audio level = 51(26/18)? ?[NONE]? ?__||||||_
[0.4 09:44:51] M6IJY>2E0SIP:(RR res, n(r)=1, f=1)
?
M6IJY audio level = 50(26/18)? ?[NONE]? ?_||||||__
[0.3 09:44:56] M6IJY>2E0SIP:(I cmd, n(s)=0, n(r)=1, p=1, pid=0xf0)INFO<0x0d>
[0L 09:44:56] 2E0SIP>M6IJY:(RR res, n(r)=1, f=1)
[0L 09:44:56] 2E0SIP>M6IJY:(I cmd, n(s)=1, n(r)=1, p=0, pid=0xf0)2E0SIP} A Test Packet Node. Not much to see here, but type <0x0d>SYSCHAT to enter a 1:1 chat with the SYSOP, 2E0SIP<0x0d><0x0d>Location: IO91SP
[0L 09:44:57] 2E0SIP>M6IJY:(I cmd, n(s)=2, n(r)=1, p=1, pid=0xf0)<0x0d>Contact: matthew@...<0x0d>Web: packet.oarc.uk<0x0d><0x0d>
?
M6IJY audio level = 50(26/18)? ?[NONE]? ?_|||||||_
[0.4 09:44:59] M6IJY>2E0SIP:(RR res, n(r)=3, f=1)
?
?
Then if I force the user to think it has disconnected without actually sending a disconnect command to the node, then connect again, things go haywire. In my case I simulate this by resetting the user side TNC so it forgets its in a connected state. Then connect again.
?
When the user connects the node responds with its CTEXT, but all subsequent commands are acknowledged(?) with an RR response, but don't otherwise respond as expected:
?
M6IJY audio level = 50(26/18)? ?[NONE]? ?__||||||_
[0.4 09:46:15] M6IJY>2E0SIP:(SABM cmd, p=1)
[0L 09:46:16] 2E0SIP>M6IJY:(UA res, f=1)
[0L 09:46:16] 2E0SIP>M6IJY:(I cmd, n(s)=0, n(r)=0, p=1, pid=0xf0)Welcome to 2E0SIP's Test Packet Node. <0x0d>Type INFO for information or<0x0d>? for list of available commands.<0x0d>
?
M6IJY audio level = 51(26/18)? ?[NONE]? ?__|||||__
[0.4 09:46:18] M6IJY>2E0SIP:(RR res, n(r)=1, f=1)
?
M6IJY audio level = 50(26/18)? ?[NONE]? ?_|||||||_
[0.4 09:46:28] M6IJY>2E0SIP:(I cmd, n(s)=0, n(r)=1, p=1, pid=0xf0)INFO<0x0d>
[0L 09:46:28] 2E0SIP>M6IJY:(RR res, n(r)=1, f=1)
?
M6IJY audio level = 50(26/18)? ?[NONE]? ?_|||||||_
[0.4 09:46:34] M6IJY>2E0SIP:(I cmd, n(s)=1, n(r)=1, p=1, pid=0xf0)?<0x0d>
[0L 09:46:35] 2E0SIP>M6IJY:(RR res, n(r)=2, f=1)
?
M6IJY audio level = 51(27/18)? ?[NONE]? ?_|||||||_
[0.4 09:46:40] M6IJY>2E0SIP:(I cmd, n(s)=2, n(r)=1, p=1, pid=0xf0)INFO<0x0d>
[0L 09:46:41] 2E0SIP>M6IJY:(RR res, n(r)=3, f=1
?
Things then remain in this broken state until I issue a DISCONNECT command. Subsequent reconnects then work as expected, assuming they're cleanly disconnected.
?
Does anyone have any ideas or suggestions?
?
Thanks
Matthew


 

Hi John,

I've tested and can confirm it looks like its now fixed. I was able to drop the connection without sending the disconnect (DISC), then re-connect (SABM) without BPQ getting into the same state as before where it would ack packets without sending a response.

Really appreciate this as I'd seen it create a few problems in the wild, especially over intermittent RF links.

Thanks again

Matthew

2E0SIP