9db62811.pkt does not match an AKA (1:340/202.1)
Import from c:\mystic\echomail\in\unsecure\
! Apr 21 06:10:10 9db62811.pkt does not match an AKA (1:340/202.1
Re: Netmail Point
By: Rick Smith to All on Tue Apr 21 2020 08:03:25
i just replied to this in another area... please don't ask the same question in more than one area ;)
Greetings mark!
21 Apr 20 15:14, you wrote to me about an urgent matter!:
Re: Netmail Point
By: Rick Smith to All on Tue Apr 21 2020 08:03:25
i just replied to this in another area... please don't ask the same question in more than one area ;)
Not everyone that is available to help reads all relevant echos. So I will post where I need to get responses hence why there is a forward command.
Just skip over it if you have already read it.. You seem cranky to me, I long for the good old days when sysops were kind and less judgemental.
By: Rick Smith to mark lewis on Tue Apr 21 2020 01:42 pm
Maybe wait a day or two after posting the question in one area and
then if you get no reply, then start restating the question in another area, wait, and so on. That's what I'd do anyway.
In my experience, sysops have (mostly) always been cranky. It's like
part of the job description. :-)
Not everyone that is available to help reads all relevant echos.
I have poured over the logs for both my point setup and mystic. The
only errors I find are in the mutil log
Import from c:\mystic\echomail\in\unsecure\
! Apr 21 06:10:10 9db62811.pkt does not match an AKA (1:340/202.1
So I will post where I need to get responses
hence why there is a forward command.
Just skip over it if you have already read it.. You seem cranky to
me, I long for the good old days when sysops were kind and less judgemental.
Import from c:\mystic\echomail\in\unsecure\
! Apr 21 06:10:10 9db62811.pkt does not match an AKA (1:340/202.1
Looks like 202 does not know that it has a point 202.1 .
Re: Netmail Point
By: Kai Richter to Rick Smith on Wed Apr 22 2020 19:43:26
Import from c:\mystic\echomail\in\unsecure\
! Apr 21 06:10:10 9db62811.pkt does not match an AKA
(1:340/202.1
Looks like 202 does not know that it has a point 202.1 .
the error is my fault... the packet was sent from my system by
manually renaming it in the BSO to the boss node's address instead of properly unpacking it and repacking it with the proper destination
address in the PKT header... i could also have used a hex editor on it
to fix the PKT destination address... sadly, i didn't think about
that...
the reason i renamed it manually is because the message arrived here
with the crash bit set and due to a bug in the tosser i use, it tried
to follow the crash bit directions which were to pack the message
directly to the destination system... since the destination system is
a point system and my system has no idea about the connection details
for it, the packet and messages inside were stuck in my BSO... there
is a reason BSO is also known as a blackhole ;)
so we got with the maintainer of the tosser and looked at what was happening... originally we were concerned about something being broken
in the routing capabilities... then we discovered the crash bit and switched directions... now the tosser properly strips crash, hold, and local bits on incoming netmail so it can properly apply routing when needed...
FWIW: instead of manually renaming or doing the unpack/repack dance, i could just as easily of asked the destination point system to simply
poll here and pick it up themselves... hind sight, 20/20, and all
that...
I wish I had the appitude to understand one bit of that, but it certainly appears you do thankfully.
Does this mean things should work normally now?
Ive stopped posting about it so that I wouldnt annoy anyone further.
Sysop: | Rempala |
---|---|
Location: | Richlands, NC |
Users: | 109 |
Nodes: | 10 (0 / 10) |
Uptime: | 146:11:53 |
Calls: | 331 |
Files: | 6 |
Messages: | 110,851 |