Subj : SBBS/W32 Kermit SABOTAGE
To : STEPHEN HURD
From : MICHEL SAMSON
Date : Wed Nov 17 2004 12:32 pm
Hi Stephen,
About "SBBS/W32 Kermit SABOTAGE" of November 16:
SH> ...I'm wondering...
MS> Stop wondering...
http://public.sogetel.net/bicephale/MSK.INI
SH> ...I added a link to the kermit docs as shipped with Synchronet.
MS> This economy of words tells a lot about your so called "honesty"...
MS> Remember `Kermit.INI v1.5' of October 17?... ...still unchanged...
SH> That will be there forever. It's CVS. Are we done with this now?
How convenient... I'm supposed to believe you have no control over
the content of your Hard-Disks and there's no way to erase any *TRASH*?!
%-o
SH> ...breaking "kermit" because the interface is somehow "weak". [?]
MS} Wrong... ...his decision made him responsible for disabling some of
MS} the `Kermit' features... I also informed him that hanged sessions
MS} fail to be detected... ...message-pointer UpDating may be wrong...
MS} ...users are at risk to be kept out of an `SBBS' system for a day.
MS> This matter of a weak external protocol-driver interface only makes
MS> things worst as he won't even try to address it but `Kermit' was
MS> made crippled because of "fluff" he has rejected...
MP> If goofing up the setup could result in these things, they sound
MP> like good reasons not to risk setting up Kermit at all.
MS} That's why i refer to Rob Swindell's `Kermit.INI' as SABOTAGE!
MS> The `MS-Kermit.EXE' external file-transfer protocol-driver isn't
MS> involved... This `SBBS' issue is out of my hands...
SD> I can't seem to make sense out of this statement...
It's no surprize, one must be somewhat biased to distort statements
like you did but i may have detected a sign of hope later in your reply.
SD> SBBS must retain control of the socket... Sockets have no concept
SD> of a carrier... ...Honest, that's how TCP works...
A "Socket"!? What "Socket"? There's just no "Socket" when drivers
are considered from a ~FOSSIL~ environment perspective!... Guess again.
SD> If the problem is in fact a carrier hang, the problem is with the
SD> FOSSIL driver not the kermit setup.
I can agree on something, at last! `MS-Kermit.EXE' isn't involved,
just lets not take for granted ~FOSSIL~ layer problems alone can explain
why the "CARRIER" signal hangs, though. You appear to get the point: i
simply stated that the hanged "CARRIER" problem occurs at Rob's SoftWare
level... In other words, the external protocol drivers (`MS-Kermit.EXE'
included) only react to the (simulated) "CARRIER" condition accordingly.
If you take a look at `Kermit.INI v1.3' of October 12 you'll find a
real-life application illustrating what i refer to: "Set Port Fossil 1"
combined to "Set Carrier On", so far so good! It happens that `MSK.INI'
of November 16 also has the very same settings, but with a nuance in the
implementation sequence and the comments... Rob doesn't set the port to
~FOSSIL~ early, i do; we both "Set Carrier On", nonetheless. Rob has a
side-line note saying "Recover from HangUps IMMEDIATELY" but notice that
there's a significant difference in my comment as mine says "Immediately
recover from hangups if well supported in the BBS program", to be exact.
^^
SD) These same unspecified results...
^^^^^^^^^^^
Hummm... As if i never wrote a word! Well, i notice you discarded
the part which i re-inserted in a quote above (lines eighteen to twenty-
one, inclusively)!!! Some special people who can't stop themselves from
banging on the walls will appreciate the following distraction, i guess.
;->
Rob's comment is "misleading" at best if one reads in `Kermit.INI':
"Set Flow None", followed by "No flow control (this is handled by TCP)"!
^^^
8^o
As far as external file-transfer protocol-drivers are concerned, it
has nothing to do with Flow-Control done at other levels: if a SysOp is
using `COM/IP' and it's set for ~RTS~/~CTS~ Flow-Control then the advice
i'd find appropriate would be to revise the .INI and set it accordingly.
This is why `MSK.INI' says "Seems OKay for this particular use": i
never got an opportunity to put `MSK.INI' to test when i submitted it to
the attention of Rob Swindell on July, 2003, to say the least - he seems
to think he's omnipotent enough to decide what qualifies as "Ready-Made"
before tests are over but i don't (i'm only an ordinary user after all)!
The comment in Rob's `Kermit.INI' is valid only when `MS-Kermit' is
communicating with a DOS InterNet interface, like `Waterloo-TCP' packet-
drivers, a Novell ~ODI~ setup, etc., and which would mean using INTERNAL
~TelNet~ support. There's no reference to speed or, euh... ~TCP~/~IP~,
euh... because the port is set to ~FOSSIL~. Isn't that simple enough?!
Now, back to "unspecified" stuff, after this educative interlude...
%-b,
SD> More on this later... ...given that a largeish number of Synchronet
SD> BBSs run a largeish number of FOSSIL doors regularily...
Oups, your time is over!... You've got fifteen months to check it.
Salutations,
Michel Samson
a/s Bicephale
... Rob's SBBS/Kermit: spend spare-time just to probe weak interfacing!
--- MultiMail/MS-DOS v0.45 - Who votes for UNIVERSAL TelNet OLMR BBSing?
* Origin: BBS Networks @ www.bbsnets.com 808-839-6036 (1:10/345)