• lost PKTs in /sbbs/temp

    From waldo kitty@1:103/705 to Digital Man on Mon Oct 15 10:58:55 2018
    i've just found numerous "lost" FTN PKTs in my /sbbs/temp directory... internally they all carry a PID of

    Synchronet 3.17a-Linux Oct 11 2018 GCC 5.5.0

    and they all come from the same system that i'm working with to set up a connection with... looking at the file names, it suddenly dawned on me that they are not named with only hex characters... i don't have a problem with that... it was just noticible and unlikely to be part of the problem... research continues...

    so i scan my sbbsecho.log file and don't find any indication of the files being processed... ok, so time to figure out how to scan my syslog.*.gz files and see what i can find there... [time passes] this is interesting... this is one of the lost PKTs...

    Oct 12 16:56:00 southeaststar synchronet: srvc 0068 BINKP Receiving file: /sbbs/temp/lmkvyy4g.pkt (7.5KB)
    Oct 12 16:56:00 southeaststar synchronet: srvc 0068 BINKP Received file: /sbbs/temp/lmkvyy4g.pkt (7.5KB)
    Oct 12 16:56:00 southeaststar synchronet: srvc 0068 BINKP Moving '/sbbs/temp/lmkvyy4g.pkt' to '../fido/nonsecure/lmkvyy4g.pkt'.
    Oct 12 16:56:00 southeaststar synchronet: srvc 0068 BINKP Callback returned false for '/sbbs/temp/lmkvyy4g.pkt'.

    why'd the callback return "false"? every one of the lost PKTs shows up like the above...

    ok, so now i manually copy the files into my unsecure inbound and trigger fidoin.now... hummm, they're all still in unsecure and nothing reported in sbbsecho.log about processing them...

    2018-10-15 10:34:34 SBBSecho 3.06-Linux r3.93 Oct 7 2018 GCC 7.3.0 invoked with options: -ce
    2018-10-15 10:34:34 Configured: 7 archivers, 42 linked-nodes, 10 echolists 2018-10-15 10:34:34 NetMail directory: /sbbs/netmail/
    2018-10-15 10:34:34 Secure Inbound directory: /sbbs/fido/inbound/
    2018-10-15 10:34:34 Non-secure Inbound directory: /sbbs/fido/nonsecure/ 2018-10-15 10:34:34 Outbound (BSO root) directory: /sbbs/fido/outbound 2018-10-15 10:34:34 Read 234 areas from ../data/areas.bbs
    2018-10-15 10:34:34 Read 0 areas from ../data/badareas.lst
    2018-10-15 10:34:34 Read 96 echo statistics from ../data/echostats.ini 2018-10-15 10:34:34 Writing 0 areas to ../data/badareas.lst
    2018-10-15 10:34:34 Deleting /sbbs/ctrl/sbbsecho.bsy (from line 2973) 2018-10-15 10:34:34 SBBSecho exiting with error level 0

    i moved them to my secure inbound and they were properly processed and imported into synchronet... even the attached file(s) that a few of them carried :)

    am i missing a setting that allows sbbsecho to process netmail in unsecure/ PKTs?

    )/\(aldo

    ---
    * Synchronet * SouthEast Star Mail HUB - SESTAR
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to waldo kitty on Mon Oct 15 13:42:42 2018
    Re: lost PKTs in /sbbs/temp
    By: waldo kitty to Digital Man on Mon Oct 15 2018 10:58 am

    i've just found numerous "lost" FTN PKTs in my /sbbs/temp directory... internally they all carry a PID of

    Synchronet 3.17a-Linux Oct 11 2018 GCC 5.5.0

    and they all come from the same system that i'm working with to set up a connection with... looking at the file names, it suddenly dawned on me that they are not named with only hex characters... i don't have a problem with that... it was just noticible and unlikely to be part of the problem... research continues...

    so i scan my sbbsecho.log file and don't find any indication of the files being processed... ok, so time to figure out how to scan my syslog.*.gz files and see what i can find there... [time passes] this is interesting... this is one of the lost PKTs...

    Oct 12 16:56:00 southeaststar synchronet: srvc 0068 BINKP Receiving file: /sbbs/temp/lmkvyy4g.pkt (7.5KB)
    Oct 12 16:56:00 southeaststar synchronet: srvc 0068 BINKP Received file: /sbbs/temp/lmkvyy4g.pkt (7.5KB)
    Oct 12 16:56:00 southeaststar synchronet: srvc 0068 BINKP Moving '/sbbs/temp/lmkvyy4g.pkt' to '../fido/nonsecure/lmkvyy4g.pkt'.
    Oct 12 16:56:00 southeaststar synchronet: srvc 0068 BINKP Callback returned false for '/sbbs/temp/lmkvyy4g.pkt'.

    why'd the callback return "false"? every one of the lost PKTs shows up like the above...

    I don't know, but I just committed an update to binkit.js to log more details in those failure cases.

    ok, so now i manually copy the files into my unsecure inbound and trigger fidoin.now... hummm, they're all still in unsecure and nothing reported in sbbsecho.log about processing them...

    2018-10-15 10:34:34 SBBSecho 3.06-Linux r3.93 Oct 7 2018 GCC 7.3.0 invoked with options: -ce
    2018-10-15 10:34:34 Configured: 7 archivers, 42 linked-nodes, 10 echolists 2018-10-15 10:34:34 NetMail directory: /sbbs/netmail/
    2018-10-15 10:34:34 Secure Inbound directory: /sbbs/fido/inbound/
    2018-10-15 10:34:34 Non-secure Inbound directory: /sbbs/fido/nonsecure/

    Perhaps you've confused "unsecure" with "nonsecure"?

    2018-10-15 10:34:34 Outbound (BSO root) directory: /sbbs/fido/outbound 2018-10-15 10:34:34 Read 234 areas from ../data/areas.bbs
    2018-10-15 10:34:34 Read 0 areas from ../data/badareas.lst
    2018-10-15 10:34:34 Read 96 echo statistics from ../data/echostats.ini 2018-10-15 10:34:34 Writing 0 areas to ../data/badareas.lst
    2018-10-15 10:34:34 Deleting /sbbs/ctrl/sbbsecho.bsy (from line 2973) 2018-10-15 10:34:34 SBBSecho exiting with error level 0

    i moved them to my secure inbound and they were properly processed and imported into synchronet... even the attached file(s) that a few of them carried :)

    am i missing a setting that allows sbbsecho to process netmail in unsecure/ PKTs?

    I don't know of any such setting. :-/

    digital man

    Synchronet "Real Fact" #31:
    The Synchronet IRC server (ircd) was written in JS by Randy Sommerfeld (Cyan). Norco, CA WX: 71.7oF, 11.0% humidity, 2 mph SSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.06-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From mark lewis@1:3634/12.73 to Digital Man on Thu Oct 18 13:32:10 2018

    On 2018 Oct 15 13:42:42, you wrote to waldo kitty:

    why'd the callback return "false"? every one of the lost PKTs shows up
    like the above...

    I don't know, but I just committed an update to binkit.js to log more details in those failure cases.

    thanks...

    Perhaps you've confused "unsecure" with "nonsecure"?

    maybe only when typing... i view them as the same but my inbound directories are "inbound" and "unsecure" (right now)...

    am i missing a setting that allows sbbsecho to process netmail in
    unsecure/ PKTs?

    I don't know of any such setting. :-/

    ok... i'll just have to keep an eye on my inbound for unprocessed netmail PKTs... i will see them from random systems contacting me for a fidonet node number or even wanting to connect to the message and file services i offer... certainly unsecure sessions since their contact would likely be sending me an application with needed connection information 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...
    ... The cost of feathers has risen...now even DOWN is up!
    ---
    * Origin: (1:3634/12.73)
  • From Digital Man@1:103/705 to mark lewis on Thu Oct 18 13:43:02 2018
    Re: lost PKTs in /sbbs/temp
    By: mark lewis to Digital Man on Thu Oct 18 2018 01:32 pm


    On 2018 Oct 15 13:42:42, you wrote to waldo kitty:

    why'd the callback return "false"? every one of the lost PKTs shows up
    like the above...

    I don't know, but I just committed an update to binkit.js to log more details in those failure cases.

    thanks...

    Perhaps you've confused "unsecure" with "nonsecure"?

    maybe only when typing... i view them as the same but my inbound directories are "inbound" and "unsecure" (right now)...

    am i missing a setting that allows sbbsecho to process netmail in
    unsecure/ PKTs?

    I don't know of any such setting. :-/

    ok... i'll just have to keep an eye on my inbound for unprocessed netmail PKTs... i will see them from random systems contacting me for a fidonet node number or even wanting to connect to the message and file services i offer... certainly unsecure sessions since their contact would likely be sending me an application with needed connection information in it ;)

    *netmail* packets should import just fine from the nonsecure directory. If you have unprocessed netmail packets, please provide me the sbbsecho.log snippet that shows what SBBSecho reported about them and why they weren't imported.

    digital man

    Synchronet "Real Fact" #5:
    Synchronet version 3 for Win32 development began in 1999.
    Norco, CA WX: 84.0oF, 18.0% humidity, 0 mph E wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.06-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From mark lewis@1:3634/12.73 to Digital Man on Thu Oct 18 20:38:30 2018

    On 2018 Oct 18 13:43:02, you wrote to me:

    ok... i'll just have to keep an eye on my inbound for unprocessed
    netmail PKTs... i will see them from random systems contacting me for a
    fidonet node number or even wanting to connect to the message and file
    services i offer... certainly unsecure sessions since their contact
    would likely be sending me an application with needed connection
    information in it ;)

    *netmail* packets should import just fine from the nonsecure
    directory. If you have unprocessed netmail packets, please provide me
    the sbbsecho.log snippet that shows what SBBSecho reported about them
    and why they weren't imported.

    i'm keeping an eye on it...

    the one link i was having a problem with has two netmail packers in use... squish for some stuff and irex for dynamically packed stuff that he writes... i
    don't know if his BBS users netmails also are exported to the dynamic mailer's netmail directory for processing, though... in any case, echomail was coming in
    with the proper packet password but not routed netmails... turns out that with two netmail managers, he had to set the proper packet password in both tools...
    now that that is done, everything seems to be flowing smoothly... even with sbbsecho having an uppercase packet password and them sending a lowercase one... everything is working properly from this end of the chain :)

    )\/(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 desert is not hostile to people, only indifferent to them.
    ---
    * Origin: (1:3634/12.73)