I've noticed on quite a few Mystic based boards that when I join a network
and do a rescan, one of the packets I get ends up being unable to import
into Synchronet.

After looking at the packet, it seems a NULL value is missing, now I'm not
sure if it's the first or the last that gets received or somewhere in the middle, but it's happened a number of times and I'm pretty sure it's only Mystic boards.

Any Mystic Sysops had anything similar reported to them? Maybe this is something g00r00 could look at.
--- SBBSecho 3.05-Linux
* Origin: End Of The Line BBS - endofthelinebbs.com (21:2/101)

Re: Issue with areafix rescan
By: Nigel Reed to FSXNET.FSX_MYS on Tue Jul 24 2018 10:10 pm

I've noticed on quite a few Mystic based boards that when I join a network and do a rescan, one of the packets I get ends up being unable to import into Synchronet.

After looking at the packet, it seems a NULL value is missing, now I'm not sure if it's the first or the last that gets received or somewhere in the middle, but it's happened a number of times and I'm pretty sure it's only Mystic boards.

Any Mystic Sysops had anything similar reported to them? Maybe this is something g00r00 could look at.

To add a little more detail:

FidoNet Type-2 packets are supposed to be (per FTS-1) terminated with 2 NUL (0) bytes. The packet in question is terminated only with a single NUL byte, for example:

55980: 39 37 33 2F 34 20 39 0D - 01 50 41 54 48 3A 20 37 : 973/4 9..PATH: 7 55990: 37 2F 31 20 33 36 2F 31 - 0D 00 : 7/1 36/1..

digital man

This Is Spinal Tap quote #21:
So when you're playing you feel like a preserved moose on stage?
Norco, CA WX: 72.4øF, 76.0% humidity, 0 mph S wind, 0.00 inches rain/24hrs
--- SBBSecho 3.05-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (21:1/183)

Digital wrote:

Re: Issue with areafix rescan
By: Nigel Reed to FSXNET.FSX_MYS on Tue Jul 24 2018 10:10 pm

I've noticed on quite a few Mystic based boards that when I join a network
and do a rescan, one of the packets I get ends up being unable to import
into Synchronet.

After looking at the packet, it seems a NULL value is missing, now I'm not
sure if it's the first or the last that gets received or somewhere in the
middle, but it's happened a number of times and I'm pretty sure it's only
Mystic boards.

Any Mystic Sysops had anything similar reported to them? Maybe this is
something g00r00 could look at.

To add a little more detail:

FidoNet Type-2 packets are supposed to be (per FTS-1) terminated with 2 NUL

(0)

bytes. The packet in question is terminated only with a single NUL byte, for example:

55980: 39 37 33 2F 34 20 39 0D - 01 50 41 54 48 3A 20 37 : 973/4 9..PATH:

7

55990: 37 2F 31 20 33 36 2F 31 - 0D 00 : 7/1 36/1..

To verify this, I wiped whispnet and refetched using %RESCAN R=5000

I received a large .we4 file that I unzipped into 14 .pkt files. Doing a
tail on all of them showed that they all termined with x0d followed by
3 nulls except the last packet which had x0d followed by just the one null value. Since it is incorrectly terminated the last packet of messages
is never imported.

The only work around is to turn off the fidonet importing, unpack the
files and echo -n -e "\x00\x00" >> to the packet name to get two extra
nulls, though I believe a packet just needs two null terminators.

0f2559e3.pkt
00081630 65 74 0d 20 2a 20 4f 72 69 67 69 6e 3a 20 54 69 |et. * Origin: Ti| 00081640 6d 65 20 57 61 72 70 20 6f 66 20 74 68 65 20 46 |me Warp of the F| 00081650 75 74 75 72 65 20 42 42 53 20 2d 20 48 6f 6d 65 |uture BBS - Home| 00081660 20 6f 66 20 4c 65 61 67 75 65 20 31 30 20 28 33 | of League 10 (3| 00081670 31 36 3a 37 37 2f 31 29 0d 53 45 45 4e 2d 42 59 |16:77/1).SEEN-BY| 00081680 3a 20 33 36 2f 31 20 35 20 36 20 37 20 34 30 33 |: 36/1 5 6 7 403| 00081690 2f 32 20 33 20 37 31 39 2f 31 20 33 20 37 37 2f |/2 3 719/1 3 77/| 000816a0 30 20 31 20 39 37 33 2f 34 20 39 0d 01 50 41 54 |0 1 973/4 9..PAT| 000816b0 48 3a 20 37 37 2f 31 20 33 36 2f 31 0d 00 00 00 |H: 77/1 36/1....| 000816c0
0f2559ec.pkt
00001f90 2e 33 30 0d 2d 2d 2d 20 53 42 42 53 65 63 68 6f |.30.--- SBBSecho| 00001fa0 20 33 2e 30 30 2d 57 69 6e 33 32 0d 20 2a 20 4f | 3.00-Win32. * O| 00001fb0 72 69 67 69 6e 3a 20 4e 69 6e 68 6f 20 64 6f 20 |rigin: Ninho do | 00001fc0 41 62 75 74 72 65 20 32 20 2d 20 52 69 6f 20 64 |Abutre 2 - Rio d| 00001fd0 65 20 4a 61 6e 65 69 72 6f 20 2d 20 42 72 61 73 |e Janeiro - Bras| 00001fe0 69 6c 20 2a 20 28 33 31 36 3a 33 34 31 2f 33 29 |il * (316:341/3)| 00001ff0 0d 53 45 45 4e 2d 42 59 3a 20 33 34 31 2f 33 20 |.SEEN-BY: 341/3 | 00002000 33 36 2f 31 20 37 31 39 2f 33 0d 01 50 41 54 48 |36/1 719/3..PATH| 00002010 3a 20 33 34 31 2f 33 20 33 36 2f 31 0d 00 |: 341/3 36/1..| 0000201e
--- SBBSecho 3.05-Linux
* Origin: End Of The Line BBS - endofthelinebbs.com (21:2/101)

