#7 thebridge1.09 and 1.06 .disconnect crash

[VE3GOB]

So I installed latest version of thebridge. (1.09). It looks fine.
Another admin Tom of DX-LINK was explaining the admin commands. He told me to .connect DX-LINK. I did all was fine. Then he went to bed and I tried to disconnect. Thebridge crashed. Not good. I could not figure out why. Went thru the setting in tbd.conf carefully several times and found no issue. I started conference back up and was immediatly connected to DX-LINK again, ok I learned this was a persistant setting. Tried to disconnect again and boom said disconnecting and crashed again. I tried to find he file where this setting is located so that I may edit out that setting without any success. Can you tell me which file saves that .connect command? All other commands I have tried work fine except for .ban where I get the same crash when I tryed to .ban DX-LINK as a temp work around.
I became so frustrated that I completely wiped the install and started agian with a fresh OS (UBUNTU Server 16.04 64bit). This is hosted on a paid VPS with rediculous amounts of bandwidth and power. After a few hours setting it up I fired up the new conference server and it did the same thing. Now I feel certain that this is a network issue as there could be no old settings in this FRESH install of a new OS and a fresh install of thebridge. Theres just no way any old settings could remain. What's next for me to do to fix this? If it wasn't persistant though fresh installs and had repeated the issue with another callsign would try a 32bit OS but at this point I am at loss to explain this. I .connect to DODROPIN OK, then, tried to .disconnect with DODROPIN and had the same crashing result so I can't blame it on only one coference server.
Please help.
Attached is a screenshot of coredump produced after crash.
73s
Doug

[VE3GOB]

Update: Tried UBUNTU Server 16,04 64bit = No Luck
Update: Tried UBUNTU Server 16,04 32bit = No Luck
Update: Tried UBUNTU Server 12,04 32bit = Success :) Too bad 12.04 will soon be End Of Life.

[Skip Hansen]

Hi Doug,

I don't know if anyone has been running thelinkbox or thebridge on a
64 bit OS successfully or not. 64 bit boxes were rare when thebridge
was being developed initially. As best as I can tell from your dump
the 64 bit OS and machine caught a buffer overwrite bug that appears
to have been benign on 32 bit machines.

If you are willing to give me access to your box I can probably debug
it remotely. Please email me privately at wb6ymh@gfrn.org.

73's Skip WB6YMH

On Thu, Mar 2, 2017 at 12:53 PM, Doug ve3gob@users.sf.net wrote:

---

[support-requests:#7] thebridge1.09 and 1.06 .disconnect crash

Status: open
Group: v1.0 (example)
Labels: tbd1.09 Crash .disconnect
Created: Thu Mar 02, 2017 08:53 PM UTC by Doug
Last Updated: Thu Mar 02, 2017 08:53 PM UTC
Owner: nobody
Attachments:

Screenshot from 2017-02-28 07-30-11.png (76.1 kB; image/png)

So I installed latest version of thebridge. (1.09). It looks fine.
Another admin Tom of DX-LINK was explaining the admin commands. He told me
to .connect DX-LINK. I did all was fine. Then he went to bed and I tried to
disconnect. Thebridge crashed. Not good. I could not figure out why. Went
thru the setting in tbd.conf carefully several times and found no issue. I
started conference back up and was immediatly connected to DX-LINK again, ok
I learned this was a persistant setting. Tried to disconnect again and boom
said disconnecting and crashed again. I tried to find he file where this
setting is located so that I may edit out that setting without any success.
Can you tell me which file saves that .connect command? All other commands I
have tried work fine except for .ban where I get the same crash when I tryed
to .ban DX-LINK as a temp work around.
I became so frustrated that I completely wiped the install and started agian
with a fresh OS (UBUNTU Server 16.04 64bit). This is hosted on a paid VPS
with rediculous amounts of bandwidth and power. After a few hours setting it
up I fired up the new conference server and it did the same thing. Now I
feel certain that this is a network issue as there could be no old settings
in this FRESH install of a new OS and a fresh install of thebridge. Theres
just no way any old settings could remain. What's next for me to do to fix
this? If it wasn't persistant though fresh installs and had repeated the
issue with another callsign would try a 32bit OS but at this point I am at
loss to explain this. I .connect to DODROPIN OK, then, tried to .disconnect
with DODROPIN and had the same crashing result so I can't blame it on only
one coference server.
Please help.
Attached is a screenshot of coredump produced after crash.
73s
Doug

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/cqinet/support-requests/7/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Drew]

