Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!news.kei.com!news.mathworks.com!newscaster-1.mcast.net!cs.tu-berlin.de!zrz.TU-Berlin.DE!news.tu-chemnitz.de!irz401!orion.sax.de!uriah.heep!news From: j@uriah.heep.sax.de (J Wunsch) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: ping works, telnet won't Date: 8 Jul 1996 20:56:07 GMT Organization: Private BSD site, Dresden Lines: 35 Message-ID: <4rrsl7$1eu@uriah.heep.sax.de> References: <4r2kho$f5p@agate.berkeley.edu> <4r3gkm$s7j@uriah.heep.sax.de> <4requk$npt@atlas.uniserve.com> <4rg5dr$539@symiserver2.symantec.com> Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) NNTP-Posting-Host: localhost.heep.sax.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: knews 0.9.6 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E tedm@agora.rdrop.com wrote: > My theory is that the sio.c driver in FreeBSD is probably written for just a > few 16550A chipsets, such as SMC's, the original (Nationals) etc and hasn't > been tested and debugged thoroughly on the cheaper and crummier chipsets, > as a result the driver/chipset combination is dropping characters somewhere. That's a bit unfair to the author of sio, in particular since you apparently neither know him nor attempted to approach him on this. ;-) There are far too many broken UART combos around, and some of the bugs can only be poorly worked around. I think Bruce Evans' worst offender is the UMC 8669F chipset, which unavoidably loses sync when its divider is being reprogrammed while data are coming in. One would tolerate that it loses _characters_ in this case, but it should re-synchronize to the data stream at least at the next start bit. Apparently, Taylor-UUCP reprograms the clock divider quite often, as a side-effect of a bunch of tcsetattr() calls. That's why you seen the UMC chip fail to run Taylor-UUCP while it can e.g. transfer data with z-modem protocol fine. Of course, this wouldn't justify the reported case where a SLIP or PPP connection works for ICMP and UDP, but fails for TCP only. That's almost every time either T/TCP, or (as i've been corrected) VJ header compression where the remote peer wouldn't anticipate it. The latter can only happen with SLIP, since VJ compression is subject of negotiation for PPP. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)