The following bugs have been squashed.
- Fixed FTP put security hole (UNIX)
If creating a new file, the directories write permissions were not being
used to determine whether or not the action would be permitted.
- AXUI callsign buffer expanded in size
- Fixed a buglet that crashed the system w/long nickname in convers
Only occurred with a LONG nickname when executing the '/cut' command.
Obscure, but there.....
- Fixed a few assorted buglets that weren't reported before 2.10 :-(
- Fixed crash if corrupted wpages files are expired
- Fixed a subtle bug affect the pathname() function
This only affected 'finger' when using the '-d dirname' command line
option, and then not always.
- Fixed a minor problem with forwarding using an area rewrite
If multiple messages were being sent during an FBB or XFWD bundle, then
only the first address was being rewritten......
- Fixed problem with a CC: to a public area
If you send a 'SP' BBS message (or 'SC') and end up
with a CC: to a public area it has an 'X-BBS-Type' line defining it as
personal, when it should be bulletin. This only is examined when
forwarding PBBS traffic. There used to be code in TNOS (from JNOS) that
made the 'X-BBS-Type' line *the* authority on the message's type. Now, if
a message is in a public area, it is a bulletin, and the 'X-BBS-Type'
value is ignored (i.e. a 'B'ulletin will not be changed to a 'P'ersonal).
If it is public, it cannot be personal. This does NOT prevent having the
reverse, that is messages in private areas (maybe a private storage area
for an individual PBBS's forwarded messages) being sent as bulletins.
Also, in doing this, I noticed that you COULD have a message in a 'nts'
area that sometimes would NOT be sent as a 'ST' message. This was also
fixed.
- Fixed displaying parameter strings with a '\r'
Now, if you define a parameter string (like 'ax25 bctext') to be a multi-line
string with a '\r', the output to the screen or the remote user
will be as expected, i.e. it will look the same as '\n'.
- Fixed problem with 'editheader' and messages without a X-BBS-Type
- Several unreported RIP bugs found (in LINT'ing) related to broadcasts
- Fixed where some HTTPPBBS accesses weren't removing 'users' when done
- Added a fix for supressing Polled Kiss polls on multidrop kiss
- Fixed convers compatibility problem with NON-TPP servers
If the callsign/nickname combo's is larger than 9 characters, this will
prevent a Jnos host that is linked in from hearing what that person is
saying. Now when speaking with a non-TPP compatible system, the nickname
should be striped off (if one was set) before passing the data to the
brain-dead server.
- Fixed an evasive buglet in FBB forwarding code
At times, after sending a transaction, TNOS would send another one, without
allowing the remote side to take their turn. Though this has happened since
FBB forwarding was added, it happened so infrequently is was hard to pin
down, and even when spotting it, there didn't seem to be a pattern to it.
Well, there was ;-) It turns out that if all messages in the negotiation
bundle were rejected, that's when this occurred. The first line of the
remote's negotiations would get eaten, and then TNOS would start a new
negotiation, in which it THOUGHT that the remainder of the remote's
negotiation was an invalid response. All fixed now!
- Fixed a rare bug with the at command
- Fixed a kiss trace buglet, for multidrop kiss
- Fixed buglet where some forwarded personal messages weren't deleted
They were removed from the forwarding queue, but not marked as deleted
messages This only affected FBB and XFWD sessions. This normally didn't
happen, except when a message was rejected, for whatever reason.
- Fixed a discovered memory leak with FBB and XFWD sessions
- Forward file locking fixed
If a record got added into a *.fwd file when a forwarding session is
concluding, sometimes the new record STILL got missed, and the *.fwd file
would get deleted, losing that new record. Only happened if the new message
was in the SAME area as the area last processed.
Rare, but needed to be addressed.
- Fixed a XFWD trace buglet, with incoming messages
Thanks to a typo, if the 'forward xtrace' is on and a new message comes
in, there was a crash.
- Corrected occasional delay in noticing new messages in PBBS queues
While not bad previously, new messages MIGHT not have caused an immediate
rescan of the queue on the very next negotiation for FBB or XFWD sessions.
Now this should always rescan on the next negotiation.The net result is that (for example) if a new personal message comes in
on one forwarding session that is queued for another PBBS that is also
actively forwarding, then that message will go out on the next negotiation
(assuming that you have the personal areas located before the public areas
in that PBBS's forwarding entry in the 'forward.bbs' file).
- Added Gareth's fix for incomplete nntp file crashes
- Fixed a parsing bug with incoming XFWD sessions
- Fix for possible string overflow during command line expansion
- LONGSTANDING DNS buglet found!
The DNS code had a subtile bug, which allows overrunning a buffer if the
address being queried returned a LONG response. This only occured if the
DNS was serving for others, and NOT for local usage.
This one probably accounted for the assorted DNS quirks, as well as some
(possibly ALL) of the strangely corrupted memory problems.
For example, if you queried a TNOS site (connected to the Internet) for
the address 'mx1.compuserve.com', then you would PROBABLY would have
crashed the system, 1 out of every 3 or less attempts. But a query on
a simpler address (such as 'lantz.com') would NEVER crash it.
The 'mx1.compuserve.com' address returns *10* 'A' records, and uses
about 2K of space to store it, when previously only 1K
was being allocated.
If your 'domain dns' is off, this would NEVER affect you. It was not in
the mainline DNS code, just in the code used when TNOS was acting as a
server for others.
The original RFC stated that 512 bytes should be the MAX that is returned
in a DNS UDP packet, but this seems (at a quick glance) to be being
ignored (deliberately or accidently) by every server I checked.
For the time being, this has been changed to 4K, which should be FAR more
than enough. This will need to be revisited when I've had time to
investigate whether the RFC is obsolete or not.
- Fixed a problem sending ReturnReceipts to incomplete messages
There would be a crash if trying to send a ReturnReceipt to a message that
didn't contain a 'To:' header or a 'Subject:' header.
- Fixed a PBBS 'vm' crash with more than 30 messages
- Fixed a buglet with 'smtp kick <host>'
- Fixed a longstanding startup file/DNS problem
Several commands take a hostname or an IP address. If these are used in
the startup file, they must be used with the ip address, NOT the
hostname. This is regardless of whether or not the DNS is already configured.
The reason is that the multitude of command that call the resolver, do so
expecting that they will NOT be swapped out. This is NOT so with the
resolver, as a DNS response can take a while.
In the past, this led to a quick crash, as the commands parameters got
freed before the command was finished with them.
In this release, the restriction of no hostname usage in the startup
file remains, though now the line causing the error will report a useful
message, and a crash will NOT occur.
If you REALLY need to have a command in the startup file using a
hostname, you can (for example) do a:
nntp add ko4ks 3600 *
like this:
at now+0001 "nntp add ko4ks 3600 *"
It will delay it's action by 1 minute, though.
- Fixed incorrect paging in 'nntp read' newsgroup reader
- Fixed XFWD email 'PBBS' name and dups scanning
Previously, all received email from XFWD sessions came in as if it came
from a PBBS named 'import', since it was being processed by the import
code. Now it properly identifies the PBBS sending it.
Also, it was discovered that the setup for the import call did not set
enough options to allow the message to be properly scanned for R:
line dups, if ALTERBID is enabled. Now this is fixed.
- Fixed NNTP code that was improper in view of RFC977
If an 'IHAVE' failed, the connection was aborted. RFC977 states that if
a server has a problem with an 'IHAVE', it can report an error, or just
drop it silently. It should NOT need to abort. And all xNOS NNTP servers
would have then gotten into a loop, as an aborted session did not update
the 'poll' files polling time. This would NOT remove the erring message
from those that it would try to send (unsuccessfully) next time, in a
loop until humans intervened.
Aside from that, aborting due to a single rejected posting (via IHAVE)
is NOT efficient, as the two sites MAY only connect once or so a day.
Postponing VALID news articles because of one INVALID one is not
acceptable. If PBBS forwarding aborted a session due to rejecting a
single message, SYSOPs would be screaming ;-)
The loop had already been found and fixed in this TNOS release, but now
the bad message sent via 'IHAVE' will not cause an abort.
- Added incoming negotiations from XFWD to log file (an oversight)
- Added code to delete incomplete PBBS messages from forwarding queues
If the forwarding code sees a message without a 'To:' and 'From:' field,
then that message is deleted from the forwarding queue. Previously,
this message could not be forwarded (obviously) but it also did not
get removed from the forward queues, without sysop intervention.
- FOUND THE ELUSIVE "gateway no-timeout disconnect" bug!
- Added a few pwait()'s to the fwding code, it was greedy at times
- Also refresh 'pbbs tdisc' counter during gatewaying for incoming data
- PBBS gatewaying now yields to 'pbbs maxtimer' setting, if used
- All the above items included in beta release 2.20b1
- Fixed NNTP buglet with multiple "GMT"s in a NEWNEWS command line
- Fixed NNTP bug in code gatewaying PBBS->NNTP messages
- Fixed a bug in the IMPORT code
- Fixed an FTP server buglet (in Unix)
The security patches weren't complete, and you COULD do an 'ls' on a
directory which didn't allow reading in it's permissions.
- All the above items included in beta release 2.20b2
- Fixed a buglet in the NNTP code that could trash the 'domain trans' setting