When a node sends a packet with a password not configured that the HUB

[snip]

! Jan 10 15:38:57 Import from c:\mystfsx-net4\echomail\in\
+ Jan 10 15:38:57 Extracting 0000000f.we0
- Jan 10 15:38:57 unzip -oqqjC "c:\mystfsx-net4\echomail\in\0000000f.we0" "*.pkt" -d c:\mystfsx-net4\temputil\
+ Jan 10 15:38:57 Importing 05fa24d6.pkt (21:4/115 to 21:4/100)
! Jan 10 15:38:57 Invalid PKT password
! Jan 10 15:38:57 Import from c:\mystfsx-net4\echomail\in\unsecure\

[snip]

There's only good luck that I look at the logs to catch the above and trouble shoot with the node. This is because MUTIL just deletes the invalid packet and there's no loud flag to say there is a problem .. except if know to go looking in the logs for a suspected issue.

What would be great would be if MUTIL kept the bad packet, put it in a configurable directory, generated a netmail (or similar) to the sysop to let him/her know of the issue. At the very least being able to see the faulty packets in a directory somewhere would be a flag to someone that something is amiss :)

Best, Paul


`I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

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

Re: Suggestion/Idea
By: Avon to g00r00 on Wed Jan 10 2018 03:48 pm

+ Jan 10 15:38:57 Importing 05fa24d6.pkt (21:4/115 to 21:4/100)
! Jan 10 15:38:57 Invalid PKT password

What would be great would be if MUTIL kept the bad packet, put it in a configurable directory, generated a netmail (or similar) to the sysop to let him/her know of the issue. At the very least being able to see the faulty packets in a directory somewhere would be a flag to someone that something is amiss :)

Synchronet does this also, just deletes the packet.

Other tossers I have used rename the packet to *.sec so the OP can decide what to do in that situation.. once he/she finds the .sec!

Ttyl :-),
Al


...Do it! It's easier to get forgiveness than permission.
--- SBBSecho 3.03-Linux
* Origin: The Rusty MailBox - Penticton, BC trmb.synchro.net (21:4/106)

There's only good luck that I look at the logs to catch the above and trouble shoot with the node. This is because MUTIL just deletes the invalid packet and there's no loud flag to say there is a problem .. except if know to go looking in the logs for a suspected issue.

I think this is just a case of misunderstanding the proper approach. Mystic puts it in the log, but it expects that the Sysop uses their ESP to detect when this issue occurs. Its just a matter of understanding how you're supposed to be using it!

I'm just kidding :)

What would be great would be if MUTIL kept the bad packet, put it in a configurable directory, generated a netmail (or similar) to the sysop to let him/her know of the issue. At the very least being able to see the faulty packets in a directory somewhere would be a flag to someone that something is amiss :)

I plan to do what you suggest, mostly. I think the plan will be to add the option to keep bad PKT files in a configurable directory (optionally) via the .ini file. It will also log into "errors.log" in your LOGS directory.

You may recall that errors.log is intended to be a single repo of meaningful errors which can then be used for notifications via SMS, email, etc. I think a bad PKT is a good candidate for this.

Anyway, the question I have for you is how should these files be named?
Should we put some sort of prefix on them or just do something like:

"asdfasdf.bad"
"asdfasdf.1.bad"

If there are filename conflicts, they must be renamed. But we have the option here to possibly come up with a naming standard that is more descriptive. Like "z1n123n123_asdfasdf.bad" or something. Any ideas here?

Maybe we could even have it create a directory with their addressing:

\mystic\in\badpackets\z1n1n123\asdfasdf.bad \mystic\in\badpackets\z1n1n123\asdfasdf.1.bad

Obviously I'd like to not make it overly complex if possible so maybe I am overthinking this.

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

On 01/10/18, g00r00 said the following...

I think this is just a case of misunderstanding the proper approach. Mystic puts it in the log, but it expects that the Sysop uses their ESP
to detect when this issue occurs. Its just a matter of understanding
how you're supposed to be using it!

I'm just kidding :)

I just love your sense of humor. ;)

Anyway, the question I have for you is how should these files be named? Should we put some sort of prefix on them or just do something like:

"asdfasdf.bad"
"asdfasdf.1.bad"

I would think that just changing the extension on the incoming packets would
be sufficient.

Obviously I'd like to not make it overly complex if possible so maybe I
am overthinking this.

I like the way you're thinking here. :) However, at least on my system, there really isn't that many bad packets coming in. (I'm not sure about Paul's systems, as he has a lot more traffic) I think I've only had 2 or 3 in the
last year.

My two-cents, would be to just rename the files with the .bad extension. When those are present, the Sysop can then read the logs to find out why there are bad packets, and where the came from.


---

Black Panther
a.k.a. Dan Richter
Sysop - Castle Rock BBS (RCS)
The sparrows are flying again....

--- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: Castle Rock BBS - castlerockbbs.com (21:1/186)

On 01/10/18, g00r00 said the following...

Anyway, the question I have for you is how should these files be named? Should we put some sort of prefix on them or just do something like:

Most mailers I've used just changed the extension to .bad and threw them into
a common badfile directory. It seemed entirely sufficient.

--- Mystic BBS v1.12 A38 2018/01/01 (Linux/64)
* Origin: Subcarrier BBS (21:2/140)

On 01/10/18, g00r00 pondered and said...

I think this is just a case of misunderstanding the proper approach. Mystic puts it in the log, but it expects that the Sysop uses their ESP
to detect when this issue occurs. Its just a matter of understanding
how you're supposed to be using it!

I'm just kidding :)

Ha! You had me there for a split second :)

I plan to do what you suggest, mostly. I think the plan will be to add the option to keep bad PKT files in a configurable directory
(optionally) via the .ini file. It will also log into "errors.log" in your LOGS directory.

Sounds good.

You may recall that errors.log is intended to be a single repo of meaningful errors which can then be used for notifications via SMS,
email, etc. I think a bad PKT is a good candidate for this.

Yes I agree. It's one of those things someone needs to be told about :)

Anyway, the question I have for you is how should these files be named? Should we put some sort of prefix on them or just do something like: "asdfasdf.bad"
"asdfasdf.1.bad"
If there are filename conflicts, they must be renamed. But we have the option here to possibly come up with a naming standard that is more descriptive. Like "z1n123n123_asdfasdf.bad" or something. Any ideas
here?
Maybe we could even have it create a directory with their addressing: \mystic\in\badpackets\z1n1n123\asdfasdf.bad

I would set one nominated directory for all failed packets to end up in. I
like your suggested naming standard above as it denotes the origin/sender
*and* retains the original file name. That means it's possible to sort files
by originating system(s) without the need for extra directories to split
them out. I do think keeping the original name of the file in the renamed file is essential and really useful when debugging issues with a node.

Also of note, I'd encourage as much info a possible about the error(s) and sending system AKA etc. to be logged in errors.log

Currently MUTL displays this kind of thing, so I'm picking you would copy it across to errors.log? :)

+ Jan 10 15:38:57 Importing 05fa24d6.pkt (21:4/115 to 21:4/100)
! Jan 10 15:38:57 Invalid PKT password

Changing the extension to .BAD is a nice touch, I've seen that before in other software (FastEcho).

The key thing is regardless of weather you just change the extension or rename them to something along the lines as mooted above - make sure to allow Mystic/MUTIL to retoss them again in that format.

Perhaps add/require a special switch that would force MUTIL to retoss .BAD packets only. That could be good. Also nice to have would be a command line option to override the directory MUTIL is to look for those .BAD packets.

Best, Paul


`I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

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

