Still trying to debug this one and only starting on it but a packet that came in via FrontDoor at 21:3/100 from 21:1/116 caused the copy of MUTIL to
shutdown with a 216 error

! Oct 04 09:39:24 Import from c:\fd\mystic\echomail\in\
+ Oct 04 09:39:24 Extracting 4878F4D3.TU0
- Oct 04 09:39:24 unzip -oqqjC "c:\fd\mystic\echomail\in\4878F4D3.TU0" "*.pkt" -d c:\fd\mystic\temputil\
+ Oct 04 09:39:24 Importing 8A966E3E.PKT (21:1/116 to 21:3/100)
+ Oct 04 09:39:24 Shutdown Corrupted memory (216)

I cleared the *bsy files with a fidopoll killbusy all and re ran the process again manually and hit the same 216 error.

Runtime error 216 at $0042DD42
$0042DD42
$00422F91
$004229D5
$00422369
$004022E0
$0040EFF1


The packet is echomail and created by Telegard

MSGID: 21:1/116 97b4dc6e
PID: Telegard 3.02/mL
TID: GE 1.1+


I unzipped the packet and re-ran MUTIL again to try and toss it and hit the same error so I can only conclude it's something to do with the packet.

After moving this packet out of echomail\in I then successfully tossed around 25 messages from packets that had been sitting stuck in the inbound directory sent from 1/100

My guess it there's something in the packet structure generated by the DOS Telegard that MUTIL does not like.

I have the packet if you want it :)

Best, Paul

--- Mystic BBS v1.12 A35 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

Still trying to debug this one and only starting on it but a packet that came in via FrontDoor at 21:3/100 from 21:1/116 caused the copy of MUTIL to shutdown with a 216 error

Can you send me the packet if you still have it?

Thanks

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 10/22/17, g00r00 pondered and said...

Still trying to debug this one and only starting on it but a packet t came in via FrontDoor at 21:3/100 from 21:1/116 caused the copy of MU to shutdown with a 216 error

Can you send me the packet if you still have it?

Packet 8A966E3E.PKT is sitting in your file box waiting for your next poll :)

Best, Paul

--- Mystic BBS v1.12 A35 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

Packet 8A966E3E.PKT is sitting in your file box waiting for your next
poll :)

Thanks.

It shows as invalid by PKTDUMP and PKTVIEW, and INSPECT shows it that it has invalid data in it, although it reads it when nothing else does. Mystic's PKT reader also says its not valid as well.

Unfortunately I cannot seem to reproduce the actual crash but there is certainly something not right with this PKT that needs to be looked into more.

What created it?

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 10/22/17, g00r00 pondered and said...

Still trying to debug this one and only starting on it but a pac came in via FrontDoor at 21:3/100 from 21:1/116 caused the copy to shutdown with a 216 error

Can you send me the packet if you still have it?

Packet 8A966E3E.PKT is sitting in your file box waiting for your next
poll :)

This is a problem with the software that created that PKT; the date field
is completely butchered and it has an extra NULL character at the end of it too.

I made a work around for it and it seemed to work but I have no idea if this
is something I should move forward with. What made this PKT? It needs to be fixed on their end...

I am not sure I should put code to work around this in because it could have other unknown effects with actual proper PKT files. I am going to upload to the prealpha directory the version that has this workaround in it, if you
want to test it.

Just be careful as I don't know what adverse effects it could have... it
seems to work okay here on my system with the small testing I've done.

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 10/22/17, g00r00 pondered and said...

On 10/22/17, g00r00 pondered and said...

This is a problem with the software that created that PKT; the date field is completely butchered and it has an extra NULL character at the end of it too.

I made a work around for it and it seemed to work but I have no idea if this is something I should move forward with. What made this PKT? It needs to be fixed on their end...

Well it came in from Marco aka sPINOZa 21:1/116 who was doing some testing.
The PID says is was created on Telegard 3.02/mL and I see it carries a TID of GE 1.1+ if that's of any help - I'm not sure?

I am not sure I should put code to work around this in because it could have other unknown effects with actual proper PKT files. I am going to upload to the prealpha directory the version that has this workaround in it, if you want to test it.

