Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!sol.ctr.columbia.edu!news.kei.com!news.byu.edu!cwis.isu.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: Problems with patchkit 0.2.4 Message-ID: <1993Jul29.032615.9906@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <BLYMN.93Jul25173659@siren.awadi.com.au> <1993Jul25.220104.13519@fcom.cc.utah.edu> <BLYMN.93Jul28182459@siren.awadi.com.au> Date: Thu, 29 Jul 93 03:26:15 GMT Lines: 84 In article <BLYMN.93Jul28182459@siren.awadi.com.au> blymn@awadi.com.au (Brett Lymn) writes: >I do not know if it was changed by CGD or what but CTS/RTS >flow-control works fine with the setup I have (dataplex modem/386bsd >0.1/CGD com-beta patches...old I know but it works) The CGD stuff isn't supported and has been deprecated (by the author). The new stuff is still fuzzy around the edges. >Why buy MNP? IMHO it has too many problems to be worth it. Apart ^^^^^^^^^^^ >from, as you correctly state, the implementation varying between >manufacturers (I have experienced some MNP5 modems not talking to each >other at all) but also MNP will happily compress the data irrespective >of whether the data size is increased by the compression or not. Much >better to get a v.42bis modem, they seem more reliable (from my ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >experience) and do not try to compress uncompressible data. Besides >from what I see of the modem market MNP is a bit passe most high end >ones support v.42bis. As for in-band flow control, I have an option >on my modem to turn it off, I have done so. Ask yourself "What standard do they use in v.32-BIS and v.42-BIS modems to do their compressing?". This statement actually becomes kinda funny. >TL> In any case, it is not safe to use CTS/RTS flow control until the driver >TL> has been fixed, and it hasn't been fixed yet. When* it has been fixed, >TL> *then* your advice will be applicable. > >Ummmm depends, the problem you stated is correct if you are accepting >incoming calls on a 386bsd system with a compressing modem. In this >case I agree there is a possibility of a security problem BUT I only >use my modem for outbound v.42bis slip traffic. I can see no problem >with this. It's not just the security problem of someone else getting your session, there's the "hang forever" and "stuck at a bad baud rate" problems, too. >TL> Until then, don't set the connection to the modem to 19200 baud unless you >TL> *know* the modem will *always* be able to push 1920 characters a second >TL> down the line. > >I run my link at 38400 (I have a 16550 and some com patches). I was >able to quite easily destroy my slip link by attempting to ftp stuff >from my home machine to work without flow control - the ftp would just >hang and time out. With CTS/RTS flow control I can run my link at >38400 without problems (In fact I have a friend with a DOS box that >had the same problems using z-modem, the same fix worked for him) With all due respect, if you are running 38400 baud and you trigger flow control (even once) then you aren't running 38400 baud. >I think you need to qualify your advice Terry. From what you said >RTS/CTS on an incoming line could be a BAD THING, I can see not >problem with using it on an exclusively out-going line. Comments? An outgoing line where carrier is dropped due to a line glitch (for instance, you may have forgotten to stop call waiting or there might be a storm in the area). There is no way to talk to the modem until it reasserts CTS, and it won't do that until you dial out again because you didn't drop DTR to the modem because you didn't see the DCD drop from the modem because you are stuck waiting for CTS. Qualified enough? Of course this is nothing compared to the UUCP O_EXCL flag bug in the old SVR3 kernel in sys2.c (in the dup code), where the dup'ed fd is invalid, even though O_EXCL is only supposed to apply to exclusive use by the current process, not exclusive between opens in the process. Luckily, I have argued long and loud for the serial driver keeping its calling unit devices so that this isn't an issue in 386BSD (which has a similar bug). I've only been working in UNIX async for 11 years, but it seems pretty clear to me that you can't trust a serial driver to be 100% reliable for the duration of your equipment power if it has states that it can get into where a starvation deadlock is possible. Your use is assuming its reliability. There will eventually be a version where starvation deadlock is not possible with CTS/RTS enabled, but it's not this version. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.