From: digital.man@vert.synchro.net.remove-6ev-this

To: Ray Quinn
Re: Binkit & Segmentation Fault
By: Ray Quinn to All on Sun Feb 17 2019 09:14 am

I am going to address the segmentation fault first.

After downloading the latest development source on Tursday February 14, 2019 and compiling it, SBBS would not run. I am running Debian Stretch. I tried the GDB method to see about getting a core file, no good.

gdb /sbbs/exec/sbbs /tmp/core.sbbs.0001

What does that mean - no good?

I ran it several times in a console window and got a segmentation fault at various stages.

Try a clean rebuild.

I went to my source backup, compiled it, and all is well. I
likely have no other information to provide. I will try again later today and, if it fails again, get more information.

Run src/cleanall.sh before your next build.

The latest CVS sources compile and run just fine on the Windows 10 "linux":

uname --all
Linux RLQ 4.4.0-17134-Microsoft #345-Microsoft Wed Sep 19 17:47:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux

Now on to BINKIT.

I have a node configured in sbbsecho as such:
[node:314:314/0@piNet]
Name = NecroBBS PiNet Feed
Comment = piNET HQ
Archive = ZIP
PacketType = 2+
PacketPwd =
AreaFix = true
AreaFixPwd = SECRET
SessionPwd = SECRET
TicFilePwd =
Inbox =
Outbox =
Passive = false
Direct = true
Notify = false
Keys = P
Status = Normal
LocalAddress = 314:314/45
GroupHub =
BinkpHost = necrobbs.strangled.net
BinkpPort = 24556
BinkpPoll = true
BinkpPlainAuthOnly = false
BinkpAllowPlainAuth = false
BinkpAllowPlainText = true
BinkpSourceAddress = 314:314/45

I also have this:

[node:314:ALL]
Name =
Comment =
Archive = ZIP
PacketType = 2+
PacketPwd =
AreaFix = false
AreaFixPwd =
SessionPwd = yaesu
TicFilePwd =
Inbox =
Outbox =
Passive = false
Direct = false
Notify = false
Keys = P
Status = Normal
Route = 314:314/0
LocalAddress = 314:314/45
GroupHub =
BinkpHost =
BinkpPort = 24556
BinkpPoll = false
BinkpPlainAuthOnly = false
BinkpAllowPlainAuth = false
BinkpAllowPlainText = true
BinkpSourceAddress = 314:314/45

However, when BINKIT calls out, it tries to use "example.com".

[callout failure: 314:314/0]
host = f0.n314.z314.example.com
port = 24554
connect_error = 0
localtime = Feb 16 2019 20:51:57

From where can BINKIT possibly be getting "example.com"? The above
node is also not the only one for which BINKIT tries to contact "example.com".

I think it's because you're mixing up use of 4D and 5D addressing. You have "314:314/0@piNet" configured as a linked node, not 314:314/0. So it's routing to an unlinked-node, so it's trying to lookup the node's address using DNS. If you don't have a DNSSuffix configured for [domain:piNet] in your sbbsecho.ini, it'll default to 'example.com'.

Another BINKIT issue I noticed is that it seems to call itself:

[callout success: 9:91/2@survnet]
oper = Ray Quinn
AKAs = 1:214/22@fidonet,1:214/0@fidonet,1:214/1@fidonet,9:91/2@survn et,24:160/1@sportn et,24:160/0@sportnet,24:160/22@sportn$
caps = 115200,TCP,BINKP
vers = BinkIT/2.17,JSBinkP/1.114,sbbs3.17a/Linux
host = bbs.quinnnet.org
port = 24554
info.sys = US 99 BBS
info.loc = Visalia, CA
info.time = Sun Feb 17 2019 09:30:59 GMT-0800 (PST)
localtime = Feb 17 2019 09:31:04

This node is opviously not configured in sbbsecho.ini as it is a system address.

Any ideas?

