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) .