i ran into this this morning when i came in to check on the system... my first clue there was a problem was there was no new echomail on this point system... that told me that either sbbsecho or binkd.js was having a problem... so i went snooping and finally found the following...


==== Begin "20190412-sbbsecho-fault-log.txt" ====
2019-04-11 17:18:48 Unpacking bundle: /sbbs/fido/inbound/f249006c.th0 (0.6KB) 2019-04-11 17:18:48 Importing /sbbs/fido/inbound/06ed543e.pkt (Type 2e, 0.4KB) from 1:123/120 to 1:3634/12
2019-04-11 17:18:48 Sam Penwright (1:123/120) To: AREAFIX (1:3634/12) 2019-04-11 17:18:48 AreaFix (for 1:123/120) Request received from Sam Penwright
2019-04-11 17:18:48 AreaFix (for 1:123/120) Link-requested echo not found: * Origin: Deep Space Gateway Crystal River Florida (1:123/120)
2019-04-11 17:32:31 Mutex file exists (/sbbs/ctrl/sbbsecho.bsy): SBBSecho appears to be already running
2019-04-11 17:32:55 Mutex file exists (/sbbs/ctrl/sbbsecho.bsy): SBBSecho appears to be already running

[... removed many mutex exists lines ...]

2019-04-12 05:13:41 Mutex file exists (/sbbs/ctrl/sbbsecho.bsy): SBBSecho appears to be already running
2019-04-12 05:17:10 Mutex file exists (/sbbs/ctrl/sbbsecho.bsy): SBBSecho appears to be already running
2019-04-12 05:19:07 /sbbs/netmail/3978.msg Invalid length of 0 bytes
2019-04-12 05:31:26 Importing /sbbs/fido/inbound/0001ce30.pkt (Type 2e, 1.2KB) from 3:640/1384 to 1:3634/12
2019-04-12 05:31:26 Importing /sbbs/fido/inbound/0001ce38.pkt (Type 2e, 2.3KB) from 3:640/1384 to 1:3634/12

[... removed multiple importing pkt lines ...]

2019-04-12 05:31:26 Importing /sbbs/fido/inbound/0001cf6e.pkt (Type 2e, 1.4KB) from 3:640/1384 to 1:3634/12
2019-04-12 05:31:26 Importing /sbbs/fido/inbound/0001cf73.pkt (Type 2e, 2.7KB) from 3:640/1384 to 1:3634/12
2019-04-12 05:31:26 Importing /sbbs/fido/inbound/06ed543e.pkt (Type 2e, 0.4KB) from 1:123/120 to 1:3634/12
2019-04-12 05:31:26 Sam Penwright (1:123/120) To: AREAFIX (1:3634/12) 2019-04-12 05:31:26 AreaFix (for 1:123/120) Request received from Sam Penwright
2019-04-12 05:31:26 AreaFix (for 1:123/120) Link-requested echo not found: * Origin: Deep Space Gateway Crystal River Florida (1:123/120)
2019-04-12 05:34:07 Mutex file exists (/sbbs/ctrl/sbbsecho.bsy): SBBSecho appears to be already running
2019-04-12 05:49:08 Mutex file exists (/sbbs/ctrl/sbbsecho.bsy): SBBSecho appears to be already running

[... removed many mutex exists lines ...]

2019-04-12 08:05:04 Mutex file exists (/sbbs/ctrl/sbbsecho.bsy): SBBSecho appears to be already running
2019-04-12 08:13:30 Mutex file exists (/sbbs/ctrl/sbbsecho.bsy): SBBSecho appears to be already running
==== End "20190412-sbbsecho-fault-log.txt" ====


i recovered the system at this point by removing the PKT with the ""bad"" areafix netmail in it and deleting two zero byte msg files... only one zero byte msg file is noted above... i suspect it was supposed to be a reply to the areafix message but sbbsecho faulted out before completly writing it... the second zero byte one came from the second attempt to process that areafix message a second time...

the problem with the areafix message in the PKT is multifold but i'm not sure what, exactly, caused sbbsecho to fault out leaving the bsy behind and the zero byte msg files... i do still have the raw PKT with the offending areafix netmail message if you want it but here's the pktdump of it... passwords masked, tear and origin lines negated to avoid intermediate systems misreading them...


==== Begin "20190412-pktdump-06ed543e-pkt.txt" ====
pktdump rev 1.12 - Dump FidoNet Packets

Opening 06ed543e.pkt
06ed543e.pkt Packet Type 2+ (prod: FEFE, rev: 0.0) from 1:123/120 to 1:3634/12 Password: 'xxxxxxxx'
0000003A
06ed543e.pkt 00003A Packed Message Type: 2 from 123/120 to 3634/12
Attribute: 0103
Date/Time: 11 Apr 19 17:16:05
To : AREAFIX
From : Sam Penwright
Subj : xxxxxxxx