My guess is that its mixedup with the use of 5D addresses. Maybe try sticking with 3D and 4D addressing?

In the future, please try to stick to one problem/topic per message.

digital man

Synchronet "Real Fact" #17:
"Vertrauen" (ver-trow-en) translates to "trust" in German, and was a band name. Norco, CA WX: 49.4øF, 81.0% humidity, 2 mph NE wind, 0.00 inches rain/24hrs
--- Synchronet 3.17c-Win32 NewsLink 1.110
* Vertrauen - Riverside County, California - telnet://vert.synchro.net

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)

From: mark.lewis@1:3634/12.73.remove-6ev-this

To: Ray Quinn

On 2019 Feb 17 09:14:46, you wrote to All:

I am going to address the segmentation fault first.

i can't help with that...

Now on to BINKIT.

I have a node configured in sbbsecho as such:
[node:314:314/0@piNet]

this one looks good but perhaps you should use @pinet everywhere so you don't run in to capialtization problems...

I also have this:

[node:314:ALL]
Name =
Comment =
Archive = ZIP
PacketType = 2+
PacketPwd =
AreaFix = false
AreaFixPwd =
SessionPwd = yaesu

remove this password... it is useless in a forwarding situation like this... the rest looks good...

However, when BINKIT calls out, it tries to use "example.com".

[callout failure: 314:314/0]
host = f0.n314.z314.example.com
port = 24554
connect_error = 0
localtime = Feb 16 2019 20:51:57

have you configured pinet in echocfg in the domains section?

one might think that binkit should be using the BinkpHost value from the 314:314/0@pinet record but i can't if it can't match the domain in the configs...

From where can BINKIT possibly be getting "example.com"? The above
node is also not the only one for which BINKIT tries to contact "example.com".

