Hey all,

I'm having a couple issues with InterBBS Last Callers from xqtr.

Everything is installed correctly and any user log in data is being pushed
out to the correct echonode.

When I try to run the wall it's throwing up the following Python error:

"for ibbs in bbses: TypeError; 'NoneType' object is not iterable"

the error is in line 307.

Does this sounds familiar to anyone?

Cheers!

... It's all about the subculture, man!

--- Mystic BBS v1.12 A48 (Windows/64)
* Origin: Retro32 BBS (21:1/215)

"for ibbs in bbses: TypeError;
'NoneType' object is not iterable"

the error is in line 307.

Does this sounds familiar to
anyone?

I don't use this mod myself, but I seem to remember something about it not liking when messages are missing a field. If I remember right, there's no error checking so the whole thing blows up when it comes a cross a message that doesn't have all fields filled in.

Checking my last callers, there's a a few from the past week that are missing the BBS address field. That might be what's doing it.

Someone more familiar with the exact mod might be able to help with a fix. (Possibly just throwing a try/catch around it and skipping any failed messages...)

Hope this helps!


--- NE BBS v1.10 (linux; x64)
* Origin: NE BBS - nebbs.servehttp.com:9223 (21:3/193)

Someone more familiar with the exact mod might be able to help with a fix. (Possibly just throwing a try/catch around it and skipping any failed messages...)

Handling the exceptions, is not always the preferred way. If you catch that exception then no one, will know that a BBS is "injecting" wrong or even corrupted data packets into the feed/echomail, perhaps multiple BBSes. If this continues for some time and more and more BBSes don't report correctly, then the mod would be useless.

Another solution, would be to create a log, but i don't think that many people would look into that. :)

It's preferred to check the FSX_DAT or any other echonet area that handles the data packets (for FSX, is FSX_DAT) for corrupted messages or a wrong set up BBSes and report to the BBS sysop or a FSX admin.

To bypass the problem, just delete the FSX_DAT.* files, which will erase all messages, along with the corrupted ones ;) The echonet, will be re-created when it receives new messages.

.
:: XQTR :: Another Droid BBS :: andr01d.zapto.org:9999 :: xqtr@gmx.com

--- Mystic BBS v1.12 A47 2020/11/23 (Raspberry Pi/32)
* Origin: Another Droid BBS # andr01d.zapto.org:9999 (21:1/111)

Re: Re: InterBBS Last Callers
By: xqtr to slacker on Tue Jul 15 2025 03:45 pm

Another solution, would be to create a log, but i don't think that many people would look into that. :)

You underestimate sysops. Plenty know to check logs for errors, and do.

It's preferred to check the FSX_DAT or any other echonet area that handles the data packets (for FSX, is FSX_DAT) for corrupted messages or a wrong set up BBSes and report to the BBS sysop or a FSX admin.

No disrespect, but no. It's not fsxNet's fault that the script is failing to process a message. The script should be more fault-tolerant of unexpected scenarios like the one described here, and handle it gracefully.

To bypass the problem, just delete the FSX_DAT.* files, which will erase all messages, along with the corrupted ones ;) The echonet, will be re-created when it receives new messages.

This gets around the current problem at hand, sure. But only until it re-surfaces. Then the sysop (in fact, all sysops who use this script) will inevitably find themselves in the same situation again.

The script needs to be fault-tolerant.

|15 þ ù ú codefenix ú ù ú ConstructiveChaos BBS ú ú ù þ þ
|08 þ þ ù (https/telnet/ssh)://conchaos.synchro.net ú ù þ
|07
--- SBBSecho 3.28-Win32
* Origin: -=[conchaos.synchro.net | ConstructiveChaos BBS]=- (21:4/141)

You underestimate sysops. Plenty know to check logs for errors, and do.

I don't under/over estimate no one. It's not about if they know, which i think it's obvious they do, cause setting a BBS in a Linux/Windows machine, is not for an amature... but if they do or have the time and will to do, to debug something.

Personal speaking, i am not even logging to my BBS daily, about once per two-three days and even then, i don't check logs, unless something went wrong.

No disrespect, but no. It's not fsxNet's fault that the script is faili cess a message. The script should be more fault-tolerant of unexpected sce
like the one described here, and handle it gracefully.

I never said that. For the second time in the same post you imply things that i haven't said... don't try to tell others, what i think. Just tell your opinion on the subject.

Of course it's not the fsx/zero/arak net error. The mod uses an echoarea just for data transfer. The "obligation" for the data to be correct is of the sysop that sets it up, to his BBS. And even then, we can't accuse anyone, that did something deliberately. Something may was misunderstood or was setup by mistake... mistakes happen.

This gets around the current problem at hand, sure. But only until it r
s. Then the sysop (in fact, all sysops who use this script) will inevitabl
themselves in the same situation again.|07

Yes and when it happen again, anyone will know and contact the BBS that "caused" it and will be fixed immediately, cause it affects the mod and data transfer for it ;)

The script needs to be fault-tolerant.

I explained my self earlier. "Hiding" network errors, meaning the corrupt or wrong packet messges, will just delay or not correct the problem at all.

Feel free to make a fork and apply any changes to the original mod/script. All of my mods are under GPL3 lic. and anyone is free to alter them in the way they think.

.
:: XQTR :: Another Droid BBS :: andr01d.zapto.org:9999 :: xqtr@gmx.com

--- Mystic BBS v1.12 A47 2020/11/23 (Raspberry Pi/32)
* Origin: Another Droid BBS # andr01d.zapto.org:9999 (21:1/111)

xqtr wrote to Codefenix <=-

You underestimate sysops. Plenty know to check logs for errors, and do.

I don't under/over estimate no one. It's not about if they know, which
i think it's obvious they do, cause setting a BBS in a Linux/Windows machine, is not for an amature... but if they do or have the time and
will to do, to debug something.

Personal speaking, i am not even logging to my BBS daily, about once
per two-three days and even then, i don't check logs, unless something went wrong.

But.... how would you know if anything went wrong, without checking
logs? I check mine multiple times per day, and have caught problems
early because of following logs. Stuff like a netmail stuck in an
endless loop or something.

IMHO any sysop should be checking things at least daily.



... All the easy problems have been solved.
=== MultiMail/Linux v0.52
--- SBBSecho 3.28-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (21:2/138)