Ha! You had me there for a split second :)

I had a feeling that I might...

Ehh... Nevermind. I've beat this one dead with a bat at this point lol

I would set one nominated directory for all failed packets to end up in.
I like your suggested naming standard above as it denotes the origin/sender *and* retains the original file name. That means it's possible to sort files by originating system(s) without the need for
extra directories to split them out. I do think keeping the original
name of the file in the renamed file is essential and really useful when debugging issues with a node.

I think this is a good idea and I agree with everything you've said.

Currently MUTL displays this kind of thing, so I'm picking you would
copy it across to errors.log? :)

Yep it'll tell you the reason its there in the log.

Changing the extension to .BAD is a nice touch, I've seen that before in other software (FastEcho).

I have changed my mind on this since you mentioned the ability to retoss it easily if the issue can be resolved. I hadn't taken that into consideration.

Rather than putting code in to toss ".bad" files I'll just leave them as .PKT so they can just be dropped back into the incoming directory.

I've noted all of this in the todo hopefully I can get some serious
programming time this weekend!

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

On 01/10/18, g00r00 pondered and said...

I think this is a good idea and I agree with everything you've said.

I'm going export this to a text file, print it off and stick it on my wall in
a frame... because I can :)

Best, Paul


`I'm not expendable, I'm not stupid, and I'm not going' - Kerr Avon, Blake's 7

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

On 01/10/18, g00r00 said the following...

I think this is just a case of misunderstanding the proper approach. Mystic puts it in the log, but it expects that the Sysop uses their ESP
to detect when this issue occurs. Its just a matter of understanding
how you're supposed to be using it!

My ESP is telling me things that I should not be hearing and I feel crowded.

-- cr1mson

--- Mystic BBS v1.12 A37 2017/12/16 (Windows/32)
* Origin: Raiders Inc BBS -- vintagebbsing.com (21:1/154)