All outgoing packets are being marked with the extension .bad .
I just realized none of my fidonet mail is going out anymore. I'm getting inbound, so I know it's not a connection issue. I think I've traced it back as far as the 318 R3 update was installed. All outgoing packets are being marked with the extension .bad . The .FLO files look ok. I'm using radius, which I've been using for years. Any idea what area I need to look for the problem in. I'm not that sharp when it comes to fido, so any hints will be appreciated. Thanks
packet password or it is not the write password... the remote system's tosser logs should be telling them exactly why those PKTs are being renamed... once that is know, the fix is quite simple...
Look at your logs to find out what's happening. SBBSecho never marks *outbound* packets as bad - only *inbound* (and only if they're bad) - but the sbbsecho.log file would tell you if/why that is occurring. Otherwise, something else is renaming the packets. --
digital man
Look at your logs to find out what's happening. SBBSecho never marks *outbound* packets as bad - only *inbound* (and only if they're bad) - but
! 28-Mar-2021 15:56:57 SYS00003 'C:\SBBS\radius\OUT\01130064.TMP\/SBBS/RADIUS/OUT/0000fff9.SU0' (The system cannot find the path specified)
i think it is possible to correct this on the radius side of the fence
but more research is needed...
! 28-Mar-2021 15:56:57 SYS00003if i'm reading that properly, it is a bundle destined to 275/100... i will assume zone 1...
'C:\SBBS\radius\OUT\01130064.TMP\/SBBS/RADIUS/OUT/0000fff9.SU0' (The
system cannot find the path specified)
the real question is why is radius:
1. looking at a .TMP file/directory?
2. adding the path onto the file or directory?
what is your radius outbound defined as?
what is your sbbsecho outbound defined as?
also remember that sbbsecho includes the path to the packets bundles in its ?LO files... can you capture one of those outbound ?lo files before radius does?
i think it is possible to correct this on the radius side of the fence but more research is needed...
this also should not be causing the remote to rename packets and bundles from your system to .bad but it is possible...
also remember that sbbsecho includes the path to the packets bundles in its ?LO files... can you capture one of those outbound ?lo files before radius does?
! 28-Mar-2021 15:56:57 SYS00003
'C:\SBBS\radius\OUT\01130064.TMP\/SBBS/RADIUS/OUT/0000fff9.SU0' (The
system cannot find the path specified)
i think it is possible to correct this on the radius side of the fence but more research is needed...
'C:\SBBS\radius\OUT\01130064.TMP\/SBBS/RADIUS/OUT/0000fff9.SU0' (The
system cannot find the path specified)
if i'm reading that properly, it is a bundle destined to 275/100... i will assume zone 1...
You are correct
this also should not be causing the remote to rename packets and bundles from your system to .bad but it is possible...
I think it's my side doing the renaming. It seems to leave it alone until the mailer tries to send it for the third time, then it's renamed to .bad, but unfortunatly none of this is in the logs.
Here is the .CLO file before radius sees it
^C:/SBBS/RADIUS/OUT/0000fff9.MO0
Here is the .FLO file after Radius see it and changes it.
^C:\SBBS\radius\OUT\01130064.TMP\/SBBS/RADIUS/OUT/0000fff9.MO0
and 0000fff9.MO0 has been renamed to 6061d405.bad and there
is a 01130064.tmp in the same directory.
Funny thing, I switched to Trapgate mailer today, and it does the same thing. I do like Trapgate, so hopfully there is a fix.
I was thinking about going to Binkit, but I would at least lkike to
know what is causing this before I spend the time to switch to another mailer and the same thing happens again. Stumped in Virginia.
cool... my next question is why is that TMP directory in your outbound? what is creating it there?
[...]and bundles from your system to .bad but it is possible...
this also should not be causing the remote to rename packets
I think it's my side doing the renaming. It seems to leave it alone until the
wait... i thought we were talking about your mail being renamed on the remote side... are we instead talking about you finding .bad files in your outbound that are not being sent??
i'm starting to think that it has something to do with that TMP directory in your outbound directory structure... AFAIK, they should not be there at alll... the question is why are they and what is creating them...
you're not using fileboxes are you??
Here is the .CLO file before radius sees it
^C:/SBBS/RADIUS/OUT/0000fff9.MO0
ok, that looks fine...
Here is the .FLO file after Radius see it and changes it.
^C:\SBBS\radius\OUT\01130064.TMP\/SBBS/RADIUS/OUT/0000fff9.MO0
and 0000fff9.MO0 has been renamed to 6061d405.bad and there
is a 01130064.tmp in the same directory.
eeewwwww... that is certainly not right... this is definitely something in radius... likely something to do with your path definitions but i'm guessing there... it has been a very long time since i ran any of the ART (Argus, Radius, Taurus) family of mailers but i have run all of them as they appeared... Taurus was the last one i ran back when i had a working Vista system...
Funny thing, I switched to Trapgate mailer today, and it does the same
thing. I do like Trapgate, so hopfully there is a fix.
IIRC, trapgate is one of the ART family in other clothes...
i'm curious as to what your paths settings are... like your temp directory definition if there is one...
i'm curious as to what your paths settings are... like your temp
directory definition if there is one...
There is no outbound temp setting, only inbound in either radius or trapgate.
I have not seen any listing for an outbound temp setting. I always
thought that was done on the fly with the program, then deleted by
the program after the mail has been sent.
Re: Outgoing Fido Mail
By: Rampage to DesotoFireflite on Sun Mar 28 2021 07:29 pm
also remember that sbbsecho includes the path to the packets bundles in its ?LO files... can you capture one of those outbound ?lo files before radius does?
Here is the .CLO file before radius sees it
^C:/SBBS/RADIUS/OUT/0000fff9.MO0
Here is the .FLO file after Radius see it and changes it.
^C:\SBBS\radius\OUT\01130064.TMP\/SBBS/RADIUS/OUT/0000fff9.MO0
and 0000fff9.MO0 has been renamed to 6061d405.bad and there
is a 01130064.tmp in the same directory.
! 28-Mar-2021 15:56:57 SYS00003 'C:\SBBS\radius\OUT\01130064.TMP\/SBBS/RADIUS/OUT/0000fff9.SU0' (The system cannot find the path specified)
if i'm reading that properly, it is a bundle destined to 275/100... i will assume zone 1...
the real question is why is radius:
1. looking at a .TMP file/directory?
2. adding the path onto the file or directory?
what is your radius outbound defined as?
what is your sbbsecho outbound defined as?
also remember that sbbsecho includes the path to the packets bundles in its ?LO files... can you capture one of those outbound ?lo files before radius does?
i think it is possible to correct this on the radius side of the fence but more research is needed...
this also should not be causing the remote to rename packets and bundles from your system to .bad but it is possible...
^C:\SBBS\radius\OUT\01130064.TMP\/SBBS/RADIUS/OUT/0000fff9.MO0
and 0000fff9.MO0 has been renamed to 6061d405.bad and there
is a 01130064.tmp in the same directory.
Maybe the back-slashes vs. forward-slashes are an issue for Radius?
i've just spent some time to locate and grab a copy of the radius source code... it is, indeed, doing that xxxxxxxx.TMP thing and i think i have figured out why... somewhere in your settings, have you enabled something called "Dynamic Outbounds"?? if so, turn that off and see what happens...
Here is the .CLO file before radius sees it
^C:/SBBS/RADIUS/OUT/0000fff9.MO0
Here is the .FLO file after Radius see it and changes it.
^C:\SBBS\radius\OUT\01130064.TMP\/SBBS/RADIUS/OUT/0000fff9.MO0
and 0000fff9.MO0 has been renamed to 6061d405.bad and there
is a 01130064.tmp in the same directory.
Maybe the back-slashes vs. forward-slashes are an issue for Radius?
i've just spent some time to locate and grab a copy of the radius source code... it is, indeed, doing that xxxxxxxx.TMP thing and i think i have figured out why... somewhere in your settings, have you enabled something called "Dynamic Outbounds"?? if so, turn that off and see what happens...
Ok, I cut off Dynamic Outbounds, and mail went out, but now the hub is getting "Invalid File Name Kickbacks",
what does that even mean??? we need logs, man... logs of the same session from both sides... these eWAGS* are getting old... fast...
^C:/SBBS/RADIUS/OUT/0000fff9.MO0
Here is the .FLO file after Radius see it and changes it.
^C:\SBBS\radius\OUT\01130064.TMP\/SBBS/RADIUS/OUT/0000fff9.MO0
Maybe the back-slashes vs. forward-slashes are an issue for Radius?
Re: Outgoing Fido Mail
By: Digital Man to DesotoFireflite on Mon Mar 29 2021 04:01 pm
^C:/SBBS/RADIUS/OUT/0000fff9.MO0
Here is the .FLO file after Radius see it and changes it.
^C:\SBBS\radius\OUT\01130064.TMP\/SBBS/RADIUS/OUT/0000fff9.MO0
Maybe the back-slashes vs. forward-slashes are an issue for Radius?
Just curious, and work with me here, was there a change in how sbbsecho would pass this file dir and name in the .clo/.flo, when it comes to forward-slashes and back-slashes when 3.18b came out.
I'm grasping at straws
here, but I've been using radius for about 3 to 4 years, and this all started about the time I did the last update. In sbbsecho.ini, it's listed as:
"outbound = C:\SBBS\RADIUS\OUT\" but it's forward slashes in the .clo/.flo
The logs don't tell me squat, and I can't get the hub to send me their logs, so I'm shooting in the dark. I plan on updating to binkit this weekend, but I really would like to know what is causing this if possable. As always, thanks.
Sysop: | Xerxes |
---|---|
Location: | Azle, Texas |
Users: | 131 |
Nodes: | 10 (0 / 10) |
Uptime: | 85:58:13 |
Calls: | 3,190 |
Calls today: | 1 |
Files: | 195 |
U/L today: |
0 files (0K bytes) |
D/L today: |
0 files (0K bytes) |
Messages: | 366,067 |
Posted today: | 0 |