Re: Re: Issue with areafix rescan
By: Nigel Reed to Digital Man on Wed Jul 25 2018 11:32 am

The only work around is to turn off the fidonet importing, unpack the files and echo -n -e "\x00\x00" >> to the packet name to get two extra nulls, though I believe a packet just needs two null terminators.

Nifty. I've run into this before also. I only ever notice this when doing a %RESCAN from a Mystic system.

I'm going to save the above echo -n -e "\x00\x00" >> packet.pkt command to a file so I can remember it in case I run into that again.

Ttyl :-),
Al


... Don't eat that. Studies prove it is hazardous to your health
--- SBBSecho 3.05-Linux
* Origin: The Rusty MailBox - Penticton, BC Canada (21:4/106)

Al wrote:

Re: Re: Issue with areafix rescan
By: Nigel Reed to Digital Man on Wed Jul 25 2018 11:32 am

The only work around is to turn off the fidonet importing, unpack the
files and echo -n -e "\x00\x00" >> to the packet name to get two extra
nulls, though I believe a packet just needs two null terminators.

Nifty. I've run into this before also. I only ever notice this when doing a %RESCAN from a Mystic system.

I'm going to save the above echo -n -e "\x00\x00" >> packet.pkt command to a file so I can remember it in case I run into that again.

Keep in mind, if you're going to do a rescan, you'll want to turn off the creation of fidoin.now file, comment out in binkd.cnf, no idea for binkit
or anything else.

I moved the packet to a new directory and uncompressed it. Find the last packet, and you can run it through hd to verify (that's how I got the
hex output). It's available for CentOS and Ubuntu and probably whatever
else.

Then just use that echo. Don't edit it in vi, if you do it'll save with a
0x0a on the end and you don't want that.

You can then just move all your pkt files into your inbound directory, /sbbs/fido/inbsecure for me, and touch /sbbs/data/fidoin.now and watch
it import away.

Don't forget to go back to your binkd.cfg and turn on the creation of fidoin.now
--- SBBSecho 3.05-Linux
* Origin: End Of The Line BBS - endofthelinebbs.com (21:2/101)

On 07/25/18, Nigel Reed pondered and said...

Digital wrote:

Re: Issue with areafix rescan
By: Nigel Reed to FSXNET.FSX_MYS on Tue Jul 24 2018 10:10 pm

I've noticed on quite a few Mystic based boards that when I join a net
and do a rescan, one of the packets I get ends up being unable to impo
into Synchronet.

To verify this, I wiped whispnet and refetched using %RESCAN R=5000

I received a large .we4 file that I unzipped into 14 .pkt files. Doing a tail on all of them showed that they all termined with x0d followed by
3 nulls except the last packet which had x0d followed by just the one
null value. Since it is incorrectly terminated the last packet of
messages is never imported.

Thanks to both of you for the investigative work, I have noted this thread and added it to a to-do list I will pass to g00r00 when he resurfaces.

--- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Avon wrote:

On 07/25/18, Nigel Reed pondered and said...

Digital wrote:

Re: Issue with areafix rescan
By: Nigel Reed to FSXNET.FSX_MYS on Tue Jul 24 2018 10:10 pm

I've noticed on quite a few Mystic based boards that when I join a net
and do a rescan, one of the packets I get ends up being unable to impo
into Synchronet.

To verify this, I wiped whispnet and refetched using %RESCAN R=5000

I received a large .we4 file that I unzipped into 14 .pkt files. Doing a
tail on all of them showed that they all termined with x0d followed by
3 nulls except the last packet which had x0d followed by just the one
null value. Since it is incorrectly terminated the last packet of
messages is never imported.

Thanks to both of you for the investigative work, I have noted this thread

and

added it to a to-do list I will pass to g00r00 when he resurfaces.

Sure, please let me know if you hear anything. I know I've joined a number of networks and had this problem. I was putting it down to something lost by
binkd or whatever but then I decided to investigate it a little more. DM checked
the packet and it was missing a terminating null. Once I added that it worked. I may have lost 300+ messages from other nets that I rescanned, including fsxnet when I first set it up. Oh well.
--- SBBSecho 3.05-Linux
* Origin: End Of The Line BBS - endofthelinebbs.com (21:2/101)