| |
N1URO > PACKET 08.12.19 09:39l 52 Lines 2686 Bytes #999 (0) @ WW
BID : 35024_N1URO
Read: GUEST
Subj: Re: lu9dce: Line should start with 'F',>
Path: IZ3LSV<IK7IJR<IW2OHX<HB9ON<IW8PGT<CX2SA<OK2PEN<N1URO
Sent: 191122/1618Z @:N1URO.#CCT.CT.USA.NOAM #:35024 [Unionville] $:35024_N1URO
From: N1URO@N1URO.#CCT.CT.USA.NOAM
To : PACKET@WW
The trigger for BBS<>BBS mail exchanging is > and a line feed "/n".
Years ago we had issues with the earlier versions of TheNet because
the node's prompt used to return a > so if there wasn't a connect it was
possible the node could return a BBS forwarding trigger.
A "fix" for this was to change the NetRom prompts from a > to a }. This
allowed a BBS to node hop from within a NetRom node to a more distant
BBS. Mail forwarding was much more successful since this change was
engaged and eproms were reburned.
As Gus mentions sysops changing prompts, pushing CTexts upon connects,
welcome messages when one is flagged as a BBS, etc. causes issues with
BBS forwarding. Systems such as pc/FlexNet don't allow for prompt changing
yet there's no issue with BBS hopping from one flexnet node to another
even though the prompt is fixed at "=>" because there's no line feed after
the ">". While customizing one's BBS and other services is a nice thing
to be able to do, we need to keep in mind how certain things work and
why they work the way they do.
What this all however does NOT explain is how some messages are coming
through with the subject line changed to F> which is a reverse forward
request. In order for a forwarded mail message received to get altered
this would have to occur within the software of the BBS that received
and altered that message... most likely a varable out of place somewhere.
On another note, on that same website that LU9DCE received his information
from it talks about KEEPLV frames to keep a circuit open. This is being
done totally backwards because it's using the OSI Layer 4 (NetRom) to
keep an OSI Layer 3 (ax.25) virtual circuit alive. Ax.25 can handle this
by itself while using less bytes per frame rather than sending the full
ax25 protocol overhead + NetRom protocol overhead + data segment overhead.
This is controlled with the "ax25 t3 timeout" setting.
ax.25's T3 setting will send a plain ax.25 "ping" while the virtual circuit
is established to insure the remote end is still alive and connected. If
the remote end has died, the circuit will close after retries have exhausted.
Otherwise the link will continue to poll itself in the number of seconds
specified in T3 until the link has been determined exhausted in an idle
state to where the link will then be closed due to inactivity.
If the path is still valid, it will only take a second to re-establish
the virtual circuit to pass NetRom through again, otherwise there's no need
to use up one's finals in their radios for something that hasn't been in
use for possibly hours.
73 de N1URO
---
SendBBS v1.1 by N1URO for LinFBB
Read previous mail | Read next mail
| |