sbbs@bbs:/sbbs/exec$ grep example.com ../data/*
../data/binkstats.ini: host = f756.n322.z1.example.com ../data/binkstats.ini: host = f1.n104.z900.example.com ../data/binkstats.ini: host = f0.n314.z314.example.com

this comes from exec/load/fido.js, line 524, because the domains do not exist in your echocfg domains area... i would use all lowercase for domains everywhere, though... seriously...

Another BINKIT issue I noticed is that it seems to call itself:

that's interesting... maybe it called itself when it recycled at some point while you were (re)configuring it?

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Sneaker Net - walk floppies between 2 computers.
---
* Origin: (1:3634/12.73)
--- Synchronet 3.17c-Win32 NewsLink 1.110
* Vertrauen - Riverside County, California - telnet://vert.synchro.net

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)

From: ray.quinn@1:214/23.remove-f0r-this

I am going to address the segmentation fault first.

After downloading the latest development source on Tursday February 14, 2019 and compiling it, SBBS would not run. I am running Debian Stretch. I tried the GDB method to see about getting a core file, no good.

gdb /sbbs/exec/sbbs /tmp/core.sbbs.0001

I ran it several times in a console window and got a segmentation fault at various stages. I went to my source backup, compiled it, and all is well. I likely have no other information to provide. I will try again later today and, if it fails again, get more information.

The latest CVS sources compile and run just fine on the Windows 10 "linux":

uname --all
Linux RLQ 4.4.0-17134-Microsoft #345-Microsoft Wed Sep 19 17:47:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux


Now on to BINKIT.

I have a node configured in sbbsecho as such:
[node:314:314/0@piNet]
Name = NecroBBS PiNet Feed
Comment = piNET HQ
Archive = ZIP
PacketType = 2+
PacketPwd =
AreaFix = true
AreaFixPwd = SECRET
SessionPwd = SECRET
TicFilePwd =
Inbox =
Outbox =
Passive = false
Direct = true
Notify = false
Keys = P
Status = Normal
LocalAddress = 314:314/45
GroupHub =
BinkpHost = necrobbs.strangled.net
BinkpPort = 24556
BinkpPoll = true
BinkpPlainAuthOnly = false
BinkpAllowPlainAuth = false
BinkpAllowPlainText = true
BinkpSourceAddress = 314:314/45

I also have this:

[node:314:ALL]
Name =
Comment =
Archive = ZIP
PacketType = 2+
PacketPwd =
AreaFix = false
AreaFixPwd =
SessionPwd = yaesu
TicFilePwd =
Inbox =
Outbox =
Passive = false
Direct = false
Notify = false
Keys = P
Status = Normal
Route = 314:314/0
LocalAddress = 314:314/45
GroupHub =
BinkpHost =
BinkpPort = 24556
BinkpPoll = false
BinkpPlainAuthOnly = false
BinkpAllowPlainAuth = false
BinkpAllowPlainText = true
BinkpSourceAddress = 314:314/45


However, when BINKIT calls out, it tries to use "example.com".

[callout failure: 314:314/0]
host = f0.n314.z314.example.com
port = 24554
connect_error = 0
localtime = Feb 16 2019 20:51:57

From where can BINKIT possibly be getting "example.com"? The above
node is also not the only one for which BINKIT tries to contact "example.com".

sbbs@bbs:/sbbs/exec$ grep example.com ../data/*
../data/binkstats.ini: host = f756.n322.z1.example.com
../data/binkstats.ini: host = f1.n104.z900.example.com
../data/binkstats.ini: host = f0.n314.z314.example.com



Another BINKIT issue I noticed is that it seems to call itself:

[callout success: 9:91/2@survnet]
oper = Ray Quinn
AKAs = 1:214/22@fidonet,1:214/0@fidonet,1:214/1@fidonet,9:91/2@survnet,24:160/1@sportn et,24:160/0@sportnet,24:160/22@sportn$
caps = 115200,TCP,BINKP
vers = BinkIT/2.17,JSBinkP/1.114,sbbs3.17a/Linux
host = bbs.quinnnet.org
port = 24554
info.sys = US 99 BBS
info.loc = Visalia, CA
info.time = Sun Feb 17 2019 09:30:59 GMT-0800 (PST)
localtime = Feb 17 2019 09:31:04


This node is opviously not configured in sbbsecho.ini as it is a system address.

Any ideas?

Ray Quinn W6RAY
Visalia, CA DM06ii


--- GoldED+/W64-MSVC 1.1.5-b20180707
* Origin: Ray's Road Node - Somewhere in California. (1:214/23)
--- Synchronet 3.17c-Win32 NewsLink 1.110
* Vertrauen - Riverside County, California - telnet://vert.synchro.net

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)

From: ray.quinn@US99.remove-mwb-this

To: Digital Man

Re: Binkit & Segmentation Fault
By: Ray Quinn to All on Sun Feb 17 2019 09:14 am

I am going to address the segmentation fault first.

After downloading the latest development source on Tursday February 14, 2019 and compiling it, SBBS would not run. I am running Debian Stretch. I tried the GDB method to see about getting a core file, no good.

gdb /sbbs/exec/sbbs /tmp/core.sbbs.0001

What does that mean - no good?

It didn't create any core, it ran as long as it did trying any other method I mentioned.

I ran it several times in a console window and got a segmentation fault at various stages.

Try a clean rebuild.

I do a clean build every time.

I went to my source backup, compiled it, and all is well. I
likely have no other information to provide. I will try again later today and, if it fails again, get more information.

Run src/cleanall.sh before your next build.

I ran this script, too. A clean build usually generates fewer issues. I will try again when I have
more time to mess with it. The older source is working for now. I just like to try to keep up with
any new changes, etc. Thanks!





---

If the right side of the brain controls the left side of the body,
then only left handed people are in their right minds.

_____
, |[][]|
,__| ______| |
,__/__]|| ________ | D8 |
|__!___!!`--'L_______\ |__________|() ___________
"(_)[___]====(_)(_)=| \_(___________)_/__/=(_)===(_)~'

73 de Ray Quinn W6RAY
GMRS WQTX645
Visalia, CA USA DM06ii
When all else fails, ham radio works!
---
þ Synchronet þ US 99 BBS - Visalia, CA - bbs.quinnnet.org
--- Synchronet 3.17c-Win32 NewsLink 1.110
* Vertrauen - Riverside County, California - telnet://vert.synchro.net

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)

From: digital.man@vert.synchro.net.remove-zri-this

To: Ray Quinn
Re: Segmentation Fault
By: Ray Quinn to Digital Man on Sun Feb 17 2019 08:18 pm

Re: Binkit & Segmentation Fault
By: Ray Quinn to All on Sun Feb 17 2019 09:14 am

I am going to address the segmentation fault first.

After downloading the latest development source on Tursday February 14, 2019 and compiling it, SBBS would not run. I am running Debian Stretch. I tried the GDB method to see about getting a core file, no good.

gdb /sbbs/exec/sbbs /tmp/core.sbbs.0001

What does that mean - no good?

It didn't create any core, it ran as long as it did trying any other method I mentioned.

You don't have core files from the previous segfaults? You don't need to run sbbs from gdb to get a core dump file created upon segfault. Check your /tmp directory or wherever you have your system configured to save core dumps.


digital man

Synchronet "Real Fact" #48:
Synchronet directory naming (i.e. ctrl, exec, data) was suggested by S. Deppe. Norco, CA WX: 45.4øF, 77.0% humidity, 8 mph ESE wind, 0.00 inches rain/24hrs --- Synchronet 3.17c-Win32 NewsLink 1.110
* Vertrauen - Riverside County, California - telnet://vert.synchro.net

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)

From: mark.lewis@1:3634/12.73.remove-jco-this

To: Ray Quinn

On 2019 Feb 17 22:41:12, Digital Man wrote to you:

It didn't create any core, it ran as long as it did trying any other
method I mentioned.

You don't have core files from the previous segfaults? You don't need
to run sbbs from gdb to get a core dump file created upon segfault.
Check your /tmp directory or wherever you have your system configured
to save core dumps.

you might have to set your ulimit, too... i've had numerous programs segfault and say a core file was written when in fact none was... setting ulimit as needed allowed the core files to be created properly...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... The ability to understand a question from all sides meant one was totally unfi
---
* Origin: (1:3634/12.73)
--- Synchronet 3.17c-Win32 NewsLink 1.110
* Vertrauen - Riverside County, California - telnet://vert.synchro.net

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)

From: digital.man@vert.synchro.net.remove-k3q-this

To: mark lewis
Re: Segmentation Fault
By: mark lewis to Ray Quinn on Mon Feb 18 2019 12:46 pm

On 2019 Feb 17 22:41:12, Digital Man wrote to you:

It didn't create any core, it ran as long as it did trying any other
method I mentioned.

You don't have core files from the previous segfaults? You don't need to run sbbs from gdb to get a core dump file created upon segfault. Check your /tmp directory or wherever you have your system configured to save core dumps.

you might have to set your ulimit, too... i've had numerous programs segfault and say a core file was written when in fact none was... setting ulimit as needed allowed the core files to be created properly...

And other tweaks, as outlined here:
http://wiki.synchro.net/howto:gdb#core_file

digital man

Synchronet "Real Fact" #5:
Synchronet version 3 for Win32 development began in 1999.
Norco, CA WX: 55.0øF, 35.0% humidity, 5 mph SSW wind, 0.00 inches rain/24hrs --- Synchronet 3.17c-Win32 NewsLink 1.110
* Vertrauen - Riverside County, California - telnet://vert.synchro.net

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)

From: ray.quinn@US99.remove-72l-this

To: mark lewis

On 2019 Feb 17 22:41:12, Digital Man wrote to you:

It didn't create any core, it ran as long as it did trying any other
method I mentioned.

You don't have core files from the previous segfaults? You don't need to run sbbs from gdb to get a core dump file created upon segfault. Check your /tmp directory or wherever you have your system configured to save core dumps.

you might have to set your ulimit, too... i've had numerous programs segfault and say a core file was written when in fact none was... setting ulimit as needed allowed the core files to be created properly...

I took your advice and set "ulimit -c unlimited". We shall see...

Thanks!!

---

If the right side of the brain controls the left side of the body,
then only left handed people are in their right minds.

_____
, |[][]|
,__| ______| |
,__/__]|| ________ | D8 |
|__!___!!`--'L_______\ |__________|() ___________
"(_)[___]====(_)(_)=| \_(___________)_/__/=(_)===(_)~'

73 de Ray Quinn W6RAY
GMRS WQTX645
Visalia, CA USA DM06ii
When all else fails, ham radio works!
---
þ Synchronet þ US 99 BBS - Visalia, CA - bbs.quinnnet.org
--- Synchronet 3.17c-Win32 NewsLink 1.110
* Vertrauen - Riverside County, California - telnet://vert.synchro.net

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)

From: ray.quinn@US99.remove-72l-this

To: Digital Man

You don't have core files from the previous segfaults? You don't need to run sbbs from gdb to get a core dump file created upon segfault. Check your /tmp directory or wherever you have your system configured to save core dumps.

There were no cores. I took Mark Lewis' suggestion regarding ulimit and noticed that
the size was set to 0. I changed it to unlimited "ulimit -c unlimited", so next time
I have a segfault, it should generate a core.

Thanks!

---

If the right side of the brain controls the left side of the body,
then only left handed people are in their right minds.

_____
, |[][]|
,__| ______| |
,__/__]|| ________ | D8 |
|__!___!!`--'L_______\ |__________|() ___________
"(_)[___]====(_)(_)=| \_(___________)_/__/=(_)===(_)~'

73 de Ray Quinn W6RAY
GMRS WQTX645
Visalia, CA USA DM06ii
When all else fails, ham radio works!
---
þ Synchronet þ US 99 BBS - Visalia, CA - bbs.quinnnet.org
--- Synchronet 3.17c-Win32 NewsLink 1.110
* Vertrauen - Riverside County, California - telnet://vert.synchro.net

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)

From: ray.quinn@US99.remove-72l-this

To: Digital Man

Re: Segmentation Fault
By: mark lewis to Ray Quinn on Mon Feb 18 2019 12:46 pm

On 2019 Feb 17 22:41:12, Digital Man wrote to you:

It didn't create any core, it ran as long as it did trying any other
method I mentioned.

You don't have core files from the previous segfaults? You don't need to run sbbs from gdb to get a core dump file created upon segfault. Check your /tmp directory or wherever you have your system configured to save core dumps.

you might have to set your ulimit, too... i've had numerous programs segfault and say a core file was written when in fact none was... setting ulimit as needed allowed the core files to be created properly...

And other tweaks, as outlined here: http://wiki.synchro.net/howto:gdb#core_file

I had done most of these, too, but not all. I made the changes as suggested in the
above wiki entry.

Thanks.

---

If the right side of the brain controls the left side of the body,
then only left handed people are in their right minds.

_____
, |[][]|
,__| ______| |
,__/__]|| ________ | D8 |
|__!___!!`--'L_______\ |__________|() ___________
"(_)[___]====(_)(_)=| \_(___________)_/__/=(_)===(_)~'

73 de Ray Quinn W6RAY
GMRS WQTX645
Visalia, CA USA DM06ii
When all else fails, ham radio works!
---
þ Synchronet þ US 99 BBS - Visalia, CA - bbs.quinnnet.org
--- Synchronet 3.17c-Win32 NewsLink 1.110
* Vertrauen - Riverside County, California - telnet://vert.synchro.net

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)