Hi. Did you ever resolve this issue? I'm getting the same error. .disconnect will crash thebridge 1.06 running on Ubuntu 18.04.1 LTS 64 bit

[VE3GOB]

Try uding the most current versionof thebride. I ended up using debian 8
and it worked just fine.
Funny you asked i forgot all about that issue and was going to do a
dist-uprade tonight. I am using allstarlink right now but I could disable
it for a few mins and rewnable cqi to see if it works for ya.
I better take a snapshot of server first so it will be a while before i get
back to you. But it will be tonight.

----------- SIGNED -----------
-Doug-
VE3GOB or VA3TDG
Sudbury, Ontario,
Canada
73s

On Fri, Nov 30, 2018, 11:18 PM Drew <m0se5@users.sourceforge.net wrote:

Hi. Did you ever resolve this issue? I'm getting the same error.
.disconnect will crash thebridge 1.06 running on Ubuntu 18.04.1 LTS 64 bit

---

[support-requests:#7] thebridge1.09 and 1.06 .disconnect crash

Status: open
Group: v1.0 (example)
Labels: tbd1.09 Crash .disconnect
Created: Thu Mar 02, 2017 08:53 PM UTC by VE3GOB
Last Updated: Sun Mar 05, 2017 02:13 AM UTC
Owner: nobody
Attachments:

• Screenshot from 2017-02-28 07-30-11.png
  (76.1 kB; image/png)

So I installed latest version of thebridge. (1.09). It looks fine.
Another admin Tom of DX-LINK was explaining the admin commands. He told
me to .connect DX-LINK. I did all was fine. Then he went to bed and I
tried to disconnect. Thebridge crashed. Not good. I could not figure out
why. Went thru the setting in tbd.conf carefully several times and found no
issue. I started conference back up and was immediatly connected to
DX-LINK again, ok I learned this was a persistant setting. Tried to
disconnect again and boom said disconnecting and crashed again. I tried to
find he file where this setting is located so that I may edit out that
setting without any success. Can you tell me which file saves that .connect
command? All other commands I have tried work fine except for .ban where I
get the same crash when I tryed to .ban DX-LINK as a temp work around.
I became so frustrated that I completely wiped the install and started
agian with a fresh OS (UBUNTU Server 16.04 64bit). This is hosted on a paid
VPS with rediculous amounts of bandwidth and power. After a few hours
setting it up I fired up the new conference server and it did the same
thing. Now I feel certain that this is a network issue as there could be no
old settings in this FRESH install of a new OS and a fresh install of
thebridge. Theres just no way any old settings could remain. What's next
for me to do to fix this? If it wasn't persistant though fresh installs and
had repeated the issue with another callsign would try a 32bit OS but at
this point I am at loss to explain this. I .connect to DODROPIN OK, then,
tried to .disconnect with DODROPIN and had the same crashing result so I
can't blame it on only one coference server.
Please help.
Attached is a screenshot of coredump produced after crash.
73s
Doug

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/cqinet/support-requests/7/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[VE3GOB]

Sorry, I cannot try. I cannot upgrade to Debian 9 with risking destruction
of the MySQL database

On Fri, Nov 30, 2018 at 11:18 PM Drew m0se5@users.sourceforge.net wrote:

Hi. Did you ever resolve this issue? I'm getting the same error.
.disconnect will crash thebridge 1.06 running on Ubuntu 18.04.1 LTS 64 bit

---

[support-requests:#7] thebridge1.09 and 1.06 .disconnect crash

Status: open
Group: v1.0 (example)
Labels: tbd1.09 Crash .disconnect
Created: Thu Mar 02, 2017 08:53 PM UTC by VE3GOB
Last Updated: Sun Mar 05, 2017 02:13 AM UTC
Owner: nobody
Attachments:

• Screenshot from 2017-02-28 07-30-11.png
  (76.1 kB; image/png)

So I installed latest version of thebridge. (1.09). It looks fine.
Another admin Tom of DX-LINK was explaining the admin commands. He told
me to .connect DX-LINK. I did all was fine. Then he went to bed and I
tried to disconnect. Thebridge crashed. Not good. I could not figure out
why. Went thru the setting in tbd.conf carefully several times and found no
issue. I started conference back up and was immediatly connected to
DX-LINK again, ok I learned this was a persistant setting. Tried to
disconnect again and boom said disconnecting and crashed again. I tried to
find he file where this setting is located so that I may edit out that
setting without any success. Can you tell me which file saves that .connect
command? All other commands I have tried work fine except for .ban where I
get the same crash when I tryed to .ban DX-LINK as a temp work around.
I became so frustrated that I completely wiped the install and started
agian with a fresh OS (UBUNTU Server 16.04 64bit). This is hosted on a paid
VPS with rediculous amounts of bandwidth and power. After a few hours
setting it up I fired up the new conference server and it did the same
thing. Now I feel certain that this is a network issue as there could be no
old settings in this FRESH install of a new OS and a fresh install of
thebridge. Theres just no way any old settings could remain. What's next
for me to do to fix this? If it wasn't persistant though fresh installs and
had repeated the issue with another callsign would try a 32bit OS but at
this point I am at loss to explain this. I .connect to DODROPIN OK, then,
tried to .disconnect with DODROPIN and had the same crashing result so I
can't blame it on only one coference server.
Please help.
Attached is a screenshot of coredump produced after crash.
73s
Doug

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/cqinet/support-requests/7/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

--
--SIGNATURE--
VE3GOB/VA3TDG - DOUG
CANADA on Echolink http: http://canadianham.org//canadianham.org
http://canadianham.org
'73s from THE GREAT WHITE NORTH, EH.
Sudbury, Ontario, Canada.

--AGREEMENT/PRIVACY POLICY--

THE RECIPIENT IS EXPRESSLY FORBIDDEN TO USE MY EMAIL ADDRESS FOR SPAM,
MARKETING, SUBSCRIPTIONS, ADVERTISING, NEWS GROUP, PUBLIC FORUM, CHAT, OR
TO RELEASE THE EMAIL ADDRESS TO ANY THIRD PARTY. THIS AGREEMENT SUPERSEDES
ANY COMPETING POLICIES THAT YOU OR YOUR COMPANY MAY ATTEMPT TO IMPOSE. THIS
EMAIL MUST BE DELETED IF YOU ARE NOT IN AGREEMENT WITH THIS POLICY.

--END--

[Drew]

I've got some debug information here that may help with this .disconnect issue.
- thebridge-1.09
- Ubuntu 18.04.1 LTS 64bit
- Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz

make output:
https://pastebin.com/pMpcCkAS

syslog:
systemd[1]: tbd.service: Main process exited, code=dumped, status=6/ABRT
systemd[1]: tbd.service: Failed with result 'core-dump'.

output from tbd -d:
2:50:49 DX-LINK disconnected by tbdcmd
buffer overflow detected : tbd terminated
Aborted (core dumped)

[Skip Hansen]

Hi Drew,

I appreciate the effort in reporting the crash, but basically neither thelinkbox nor thebridge were ever tested on 64 bit machines. The code was originally written 14 years ago when 64 bit machines were rare and expensive. I am not longer developing this code. If someone comes up with a fix I'd be more than happy to merge it, otherwise it's unlikely to get fixed anytime soon.

73's Skip WB6YMH

[VE3GOB]

Actually I had no problems with debian 8 64bit. But debian 9 64bit has
been a no go for me every time. I suggest drew you look at all the changes
between 8 and 9. There's some big ones. Maybe you can come up with a
reason. I actually prefer 8 because it comes with MySQL and 9 comes with
MariaDB so transitioning things that used to use the former is difficult
and risky.

G luck and Merry xmas.

----------- SIGNED -----------
-Doug-
VE3GOB or VA3TDG
Sudbury, Ontario,
Canada
73s

On Wed, Dec 12, 2018, 2:57 PM Skip Hansen <wb6ymh@users.sourceforge.net
wrote:

Hi Drew,

I appreciate the effort in reporting the crash, but basically neither
thelinkbox nor thebridge were ever tested on 64 bit machines. The code was
originally written 14 years ago when 64 bit machines were rare and
expensive. I am not longer developing this code. If someone comes up
with a fix I'd be more than happy to merge it, otherwise it's unlikely to
get fixed anytime soon.

73's Skip WB6YMH

---

[support-requests:#7] thebridge1.09 and 1.06 .disconnect crash

Status: open
Group: v1.0 (example)
Labels: tbd1.09 Crash .disconnect
Created: Thu Mar 02, 2017 08:53 PM UTC by VE3GOB
Last Updated: Mon Dec 10, 2018 03:11 AM UTC
Owner: nobody
Attachments:

• Screenshot from 2017-02-28 07-30-11.png
  (76.1 kB; image/png)

So I installed latest version of thebridge. (1.09). It looks fine.
Another admin Tom of DX-LINK was explaining the admin commands. He told
me to .connect DX-LINK. I did all was fine. Then he went to bed and I
tried to disconnect. Thebridge crashed. Not good. I could not figure out
why. Went thru the setting in tbd.conf carefully several times and found no
issue. I started conference back up and was immediatly connected to
DX-LINK again, ok I learned this was a persistant setting. Tried to
disconnect again and boom said disconnecting and crashed again. I tried to
find he file where this setting is located so that I may edit out that
setting without any success. Can you tell me which file saves that .connect
command? All other commands I have tried work fine except for .ban where I
get the same crash when I tryed to .ban DX-LINK as a temp work around.
I became so frustrated that I completely wiped the install and started
agian with a fresh OS (UBUNTU Server 16.04 64bit). This is hosted on a paid
VPS with rediculous amounts of bandwidth and power. After a few hours
setting it up I fired up the new conference server and it did the same
thing. Now I feel certain that this is a network issue as there could be no
old settings in this FRESH install of a new OS and a fresh install of
thebridge. Theres just no way any old settings could remain. What's next
for me to do to fix this? If it wasn't persistant though fresh installs and
had repeated the issue with another callsign would try a 32bit OS but at
this point I am at loss to explain this. I .connect to DODROPIN OK, then,
tried to .disconnect with DODROPIN and had the same crashing result so I
can't blame it on only one coference server.
Please help.
Attached is a screenshot of coredump produced after crash.
73s
Doug

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/cqinet/support-requests/7/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[Charles Blackburn]

is there any update to this? Just installed the latest version from SF and each time a user disconnects or times out the bridge core dumps. i'm working on getting some logs, but it's pretty much exactly as already been posted in here

charlesb@UbuntuDev:~/echolink$ uname -a
Linux UbuntuDev 4.15.0-64-generic #73-Ubuntu SMP Thu Sep 12 13:16:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
charlesb@UbuntuDev:~/echolink$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
charlesb@UbuntuDev:~/echolink$

[Drew]

I just run mine on debian 8 64 bit... Works fine.

On Wed, Jan 15, 2020, 11:52 AM Charles Blackburn, wx4cb@users.sourceforge.net wrote:

is there any update to this? Just installed the latest version from SF and
each time a user disconnects or times out the bridge core dumps. i'm
working on getting some logs, but it's pretty much exactly as already been
posted in here

charlesb@UbuntuDev:~/echolink$ uname -a
Linux UbuntuDev 4.15.0-64-generic #73-Ubuntu SMP Thu Sep 12 13:16:13 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
charlesb@UbuntuDev:~/echolink$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
charlesb@UbuntuDev:~/echolink$

---

[support-requests:#7] thebridge1.09 and 1.06 .disconnect crash

Status: open
Group: v1.0 (example)
Labels: tbd1.09 Crash .disconnect
Created: Thu Mar 02, 2017 08:53 PM UTC by VE3GOB
Last Updated: Wed Dec 12, 2018 07:57 PM UTC
Owner: nobody
Attachments:

• Screenshot from 2017-02-28 07-30-11.png
  (76.1 kB; image/png)

So I installed latest version of thebridge. (1.09). It looks fine.
Another admin Tom of DX-LINK was explaining the admin commands. He told
me to .connect DX-LINK. I did all was fine. Then he went to bed and I
tried to disconnect. Thebridge crashed. Not good. I could not figure out
why. Went thru the setting in tbd.conf carefully several times and found no
issue. I started conference back up and was immediatly connected to
DX-LINK again, ok I learned this was a persistant setting. Tried to
disconnect again and boom said disconnecting and crashed again. I tried to
find he file where this setting is located so that I may edit out that
setting without any success. Can you tell me which file saves that .connect
command? All other commands I have tried work fine except for .ban where I
get the same crash when I tryed to .ban DX-LINK as a temp work around.
I became so frustrated that I completely wiped the install and started
agian with a fresh OS (UBUNTU Server 16.04 64bit). This is hosted on a paid
VPS with rediculous amounts of bandwidth and power. After a few hours
setting it up I fired up the new conference server and it did the same
thing. Now I feel certain that this is a network issue as there could be no
old settings in this FRESH install of a new OS and a fresh install of
thebridge. Theres just no way any old settings could remain. What's next
for me to do to fix this? If it wasn't persistant though fresh installs and
had repeated the issue with another callsign would try a 32bit OS but at
this point I am at loss to explain this. I .connect to DODROPIN OK, then,
tried to .disconnect with DODROPIN and had the same crashing result so I
can't blame it on only one coference server.
Please help.
Attached is a screenshot of coredump produced after crash.
73s
Doug

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/cqinet/support-requests/7/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[VE3GOB]

Oh yes thats another thing, deb 9 had some major changes. Screwed up alot
of running servers if one did a dist-upgrade. I was lucky i had read the
release notes and tried on a non production machine first. Deb 9+ never
worked. I am glad to hear you got it running on the 64bit.
I wonder if ubuntu 18.04 is bases on debian 9? I dont have that info on my
cell phone right now but worth checking into.

On Wed., Jan. 15, 2020, 3:09 p.m. Drew, m0se5@users.sourceforge.net wrote:

I just run mine on debian 8 64 bit... Works fine.

On Wed, Jan 15, 2020, 11:52 AM Charles Blackburn, wx4cb@users.sourceforge.net wrote:

is there any update to this? Just installed the latest version from SF
and
each time a user disconnects or times out the bridge core dumps. i'm
working on getting some logs, but it's pretty much exactly as already
been
posted in here

charlesb@UbuntuDev:~/echolink$ uname -a
Linux UbuntuDev 4.15.0-64-generic #73-Ubuntu SMP Thu Sep 12 13:16:13 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
charlesb@UbuntuDev:~/echolink$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
charlesb@UbuntuDev:~/echolink$

---

[support-requests:#7] thebridge1.09 and 1.06 .disconnect crash

Status: open
Group: v1.0 (example)
Labels: tbd1.09 Crash .disconnect
Created: Thu Mar 02, 2017 08:53 PM UTC by VE3GOB
Last Updated: Wed Dec 12, 2018 07:57 PM UTC
Owner: nobody
Attachments:

• [Screenshot from 2017-02-28 07-30-11.png](

https://sourceforge.net/p/cqinet/support-requests/7/attachment/Screenshot%20from%202017-02-28%2007-30-11.png
)
(76.1 kB; image/png)

So I installed latest version of thebridge. (1.09). It looks fine.
Another admin Tom of DX-LINK was explaining the admin commands. He told
me to .connect DX-LINK. I did all was fine. Then he went to bed and I
tried to disconnect. Thebridge crashed. Not good. I could not figure out
why. Went thru the setting in tbd.conf carefully several times and found
no
issue. I started conference back up and was immediatly connected to
DX-LINK again, ok I learned this was a persistant setting. Tried to
disconnect again and boom said disconnecting and crashed again. I tried
to
find he file where this setting is located so that I may edit out that
setting without any success. Can you tell me which file saves that
.connect
command? All other commands I have tried work fine except for .ban where
I
get the same crash when I tryed to .ban DX-LINK as a temp work around.
I became so frustrated that I completely wiped the install and started
agian with a fresh OS (UBUNTU Server 16.04 64bit). This is hosted on a
paid
VPS with rediculous amounts of bandwidth and power. After a few hours
setting it up I fired up the new conference server and it did the same
thing. Now I feel certain that this is a network issue as there could be
no
old settings in this FRESH install of a new OS and a fresh install of
thebridge. Theres just no way any old settings could remain. What's next
for me to do to fix this? If it wasn't persistant though fresh installs
and
had repeated the issue with another callsign would try a 32bit OS but at
this point I am at loss to explain this. I .connect to DODROPIN OK,
then,
tried to .disconnect with DODROPIN and had the same crashing result so
I
can't blame it on only one coference server.
Please help.
Attached is a screenshot of coredump produced after crash.
73s
Doug

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/cqinet/support-requests/7/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

---

[support-requests:#7] thebridge1.09 and 1.06 .disconnect crash

Status: open
Group: v1.0 (example)
Labels: tbd1.09 Crash .disconnect
Created: Thu Mar 02, 2017 08:53 PM UTC by VE3GOB
Last Updated: Wed Jan 15, 2020 06:52 PM UTC
Owner: nobody
Attachments:

• Screenshot from 2017-02-28 07-30-11.png
  (76.1 kB; image/png)

So I installed latest version of thebridge. (1.09). It looks fine.
Another admin Tom of DX-LINK was explaining the admin commands. He told
me to .connect DX-LINK. I did all was fine. Then he went to bed and I
tried to disconnect. Thebridge crashed. Not good. I could not figure out
why. Went thru the setting in tbd.conf carefully several times and found no
issue. I started conference back up and was immediatly connected to
DX-LINK again, ok I learned this was a persistant setting. Tried to
disconnect again and boom said disconnecting and crashed again. I tried to
find he file where this setting is located so that I may edit out that
setting without any success. Can you tell me which file saves that .connect
command? All other commands I have tried work fine except for .ban where I
get the same crash when I tryed to .ban DX-LINK as a temp work around.
I became so frustrated that I completely wiped the install and started
agian with a fresh OS (UBUNTU Server 16.04 64bit). This is hosted on a paid
VPS with rediculous amounts of bandwidth and power. After a few hours
setting it up I fired up the new conference server and it did the same
thing. Now I feel certain that this is a network issue as there could be no
old settings in this FRESH install of a new OS and a fresh install of
thebridge. Theres just no way any old settings could remain. What's next
for me to do to fix this? If it wasn't persistant though fresh installs and
had repeated the issue with another callsign would try a 32bit OS but at
this point I am at loss to explain this. I .connect to DODROPIN OK, then,
tried to .disconnect with DODROPIN and had the same crashing result so I
can't blame it on only one coference server.
Please help.
Attached is a screenshot of coredump produced after crash.
73s
Doug

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/cqinet/support-requests/7/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[VE3GOB]

All I can say is that I believe the bridge only ran on 32bit OS. Its been a
long time and I use allstarlink now for both echolink and asterisk services.
You could make sure all permissions are setup correct.
I will have to think on this for a while.
73s

On Wed., Jan. 15, 2020, 1:52 p.m. Charles Blackburn, wx4cb@users.sourceforge.net wrote:

is there any update to this? Just installed the latest version from SF and
each time a user disconnects or times out the bridge core dumps. i'm
working on getting some logs, but it's pretty much exactly as already been
posted in here

charlesb@UbuntuDev:~/echolink$ uname -a
Linux UbuntuDev 4.15.0-64-generic #73-Ubuntu SMP Thu Sep 12 13:16:13 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
charlesb@UbuntuDev:~/echolink$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
charlesb@UbuntuDev:~/echolink$

---

[support-requests:#7] thebridge1.09 and 1.06 .disconnect crash

Status: open
Group: v1.0 (example)
Labels: tbd1.09 Crash .disconnect
Created: Thu Mar 02, 2017 08:53 PM UTC by VE3GOB
Last Updated: Wed Dec 12, 2018 07:57 PM UTC
Owner: nobody
Attachments:

• Screenshot from 2017-02-28 07-30-11.png
  (76.1 kB; image/png)

So I installed latest version of thebridge. (1.09). It looks fine.
Another admin Tom of DX-LINK was explaining the admin commands. He told
me to .connect DX-LINK. I did all was fine. Then he went to bed and I
tried to disconnect. Thebridge crashed. Not good. I could not figure out
why. Went thru the setting in tbd.conf carefully several times and found no
issue. I started conference back up and was immediatly connected to
DX-LINK again, ok I learned this was a persistant setting. Tried to
disconnect again and boom said disconnecting and crashed again. I tried to
find he file where this setting is located so that I may edit out that
setting without any success. Can you tell me which file saves that .connect
command? All other commands I have tried work fine except for .ban where I
get the same crash when I tryed to .ban DX-LINK as a temp work around.
I became so frustrated that I completely wiped the install and started
agian with a fresh OS (UBUNTU Server 16.04 64bit). This is hosted on a paid
VPS with rediculous amounts of bandwidth and power. After a few hours
setting it up I fired up the new conference server and it did the same
thing. Now I feel certain that this is a network issue as there could be no
old settings in this FRESH install of a new OS and a fresh install of
thebridge. Theres just no way any old settings could remain. What's next
for me to do to fix this? If it wasn't persistant though fresh installs and
had repeated the issue with another callsign would try a 32bit OS but at
this point I am at loss to explain this. I .connect to DODROPIN OK, then,
tried to .disconnect with DODROPIN and had the same crashing result so I
can't blame it on only one coference server.
Please help.
Attached is a screenshot of coredump produced after crash.
73s
Doug

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/cqinet/support-requests/7/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[Charles Blackburn]

so here is what i get... been happening more lately now as far as the IP address, it doesn't matter that was just the last one, it appears to be mainly people that are coming in via a proxy or via cell phone etc. (my only way of testing). i've attached the core dump if anyone's interested

Feb 7 2:38:30 RTP_Data: Failed to find client 44.190.12.83
Feb 7 2:38:30 Rejecting N1FBF, dir IP 44.137.75.243 != IP 44.190.12.83.
Feb 7 2:38:30 Disconnecting unauthorized user N1FBF.

CORE DUMPED - Buffer overflow

[Charles Blackburn]

ok update.. had chance to take a quick look at the core dump. it appears that the buffer used for messages coming from the server for disconnects is too small you can see where in line #6 where strcpy takes a crap because of the buffer overflow

charlesb@UbuntuDev:~/echolink$ gdb /usr/local/bin/tbd core.current
Reading symbols from /usr/local/bin/tbd...done.
[New LWP 10187]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `tbd -d -d -h -f tbd.conf'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffb2dced801 in __GI_abort () at abort.c:79
#2  0x00007ffb2dd36897 in __libc_message (action=action@entry=(do_abort | do_backtrace), fmt=fmt@entry=0x7ffb2de63988 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007ffb2dde1cff in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=true, msg=msg@entry=0x7ffb2de63905 "buffer overflow detected") at fortify_fail.c:33
#4  0x00007ffb2dde1d21 in __GI___fortify_fail (msg=msg@entry=0x7ffb2de63905 "buffer overflow detected") at fortify_fail.c:44
#5  0x00007ffb2dddfa10 in __GI___chk_fail () at chk_fail.c:28
#6  0x00007ffb2dddeca2 in __strcpy_chk (dest=dest@entry=0x5614e6b7d401 "\bCALLSIGN\002\022DG4BBP         Uwe\003\bCALLSIGN\004\b208B60FA\006\006E2.12C\b\006\001P5198\b\003\001D0",
    src=src@entry=0x5614e6792cb2 "Bye Bye", destlen=destlen@entry=0) at strcpy_chk.c:30
#7  0x00005614e6779fe9 in strcpy (__src=0x5614e6792cb2 "Bye Bye", __dest=0x5614e6b7d401 "\bCALLSIGN\002\022DG4BBP         Uwe\003\bCALLSIGN\004\b208B60FA\006\006E2.12C\b\006\001P5198\b\003\001D0")
    at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:90
#8  GenBye (pCC=pCC@entry=0x5614e6d108b0, Temp=0x5614e6b7d3f0 "\300", <incomplete sequence \311>, Reason=Reason@entry=0x5614e6792cb2 "Bye Bye") at conference.c:3651
#9  0x00005614e677fdea in RTCP_Rx (p=p@entry=0x5614e6b7d360) at conference.c:2212
#10 0x00005614e67807f0 in RTCP_Handler (p=0x5614e6b7d360) at conference.c:2614
#11 0x00005614e678c593 in CallCurrentState (pClient=0x5614e6b7d360) at main.c:684
#12 0x00005614e678cd76 in MainLoop () at main.c:508
#13 0x00005614e67877fe in StartRunning () at thebridge.c:522
#14 0x00005614e6775d26 in main (argc=6, argv=0x7ffc78939ea8, envp=<optimized out>) at thebridge.c:381

[Skip Hansen]

Hi Charles,

Thanks for the detailed report! This might be enough to fix the issue. I'll try to find time in the next week or so.

I no longer have a running testbed and I never ran thelinkbox on a 64 bit machine in any case so I will need help testing. If you can help test a future fix I'll send you some code.

BTW I've moved to github: https://github.com/skiphansen/thelinkbox

73's Skip WB6YMH

[Drew]

I can help with testing. I can have a digital ocean droplet up and running
in 2 minutes. Let me know which operating system you want, and I'll send
you the login info.

DE VE1DRU

On Fri, Feb 7, 2020, 4:54 PM Skip Hansen, wb6ymh@users.sourceforge.net
wrote:

Hi Charles,

Thanks for the detailed report! This might be enough to fix the issue.
I'll try to find time in the next week or so.

I no longer have a running testbed and I never ran thelinkbox on a 64 bit
machine in any case so I will need help testing. If you can help test a
future fix I'll send you some code.

BTW I've moved to github: https://github.com/skiphansen/thelinkbox

73's Skip WB6YMH

---

[support-requests:#7] thebridge1.09 and 1.06 .disconnect crash

Status: open
Group: v1.0 (example)
Labels: tbd1.09 Crash .disconnect
Created: Thu Mar 02, 2017 08:53 PM UTC by VE3GOB
Last Updated: Fri Feb 07, 2020 07:14 PM UTC
Owner: nobody
Attachments:

• Screenshot from 2017-02-28 07-30-11.png
  (76.1 kB; image/png)

So I installed latest version of thebridge. (1.09). It looks fine.
Another admin Tom of DX-LINK was explaining the admin commands. He told
me to .connect DX-LINK. I did all was fine. Then he went to bed and I
tried to disconnect. Thebridge crashed. Not good. I could not figure out
why. Went thru the setting in tbd.conf carefully several times and found no
issue. I started conference back up and was immediatly connected to
DX-LINK again, ok I learned this was a persistant setting. Tried to
disconnect again and boom said disconnecting and crashed again. I tried to
find he file where this setting is located so that I may edit out that
setting without any success. Can you tell me which file saves that .connect
command? All other commands I have tried work fine except for .ban where I
get the same crash when I tryed to .ban DX-LINK as a temp work around.
I became so frustrated that I completely wiped the install and started
agian with a fresh OS (UBUNTU Server 16.04 64bit). This is hosted on a paid
VPS with rediculous amounts of bandwidth and power. After a few hours
setting it up I fired up the new conference server and it did the same
thing. Now I feel certain that this is a network issue as there could be no
old settings in this FRESH install of a new OS and a fresh install of
thebridge. Theres just no way any old settings could remain. What's next
for me to do to fix this? If it wasn't persistant though fresh installs and
had repeated the issue with another callsign would try a 32bit OS but at
this point I am at loss to explain this. I .connect to DODROPIN OK, then,
tried to .disconnect with DODROPIN and had the same crashing result so I
can't blame it on only one coference server.
Please help.
Attached is a screenshot of coredump produced after crash.
73s
Doug

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/cqinet/support-requests/7/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[Charles Blackburn]

no problem. i don't mind testing i can help. i haven't had time to look at the code yet, but it's a (relatively) simple buffer overflow so maybe einstead of using strcpy, use strncpy with the size of the buffer should fix it.

oh and it's the bridge, not TLB, unless im missing something :D