-start of message text-
INTL 1:3634/12 1:123/120
TID: Mystic BBS 1.12 A43
MSGID: 1:123/120 e8079299
TZUTC: -0400
%LINUX-UBUNTU
%POINTS
%FIDO-REQ
%FUTURE4FIDO
%WEATHER
--------

-!- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)
! Origin: Deep Space Gateway Crystal River Florida (1:123/120)
-end of message text-
0000018A
==== End "20190412-pktdump-06ed543e-pkt.txt" ====


so what i see is that sbbsecho appears to still be in processing mode even after it saw the valid and proper tear line... even without the tear line, it should have ignored the origin line completely instead of reporting it as an unknown echotag even if netmail should not have an origin line anyway... it is possibly a configuration problem on the sending system where they may not have their netmail area marked as a netmail area... i don't know... in any case, i think that sbbsecho should have stopped processing the message at the tear line and reported six unknown echotags or five unknown %commands and one unknown echotag...

thanks for your time and effort in looking into this problem...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Canada is so square even the female impersonators are women.
---
* Origin: (1:3634/12.73)

Re: sbbsecho failure
By: mark lewis to Digital Man on Fri Apr 12 2019 01:26 pm

i recovered the system at this point by removing the PKT with the ""bad"" areafix netmail in it and deleting two zero byte msg files... only one zero byte msg file is noted above... i suspect it was supposed to be a reply to the areafix message but sbbsecho faulted out before completly writing

it...

the second zero byte one came from the second attempt to process that areafix message a second time...

the problem with the areafix message in the PKT is multifold but i'm not sure what, exactly, caused sbbsecho to fault out leaving the bsy behind

and

the zero
byte msg files... i do still have the raw PKT with the offending areafix netmail message if you want it but here's the pktdump of it... passwords masked, tear and origin lines negated to avoid intermediate systems misreading them...

Can you reproduce the problem? If so, please provide a stack trace of the fault: http://wiki.synchro.net/howto:gdb

digital man

Synchronet/BBS Terminology Definition #54:
RIP = Remote Imaging Protocol (e.g. RIPscrip)
Norco, CA WX: 72.6øF, 34.0% humidity, 8 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2019 Apr 12 15:06:32, you wrote to me:

Can you reproduce the problem?

i'm sure i can by putting that packet back in place... i do still have it...

If so, please provide a stack trace of the fault: http://wiki.synchro.net/howto:gdb

i don't have a clue if it is that type of fault... i was thinking that it was an unknown exit point... i can try but whooooboy, that may be """interesting""" to say the least... definitely not sure how to keep the testing private so it doesn't leak back into the network (areafix replies)... not to mention that the system is very alive and throwing FTN mail into the wind almost all the time... i *have* to use grep to find anything else other than BINKP and BINKOUT there's so much of that going on...

maybe i can do something tomorrow? i should do it on a test system that's disconnected... i guess that means cloning the VM and going from there... i dunno... the wine and meds are at it again... at least it ain't rum in the fight like i normally consume :lol:

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Sex is like chinese food, half an hour later, ya want more!
---
* Origin: (1:3634/12.73)

Re: sbbsecho failure
By: mark lewis to Digital Man on Fri Apr 12 2019 06:52 pm

On 2019 Apr 12 15:06:32, you wrote to me:

Can you reproduce the problem?

i'm sure i can by putting that packet back in place... i do still have

it...

If so, please provide a stack trace of the fault: http://wiki.synchro.net/howto:gdb

i don't have a clue if it is that type of fault... i was thinking that it was an unknown exit point... i can try but whooooboy, that may be """interesting"""
to say the least... definitely not sure how to keep the testing private so it doesn't leak back into the network (areafix replies)... not to mention that the
system is very alive and throwing FTN mail into the wind almost all the time...
i *have* to use grep to find anything else other than BINKP and BINKOUT there's
so much of that going on...

maybe i can do something tomorrow? i should do it on a test system that's disconnected... i guess that means cloning the VM and going from there... i dunno... the wine and meds are at it again... at least it ain't rum in the fight like i normally consume :lol:

Or at the minimum, send me the offending packet?

digital man

Synchronet "Real Fact" #57:
Synchronet introduced Telnet, FTP, SMTP and POP3 support w/v3.00a-Win32 in 2000.
Norco, CA WX: 80.1øF, 25.0% humidity, 6 mph WNW wind, 0.00 inches rain/24hrs --- SBBSecho 3.07-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2019 Apr 13 15:19:22, you wrote to me:

maybe i can do something tomorrow? i should do it on a test system
that's disconnected... i guess that means cloning the VM and going from
there... i dunno... the wine and meds are at it again... at least it
ain't rum in the fight like i normally consume :lol:

Or at the minimum, send me the offending packet?

done... sent via email with the pkt attached that way... subject line has "[FIDO]" in 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...
... To live in the hearts we leave behind, is not to die.
---
* Origin: (1:3634/12.73)