OK understood, I had pulled down a copy of the pre-alpha earlier but had not installed it as yet, planned to update Agency with it for now. If I update 1/100 HUB then I really should update 2/100 and 3/100 as well I guess just to avoid confounding things with two different versions running across the network?

I'm also unsure of the merits of keeping that code in. Overall there have
been few PKT tossing related issues for quite sometime now.

Just be careful as I don't know what adverse effects it could have... it seems to work okay here on my system with the small testing I've done.

Yep yep :)

Best, Paul

--- Mystic BBS v1.12 A35 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 10/22/17, g00r00 pondered and said...

Packet 8A966E3E.PKT is sitting in your file box waiting for your next

This is a problem with the software that created that PKT; the date field is completely butchered and it has an extra NULL character at the end of it too.

I made a work around for it and it seemed to work but I have no idea if this is something I should move forward with. What made this PKT? It needs to be fixed on their end...

I am not sure I should put code to work around this in because it could have other unknown effects with actual proper PKT files. I am going to upload to the prealpha directory the version that has this workaround in it, if you want to test it.

Just be careful as I don't know what adverse effects it could have... it seems to work okay here on my system with the small testing I've done.

--- Mystic BBS v1.12 A36 (Windows/32)

OK have updated Agency 1/101, the NET 1 HUB 1/100 and the NET 3 HUB that handles incoming FD traffic to the pre alpha test.

Just re-tested the offending packet and it's tossed fine this time, as is to
be expected given the tweak you made.

[snip]

+ Oct 26 19:46:02 Process: Importing EchoMail
+ Oct 26 19:46:02 Waiting for BUSY nodes
- Oct 26 19:46:02 LINKS:
- Oct 26 19:46:02 Node 1 21:1/100@fsxnet
- Oct 26 19:46:02 Node 2 21:3/101@fsxnet
! Oct 26 19:46:02 Import from c:\fd\mystic\echomail\in\
+ Oct 26 19:46:02 Importing 8A966E3E.PKT (21:1/116 to 21:3/100)
+ Oct 26 19:46:02 Import #34268 to FSX_GEN
+ Oct 26 19:46:02 Export FSX_GEN #34268 to 21:1/100@fsxnet
+ Oct 26 19:46:02 Export FSX_GEN #34268 to 21:3/101@fsxnet
+ Oct 26 19:46:02 Export FSX_GEN #34268 to 21:3/102@fsxnet
! Oct 26 19:46:02 Import from c:\fd\mystic\echomail\in\unsecure\
+ Oct 26 19:46:02 Bundling Messages
- Oct 26 19:46:02 EXEC: zip -qj9 c:\fd\mystic\echomail\out\fidonet\00020000.th0 c:\fd\mystic\temputil\0febded2.pkt
+ Oct 26 19:46:02 Adding PKT
"c:\fd\mystic\echomail\out\fidonet\00020000.th0" to FLO c:\fd\mystic\echomail\out\fidonet\00010064.clo
- Oct 26 19:46:02 EXEC: zip -qj9 c:\fd\mystic\echomail\out\fidonet\0000ffff.thx c:\fd\mystic\temputil\0febded2.pkt
+ Oct 26 19:46:02 Adding PKT
"c:\fd\mystic\echomail\out\fidonet\0000ffff.thx" to FLO c:\fd\mystic\echomail\out\fidonet\00030065.flo
+ Oct 26 19:46:02 Adding PKT
"c:\fd\mystic\echomail\out\fidonet\0febded4.pkt" to FLO c:\fd\mystic\echomail\out\fidonet\00030066.flo
+ Oct 26 19:46:02 Results: 1 echo, 0 net, 0 dupes, 3 tossed in 0.47s
+ Oct 26 19:46:02 Shutdown Normal (0)

[snip]

So I am going to leave those systems all up running the pre-alpha and will
keep an eye on things and let you know if I see anything that may look suspicious.

Next up some testing of netmail :)

Best, Paul

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 10/26/17, Avon pondered and said...

Next up some testing of netmail :)

I set a packet password between 3/100 and 1/100 then sent routed netmail via 1/100 from 3/100 addressed to 1/101

The outgoing packet from 3/100 did have a password in it, was imported OK by 1/100 and importantly was exported without issue to 1/101

[snip]

+ Oct 26 20:08:25 Extracting 00020000.th2
- Oct 26 20:08:25 unzip -oqqjC "c:\mystfsx\echomail\in\00020000.th2"
"*.pkt" -d c:\mystfsx\temputil\
+ Oct 26 20:08:25 Importing 0fedc238.pkt (21:3/100 to 21:1/100)
+ Oct 26 20:08:25 Route (21:3/100 to 21:1/101) via 21:1/101
! Oct 26 20:08:25 Import from c:\mystfsx\echomail\in\unsec\
+ Oct 26 20:08:25 Results: 0 echo, 1 net, 0 dupes, 0 tossed in 0.17s

[snip]

I then checked the packet at 1/101 prior to import, the packet password had been correctly stripped.

Final test was to import the packet at 1/101 and all went well.

[snip]

! Oct 26 20:13:47 Import from c:\bbs\mystic\echomail\in\
+ Oct 26 20:13:47 Importing 0fee5044.pkt (21:3/100 to 21:1/101)
+ Oct 26 20:13:47 Netmail from Paul Hayton to Paul Hayton

[snip]

From: Paul Hayton
To: Paul Hayton
Subj: Testing 2
Date: 10/26/17 20:06
Base: Netmail (fsxNet)

@INTL 21:1/101 21:3/100
@TID: Mystic BBS 1.12 A36
@MSGID: 21:3/100 4e957d39
@TZUTC: 1300
@Via: 21:1/100 @20171026.200825.UTC Mystic 1.1
Just another test.

1
2
3


Thanks!

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Mutura HUB (21:3/100)


[snip]

So in sum...

! When routing pass-through netmail, Mystic was not setting the PKT password
properly to the new routed node's configured PKT password.

Confirmed.

! When calculating pass-through and exported netmail by route, Mystic was not
skipping over echomail nodes that were flagged as Inactive.

Confirmed.

Best, Paul

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

So I am going to leave those systems all up running the pre-alpha and
will keep an eye on things and let you know if I see anything that may look suspicious.

Next up some testing of netmail :)

Great thank you! I'll plan on leaving that work around in there unless we
find something it breaks.

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

So in sum...

! When routing pass-through netmail, Mystic was not setting the PKT password properly to the new routed node's configured PKT password.

Confirmed.

! When calculating pass-through and exported netmail by route, Mystic
was not skipping over echomail nodes that were flagged as Inactive.

Confirmed.

Thank you very much for your efforts in testing this!

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

i don't know if they reported to you that when you download allfiles after a door the drop files were included. i made an mpl release to fix it until you got the info.

|08 .|05ú|13ù|15Dr|07e|08am Ma|07st|15er|13ù|05ú|08.
|08 øù|05ú|13ùø |13øù|05ú|08ùø
|11 DoRE|03!|11ACiDiC|03!|11Demonic |08[|15dreamland|09.|15darktech|09.|15org|08]

--- Mystic BBS v1.12 A35 (Windows/64)
* Origin: |08--[|15!|07dreamland BBS dreamland.darktech.org (21:1/163)

i don't know if they reported to you that when you download allfiles
after a door the drop files were included. i made an mpl release to fix it until you got the info.

It has been fixed in the "prealpha" A36 and will be in the offical A36 as
well.

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 10/27/17, g00r00 said the following...

It has been fixed in the "prealpha" A36 and will be in the offical A36 as well.

thank you. ;)

|08 .|05ú|13ù|15Dr|07e|08am Ma|07st|15er|13ù|05ú|08.
|08 øù|05ú|13ùø |13øù|05ú|08ùø
|11 DoRE|03!|11ACiDiC|03!|11Demonic |08[|15dreamland|09.|15darktech|09.|15org|08]

--- Mystic BBS v1.12 A35 (Windows/64)
* Origin: |08--[|15!|07dreamland BBS dreamland.darktech.org (21:1/163)