1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243253263273283293303313323333343353363373383393403413423433443453463473483493503513523533543553563573583593603613623633643653663673683693703713723733743753763773783793803813823833843853863873883893903913923933943953963973983994004014024034044054064074084094104114124134144154164174184194204214224234244254264274284294304314324334344354364374384394404414424434444454464474484494504514524534544554564574584594604614624634644654664674684694704714724734744754764774784794804814824834844854864874884894904914924934944954964974984995005015025035045055065075085095105115125135145155165175185195205215225235245255265275285295305315325335345355365375385395405415425435445455465475485495505515525535545555565575585595605615625635645655665675685695705715725735745755765775785795805815825835845855865875885895905915925935945955965975985996006016026036046056066076086096106116126136146156166176186196206216226236246256266276286296306316326336346356366376386396406416426436446456466476486496506516526536546556566576586596606616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929939949959969979989991000100110021003100410051006100710081009101010111012101310141015101610171018101910201021102210231024102510261027102810291030103110321033103410351036103710381039104010411042104310441045104610471048104910501051105210531054105510561057105810591060106110621063106410651066106710681069107010711072107310741075107610771078107910801081108210831084108510861087108810891090109110921093109410951096109710981099110011011102110311041105110611071108110911101111111211131114111511161117111811191120112111221123112411251126112711281129113011311132113311341135113611371138113911401141114211431144114511461147114811491150115111521153115411551156115711581159116011611162116311641165116611671168116911701171117211731174117511761177117811791180118111821183118411851186118711881189119011911192119311941195119611971198119912001201120212031204120512061207120812091210121112121213121412151216121712181219122012211222122312241225122612271228122912301231123212331234123512361237123812391240124112421243124412451246124712481249125012511252125312541255125612571258125912601261126212631264126512661267126812691270127112721273127412751276127712781279128012811282128312841285128612871288128912901291129212931294129512961297129812991300130113021303130413051306130713081309131013111312131313141315131613171318131913201321132213231324132513261327132813291330133113321333133413351336133713381339134013411342134313441345134613471348134913501351135213531354135513561357135813591360136113621363136413651366136713681369137013711372137313741375137613771378137913801381138213831384138513861387138813891390139113921393139413951396139713981399140014011402140314041405140614071408140914101411141214131414141514161417141814191420142114221423142414251426142714281429143014311432143314341435143614371438143914401441144214431444144514461447144814491450145114521453145414551456145714581459146014611462146314641465146614671468146914701471147214731474147514761477147814791480148114821483148414851486148714881489149014911492149314941495149614971498149915001501150215031504150515061507150815091510151115121513151415151516151715181519152015211522152315241525152615271528152915301531153215331534153515361537153815391540154115421543154415451546154715481549155015511552155315541555155615571558155915601561156215631564156515661567156815691570157115721573157415751576157715781579158015811582158315841585158615871588158915901591159215931594159515961597159815991600160116021603160416051606160716081609161016111612161316141615161616171618161916201621162216231624162516261627162816291630163116321633163416351636163716381639164016411642164316441645164616471648164916501651165216531654165516561657165816591660166116621663166416651666166716681669167016711672167316741675167616771678167916801681168216831684168516861687168816891690169116921693169416951696169716981699170017011702170317041705170617071708170917101711171217131714171517161717171817191720172117221723172417251726172717281729173017311732173317341735173617371738173917401741174217431744174517461747174817491750175117521753175417551756175717581759176017611762176317641765176617671768176917701771177217731774177517761777177817791780178117821783178417851786178717881789179017911792179317941795179617971798179918001801180218031804180518061807180818091810181118121813181418151816181718181819182018211822182318241825182618271828182918301831183218331834183518361837183818391840184118421843184418451846184718481849185018511852185318541855185618571858185918601861186218631864186518661867186818691870187118721873187418751876187718781879188018811882188318841885188618871888188918901891189218931894189518961897189818991900190119021903190419051906190719081909191019111912191319141915191619171918191919201921192219231924192519261927192819291930193119321933193419351936193719381939194019411942194319441945194619471948194919501951195219531954195519561957195819591960196119621963196419651966196719681969197019711972197319741975197619771978197919801981198219831984198519861987198819891990199119921993199419951996199719981999200020012002200320042005200620072008200920102011201220132014201520162017201820192020202120222023202420252026202720282029203020312032203320342035203620372038203920402041204220432044204520462047204820492050205120522053205420552056205720582059206020612062206320642065206620672068206920702071207220732074207520762077207820792080208120822083208420852086208720882089209020912092209320942095209620972098209921002101210221032104210521062107210821092110211121122113211421152116211721182119212021212122212321242125212621272128212921302131213221332134213521362137213821392140214121422143214421452146214721482149215021512152215321542155215621572158215921602161216221632164216521662167216821692170217121722173217421752176217721782179218021812182218321842185218621872188218921902191219221932194219521962197219821992200220122022203220422052206220722082209221022112212221322142215221622172218221922202221222222232224222522262227222822292230223122322233223422352236223722382239224022412242224322442245224622472248224922502251225222532254225522562257225822592260226122622263226422652266226722682269227022712272227322742275227622772278227922802281228222832284228522862287228822892290229122922293229422952296229722982299230023012302230323042305230623072308230923102311231223132314231523162317231823192320232123222323232423252326232723282329233023312332233323342335233623372338233923402341234223432344234523462347234823492350235123522353235423552356235723582359236023612362236323642365236623672368236923702371237223732374237523762377237823792380238123822383238423852386238723882389239023912392239323942395239623972398239924002401240224032404240524062407240824092410241124122413241424152416241724182419242024212422242324242425242624272428242924302431243224332434243524362437243824392440244124422443244424452446244724482449245024512452245324542455245624572458245924602461246224632464246524662467246824692470247124722473247424752476247724782479248024812482248324842485248624872488248924902491249224932494249524962497249824992500250125022503250425052506250725082509251025112512251325142515251625172518251925202521252225232524252525262527252825292530253125322533253425352536253725382539254025412542254325442545254625472548254925502551255225532554255525562557255825592560256125622563256425652566256725682569257025712572257325742575257625772578257925802581258225832584258525862587258825892590259125922593259425952596259725982599260026012602260326042605260626072608260926102611261226132614261526162617261826192620262126222623262426252626262726282629263026312632263326342635263626372638263926402641264226432644264526462647264826492650265126522653265426552656265726582659266026612662266326642665266626672668266926702671267226732674267526762677267826792680268126822683268426852686268726882689269026912692269326942695269626972698269927002701270227032704270527062707270827092710271127122713271427152716271727182719272027212722272327242725272627272728272927302731273227332734273527362737273827392740274127422743274427452746274727482749275027512752275327542755275627572758275927602761276227632764276527662767276827692770277127722773277427752776277727782779278027812782278327842785278627872788278927902791279227932794279527962797279827992800280128022803280428052806280728082809281028112812281328142815281628172818281928202821282228232824282528262827282828292830283128322833283428352836283728382839284028412842284328442845284628472848284928502851285228532854285528562857285828592860286128622863286428652866286728682869287028712872287328742875287628772878287928802881288228832884288528862887288828892890289128922893289428952896289728982899290029012902290329042905290629072908290929102911291229132914291529162917291829192920292129222923292429252926292729282929293029312932293329342935293629372938293929402941294229432944294529462947294829492950295129522953295429552956295729582959296029612962296329642965296629672968296929702971297229732974297529762977297829792980298129822983298429852986298729882989299029912992299329942995299629972998299930003001300230033004300530063007300830093010301130123013301430153016301730183019302030213022302330243025302630273028302930303031303230333034303530363037303830393040304130423043304430453046304730483049305030513052305330543055305630573058305930603061306230633064306530663067306830693070307130723073307430753076307730783079308030813082308330843085308630873088308930903091309230933094309530963097309830993100310131023103310431053106310731083109311031113112311331143115311631173118311931203121312231233124312531263127312831293130313131323133313431353136313731383139314031413142314331443145314631473148314931503151315231533154315531563157315831593160316131623163316431653166316731683169317031713172317331743175317631773178317931803181318231833184318531863187318831893190319131923193319431953196319731983199320032013202320332043205320632073208320932103211321232133214321532163217321832193220322132223223322432253226322732283229323032313232323332343235323632373238323932403241324232433244324532463247324832493250325132523253325432553256325732583259326032613262326332643265326632673268326932703271327232733274327532763277327832793280328132823283328432853286328732883289329032913292329332943295329632973298329933003301330233033304330533063307330833093310331133123313331433153316331733183319332033213322332333243325332633273328332933303331333233333334333533363337333833393340334133423343334433453346334733483349335033513352335333543355335633573358335933603361336233633364336533663367336833693370337133723373337433753376337733783379338033813382338333843385338633873388338933903391339233933394339533963397339833993400340134023403340434053406340734083409341034113412341334143415341634173418341934203421342234233424342534263427342834293430343134323433343434353436343734383439344034413442344334443445344634473448344934503451345234533454345534563457345834593460346134623463346434653466346734683469347034713472347334743475347634773478347934803481348234833484348534863487348834893490349134923493349434953496349734983499350035013502350335043505350635073508350935103511351235133514351535163517351835193520352135223523352435253526352735283529353035313532353335343535353635373538353935403541354235433544354535463547354835493550355135523553355435553556355735583559356035613562356335643565356635673568356935703571357235733574357535763577357835793580358135823583358435853586358735883589359035913592359335943595359635973598359936003601360236033604360536063607360836093610361136123613361436153616361736183619362036213622362336243625362636273628362936303631363236333634363536363637363836393640364136423643364436453646364736483649365036513652365336543655365636573658365936603661366236633664366536663667366836693670367136723673367436753676367736783679368036813682368336843685368636873688368936903691369236933694369536963697369836993700370137023703370437053706370737083709371037113712371337143715371637173718371937203721372237233724372537263727372837293730373137323733373437353736373737383739374037413742374337443745374637473748374937503751375237533754375537563757375837593760376137623763376437653766376737683769377037713772377337743775377637773778377937803781378237833784378537863787378837893790379137923793379437953796379737983799380038013802380338043805380638073808380938103811381238133814381538163817381838193820382138223823382438253826382738283829383038313832383338343835383638373838383938403841384238433844384538463847384838493850385138523853385438553856385738583859386038613862386338643865386638673868386938703871387238733874387538763877387838793880388138823883388438853886388738883889389038913892389338943895389638973898389939003901390239033904390539063907390839093910391139123913391439153916391739183919392039213922392339243925392639273928392939303931393239333934393539363937393839393940394139423943394439453946394739483949395039513952395339543955395639573958395939603961396239633964396539663967396839693970397139723973397439753976397739783979398039813982398339843985398639873988398939903991399239933994399539963997399839994000400140024003400440054006400740084009401040114012401340144015401640174018401940204021402240234024402540264027402840294030403140324033403440354036403740384039404040414042404340444045404640474048404940504051405240534054405540564057405840594060406140624063406440654066406740684069407040714072407340744075407640774078407940804081408240834084408540864087408840894090409140924093409440954096409740984099410041014102410341044105410641074108410941104111411241134114411541164117411841194120412141224123412441254126412741284129413041314132413341344135413641374138413941404141414241434144414541464147414841494150415141524153415441554156415741584159416041614162416341644165416641674168416941704171417241734174417541764177417841794180418141824183418441854186418741884189419041914192419341944195419641974198419942004201420242034204420542064207420842094210421142124213421442154216421742184219422042214222422342244225422642274228422942304231423242334234423542364237423842394240424142424243424442454246424742484249425042514252425342544255425642574258425942604261426242634264426542664267426842694270427142724273427442754276427742784279428042814282428342844285428642874288428942904291429242934294429542964297429842994300430143024303430443054306430743084309431043114312431343144315431643174318431943204321432243234324432543264327432843294330433143324333433443354336433743384339434043414342434343444345434643474348434943504351435243534354435543564357435843594360436143624363436443654366436743684369437043714372437343744375437643774378437943804381438243834384438543864387438843894390439143924393439443954396439743984399440044014402440344044405440644074408440944104411441244134414441544164417441844194420442144224423442444254426442744284429443044314432443344344435443644374438443944404441444244434444444544464447444844494450445144524453445444554456445744584459446044614462446344644465446644674468446944704471447244734474447544764477447844794480448144824483448444854486448744884489449044914492449344944495449644974498449945004501450245034504450545064507450845094510451145124513451445154516451745184519452045214522452345244525452645274528452945304531453245334534453545364537453845394540454145424543454445454546454745484549455045514552455345544555455645574558455945604561456245634564456545664567456845694570457145724573457445754576457745784579458045814582458345844585458645874588458945904591459245934594459545964597459845994600460146024603460446054606460746084609461046114612461346144615461646174618461946204621462246234624462546264627462846294630463146324633463446354636463746384639464046414642464346444645464646474648464946504651465246534654465546564657465846594660466146624663466446654666466746684669467046714672467346744675467646774678467946804681468246834684468546864687468846894690469146924693469446954696469746984699470047014702470347044705470647074708470947104711471247134714471547164717471847194720472147224723472447254726472747284729473047314732473347344735 |
- [1]The Columbia Crown The Kermit Project | Columbia University
- 612 West 115th Street, New York NY 10025 USA o [2]kermit@columbia.edu
- ...since 1981
- [3]Home [4]Kermit 95 [5]C-Kermit [6]Scripts [7]Current [8]New [9]FAQ
- [10]Support
- C-Kermit Unix Hints and Tips
- Frank da Cruz
- [11]The Kermit Project, [12]Columbia University
- As of: C-Kermit 9.0.302, 20 August 2011
- This page last updated: Sun Aug 21 12:08:52 2011 (New York USA Time)
- IF YOU ARE READING A PLAIN-TEXT version of this document, note it is
- a plain-text dump of a Web page. You can visit the original (and
- possibly more up-to-date) Web page here:
- [13]http://www.columbia.edu/kermit/ckubwr.html
- Since the material in this file has been accumulating since 1985,
- some (much) of it might be dated.
- Known problems with C-Kermit 9.0
- * Domain name resolution does not work in Solaris 10 or 11 (fixed in
- [14]9.0.301).
- * UUCP lockfile failure in FreeBSD 8 (fixed in [15]9.0.302).
- * Build failure FreeBSD 9 (fixed in [16]9.0.302).
- * Opening new SSH sessions after closing previous ones sometimes
- fails.
- * Heimdal Kerberos not supported.
- [ [17]C-Kermit ] [ [18]Installation Instructions ] [ [19]TUTORIAL ]
- CONTENTS
- 1. [20]INTRODUCTION
- 2. [21]PREBUILT C-KERMIT BINARIES
- 3. [22]PLATFORM-SPECIFIC NOTES
- 4. [23]GENERAL UNIX-SPECIFIC LIMITATIONS AND BUGS
- 5. [24]INITIALIZATION AND COMMAND FILES
- 6. [25]COMMUNICATION SPEED SELECTION
- 7. [26]COMMUNICATIONS AND DIALING
- 8. [27]HARDWARE FLOW CONTROL
- 9. [28]TERMINAL CONNECTION AND KEY MAPPING
- 10. [29]FILE TRANSFER
- 11. [30]EXTERNAL FILE TRANSFER PROTOCOLS
- 12. [31]SECURITY
- 13. [32]MISCELLANEOUS USER REPORTS
- 14. [33]THIRD-PARTY DRIVERS
- Quick Links: [ [34]Linux ] [ [35]*BSD ] [[36]Mac OS X] [ [37]AIX ] [
- [38]HP-UX ] [ [39]Solaris ] [ [40]SCO ]
- 1. INTRODUCTION
- [ [41]Top ] [ [42]Contents ] [ [43]Next ]
- SECTION CONTENTS
- 1.1. [44]Documentation
- 1.2. [45]Technical Support
- 1.3. [46]The Year 2000
- 1.4. [47]The Euro
- THIS IS WHAT USED TO BE CALLED the "beware file" for the Unix version
- of C-Kermit, previously distributed as ckubwr.txt and, before that, as
- ckuker.bwr, after the fashion of old Digital Equipment Corporation
- (DEC) software releases that came with release notes (describing what
- had changed) and a "beware file" listing known bugs, limitations,
- "non-goals", and things to watch out for. The C-Kermit beware file has
- been accumulating since 1985, and it applies to many different hardware
- platforms and operating systems, and many versions of them, so it is
- quite large. Prior to C-Kermit 8.0, it was distributed only in
- plain-text format. Now it is available as a Web document with links,
- internal cross references, and so on, to make it easier to use.
- This document applies to Unix C-Kermit in general, as well as to
- specific Unix variations like [48]Linux, [49]AIX, [50]HP-UX,
- [51]Solaris, and so on, and should be read in conjunction with the
- [52]platform-independent C-Kermit beware file, which contains similar
- information, but applying to all versions of C-Kermit (VMS, Windows,
- OS/2, AOS/VS, VOS, etc, as well as to Unix).
- There is much in this document that is (only) of historical interest.
- The navigation links should help you skip directly to the sections that
- are relevant to you. Numerous offsite Web links are supposed to lead to
- further information but, as you know, Web links go stale frequently and
- without warning. If you can supply additional, corrected, updated, or
- better Web links, please feel free to [53]let me know.
- 1.1. Documentation
- [ [54]Top ] [ [55]Contents ] [ [56]Next ]
- C-Kermit 6.0 is documented in the book [57]Using C-Kermit, Second
- Edition, by Frank da Cruz and Christine M. Gianone, Digital Press,
- Burlington, MA, USA, ISBN 1-55558-164-1 (1997), 622 pages. This remains
- the definitive C-Kermit documentation. Until the third edition is
- published (sorry, there is no firm timeframe for this), please also
- refer to:
- [58]Supplement to Using C-Kermit, Second Edition, For C-Kermit 7.0
- Thorough documentation of features new to version 7.0.
- [59]Supplement to Using C-Kermit, Second Edition, For C-Kermit 8.0
- Thorough documentation of features new to version 8.0.
- [60]Supplement to Using C-Kermit, Second Edition, For C-Kermit 9.0
- Thorough documentation of features new to version 9.0.
- 1.2. Technical Support
- [ [61]Top ] [ [62]Contents ] [ [63]Section Contents ] [ [64]Next ] [
- [65]Previous ]
- For information on how to get technical support, please visit:
- [66]http://www.columbia.edu/kermit/support.html
- 1.3. The Year 2000
- [ [67]Top ] [ [68]Contents ] [ [69]Section Contents ] [ [70]Next ] [
- [71]Previous ]
- The Unix version of C-Kermit, release 6.0 and later, is "Year 2000
- compliant", but only if the underlying operating system is too. Contact
- your Unix operating system vendor to find out which operating system
- versions, patches, hardware, and/or updates are required. (Quite a few
- old Unixes are still in operation in the new millenium, but with their
- date set 28 years in the past so at least the non-year parts of the
- calendar are correct.)
- As of C-Kermit 6.0 (6 September 1996), post-millenium file dates are
- recognized, transmitted, received, and reproduced correctly during the
- file transfer process in C-Kermit's File Attribute packets. If
- post-millenium dates are not processed correctly on the other end, file
- transfer still takes place, but the modification or creation date of
- the received file might be incorrect. The only exception would be if
- the "file collision update" feature is being used to prevent
- unnecessary transfer of files that have not changed since the last time
- a transfer took place; in this case, a file might be transferred
- unnecessarily, or it might not be transferred when it should have been.
- Correct operation of the update feature depends on both Kermit programs
- having the correct date and time.
- Of secondary importance are the time stamps in the transaction and/or
- debug logs, and the date-related script programming constructs, such as
- \v(date), \v(ndate), \v(day), \v(nday), and perhaps also the
- time-related ones, \v(time) and \v(ntime), insofar as they might be
- affected by the date. The \v(ndate) is a numeric-format date of the
- form yyyymmdd, suitable for both lexical and numeric comparison and
- sorting: e.g. 19970208 or 20011231. If the underlying operating system
- returns the correct date information, these variables will have the
- proper values. If not, then scripts that make decisions based on these
- variables might not operate correctly.
- Most date-related code is based upon the C Library asctime() string,
- which always has a four-digit year. In Unix, the one bit of code in
- C-Kermit that is an exception to this rule is several calls to
- localtime(), which returns a pointer to a tm struct, in which the year
- is presumed to be expressed as "years since 1900". The code depends on
- this assumption. Any platforms that violate it will need special
- coding. As of this writing, no such platforms are known.
- Command and script programming functions that deal with dates use
- C-Kermit specific code that always uses full years.
- 1.4. The Euro
- [ [72]Top ] [ [73]Contents ] [ [74]Section Contents ] [ [75]Previous ]
- C-Kermit 7.0 and later support Unicode (ISO 10646), ISO 8859-15 Latin
- Alphabet 9, PC Code Page 858, Windows Code Pages 1250 and 1251, and
- perhaps other character sets, that encode the Euro symbol, and can
- translate among them as long as no intermediate character-set is
- involved that does not include the Euro.
- 2. PREBUILT C-KERMIT BINARIES
- [ [76]Top ] [ [77]Contents ] [ [78]Next ] [ [79]Previous ]
- It is often dangerous to run a binary C-Kermit (or any other) program
- built on a different computer. Particularly if that computer had a
- different C compiler, libraries, operating system version, processor
- features, etc, and especially if the program was built with shared
- libraries, because as soon as you update the libraries on your system,
- they no longer match the ones referenced in the binary, and the binary
- might refuse to load when you run it, in which case you'll see error
- messages similar to:
- Could not load program kermit
- Member shr4.o not found or file not an archive
- Could not load library libcurses.a[shr4.o]
- Error was: No such file or directory
- (These samples are from AIX.) To avoid this problem, we try to build
- C-Kermit with statically linked libraries whenever we can, but this is
- increasingly impossible as shared libraries become the norm.
- It is often OK to run a binary built on an earlier OS version, but it
- is rarely possible (or safe) to run a binary built on a later one, for
- example to run a binary built under Solaris 8 on Solaris 2.6. Sometimes
- even the OS-or-library patch/ECO level makes a difference.
- A particularly insidious problem occurs when a binary was built on a
- version of the OS that has patches from the vendor (e.g. to libraries);
- in many cases you won't be able to run such a binary on an unpatched
- version of the same platform.
- When in doubt, build C-Kermit from the source code on the computer
- where it is to be run (if possible!). If not, ask us for a binary
- specific to your configuration. We might have one, and if we don't, we
- might be able to find somebody who will build one for you.
- 3. NOTES ON SPECIFIC UNIX VERSIONS
- [ [80]Top ] [ [81]Contents ] [ [82]Next ] [ [83]Previous ]
- SECTION CONTENTS
- 3.0. [84]C-KERMIT ON PC-BASED UNIXES
- 3.1. [85]C-KERMIT AND AIX
- 3.2. [86]C-KERMIT AND HP-UX
- 3.3. [87]C-KERMIT AND LINUX
- 3.4. [88]C-KERMIT AND NEXTSTEP
- 3.5. [89]C-KERMIT AND QNX
- 3.6. [90]C-KERMIT AND SCO
- 3.7. [91]C-KERMIT AND SOLARIS
- 3.8. [92]C-KERMIT AND SUNOS
- 3.9. [93]C-KERMIT AND ULTRIX
- 3.10. [94]C-KERMIT AND UNIXWARE
- 3.11. [95]C-KERMIT AND APOLLO SR10
- 3.12. [96]C-KERMIT AND TANDY XENIX 3.0
- 3.13. [97]C-KERMIT AND OSF/1 (DIGITAL UNIX) (TRU64 UNIX)
- 3.14. [98]C-KERMIT AND SGI IRIX
- 3.15. [99]C-KERMIT AND THE BEBOX
- 3.16. [100]C-KERMIT AND DG/UX
- 3.17. [101]C-KERMIT AND SEQUENT DYNIX
- 3.18. [102]C-KERMIT AND {FREE,OPEN,NET}BSD
- 3.19. [103]C-KERMIT AND MAC OS X
- 3.20. [104]C-KERMIT AND COHERENT
- The following sections apply to specific Unix versions. Most of them
- contain references to FAQs (Frequently Asked Questions), but these tend
- to be ephemeral. For possibly more current information see:
- [105]http://www.faqs.org
- [106]http://aplawrence.com/Unixart/newtounix.html
- One thread that runs through many of them, and implicitly perhaps
- through all, concerns the problems that occur when trying to dial out
- on a serial device that is (also) enabled for dialing in. The
- "solutions" to this problem are many, varied, diverse, and usually
- gross, involving configuring the device for bidirectional use. This is
- done in a highly OS-dependent and often obscure manner, and the effects
- (good or evil) are also highly dependent on the particular OS (and
- getty variety, etc). Many examples are given in the [107]OS-specific
- sections below.
- An important point to keep in mind is that C-Kermit is a
- cross-platform, portable software program. It was not designed
- specifically and only for your particular Unix version, or for that
- matter, for Unix in particular at all. It also runs on VMS, AOS/VS,
- VOS, and other non-Unix platforms. All the Unix versions of C-Kermit
- share common i/o modules, with compile-time #ifdef constructions used
- to account for the differences among the many Unix products and
- releases. If you think that C-Kermit is behaving badly or missing
- something on your particular Unix version, you might be right -- we
- can't claim to be expert in hundreds of different OS / version /
- hardware / library combinations. If you're a programmer, take a look at
- the source code and [108]send us your suggested fixes or changes. Or
- else just [109]send us a report about what seems to be wrong and we'll
- see what we can do.
- 3.0. C-KERMIT ON PC-BASED UNIXES
- [ [110]Top ] [ [111]Contents ] [ [112]Section Contents ] [ [113]Next ]
- Also see: [114]http://www.pcunix.com/.
- SECTION CONTENTS
- 3.0.1. [115]Interrupt Conflicts
- 3.0.2. [116]Windows-Specific Hardware
- 3.0.3. [117]Modems
- 3.0.4. [118]Character Sets
- 3.0.5. [119]Keyboard, Screen, and Mouse Access
- 3.0.6. [120]Laptops
- 3.0.1. Interrupt Conflicts
- [ [121]Top ] [ [122]Contents ] [ [123]Section Contents ] [ [124]Next ]
- PCs are not the best platform for real operating systems like Unix. The
- architecture suffers from numerous deficiencies, not the least of which
- is the stiflingly small number of hardware interrupts (either 7 or 15,
- many of which are preallocated). Thus adding devices, using multiple
- serial ports, etc, is always a challenge and often a nightmare. The
- free-for-all nature of the PC market and the lack of standards combined
- with the diversity of Unix OS versions make it difficult to find
- drivers for any particular device on any particular version of Unix.
- Of special interest to Kermit users is the fact that there is no
- standard provision in the PC architecture for more than 2 communication
- (serial) ports. COM3 and COM4 (or higher) will not work unless you (a)
- find out the hardware address and interrupt for each, (b) find out how
- to provide your Unix version with this information, and (c) actually
- set up the configuration in the Unix startup files (or whatever other
- method is used). Watch out for interrupt conflicts, especially when
- using a serial mouse, and don't expect to be able to use more than two
- serial ports.
- The techniques for resolving interrupt conflicts are different for each
- operating system (Linux, NetBSD, etc). In general, there is a
- configuration file somewhere that lists COM ports, something like this:
- com0 at isa? port 0x3f8 irq 4 # DOS COM1
- com1 at isa? port 0x2f8 irq 3 # DOS COM2
- The address and IRQ values in this file must agree with the values in
- the PC BIOS and with the ports themselves, and there must not be more
- than one device with the same interrupt. Unfortunately, due to the
- small number of available interrupts, installing new devices on a PC
- almost always creates a conflict. Here is a typical tale from a Linux
- user (Fred Smith) about installing a third serial port:
- ...problems can come from a number of causes. The one I fought with
- for some time, and finally conquered, was that my modem is on an
- add-in serial port, cua3/IRQ5. By default IRQ5 has a very low
- priority, and does not get enough service in times when the system
- is busy to prevent losing data. This in turn causes many resends.
- There are two 'fixes' that I know of, one is to relax hard disk
- interrupt hogging by using the correct parameter to hdparm, but I
- don't like that one because the hdparm man page indicates it is
- risky to use. The other one, the one I used, was to get 'irqtune'
- and use it to give IRQ5 the highest priority instead of nearly the
- lowest. Completely cured the problem.
- Here's another one from a newsgroup posting:
- After much hair pulling, I've discovered why my serial port won't
- work. Apparently my [PC] has three serial devices (two comm ports
- and an IR port), of which only two at a time can be active. I looked
- in the BIOS setup and noticed that the IR port was activated, but
- didn't realize at the time that this meant that COM2 was thereby
- de-activated. I turned off the IR port and now the serial port works
- as advertised.
- 3.0.2. Windows-Specific Hardware
- [ [125]Top ] [ [126]Contents ] [ [127]Section Contents ] [ [128]Next ]
- [ [129]Previous ]
- To complicate matters, the PC platform is becoming increasingly and
- inexorably Windows-oriented. More and more add-on devices are "Windows
- only" -- meaning they are incomplete and rely on proprietary
- Windows-based software drivers to do the jobs that you would expect the
- device itself to do. PCMCIA, PCI, or "Plug-n-Play" devices are rarely
- supported on PC-based Unix versions such as SCO; Winmodems,
- Winprinters, and the like are not supported on any Unix variety (with
- [130]a few exceptions). The self-proclaimed Microsoft PC 97 (or later)
- standard only makes matters worse since its only purpose to ensure that
- PCs are "optimized to run Windows 95 and Windows NT 4.0 and future
- versions of these operating systems".
- With the exception noted (the Lucent modem, perhaps a handful of others
- by the time you read this), drivers for "Win" devices are available
- only for Windows, since the Windows market dwarfs that of any
- particular Unix brand, and for that matter all Unixes (or for that
- matter, all non-Windows operating systems) combined. If your version of
- Unix (SCO, Linux, BSDI, FreeBSD, etc) does not support a particular
- device, then C-Kermit can't use it either. C-Kermit, like any Unix
- application, must access all devices through drivers and not directly
- because Unix is a real operating system.
- Don't waste time thinking that you, or anybody else, could write a
- Linux (or other Unix) driver for a Winmodem or other "Win" device.
- First of all, these devices generally require realtime control, but
- since Unix is a true multitasking operating system, realtime device
- control is not possible outside the kernel. Second, the specifications
- for these devices are secret and proprietary, and each one (and each
- version of each one) is potentially different. Third, a Winmodem driver
- would be enormously complex; it would take years to write and debug, by
- which time it would be obsolete.
- A more recent generation of PCs (circa 1999-2000) is marketed as
- "Legacy Free". One can only speculate what that could mean. Most likely
- it means it will ONLY run the very latest versions of Windows, and is
- made exclusively of Winmodems, Winprinters, Winmemory, and Win-CPU-fans
- (Legacy Free is a concept [131]pioneered by Microsoft).
- Before you buy a new PC or add-on equipment, especially serial ports,
- internal modems, or printers, make sure they are compatible with your
- version of Unix. This is becoming an ever-greater challenge; only a
- huge company like Microsoft can afford to be constantly cranking out
- and/or verifying drivers for the thousands of video boards, sound
- cards, network adapters, SCSI adapters, buses, etc, that spew forth in
- an uncontrolled manner from all corners of the world on a daily basis.
- With very few exceptions, makers of PCs assemble the various components
- and then verify them only with Windows, which they must do since they
- are, no doubt, preloading the PC with Windows. To find a modern PC that
- is capable of running a variety of non-Windows operating systems (e.g.
- Linux, SCO OpenServer, Unixware, and Solaris) is a formidable challenge
- requiring careful study of each vendor's "compatibility lists" and
- precise attention to exact component model numbers and revision levels.
- 3.0.3. Modems
- [ [132]Top ] [ [133]Contents ] [ [134]Section Contents ] [ [135]Next ]
- [ [136]Previous ]
- External modems are recommended:
- * They don't need any special drivers.
- * You can use the lights and speaker to troubleshoot dialing.
- * You can share them among all types of computers.
- * You can easily turn them off and on when power-cycling seems
- warranted.
- * They are more likely to have manuals.
- Internal PC modems (even when they are not Winmodems, which is
- increasingly unlikely in new PCs) are always trouble, especially in
- Unix. Even when they work for dialing out, they might not work for
- dialing in, etc. Problems that occur when using an internal modem can
- almost always be eliminated by switching to an external one. Even when
- an internal modem is not a Winmodem or Plug-n-Play, it is often a
- no-name model of unknown quality -- not the sort of thing you want
- sitting directly on your computer's bus. (Even if it does not cause
- hardware problems, it probably came without a command list, so no Unix
- software will know how to control it.) For more about Unix compatible
- modems, see:
- [137]http://www.idir.net/~gromitkc/winmodem.html
- Remember that PCs, even now -- more than two decades after they were
- first introduced -- are not (in general) capable of supporting more
- than 2 serial devices. Here's a short success story from a recent
- newsgroup posting: "I have a Diamond SupraSonic II dual modem in my
- machine. What I had to end up doing is buying a PS/2 mouse and port and
- install it. Had to get rid of my serial mouse. I also had to disable
- PnP in my computer bios. I was having IRQ conflicts between my serial
- mouse and 'com 3'. Both modems work fine for me. My first modem is
- ttyS0 and my second is ttyS1." Special third-party multiport boards
- such as [138]DigiBoard are available for certain Unix platforms
- (typically SCO, maybe Linux) that come with special platform-specific
- drivers.
- 3.0.4. Character Sets
- [ [139]Top ] [ [140]Contents ] [ [141]Section Contents ] [ [142]Next ]
- [ [143]Previous ]
- PCs generally have PC code pages such as CP437 or CP850, and these are
- often used by PC-based Unix operating systems, particularly on the
- console. These are supported directly by C-Kermit's SET FILE
- CHARACTER-SET and SET TERMINAL CHARACTER-SET commands. Some PC-based
- Unix versions, such as recent Red Hat Linux releases, might also
- support Microsoft Windows code pages such as CP1252, or even Latin
- Alphabet 1 itself (perhaps displayed with CP437 glyphs). (And work is
- in progress to support Unicode UTF8 in Linux.)
- Certain Windows code pages are not supported directly by C-Kermit, but
- since they are ISO Latin Alphabets with nonstandard "extensions" in the
- C1 control range, you can substitute the corresponding Latin alphabet
- (or other character set) in any C-Kermit character-set related
- commands:
- Windows Code Page Substitution
- CP 1004 Latin-1
- CP 1051 HP Roman-8
- Other Windows code pages are mostly (or totally) incompatible with
- their Latin Alphabet counterparts (e.g. CP1250 and Latin-2), and
- several of these are already supported by C-Kermit 7.0 and later (1250,
- 1251, and 1252).
- 3.0.5. Keyboard, Screen, and Mouse Access
- [ [144]Top ] [ [145]Contents ] [ [146]Section Contents ] [ [147]Next ]
- [ [148]Previous ]
- Finally, note that as a real operating system, Unix (unlike Windows)
- does not provide the intimate connection to the PC keyboard, screen,
- and mouse that you might expect. Unix applications can not "see" the
- keyboard, and therefore can not be programmed to understand F-keys,
- Editing keys, Arrow keys, Alt-key combinations, and the like. This is
- because:
- a. Unix is a portable operating system, not only for PCs;
- b. Unix sessions can come from anywhere, not just the PC's own
- keyboard and screen; and:
- c. even though it might be possible for an application that actually
- is running on the PC's keyboard and screen to access these devices
- directly, there are no APIs (outside of X) for this.
- 3.0.6. Laptops
- [ [149]Top ] [ [150]Contents ] [ [151]Section Contents ] [
- [152]Previous ]
- (To be filled in . . .)
- 3.1. C-KERMIT AND AIX
- [ [153]Top ] [ [154]Contents ] [ [155]Section Contents ] [ [156]Next ]
- [ [157]Previous ]
- SECTION CONTENTS
- 3.1.1. [158]AIX: General
- 3.1.2. [159]AIX: Network Connections
- 3.1.3. [160]AIX: Serial Connections
- 3.1.4. [161]AIX: File Transfer
- 3.1.5. [162]AIX: Xterm Key Map
- For additional information see:
- * [163]http://www.emerson.emory.edu/services/aix-faq/
- * [164]http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html
- * [165]http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/top
- .html
- * [166]http://aixpdslib.seas.ucla.edu/
- * [167]http://www.rootvg.net (AIX history)
- * [168]ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1
- * [169]ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/a
- ix
- and/or read the [170]comp.unix.aix newsgroup.
- ________________________________________________________________________
- 3.1.1. AIX: General
- [ [171]Top ] [ [172]Contents ] [ [173]Section Contents ] [ [174]Next ]
- About AIX version numbers: "uname -a" tells the two-digit version
- number, such as 3.2 or 4.1. The three-digit form can be seen with the
- "oslevel" command (this information is unavailable at the API level and
- is reportedly obtained by scanning the installed patch list).
- Supposedly all three-digit versions within the same two-digit version
- (e.g. 4.3.1, 4.3.2) are binary compatible; i.e. a binary built on any
- one of them should run on all others, but who knows. Most AIX advocates
- tell you that any AIX binary will run on any AIX version greater than
- or equal to the one under which it was built, but experience with
- C-Kermit suggests otherwise. It is always best to run a binary built
- under your exact same AIX version, down to the third decimal place, if
- possible. Ideally, build it from source code yourself. Yes, this advice
- would be easier to follow if AIX came with a C compiler.
- ________________________________________________________________________
- 3.1.2. AIX: Network Connections
- [ [175]Top ] [ [176]Contents ] [ [177]Section Contents ] [ [178]Next ]
- [ [179]Previous ]
- File transfers into AIX 4.2 or 4.3 through the AIX Telnet or Rlogin
- server have been observed to fail (or accumulate huge numbers of
- correctable errors, or even disconnect the session), when exactly the
- same kind of transfers into AIX 4.1 work without incident, as do such
- transfers into all non-AIX platforms on the same kind of connections
- (with a few exceptions noted elsewhere in this document). AIX 4.3.3
- seems to be particularly fragile in this regard; the weakness seems to
- be in its pseudoterminal (pty) driver. High-speed streaming transfers
- work perfectly, however, if the AIX Telnet server and pty driver are
- removed from the picture; e.g, by using "set host * 3000" on AIX.
- The problem can be completely cured by replacing the IBM Telnet server
- with [180]MIT's Kerberos Telnet server -- even if you don't actually
- use the Kerberos part. Diagnosis: AIX pseudoterminals (which are
- controlled by the Telnet server to give you a login terminal for your
- session) have quirks that not even IBM knows about. The situation with
- AIX 5.x is not known, but if it has the same problem, the same cure is
- available.
- Meanwhile, the only remedy when going through the IBM Telnet server is
- to cut back on Kermit's performance settings until you find a
- combination that works:
- * SET STREAMING OFF
- * SET WINDOW-SIZE small-number
- * SET { SEND, RECEIVE } PACKET-LENGTH small-number
- * SET PREFIXING { CAUTIOUS, ALL }
- In some cases, severe cutbacks are required, e.g. those implied by the
- ROBUST command. Also be sure that the AIX C-Kermit on the remote end
- has "set flow none" (which is the default). NOTE: Maybe this one can
- also be addressed by starting AIX telnetd with the "-a" option. The
- situation with SSH connections is not known, but almost certainly the
- same.
- When these problems occur, the system error log contains:
- LABEL: TTY_TTYHOG
- IDENTIFIER: 0873CF9F
- Type: TEMP
- Resource Name: pts/1
- Description
- TTYHOG OVER-RUN
- Failure Causes
- EXCESSIVE LOAD ON PROCESSOR
- Recommended Actions
- REDUCE SYSTEM LOAD.
- REDUCE SERIAL PORT BAUD RATE
- Before leaving the topic of AIX pseudoterminals, it is very likely that
- Kermit's PTY and SSH commands do not work well either, for the same
- reason that Telnet connections into AIX don't work well. A brief test
- with "pty rlogin somehost" got a perfectly usable terminal (CONNECT)
- session, but file-transfer problems like those just described.
- Reportedly, telnet from AIX 4.1-point-something to non-Telnet ports
- does not work unless the port number is in the /etc/services file; it's
- not clear from the report whether this is a problem with AIX Telnet (in
- which case it would not affect Kermit), or with the sockets library (in
- which case it would). The purported fix is IBM APAR IX61523.
- C-Kermit SET HOST or TELNET from one AIX 3.1 (or earlier) system to
- another won't work right unless you set your local terminal type to
- something other than AIXTERM. When your terminal type is AIXTERM, AIX
- TELNET sends two escapes whenever you type one, and the AIX telnet
- server swallows one of them. This has something to do with the "hft"
- device. This behavior seems to be removed in AIX 3.2 and later.
- ________________________________________________________________________
- 3.1.3. AIX: Serial Connections
- [ [181]Top ] [ [182]Contents ] [ [183]Section Contents ] [ [184]Next ]
- [ [185]Previous ]
- In AIX 3, 4, or 5, C-Kermit won't be able to "set line /dev/tty0" (or
- any other dialout device) if you haven't installed "cu" or "uucp" on
- your system, because installing these is what creates the UUCP lockfile
- directory. If SET LINE commands always result in "Sorry, access to lock
- denied", even when C-Kermit has been given the same owner, group, and
- permissions as cu:
- -r-sr-xr-x 1 uucp uucp 67216 Jul 27 1999 cu
- and even when you run it as root, then you must go back and install
- "cu" from your AIX installation media.
- According to IBM's "From Strength to Strength" document (21 April
- 1998), in AIX 4.2 and later "Async supports speeds on native serial
- ports up to 115.2kbps". However, no API is documented to achieve serial
- speeds higher than 38400 bps. Apparently the way to do this -- which
- might or might not work only on the IBM 128-port multiplexer -- is:
- cxma-stty fastbaud /dev/tty0
- which, according to "man cxma-stty":
- fastbaud Alters the baud rate table, so 50 baud becomes 57600 baud.
- -fastbaud Restores the baud rate table, so 57600 baud becomes 50
- baud.
- Presumably (but not certainly) this extrapolates to 110 "baud" becomes
- 76800 bps, and 150 becomes 115200 bps. So to use high serial speeds in
- AIX 4.2 or 4.3, the trick would be to give the "cxma-stty fastbaud"
- command for the desired tty device before starting Kermit, and then use
- "set speed 50", "set speed 110", or "set speed 150" to select 56700,
- 76800, or 115200 bps. It is not known whether cxma-stty requires
- privilege.
- According to one report, "Further investigation with IBM seems to
- indicate that the only hardware capable of doing this is the 128-port
- multiplexor with one (or more) of the 16 port breakout cables (Enhanced
- Remote Async Node 16-Port EIA-232). We are looking at about CDN$4,000
- in hardware just to hang a 56kb modem on there. Of course, we can then
- hang 15 more, if we want. This hardware combo is described to be good
- to 230.4kbps."
- Another report says (quote from AIX newsgroup, March 1999):
- The machine type and the adapter determine the speed that one can
- actually run at. The older microchannel machines have much slower
- crystal frequencies and may not go beyond 76,800. A feature put into
- AIX 421 allows one to key in non-POSIX baud rates and if the uart
- can support that speed, it will get set. this applies also to 43p's
- and beyond. 115200 is the max for the 43P's native serial port. As
- crytal frequencies continue to increase, the built-in serial ports
- speeds will improve. To use 'uucp' or 'ate' at the higher baud
- rates, configure the port for the desired speed, but set the speed
- of uucp or ate to 50. Any non-POSIX speeds set in the ttys
- configuration will the be used. In the case of the 128-port adapters
- or the ISA 8-port or PCI 8-port adapter, there are only a few higher
- baud rates.
- a. Change the port to enable high baud rates:
- + B50 for 57600
- + B75 for 76800
- + B110 for 115200
- + B200 for 230000
- b. chdev -l ttyX -a fastbaud=enable
- + For the 128 ports original style rans, only 57600 bps is
- supported.
- + For the new enhanced RANs, up to 230Kbps is supported.
- In AIX 2.2.1 on the RT PC with the 8-port multiplexer, SET SPEED 38400
- gives 9600 bps, but SET SPEED 19200 gives 19200 (on the built-in S1
- port).
- Note that some RS/6000s (e.g. the IBM PowerServer 320) have nonstandard
- rectangular 10-pin serial ports; the DB-25 connector is NOT a serial
- port; it is a parallel printer port. IBM cables are required for the
- serial ports, (The IBM RT PC also had rectangular serial ports --
- perhaps the same as these, perhaps different.)
- If you dial in to AIX through a modem that is connected directly to an
- AIX port (e.g. on the 128-port multiplexer) and find that data is lost,
- especially when uploading files to the AIX system (and system error
- logs report buffer overruns on the port):
- 1. Make sure the port and modem are BOTH configured for hardware
- (RTS/CTS) flow control. The port is configured somewhere in the
- system configuration, outside of Kermit.
- 2. Tell C-Kermit to "set flow keep"; experimentation shows that SET
- FLOW RTS/CTS has no effect when used in remote mode (i.e. on
- /dev/tty, as opposed to a specify port device).
- 3. Fixes for bugs in the original AIX 4.2 tty (serial i/o) support and
- other AIX bugs are available from IBM at:
- [186]http://service.software.ibm.com/rs6000/
- Downloads -> Software Fixes -> Download FixDist gets an application
- for looking up known problems.
- Many problems reported with bidirectional terminal lines on AIX 3.2.x
- on the RS/6000. Workaround: don't use bidirectional terminal lines, or
- write a shell-script wrapper for Kermit that turns getty off on the
- line before starting Kermit, or before Kermit attempts to do the SET
- LINE. (But note: These problems MIGHT be fixed in C-Kermit 6.0 and
- later.) The commands for turning getty off and on (respectively) are
- /usr/sbin/pdisable and /usr/sbin/penable.
- ________________________________________________________________________
- 3.1.4. AIX: File Transfer
- [ [187]Top ] [ [188]Contents ] [ [189]Section Contents ] [ [190]Next ]
- [ [191]Previous ]
- Evidently AIX 4.3 (I don't know about earlier versions) does not allow
- open files to be overwritten. This can cause Kermit transfers to fail
- when FILE COLLISION is OVERWRITE, where they might work on other Unix
- varieties or earlier AIX versions.
- Transfer of binary -- and maybe even text -- files can fail in AIX if
- the AIX terminal has particular port can have character-set translation
- done for it by the tty driver. The following advice from a
- knowledgeable AIX user:
- [This feature] has to be checked (and set/cleared) with a separate
- command, unfortunately stty doesn't handle this. To check:
- $ setmaps
- input map: none installed
- output map: none installed
- If it says anything other than "none installed" for either one, it
- is likely to cause a problem with kermit. To get rid of installed
- maps:
- $ setmaps -t NOMAP
- However, I seem to recall that with some versions of AIX before
- 3.2.5, only root could change the setting. I'm not sure what
- versions - it might have only been under AIX 3.1 that this was true.
- At least with AIX 3.2.5 an ordinary user can set or clear the maps.
- On the same problem, another knowledgeable AIX user says:
- The way to get information on the NLS mapping under AIX (3.2.5
- anyway) is as follows. From the command line type:
- lsattr -l tty# -a imap -a omap -E -H
- Replace the tty number for the number sign above. This will give a
- human readable output of the settings that looks like this;
- # lsattr -l tty2 -a imap -a omap -E -H
- attribute value description user_settable
- imap none INPUT map file True
- omap none OUTPUT map file True
- If you change the -H to a -O, you get output that can easily be
- processed by another program or a shell script, for example:
- # lsattr -l tty2 -a imap -a omap -E -O
- #imap:omap
- none:none
- To change the settings from the command line, the chdev command is
- used with the following syntax.
- chdev -l tty# -a imap='none' -a omap='none'
- Again substituting the appropriate tty port number for the number
- sign, "none" being the value we want for C-Kermit. Of course, the
- above can also be changed by using the SMIT utility and selecting
- devices - tty. (...end quote)
- In 2007 I noticed the following on high-speed SSH connections (local
- network) into AIX 5.3: streaming transfers into AIX just don't work.
- The same might be true for Telnet connections; I have no way to check.
- It appears that the AIX pty driver and/or the SSH (and possibly Telnet)
- server are not capable of receiving a steady stream of incoming data at
- high speed. Solution: unknown. Workaround: put "set streaming off" in
- your .kermrc or .mykermrc file, since streaming is the default for
- network connections.
- ________________________________________________________________________
- 3.1.5. AIX: Xterm Key Map
- [ [192]Top ] [ [193]Contents ] [ [194]Section Contents ] [
- [195]Previous ]
- Here is a sample configuration for setting up an xterm keyboard for
- VT220 or higher terminal emulation on AIX, courtesy of Bruce Momjian,
- Drexel Hill, PA. Xterm can be started like this:
- xterm $XTERMFLAGS +rw +sb +ls $@ -tm 'erase ^? intr ^c' -name vt220 \
- -title vt220 -tn xterm-220 "$@" &
- ---------------------------------------------------------------------------
- XTerm*VT100.Translations: #override \n\
- <Key>Home: string(0x1b) string("[3~") \n \
- <Key>End: string(0x1b) string("[4~") \n
- vt220*VT100.Translations: #override \n\
- Shift <Key>F1: string("[23~") \n \
- Shift <Key>F2: string("[24~") \n \
- Shift <Key>F3: string("[25~") \n \
- Shift <Key>F4: string("[26~") \n \
- Shift <Key>F5: string("[K~") \n \
- Shift <Key>F6: string("[31~") \n \
- Shift <Key>F7: string("[31~") \n \
- Shift <Key>F8: string("[32~") \n \
- Shift <Key>F9: string("[33~") \n \
- Shift <Key>F10: string("[34~") \n \
- Shift <Key>F11: string("[28~") \n \
- Shift <Key>F12: string("[29~") \n \
- <Key>Print: string(0x1b) string("[32~") \n\
- <Key>Cancel: string(0x1b) string("[33~") \n\
- <Key>Pause: string(0x1b) string("[34~") \n\
- <Key>Insert: string(0x1b) string("[2~") \n\
- <Key>Delete: string(0x1b) string("[3~") \n\
- <Key>Home: string(0x1b) string("[1~") \n\
- <Key>End: string(0x1b) string("[4~") \n\
- <Key>Prior: string(0x1b) string("[5~") \n\
- <Key>Next: string(0x1b) string("[6~") \n\
- <Key>BackSpace: string(0x7f) \n\
- <Key>Num_Lock: string(0x1b) string("OP") \n\
- <Key>KP_Divide: string(0x1b) string("Ol") \n\
- <Key>KP_Multiply: string(0x1b) string("Om") \n\
- <Key>KP_Subtract: string(0x1b) string("OS") \n\
- <Key>KP_Add: string(0x1b) string("OM") \n\
- <Key>KP_Enter: string(0x1b) string("OM") \n\
- <Key>KP_Decimal: string(0x1b) string("On") \n\
- <Key>KP_0: string(0x1b) string("Op") \n\
- <Key>KP_1: string(0x1b) string("Oq") \n\
- <Key>KP_2: string(0x1b) string("Or") \n\
- <Key>KP_3: string(0x1b) string("Os") \n\
- <Key>KP_4: string(0x1b) string("Ot") \n\
- <Key>KP_5: string(0x1b) string("Ou") \n\
- <Key>KP_6: string(0x1b) string("Ov") \n\
- <Key>KP_7: string(0x1b) string("Ow") \n\
- <Key>KP_8: string(0x1b) string("Ox") \n\
- <Key>KP_9: string(0x1b) string("Oy") \n
- ! <Key>Up: string(0x1b) string("[A") \n\
- ! <Key>Down: string(0x1b) string("[B") \n\
- ! <Key>Right: string(0x1b) string("[C") \n\
- ! <Key>Left: string(0x1b) string("[D") \n\
- *visualBell: true
- *saveLines: 1000
- *cursesemul: true
- *scrollKey: true
- *scrollBar: true
- 3.2. C-KERMIT AND HP-UX
- [ [196]Top ] [ [197]Contents ] [ [198]Section Contents ] [ [199]Next ]
- [ [200]Previous ]
- SECTION CONTENTS
- 3.2.0. [201]Common Problems
- 3.2.1. [202]Building C-Kermit on HP-UX
- 3.2.2. [203]File Transfer
- 3.2.3. [204]Dialing Out and UUCP Lockfiles in HP-UX
- 3.2.4. [205]Notes on Specific HP-UX Releases
- 3.2.5. [206]HP-UX and X.25
- REFERENCES
- For further information, read the [207]comp.sys.hp.hpux newsgroup.
- C-Kermit is included as part of the HP-UX operating system by contract
- between Hewlett Packard and Columbia University for HP-UX 10.00 and
- later. Each level of HP-UX includes a freshly built C-Kermit binary in
- /bin/kermit, which should work correctly. Binaries built for regular
- HP-UX may be used on Trusted HP-UX and vice-versa, except for use as
- IKSD because of the different authentication methods.
- Note that HP does not update C-Kermit versions for any but its most
- current HP-UX release. So, for example, HP-UX 10.20 has C-Kermit 6.0;
- 11.00 has C-Kermit 7.0, and 11.22 has 8.0. Of course, as with all
- software, older Kermit versions have bugs (such as buffer overflow
- vulnerabilities) that are fixed in later versions. From time to time,
- HP discovers one of these (long-ago fixed) bugs and issues a security
- alert for the older OS's, recommending some draconian measure to avoid
- the problem. The true fix in each situation is to install the current
- release of C-Kermit.
- 3.2.0. Common Problems
- [ [208]Top ] [ [209]Contents ] [ [210]Section Contents ] [ [211]Next ]
- Some HP workstations have a BREAK/RESET key. If you hit this key while
- C-Kermit is running, it might kill or suspend the C-Kermit process.
- C-Kermit arms itself against these signals, but evidently the
- BREAK/RESET key is -- at least in some circumstances, on certain HP-UX
- versions -- too powerful to be caught. (Some report that the first
- BREAK/RESET shows up as SIGINT and is caught by C-Kermit's former
- SIGINT handler even when SIGINT is currently set to SIG_IGN; the second
- kills Kermit; other reports suggest the first BREAK/RESET sends a
- SIGTSTP (suspend signal) to Kermit, which it catches and suspends
- itself. You can tell C-Kermit to ignore suspend signals with SET
- SUSPEND OFF. You can tell C-Kermit to ignore SIGINT with SET COMMAND
- INTERRUPTION OFF. It is not known whether these commands also grant
- immunity to the BREAK/RESET key (one report states that with SET
- SUSPEND OFF, the BREAK/RESET key is ignored the first four times, but
- kills Kermit the 5th time). In any case:
- 1. If this key is mapped to SIGINT or SIGTSTP, C-Kermit catches or
- ignores it, depending on which mode (CONNECT, command, etc) Kermit
- is in.
- 2. If it causes HP-UX to kill C-Kermit, there is nothing C-Kermit can
- do to prevent it.
- When HP-UX is on the remote end of the connection, it is essential that
- HP-UX C-Kermit be configured for Xon/Xoff flow control (this is the
- default, but in case you change it and then experience file-transfer
- failures, this is a likely reason).
- 3.2.1. Building C-Kermit on HP-UX
- [ [212]Top ] [ [213]Contents ] [ [214]Section Contents ] [ [215]Next ]
- [ [216]Previous ]
- This section applies mainly to old (pre-10.20) HP-UX version on old,
- slow, and/or memory-constrained hardware.
- During the C-Kermit 6.0 Beta cycle, something happened to ckcpro.w (or,
- more precisely, the ckcpro.c file that is generated from it) which
- causes HP optimizing compilers under HP-UX versions 7.0 and 8.0
- (apparently on all platforms) as well as under HP-UX 9.0 on Motorola
- platforms only, to blow up. In versions 7.0 and 8.0 the problem has
- spread to other modules.
- The symptoms vary from the system grinding to a halt, to the compiler
- crashing, to the compilation of the ckcpro.c module taking very long
- periods of time, like 9 hours. This problem is handled by compiling the
- modules that tickle it without optimization; the new C-Kermit makefile
- takes care of this, and shows how to do it in case the same thing
- begins happening with other modules.
- On HP-UX 9.0, a kernel parameter, maxdsiz (maximum process data segment
- size), seems to be important. On Motorola systems, it is 16MB by
- default, whereas on RISC systems the default is much bigger. Increasing
- maxdsiz to about 80MB seems to make the problem go away, but only if
- the system also has a lot of physical memory -- otherwise it swaps
- itself to death.
- The optimizing compiler might complain about "some optimizations
- skipped" on certain modules, due to lack of space available to the
- optimizer. You can increase the space (the incantation depends on the
- particular compiler version -- see the [217]makefile), but doing so
- tends to make the compilations take a much longer time. For example,
- the "hpux0100o+" makefile target adds the "+Onolimit" compiler flag,
- and about an hour to the compile time on an HP-9000/730. But it *does*
- produce an executable that is about 10K smaller :-)
- In the makefile, all HP-UX entries automatically skip optimization of
- problematic modules.
- 3.2.2. File Transfer
- [ [218]Top ] [ [219]Contents ] [ [220]Section Contents ] [ [221]Next ]
- [ [222]Previous ]
- Telnet connections into HP-UX versions up to and including 11.11 (and
- possibly 11.20) tend not to lend themselves to file transfer due to
- limitations, restrictions, and/or bugs in the HP-UX Telnet server
- and/or pseudoterminal (pty) driver.
- In C-Kermit 6.0 (1996) an unexpected slowness was noted when
- transferring files over local Ethernet connections when an HP-UX system
- (9.05 or 10.00) was on the remote end. The following experiment was
- conducted to determine the cause. C-Kermit 6.0 was used; the situation
- is slightly better using C-Kermit 7.0's streaming feature and HP-UX
- 10.20 on the far end.
- The systems were HP-UX 10.00 (on 715/33) and SunOS 4.1.3 (on Sparc-20),
- both on the same local 10Mbps Ethernet, packet length 4096, parity
- none, control prefixing "cautious", using only local disks on each
- machine -- no NFS. In the C-Kermit 6.0 (ACK/NAK) case, the window size
- was 20; in the streaming case there is no window size (i.e. it is
- infinite). The test file was C-Kermit executable, transferred in binary
- mode. Conditions were relatively poor: the Sun and the local net
- heavily loaded; the HP system is old, slow, and memory-constrained.
- C-Kermit 6.0... C-Kermit 7.0...
- Local Remote ACK/NAK........ Streaming......
- Client Server Send Receive Send Receive
- Sun HP 36 18 64 18
- HP HP 25 15 37 16
- HP Sun 77 83 118 92
- Sun Sun 60 60 153 158
- So whenever HP is the remote we have poor performance. Why?
- * Changing file display to CRT has no effect (so it's not the curses
- library on the client side).
- * Changing TCP RECV-BUFFER or SEND-BUFFER has little effect.
- * Telling the client to make a binary-mode connection (SET TELNET
- BINARY REQUESTED, which successfully negotiates a binary
- connection) has no effect on throughput.
- BUT... If I start HP-UX C-Kermit as a TCP service:
- set host * 3000
- server
- and then from the client "set host xxx 3000", I get:
- C-Kermit 6.0... C-Kermit 7.0...
- Local Remote ACK/NAK........ Streaming......
- Client Server Send Receive Send Receive
- Sun HP 77 67 106 139
- HP HP 50 50 64 62
- HP Sun 57 85 155 105
- Sun Sun 57 50 321 314
- Therefore the HP-UX telnet server or pty driver seems to be adding more
- overhead than the SunOS one, and most others. When going through this
- type of connection (a remote telnet server) there is little Kermit can
- do improve matters, since the telnet server and pty driver are between
- the two Kermits, and neither Kermit program can have any influence over
- them (except putting the Telnet connection in binary mode, but that
- doesn't help).
- (The numbers for the HP-HP transfers are lower than the others since
- both Kermit processes are running on the same slow 33MHz CPU.)
- Matters seem to have deteriorated in HP-UX 11. Now file transfers over
- Telnet connections fail completely, rather than just being slow. In the
- following trial, a Telnet connection was made from Kermit 95 to HP-UX
- 11.11 on an HP-9000/785/B2000 over local 10Mbps Ethernet running
- C-Kermit 8.00 in server mode (under the HP-UX Telnet server):
- Text........ Binary......
- Stream Pktlen GET SEND GET SEND
- On 4000 Fail Fail Fail Fail
- Off 4000 Fail Fail Fail Fail
- Off 2000 OK Fail OK Fail
- On 2000 OK Fail OK Fail
- On 3000 Fail Fail Fail Fail
- On 2500 Fail Fail Fail Fail
- On 2047 OK Fail OK Fail
- On 2045 OK Fail OK Fail
- Off 500 OK OK OK OK
- On 500 OK Fail OK Fail
- On 240 OK Fail OK Fail
- As you can see, downloads are problematic unless the receiver's Kermit
- packet length is 2045 or less, but uploads work only with streaming
- disabled and the packet length restricted to 500. To force file
- transfers to work on this connection, the desktop Kermit must be told
- to:
- set streaming off
- set receive packet-length 2000
- set send packet-length 500
- However, if a connection is made between the same two programs on the
- same two computers over the same network, but this time a direct
- socket-to-socket connection bypassing the HP-UX Telnet server and pty
- driver (tell HP-UX C-Kermit to "set host /server * 3000 /raw"; tell
- desktop client program to "set host blah 3000 /raw"), everything works
- perfectly with the default Kermit settings (streaming, 4K packets,
- liberal control-character unprefixing, 8-bit transparency, etc):
- Text........ Binary......
- Stream Pktlen GET SEND GET SEND
- On 4000 OK OK OK OK
- And in this case, transfer rates were approximately 900,000 cps. To
- verify that the behavior reported here is not caused by the new Kermit
- release, the same experiment was performed on a Telnet connection from
- the same PC over the same network to the old 715/33 running HP-UX 10.20
- and C-Kermit 8.00. Text and binary uploads and downloads worked
- perfectly (albeit slowly) with all the default settings -- streaming,
- 4K packets, etc.
- 3.2.3. Dialing Out and UUCP Lockfiles in HP-UX
- [ [223]Top ] [ [224]Contents ] [ [225]Section Contents ] [ [226]Next ]
- [ [227]Previous ]
- HP workstations do not come with dialout devices configured; you have
- to do it yourself (as root). First look in /dev to see what's there;
- for example in HP-UX 10.00 or later:
- ls -l /dev/cua*
- ls -l /dev/tty*
- If you find a tty0p0 device but no cua0p0, you'll need to creat one if
- you want to dial out; the tty0p0 does not work for dialing out. It's
- easy: start SAM; in the main Sam window, double-click on Peripheral
- Device, then in the Peripheral Devices window, double-click on
- Terminals and Modems. In the Terminals and Modems dialog, click on
- Actions, then choose "Add modem" and fill in the blanks. For example:
- Port number 0, speed 57600 (higher speeds tend not to work reliably),
- "Use device for calling out", do NOT "Receive incoming calls" (unless
- you know what you are doing), leave "CCITT modem" unchecked unless you
- really have one, and do select "Use hardware flow control (RTS/CTS)".
- Then click OK. This creates cua0p0 as well as cul0p0 and ttyd0p0
- If the following sequence:
- set line /dev/cua0p0 ; or other device
- set speed 115200 ; or other normal speed
- produces the message "?Unsupported line speed". This means either that
- the port is not configured for dialout (go into SAM as described above
- and make sure "Use device for calling out" is selected), or else that
- speed you have given (such as 460800) is supported by the operating
- system but not by the physical device (in which case, use a lower speed
- like 57600).
- In HP-UX 9.0, serial device names began to change. The older names
- looked like "/dev/cua00", "/dev/tty01", etc (sometimes with only one
- digit). The newer names have two digits with the letter "p" in between.
- HP-UX 8.xx and earlier have the older form, HP-UX 10.00 and later have
- the newer form. HP-UX 9.xx has the newer form on Series 800 machines,
- and the older form on other hardware models. The situation is
- summarized in the following table (the Convio 10.0 column applies to
- HP-UX 10 and 11).
- Converged HP-UX Serial I/O Filenames : TTY Mux Naming
- ---------------------------------------------------------------------
- General meaning Old Form S800 9.0 Convio 10.0
- ---------------------------------------------------------------------
- tty* hardwired ports tty<YY> tty<X>p<Y> tty<D>p<p>
- diag:mux<X> diag:mux<D>
- ---------------------------------------------------------------------
- ttyd* dial-in modems ttyd<YY> ttyd<X>p<Y> ttyd<D>p<p>
- diag:ttyd<X>p<Y> diag:ttyd<D>p<p>
- ---------------------------------------------------------------------
- cua* auto-dial out cua<YY> cua<X>p<Y> cua<D>p<p>
- diag:cua<X>p<Y>
- ---------------------------------------------------------------------
- cul* dial-out cul<YY> cul<X>p<Y> cul<D>p<p>
- diag:cul<X>p<Y>
- ---------------------------------------------------------------------
- <X>= LU (Logical Unit) <D>= Devspec (decimal card instance)
- <Y> or <YY> = Port <p>= Port
- For dialing out, you should use the cua or cul devices. When C-Kermit's
- CARRIER setting is AUTO or ON, C-Kermit should pop back to its prompt
- automatically if the carrier signal drops, e.g. when you log out from
- the remote computer or service. If you use the tty<D>p<d> (e.g. tty0p0)
- device, the carrier signal should be ignored. The tty<D>p<d> device
- should be used for direct connections where the carrier signal does not
- follow RS-232 conventions (use the cul device for hardwired connections
- through a true null modem). Do not use the ttyd<D>p<d> device for
- dialing out.
- Kermit's access to serial devices is controlled by "UUCP lockfiles",
- which are intended to prevent different users using different software
- programs (Kermit, cu, etc, and UUCP itself) from accessing the same
- serial device at the same time. When a device is in use by a particular
- user, a file with a special name is created in:
- /var/spool/locks (HP-UX 10.00 and later)
- /usr/spool/uucp (HP-UX 9.xx and earlier)
- The file's name indicates the device that is in use, and its contents
- indicates the process ID (pid) of the process that is using the device.
- Since serial devices and the locks directory are not both publicly
- readable and writable, Kermit and other communication software must be
- installed setuid to the owner (bin) of the serial device and setgid to
- the group (daemon) of the /var/spool/locks directory. Kermit's setuid
- and setgid privileges are enabled only when opening the device and
- accessing the lockfiles.
- Let's say "unit" means a string of decimal digits (the interface
- instance number) followed (in HP-UX 10.00 and later) by the letter "p"
- (lowercase), followed by another string of decimal digits (the port
- number on the interface), e.g.:
- "0p0", "0p1", "1p0", etc (HP-UX 10.00 and later)
- "0p0", "0p1", "1p0", etc (HP-UX 9.xx on Series 800)
- "00", "01", "10", "0", etc (HP-UX 9.xx not on Series 800)
- "00", "01", "10", "0", etc (HP-UX 8.xx and earlier)
- Then a normal serial device (driver) name consists of a prefix ("tty",
- "ttyd", "cua", "cul", or possibly "cuad" or "culd") followed by a unit,
- e.g. "cua0p0". Kermit's treatment of UUCP lockfiles is as close as
- possible to that of the HP-UX "cu" program. Here is a table of the
- lockfiles that Kermit creates for unit 0p0:
- Selection Lockfile 1 Lockfile 2
- /dev/tty0p0 LCK..tty0p0 (none)
- * /dev/ttyd0p0 LCK..ttyd0p0 (none)
- /dev/cua0p0 LCK..cua0p0 LCK..ttyd0p0
- /dev/cul0p0 LCK..cul0p0 LCK..ttyd0p0
- /dev/cuad0p0 LCK..cuad0p0 LCK..ttyd0p0
- /dev/culd0p0 LCK..culd0p0 LCK..ttyd0p0
- <other> LCK..<other> (none)
- (* = Dialin device, should not be used.)
- In other words, if the device name begins with "cu", a second lockfile
- for the "ttyd" device, same unit, is created, which should prevent
- dialin access on that device.
- The <other> case allows for symbolic links, etc, but of course it is
- not foolproof since we have no way of telling which device is really
- being used.
- When C-Kermit tries to open a dialout device whose name ends with a
- "unit", it searches the lockfile directory for all possible names for
- the same unit. For example, if user selects /dev/cul2p3, Kermit looks
- for lockfiles named:
- LCK..tty2p3
- LCK..ttyd2p3
- LCK..cua2p3
- LCK..cul2p3
- LCK..cuad2p3
- LCK..culd2p3
- If any of these files are found, Kermit opens them to find out the ID
- (pid) of the process that created them; if the pid is still valid, the
- process is still active, and so the SET LINE command fails and the user
- is informed of the pid so s/he can use "ps" to find out who is using
- the device.
- If the pid is not valid, the file is deleted. If all such files (i.e.
- with same "unit" designation) are successfully removed, then the SET
- LINE command succeeds; up to six messages are printed telling the user
- which "stale lockfiles" are being removed.
- When the "set line" command succeeds in HP-UX 10.00 and later, C-Kermit
- also creates a Unix System V R4 "advisory lock" as a further precaution
- (but not guarantee) against any other process obtaining access to the
- device while you are using it.
- If the selected device was in use by "cu", Kermit can't open it,
- because "cu" has changed its ownership, so we never get as far as
- looking at the lockfiles. In the normal case, we can't even look at the
- device to see who the owner is because it is visible only to its
- (present) owner. In this case, Kermit says (for example):
- /dev/cua0p0: Permission denied
- When Kermit releases a device it has successfully opened, it removes
- all the lockfiles that it created. This also happens whenever Kermit
- exits "under its own power".
- If Kermit is killed with a device open, the lockfile(s) are left
- behind. The next Kermit program that tries to assign the device, under
- any of its various names, will automatically clean up the stale
- lockfiles because the pids they contain are invalid. The behavior of cu
- and other communication programs under these conditions should be the
- same.
- Here, by the way, is a summary of the differences between the HP-UX
- port driver types from John Pezzano of HP:
- There are three types of device files for each port.
- The ttydXXX device file is designed to work as follows:
- 1. The process that opens it does NOT get control of the port until CD
- is asserted. This was intentional (over 15 years ago) to allow
- getty to open the port but not control it until someone called in.
- If a process wants to use the direct or callout device files
- (ttyXXX and culXXX respectively), they will then get control and
- getty would be blocked. This eliminated the need to use uugetty
- (and its inherent problems with lock files) for modems. You can see
- this demonstrated by the fact that "ps -ef" shows a ? in the tty
- column for the getty process as getty does not have the port yet.
- 2. Once CD is asserted, the port is controlled by getty (or the
- process handling an incoming call) if there was no process using
- the port. The ? in the "ps" command now shows the port. At this
- point, the port accepts data.
- Therefore you should use either the callout culXXX device file
- (immediate control but no data until CD is asserted) or the direct
- device file ttyXXX which gives immediate control and immediate data
- and which ignores by default modem control signals.
- The ttydXXX device should be used only for callin and my
- recommendation is to use it only for getty and uugetty.
- 3.2.4 Notes on Specific HP-UX Releases
- SECTION CONTENTS
- 3.2.4.1. [228]HP-UX 11
- 3.2.4.2. [229]HP-UX 10
- 3.2.4.3. [230]HP-UX 9
- 3.2.4.4. [231]HP-UX 8
- 3.2.4.5. [232]HP-UX 7 and Earlier
- 3.2.4.1. HP-UX 11
- [ [233]Top ] [ [234]Contents ] [ [235]Section Contents ] [ [236]Next ]
- As noted in [237]Section 3.2.2, the HP-UX 11 Telnet server and/or
- pseudoterminal driver are a serious impediment to file transfer over
- Telnet connections into HP-UX. If you have a Telnet connection into
- HP-UX 11, tell your desktop Kermit program to:
- set streaming off
- set receive packet-length 2000
- set send packet-length 500
- File transfer speeds over connections from HP-UX 11 (dialed or Telnet)
- are not impeded whatsoever, and can go at whatever speed is allowed by
- the connection and the Kermit partner on the far end.
- PA-RISC binaries for HP-UX 10.20 or later should run on any PA-RISC
- system, S700 or S800, as long as the binary was not built under a later
- HP-UX version than the host operating system. HP-UX 11.00 and 11.11 are
- only for PA-RISC systems. HP-UX 11.20 is only for IA64 (subsequent
- HP-UX releases will be for both PA-RISC and IA64). To check binary
- compatibility, the following C-Kermit 8.0 binaries were run
- successfully on an HP-9000/785 with HP-UX 11.11:
- * Model 7xx HP-UX 10.20
- * Model 8xx HP-UX 10.20
- * Model 7xx HP-UX 11.00
- * Model 8xx HP-UX 11.00
- * Model 7xx HP-UX 11.11
- * Model 8xx HP-UX 11.11
- Binaries built under some of the earlier HP-UX releases, such as 9.05,
- might also work, but only if built for the same hardware family (e.g.
- s700).
- 3.2.4.2. HP-UX 10
- [ [238]Top ] [ [239]Contents ] [ [240]Section Contents ] [ [241]Next ]
- [ [242]Previous ]
- Beginning in HP-UX 10.10, libcurses is linked to libxcurses, the new
- UNIX95 (X/Open) version of curses, which has some serious bugs; some
- routines, when called, would hang and never return, some would dump
- core. Evidently libxcurses contains a select() routine, and whenever
- C-Kermit calls what it thinks is the regular (sockets) select(), it
- gets the curses one, causing a segmentation fault. There is a patch for
- this from HP, PHCO_8086, "s700_800 10.10 libcurses patch", "shared lib
- curses program hangs on 10.10", "10.10 enhanced X/Open curses core
- dumps due to using wrong select call", 96/08/02 (you can tell if the
- patch is installed with "what /usr/lib/libxcurses.1"; the unpatched
- version is 76.20, the patched one is 76.20.1.2). It has been verified
- that C-Kermit works OK with the patched library, but results are not
- definite for HP-UX 10.20 or higher.
- To ensure that C-Kermit works even on non-patched HP-UX 10.10 systems,
- separate makefile entries are provided for HP-UX 10.00/10.01, 10.10,
- 10.20, etc, in which the entries for 10.10 and above link with
- libHcurses, which is "HP curses", the one that was used in 10.00/10.01.
- HP-UX 11.20 and later, however, link with libcurses, as libHcurses
- disappeared in 11.20.
- 3.2.4.3. HP-UX 9
- [ [243]Top ] [ [244]Contents ] [ [245]Section Contents ] [ [246]Next ]
- [ [247]Previous ]
- HP-UX 9.00 and 9.01 need patch PHNE_10572 (note: this replaces
- PHNE_3641) for hptt0.o, asio0.o, and ttycomn.o in libhp-ux.a. Contact
- Hewlett Packard if you need this patch. Without it, the dialout device
- (tty) will be hung after first use; subsequent attempts to use will
- return an error like "device busy". (There are also equivalent patches
- for s700 9.03 9.05 9.07 (PHNE_10573) and s800 9.00 9.04 (PHNE_10416).
- When C-Kermit is in server mode, it might have trouble executing REMOTE
- HOST commands. This problem happens under HP-UX 9.00 (Motorola) and
- HP-UX 9.01 (RISC) IF the C-Shell is the login shell AND with the
- C-Shell Revision 70.15. Best thing is to install HP's Patch PHCO_4919
- for Series 300/400 and PHCO_5015 for the Series 700/800. PHCO_5015 is
- called "s700_800 9.X cumulative csh(1) patch with memory leak fix"
- which works for HP-UX 9.00, 9.01, 9.03, 9.04, 9.05 and 9.07. At least
- you need C-Shell Revision 72.12!
- C-Kermit works fine -- including its curses-based file-transfer display
- -- on the console terminal, in a remote session (e.g. when logged in to
- the HP 9000 on a terminal port or when telnetted or rlogin'd), and in
- an HP-VUE hpterm window or an xterm window.
- 3.2.4.4. HP-UX 8
- [ [248]Top ] [ [249]Contents ] [ [250]Section Contents ] [ [251]Next ]
- [ [252]Previous ]
- To make C-Kermit work on HP-UX 8.05 on a model 720, obtain and install
- HP-UX patch PHNE_0899. This patch deals with a lot of driver issues,
- particularly related to communication at higher speeds.
- One user reports:
- On HP-UX 8 DON'T install 'tty patch' PHKL_4656, install PHKL_3047
- instead! Yesterday I tried this latest tty patch PHKL_4656 and had
- terrible problems. This patch should fix RTS/CTS problems. With text
- transfer all looks nice. But when I switched over to binary files
- the serial interface returned only rubish to C-Kermit. All sorts of
- protocol, CRC and packed errors I had. After several tests and after
- uninstalling that patch, all transfers worked fine. MB's of data
- without any errors. So keep your fingers away from that patch. If
- anybody needs the PHKL_3047 patch I have it here. It is no longer
- available from HP's patch base.
- 3.2.4.5. HP-UX 7 and Earlier
- [ [253]Top ] [ [254]Contents ] [ [255]Section Contents ] [
- [256]Previous ]
- When transferring files into HP-UX 5 or 6 over a Telnet connection, you
- must not use streaming, and you must not use a packet length greater
- than 512. However, you can use streaming and longer packets when
- sending files from HP-UX on a Telnet connection. In C-Kermit 8.0, the
- default receive packet length for HP-UX 5 and 6 was changed to 500 (but
- you can still increase it with SET RECEIVE PACKET-LENGTH if you wish,
- e.g. for non-Telnet connections). Disable streaming with SET STREAMING
- OFF.
- The HP-UX 5.00 version of C-Kermit does not include the fullscreen
- file-transfer because of problems with the curses library.
- If HP-UX 5.21 with Wollongong TCP/IP is on the remote end of a Telnet
- connection, streaming transfers to HP-UX invariably fail. Workaround:
- SET STREAMING OFF. Packets longer than about 1000 should not be used.
- Transfers from these systems, however, can use streaming and/or longer
- packets.
- Reportedly, "[there is] a bug in C-Kermit using HP-UX version 5.21 on
- the HP-9000 series 500 computers. It only occurs when the controlling
- terminal is using an HP-27140 six-port modem mux. The problem is not
- present if the controlling terminal is logged into an HP-27130
- eight-port mux. The symptom is that just after dialing successfully and
- connecting Kermit locks up and the port is unusable until both forks of
- Kermit and the login shell are killed." (This report predates C-Kermit
- 6.0 and might no longer apply.)
- 3.2.5. HP-UX and X.25
- [ [257]Top ] [ [258]Contents ] [ [259]Section Contents ] [
- [260]Previous ]
- Although C-Kermit presently does not include built-in support for HP-UX
- X.25 (as it does for the Sun and IBM X.25 products), it can still be
- used to make X.25 connections as follows: start Kermit and then telnet
- to localhost. After logging back in, start padem as you would normally
- do to connect over X.25. Padem acts as a pipe between Kermit and X.25.
- In C-Kermit 7.0, you might also be able to avoid the "telnet localhost"
- step by using:
- C-Kermit> pty padem address
- This works if padem uses standard i/o (who knows?).
- 3.3. C-KERMIT AND LINUX
- [ [261]Top ] [ [262]Contents ] [ [263]Section Contents ] [ [264]Next ]
- [ [265]Previous ]
- SECTION CONTENTS
- 3.3.1. [266]Problems Building C-Kermit for Linux
- 3.3.2. [267]Problems with Serial Devices in Linux
- 3.3.3. [268]Terminal Emulation in Linux
- 3.3.4. [269]Dates and Times
- 3.3.5. [270]Startup Errors
- 3.3.6. [271]The Fullscreen File Transfer Display
- (August 2010) Reportedly C-Kermit packages for certain Linux
- distributions such as Centos and Ubuntu have certain features
- disabled, for example the SSH command, SET HOST PTY /SSH, and
- perhaps anything else to do with SSH and/or pseudoterminals and who
- knows what else. If you download the regular package ("tarball")
- from the Kermit Project and build from it ("make linux"), everything
- is fine.
- C-Kermit in Ubuntu 10.04 and 9.10 was reported slow to start because
- it was trying to resolve the IP address 255.255.255.255. Later, also
- in recent Debian versions. The following is seen in the strace:
- write(3, "RESOLVE-ADDRESS 255.255.255.255\n", 32)
- This is not Kermit Project code. Turns out to be something in
- glibc's resolver, and can be fixed by changing /etc/nsswitch.conf,
- but it might break other software, such as [272]Avahi or anything
- (such as Gnome, Java, or Cups) that depends on it. I'm not sure
- where it happens; I don't think Kermit tries to get its IP address
- at startup time, only when it's needed or asked for, e.g. when
- making a connection or evaluating \v(ipaddress).
- REFERENCES
- For further information, read the [273]comp.os.linux.misc,
- [274]comp.os.linux.answers, and other Linux-oriented newsgroups, and
- see:
- The Linux Document Project (LDP)
- [275]http://www.tldp.org/
- The Linux FAQ
- [276]http://www.tldp.org/FAQ/Linux-FAQ.html
- The Linux HOWTOs (especially the Serial HOWTO)
- [277]http://www.tldp.org/HOWTO/Serial-HOWTO.html
- [278]http://tldp.org/HOWTO/Modem-HOWTO.html
- [279]ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
- [280]ftp://tsx-11.mit.edu/pub/linux/docs/HOWTO
- [281]http://www.tldp.org/HOWTO/
- [282]http://www.tldp.org/hmirrors.html
- Linux Vendor Tech Support Pages:
- [283]http://www.redhat.com/apps/support/
- [284]http://www.debian.org/support
- [285]http://www.slackware.com/support/
- [286]http://www.caldera.com/support/
- [287]SUSE Linux Support
- [288]http://www.mandrake.com/support/
- [289]http://www.turbolinux.com/support/
- Linux Winmodem Support
- [290]http://www.linmodems.org/
- Also see general comments on PC-based Unixes in [291]Section 3.0.
- What Linux version is it? -- "uname -a" supplies only kernel
- information, but these days it's the distribution that matters: Red Hat
- 7.3, Debian 2.2, Slackware 8.0, etc. Unfortunately there's no
- consistent way to get the distribution version. Usually it's in a
- distribution-specific file:
- Red Hat: /etc/issue or /etc/redhat-release
- Debian: /etc/debian_version
- Slackware: /etc/slackware-version (at least in later versions)
- Did you know: DECnet is available for Linux? See:
- [292]http://linux.dreamtime.org/decnet/
- (But there is no support for it in C-Kermit -- anybody interested in
- adding it, please [293]let me know).
- Before proceeding, let's handle the some of the most frequently asked
- question in the Linux newsgroups:
- 1. Neither C-Kermit nor any other Linux application can use Winmodems,
- except in the [294]rare cases where Linux drivers have been written
- for them. See [295]Section 3.0.2 for details.
- 2. "Why does it take such a long time to make a telnet connection to
- (or from) my Linux PC?" (this applies to C-Kermit and to regular
- Telnet). Most telnet servers these days perform reverse DNS lookups
- on the client (for security and/or logging reasons). If the Telnet
- client's address cannot be found by the server's local DNS server,
- the DNS request goes out to the Internet at large, and this can
- take quite some time. The solution to this problem is to make sure
- that both client and host are registered in DNS, and that the
- registrations are exported. C-Kermit itself performs reverse DNS
- lookups unless you tell it not to; this is to allow C-Kermit to let
- you know which host it is actually connected to in case you have
- made a connection to a host pool (multihomed host). You can disable
- C-Kermit's reverse DNS lookup with SET TCP REVERSE-DNS-LOOKUP OFF.
- 3. (Any question that has the word "Telnet" in it...) The knee-jerk
- reaction is "don't use Telnet, use SSH!" There's nothing wrong with
- Telnet. In fact it's far superior to SSH as a protocol in terms of
- features and extensibility, not to mention platform neutrality. The
- issue lurking behind the knee-jerk reaction is security. SSH is
- thought to be secure, whereas Telnet is thought to be insecure.
- This is true for clear-text Telnet (because passwords travel in the
- clear across the network), but apparently few people realize that
- [296]secure Telnet clients and servers have been available for
- years, and these are more secure than SSH (for reasons explained
- [297]HERE).
- 4. (Any question that has the word "FTP" in it...) The knee-jerk
- reaction being "Don't use FTP, use SCP!" (or SFTP). Same answer as
- above, but moreso. SCP and SFTP are not only not platform neutral,
- they're diversity-hostile. They transfer files only in binary mode,
- which mangles text files across different platforms, to the same
- degree the platform's text-file record format and character set
- differ. An extreme example would be an Variable-Block format EBCDIC
- text file on an IBM mainframe, binary transfer of which to Unix
- would do you little good indeed. FTP was designed with diversity in
- mind and secure versions are available.
- 3.3.1. Problems Building C-Kermit for Linux
- [ [298]Top ] [ [299]Contents ] [ [300]Section Contents ] [ [301]Next ]
- Modern Linux distributions like Red Hat give you a choice at
- installation whether to include "developer tools". Obviously, you can't
- build C-Kermit or any other C program from source code if you have not
- installed the developer tools. But to confuse matters, you might also
- have to choose (separately) to install the "curses" or "ncurses"
- terminal control library; thus it is possible to install the C compiler
- and linker, but omit the (n)curses library and headers. If curses is
- not installed, you will not be able to build a version of C-Kermit that
- supports the fullscreen file-transfer display, in which case you'll
- need to use the "linuxnc" makefile target (nc = No Curses) or else
- install ncurses before building.
- There are all sorts of confusing issues caused by the many and varied
- Linux distributions. Some of the worst involve the curses library and
- header files: where are they, what are they called, which ones are they
- really? Other vexing questions involve libc5 vs libc6 vs glibc vs
- glibc2 (C libraries), gcc vs egcs vs lcc (compilers), plus using or
- avoiding features that were added in a certain version of Linux or a
- library or a distribution, and are not available in others. As of
- C-Kermit 8.0, these questions should be resolved by the "linux"
- makefile target itself, which does a bit of looking around to see
- what's what, and then sets the appropriate CFLAGS.
- 3.3.2. Problems with Serial Devices in Linux
- [ [302]Top ] [ [303]Contents ] [ [304]Section Contents ] [ [305]Next ]
- [ [306]Previous ]
- Also see: "man setserial", "man irqtune".
- And: [307]Sections 3.0, [308]6, [309]7, and [310]8 of this document.
- NOTE: Red Hat Linux 7.2 and later include a new API that allows
- serial-port arbitration by non-setuid/gid programs. This API has not
- yet been added to C-Kermit. If C-Kermit is to be used for dialing
- out on Red Hat 7.2 or later, it must still be installed as described
- in in Sections [311]10 and [312]11 of the [313]Installation
- Instructions.
- Don't expect it to be easy. Queries like the following are posted to
- the Linux newsgroups almost daily:
- Problem of a major kind with my Compaq Presario 1805 in the sense
- that the pnpdump doesn't find the modem and the configuration tells
- me that the modem is busy when I set everything by hand!
- I have <some recent SuSE distribution>, kernel 2.0.35. Using the
- Compaq tells me that the modem (which is internal) is on COM2, with
- the usual IRQ and port numbers. Running various Windows diagnostics
- show me AT-style commands exchanged so I have no reason to believe
- that it is a Winmodem. Also, the diagnostics under Win98 tell me
- that I am talking to an NS 16550AN.
- [Editor's note: This does not necessarily mean it isn't a Winmodem.]
- Under Linux, no joy trying to talk to the modem on /dev/cua1 whether
- via minicom, kppp, or chat; kppp at least tells me that tcgetattr()
- failed.
- Usage of setserial:
- setserial /dev/cua1 port 0x2F8 irq 3 autoconfig
- setserial -g /dev/cua1
- tells me that the uart is 'unknown'. I have tried setting the UART
- manually via. setserial to 16550A, 16550, and the other one (8550?)
- (I didn't try 16540). None of these manual settings resulted in any
- success.
- A look at past articles leads me to investigate PNP issues by
- calling pnpdump but pnpdump returns "no boards found". I have looked
- around on my BIOS (Phoenix) and there is not much evidence of it
- being PNP aware. However for what it calls "Serial port A", it
- offers a choice of Auto, Disabled or Manual settings (currently set
- to Auto), but using the BIOS interface I tried to change to 'manual'
- and saw the default settings offered to be were 0x3F8 and IRQ 4
- (COM1). The BIOS menus did not give me any chance to configure COM2
- or any "modem". I ended up not saving any BIOS changes in the course
- of my investigations.
- You can also find out a fair amount about your PC's hardware
- configuration in the text files in /proc, e.g.:
- -r--r--r-- 1 root 0 Sep 4 14:00 /proc/devices
- -r--r--r-- 1 root 0 Sep 4 14:00 /proc/interrupts
- -r--r--r-- 1 root 0 Sep 4 14:00 /proc/ioports
- -r--r--r-- 1 root 0 Sep 4 14:00 /proc/pci
- From the directory listing they look like empty files, but in fact they
- are text files that you "cat":
- $ cat /proc/pci
- Bus 0, device 14, function 0:
- Serial controller: US Robotics/3Com 56K FaxModem Model 5610 (rev 1).
- IRQ 10.
- I/O at 0x1050 [0x1057].
- $ setserial -g /dev/ttyS4
- /dev/ttyS4, UART: 16550A, Port: 0x1050, IRQ: 10
- $ cat /proc/ioports
- 1050-1057 : US Robotics/3Com 56K FaxModem Model 5610
- 1050-1057 : serial(auto)
- $ cat /proc/interrupts
- CPU0
- 0: 7037515 XT-PIC timer
- 1: 2 XT-PIC keyboard
- 2: 0 XT-PIC cascade
- 4: 0 XT-PIC serial
- 8: 1 XT-PIC rtc
- 9: 209811 XT-PIC usb-uhci, eth0
- 14: 282015 XT-PIC ide0
- 15: 6 XT-PIC ide1
- Watch out for PCI, PCMCIA and Plug-n-Play devices, Winmodems, and the
- like (see cautions in [314]Section 3.0 Linux supports Plug-n-Play
- devices to some degree via the isapnp and pnpdump programs; read the
- man pages for them. (If you don't have them, look on your installation
- CD for isapnptool or download it from sunsite or a sunsite mirror or
- other politically correct location du jour).
- PCI modems do not use standard COM port addresses. The I/O address and
- IRQ are assigned by the BIOS. All you need to do to get one working,
- find out the I/O address and interrupt number with (as root) "lspci -v
- | more" and then give the resulting address and interrupt number to
- setserial.
- Even when you have a real serial port, always be wary of interrupt
- conflicts and similar PC hardware configuration issues: a PC is not a
- real computer like other Unix workstations -- it is generally pieced
- together from whatever random components were the best bargain on the
- commodity market the week it was built. Once it's assembled and boxed,
- not even the manufacturer will remember what it's made of or how it was
- put together because they've moved on to a new model. Their job is to
- get it (barely) working with Windows; for Linux and other OS's you are
- on your own.
- "set line /dev/modem" or "set line /dev/ttyS2", etc, results in an
- error, "/dev/modem is not a tty". Cause unknown, but obviously a driver
- issue, not a Kermit one (Kermit uses "isatty()" to check that the
- device is a tty, so it knows it will be able to issue all the
- tty-related ioctl's on it, like setting the speed & flow control). Try
- a different name (i.e. driver) for the same port, e.g. "set line
- /dev/cua2" or whatever.
- To find what serial ports were registered at the most recent system
- boot, type (as root): "grep tty /var/log/dmesg".
- "set modem type xxx" (where xxx is the name of a modem) followed by
- "set line /dev/modem" or "set
- line /dev/ttyS2", etc, hangs (but can be interrupted with Ctrl-C).
- Experimentation shows that if the modem is configured to always assert
- carrier (&C0) the same command does not hang. Again, a driver issue.
- Use /dev/cua2 (or whatever) instead. (Or not -- hopefully none of these
- symptoms occurs in C-Kermit 7.0 or later.)
- "set line /dev/cua0" reports "Device is busy", but "set line
- /dev/ttyS0" works OK.
- In short: If the cua device doesn't work, try the corresponding ttyS
- device. If the ttyS device doesn't work, try the corresponding cua
- device -- but note that Linux developers do not recommend this, and are
- phasing out the cua devices. From /usr/doc/faq/howto/Serial-HOWTO:
- 12.4. What's The Real Difference Between the /dev/cuaN And /dev/ttySN
- Devices?
- The only difference is the way that the devices are opened. The
- dialin devices /dev/ttySN are opened in blocking mode, until CD
- is asserted (ie someone connects). So, when someone wants to use
- the /dev/cuaN device, there is no conflict with a program
- watching the /dev/ttySN device (unless someone is connected of
- course). The multiple /dev entries, allow operation of the same
- physical device with different operating characteristics. It
- also allows standard getty programs to coexist with any other
- serial program, without the getty being retrofitted with locking
- of some sort. It's especially useful since standard Unix kernel
- file locking, and UUCP locking are both advisory and not
- mandatory.
- It was discovered during development of C-Kermit 7.0 that rebuilding
- C-Kermit with -DNOCOTFMC (No Close/Open To Force Mode Change) made the
- aforementioned problem with /dev/ttyS0 go away. It is not yet clear,
- however, what its affect might be on the /dev/cua* devices. As of 19
- March 1998, this option has been added to the CFLAGS in the makefile
- entries for Linux ("make linux").
- Note that the cua device is now "deprecated", and new editions of Linux
- will phase (have phased) it out in favor of the ttyS device. See (if
- it's still there):
- [315]http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Mar_98/1441.html
- (no, of course it isn't; you'll have to use your imagination). One user
- reported that C-Kermit 7.0, when built with egcs 1.1.2 and run on Linux
- 2.2.6 with glibc 2.1 (hardware unknown but probably a PC) dumps core
- when given a "set line /dev/ttyS1" command. When rebuilt with gcc, it
- works fine.
- All versions of Linux seem to have the following deficiency: When a
- modem call is hung up and CD drops, Kermit can no longer read the modem
- signals; SHOW COMMUNICATIONS says "Modem signals not available". The
- TIOCMGET ioctl() returns -1 with errno 5 ("I/O Error").
- The Linux version of POSIX tcsendbreak(), which is used by C-Kermit to
- send regular (275msec) and long (1.5sec) BREAK signals, appears to
- ignore its argument (despite its description in the man page and info
- topic), and always sends a regular 275msec BREAK. This has been
- observed in Linux versions ranging from Debian 2.1 to Red Hat 7.1.
- 3.3.3. Terminal Emulation in Linux
- [ [316]Top ] [ [317]Contents ] [ [318]Section Contents ] [ [319]Next ]
- [ [320]Previous ]
- C-Kermit is not a terminal emulator. For a brief explanation of why
- not, see [321]Section 3.0.5. For a fuller explanation, [322]ClICK HERE.
- In Unix, terminal emulation is supplied by the Window in which you run
- Kermit: the regular console screen, which provides Linux Console
- "emulation" via the "console" termcap entry, or under X-Windows in an
- xterm window, which gives VTxxx emulation. An xterm that includes color
- ANSI and VT220 emulation is available with Xfree86:
- [323]http://dickey.his.com/xterm/xterm.html
- Before starting C-Kermit in an xterm window, you might need to tell the
- xterm window's shell to "stty sane".
- To set up your PC console keyboard to send VT220 key sequences when
- using C-Kermit as your communications program in an X terminal window
- (if it doesn't already), create a file somewhere (e.g. in /root/)
- called .xmodmaprc, containing something like the following:
- keycode 77 = KP_F1 ! Num Lock => DEC Gold (PF1)
- keycode 112 = KP_F2 ! Keypad / => DEC PF1
- keycode 63 = KP_F3 ! Keypad * => DEC PF3
- keycode 82 = KP_F4 ! Keypad - => DEC PF4
- keycode 111 = Help ! Print Screen => DEC Help
- keycode 78 = F16 ! Scroll Lock => DEC Do
- keycode 110 = F16 ! Pause => DEC Do
- keycode 106 = Find ! Insert => DEC Find
- keycode 97 = Insert ! Home => DEC Insert
- keycode 99 = 0x1000ff00 ! Page Up => DEC Remove
- keycode 107 = Select ! Delete => DEC Select
- keycode 103 = Page_Up ! End => DEC Prev Screen
- keycode 22 = Delete ! Backspace sends Delete (127)
- Then put "xmodmap filename" in your .xinitrc file (in your login
- directory), e.g.
- xmodmap /root/.xmodmaprc
- Of course you can move things around. Use the xev program to find out
- key codes.
- Console-mode keys are mapped separately using loadkeys, and different
- keycodes are used. Find out what they are with showkey.
- For a much more complete VT220/320 key mapping for [324]Xfree86 xterm,
- [325]CLICK HERE.
- 3.3.4. Dates and Times
- [ [326]Top ] [ [327]Contents ] [ [328]Section Contents ] [ [329]Next ]
- [ [330]Previous ]
- If C-Kermit's date-time (e.g. as shown by its DATE command) differs
- from the system's date and time:
- a. Make sure the libc to which Kermit is linked is set to GMT or is
- not set to any time zone. Watch out for mixed libc5/libc6 systems;
- each must be set independently.
- b. If you have changed your TZ environment variable, make sure it is
- exported. This is normally done in /etc/profile or /etc/TZ.
- 3.3.5. Startup Errors
- [ [331]Top ] [ [332]Contents ] [ [333]Section Contents ] [ [334]Next ]
- [ [335]Previous ]
- C-Kermit should work on all versions of Linux current through March
- 2003, provided it was built on the same version you have, with the same
- libraries and header files (just get the source code and "make linux").
- Binaries tend not to travel well from one Linux machine to another, due
- to their many differences. There is no guarantee that a particular
- C-Kermit binary will not stop working at a later date, since Linux
- tends to change out from under its applications. If that happens,
- rebuild C-Kermit from source. If something goes wrong with the build
- process, look on the [336]C-Kermit website for a newer version. If you
- have the latest version, then [337]report the problem to us.
- Inability to transfer files in Red Hat 7.2: the typical symptom would
- be if you start Kermit and tell it to RECEIVE, it fails right away with
- "?/dev/tty: No such device or address" or "?Bad file descriptor". One
- report says this is because of csh, and if you change your shell to
- bash or other shell, it doesn't happen. Another report cite bugs in Red
- Hat 7.2 Telnetd "very seldom (if ever) providing a controlling tty, and
- lots of other people piled on saying they have the same problem.") A
- third theory is that this happens only when Linux has been installed
- without "virtual terminal support".
- A search of RedHat's errata pages shows a bug advisory (RHBA-2001-153)
- issued 13 November 2001, but updated 6 December, about this same
- symptom (but with tcsh and login.) Seems that login was not always
- assigning a controlling TTY for the session, which would make most use
- of "/dev/tty" somewhat less than useful.
- [338]http://www.redhat.com/support/errata/RHBA-2001-153.html
- Quoting: "Due to terminal handling problems in /bin/login, tcsh would
- not find the controlling terminal correctly, and a shell in single user
- mode would exhibit strange terminal input characteristics. This update
- fixes both of these problems."
- Since the Red Hat 5.1 release (circa August 1998), there have been
- numerous reports of prebuilt Linux executables, and particularly the
- Kermit RPM for Red Hat Linux, not working; either it won't start at
- all, or it gives error messages about "terminal type unknown" and
- refuses to initialize its curses support. The following is from the
- [339]Kermit newsgroup:
- From: rchandra@hal9000.buf.servtech.com
- Newsgroups: comp.protocols.kermit.misc
- Subject: Red Hat Linux/Intel 5.1 and ncurses: suggestions
- Date: 22 Aug 1998 15:54:46 GMT
- Organization: Verio New York
- Keywords: RedHat RPM 5.1
- Several factors can influence whether "linux" is recognized as a
- terminal type on many Linux systems.
- 1. Your program, or the libraries it linked with (if statically
- linked), or the libraries it dynamically links with at runtime, are
- looking for an entry in /etc/termcap that isn't there. (not likely,
- but possible... I believe but am not certain that this is a very
- old practice in very old [n]curses library implementations to use a
- single file for all terminal descriptions.)
- 2. Your program, or the libraries...are looking for a terminfo file
- that just plain isn't there. (also not so likely, since many people
- in other recent message threads said that other programs work OK).
- 3. Your program, or the libraries...are looking for a terminfo file
- that is stored at a pathname that isn't expected by your program,
- the libraries--and so on. I forgot if I read this in the errata Web
- page or where exactly I discovered this (Netscape install? Acrobat
- install?), but it may just be that one libc (let's say for sake of
- argument, libc5, but I don't know this to be true) expects your
- terminfo to be in /usr/share/terminfo, and the other (let's say
- libc6/glibc) expects /usr/lib/terminfo. I remember that the
- specific instructions in this bugfix/workaround were to do the
- following or equivalent:
- cd /usr/lib
- ln -s ../share/terminfo ./terminfo
- or:
- ln -s /usr/share/terminfo /usr/lib/terminfo
- So what this says is that the terminfo database/directory structure
- can be accessed by either path. When something goes to reference
- /usr/lib/terminfo, the symlink redirects it to essentially
- /usr/share/terminfo, which is where it really resides on your
- system. I personally prefer wherever possible to use relative
- symlinks, because they still hold, more often than break, across
- mount points, particularly NFS mounts, where the directory structure
- may be different on the different systems.
- Evidently the terminfo file moved between Red Hat 5.0 and 5.1, but Red
- Hat did not include a link to let applications built prior to 5.1 find
- it. Users reported that installing the link fixes the problem.
- 3.3.6. The Fullscreen File Transfer Display
- [ [340]Top ] [ [341]Contents ] [ [342]Section Contents ] [
- [343]Previous ]
- Starting with ncurses versions dated 1998-12-12 (about a year before
- ncurses 5.0), ncurses sets the terminal for buffered i/o, but
- unfortunately is not able to restore it upon exit from curses (via
- endwin()). Thus after a file transfer that uses the fullscreen file
- transfer display, the terminal no longer echos nor responds immediately
- to Tab, ?, and other special command characters. The same thing happens
- on other platforms that use ncurses, e.g. FreeBSD. Workarounds:
- * Use SET XFER DISPLAY BRIEF, CRT, SERIAL, or NONE instead of
- FULLSCREEN; or:
- * Rebuild with KFLAGS=-DNONOSETBUF (C-Kermit 8.0)
- In Red Hat 7.1, when using C-Kermit in a Gnome terminal window, it was
- noticed that when the fullscreen file transfer display exits (via
- endwin()), the previous (pre-file-transfer-display) screen is restored.
- Thus you can't look at the completed display to see what happened. This
- is a evidently a new feature of xterm. I can only speculate that
- initscreen() and endwin() must send some kind of special escape
- sequences that command xterm to save and restore the screen. To defeat
- this effect, tell Linux you have a vt100 or other xterm-compatible
- terminal that is not actually an xterm, or else tell Kermit to SET
- TRANSFER DISPLAY to something besides FULLSCREEN.
- 3.4. C-KERMIT AND NEXTSTEP
- [ [344]Top ] [ [345]Contents ] [ [346]Section Contents ] [ [347]Next ]
- [ [348]Previous ]
- Run C-Kermit in a Terminal, Stuart, or xterm window, or when logged in
- remotely through a serial port or TELNET connection. C-Kermit does not
- work correctly when invoked directly from the NeXTSTEP File Viewer or
- Dock. This is because the terminal-oriented gtty, stty, & ioctl calls
- don't work on the little window that NeXTSTEP pops up for non-NeXTSTEP
- applications like Kermit. CBREAK and No-ECHO settings do not take
- effect in the command parser -- commands are parsed strictly line at a
- time. "set line /dev/cua" works. During CONNECT mode, the console stays
- in cooked mode, so characters are not transmitted until carriage return
- or linefeed is typed, and you can't escape back. If you want to run
- Kermit directly from the File Viewer, then launch it from a shell
- script that puts it in the desired kind of window, something like this
- (for "Terminal"):
- Terminal -Lines 24 -Columns 80 -WinLocX 100 -WinLocY 100 $FONT $FONTSIZE \
- -SourceDotLogin -Shell /usr/local/bin/kermit &
- C-Kermit does not work correctly on a NeXT with NeXTSTEP 3.0 to which
- you have established an rlogin connection, due to a bug in NeXTSTEP
- 3.0, which has been reported to NeXT.
- The SET CARRIER command has no effect on the NeXT -- this is a
- limitation of the NeXTSTEP serial-port device drivers.
- Hardware flow control on the NeXT is selected not by "set flow rts/cts"
- in Kermit (since NeXTSTEP offers no API for this), but rather, by using
- a specially-named driver for the serial device: /dev/cufa instead
- /dev/cua; /dev/cufb instead of /dev/cub. This is available only on
- 68040-based NeXT models (the situation for Intel NeXTSTEP
- implementations is unknown).
- NeXT-built 68030 and 68040 models have different kinds of serial
- interfaces; the 68030 has a Macintosh-like RS-422 interface, which
- lacks RTS and CTS signals; the 68040 has an RS-423 (RS-232 compatible)
- interface, which supports the commonly-used modem signals. WARNING: the
- connectors look exactly the same, but the pins are used in completely
- DIFFERENT ways -- different cables are required for the two kinds of
- interfaces.
- IF YOU GET LOTS OF RETRANSMISSIONS during file transfer, even when
- using a /dev/cuf* device and the modem is correctly configured for
- RTS/CTS flow control, YOU PROBABLY HAVE THE WRONG KIND OF CABLE.
- On the NeXT, Kermit reportedly (by TimeMon) causes the kernel to use a
- lot of CPU time when using a "set line" connection. That's because
- there is no DMA channel for the NeXT serial port, so the port must
- interrupt the kernel for each character in or out.
- One user reported trouble running C-Kermit on a NeXT from within NeXT's
- Subprocess class under NeXTstep 3.0, and/or when rlogin'd from one NeXT
- to another: Error opening /dev/tty:, congm: No such device or address.
- Diagnosis: Bug in NeXTSTEP 3.0, cure unknown.
- 3.5. C-KERMIT AND QNX
- [ [349]Top ] [ [350]Contents ] [ [351]Section Contents ] [ [352]Next ]
- [ [353]Previous ]
- See also: The [354]comp.os.qnx newsgroup.
- Support for QNX 4.x was added in C-Kermit 5A(190). This is a
- full-function implementation, thoroughly tested on QNX 4.21 and later,
- and verified to work in both 16-bit and 32-bit versions. The 16-bit
- version was dropped in C-Kermit 7.0 since it can no longer be built
- successfully (after stripping most most features, I succeeded in
- getting it to compile and link without complaint, but the executable
- just beeps when you run it); for 16-bit QNX 4.2x, use C-Kermit 6.0 or
- earlier, or else [355]G-Kermit.
- The 32-bit version (and the 16-bit version prior to C-Kermit 7.0)
- supports most of C-Kermit's advanced features including TCP/IP, high
- serial speeds, hardware flow-control, modem-signal awareness, curses
- support, etc.
- BUG: In C-Kermit 6.0 on QNX 4.22 and earlier, the fullscreen file
- transfer display worked fine the first time, but was fractured on
- subsequent file transfers. Cause and cure unknown. In C-Kermit 7.0 and
- QNX 4.25, this no longer occurs. It is not known if it would occur in
- C-Kermit 7.0 or later on earlier QNX versions.
- Dialout devices are normally /dev/ser1, /dev/ser2, ..., and can be
- opened explicitly with SET LINE. Reportedly, "/dev/ser" (no unit
- number) opens the first available /dev/sern device.
- Like all other Unix C-Kermit implementations, QNX C-Kermit does not
- provide any kind of terminal emulation. Terminal specific functions are
- provided by your terminal, terminal window (e.g. QNX Terminal or
- xterm), or emulator.
- QNX C-Kermit, as distributed, does not include support for UUCP
- line-locking; the QNX makefile entries (qnx32 and qnx16) include the
- -DNOUUCP switch. This is because QNX, as distributed, does not include
- UUCP, and its own communications software (e.g. qterm) does not use
- UUCP line locking. If you have a UUCP product installed on your QNX
- system, remove the -DNOUUCP switch from the makefile entry and rebuild.
- Then check to see that Kermit's UUCP lockfile conventions are the same
- as those of your UUCP package; if not, read the [356]UUCP lockfile
- section of the [357]Installation Instructions and make the necessary
- changes to the makefile entry (e.g. add -DHDBUUCP).
- QNX does, however, allow a program to get the device open count. This
- can not be a reliable form of locking unless all applications do it, so
- by default, Kermit uses this information only for printing a warning
- message such as:
- C-Kermit>set line /dev/ser1
- WARNING - "/dev/ser1" looks busy...
- However, if you want to use it as a lock, you can do so with:
- SET QNX-PORT-LOCK { ON, OFF }
- This is OFF by default; if you set in ON, C-Kermit will fail to open
- any dialout device when its open count indicates that another process
- has it open. SHOW COMM (in QNX only) displays the setting, and if you
- have a port open, it also shows the open count.
- As of C-Kermit 8.0, C-Kermit's "open-count" form of line locking works
- only in QNX4, not in QNX6 (this might change in a future C-Kermit
- release).
- 3.6. C-KERMIT AND SCO
- [ [358]Top ] [ [359]Contents ] [ [360]Section Contents ] [ [361]Next ]
- [ [362]Previous ]
- SECTION CONTENTS
- 3.6.1. [363]SCO XENIX
- 3.6.2. [364]SCO UNIX and OSR5
- 3.6.3. [365]Unixware
- 3.6.4. [366]Open UNIX 8
- REFERENCES
- * The comp.unix.sco.* newsgroups.
- * [367]Section 3.10 below for Unixware.
- * The following FAQs:
- The comp.sco.misc FAQ:
- [368]http://aplawrence.com/SCOFAQ/
- Caldera (SCO) comp.unix.sco.programmer FAQ:
- [369]http://www.zenez.com/cgi-bin/scoprogfaq/faq.pl
- The UnixWare 7/OpenUNIX 8 FAQ:
- [370]http://www.zenez.com/cgi-bin/scouw7faq/faq.pl
- [371]http://zenez.pcunix.com/cgi-bin/scouw7faq/faq.pl
- High Speed Modems for SCO Unix:
- [372]http://pcunix.com/Unixart/modems.html
- The UnixWare FAQ
- [373]http://www.freebird.org/faq/
- The UnixWare 1.x and 2.0 Programmer FAQ
- [374]http://www.freebird.org/faq/developer.html
- Caldera Support Knowledge Base
- [375]http://support.caldera.com/caldera
- [376]http://stage.caldera.com/ta/
- Caldera (SCO) Technical Article Search Center
- [377]http://aplawrence.com/newtosco.html
- New to SCO (Tony Lawrence)
- The same comments regarding terminal emulation and key mapping apply to
- SCO operating systems as to all other Unixes. C-Kermit is not a
- terminal emulator, and you can't use it to map F-keys, Arrow keys, etc.
- The way to do this is with xmodmap (xterm) or loadkeys (console). For a
- brief explanation, see [378]Section 3.0.5. For a fuller explanation,
- [379]ClICK HERE.
- Also see general comments on PC-based Unixes in [380]Section 3.0.
- 3.6.1. SCO XENIX
- [ [381]Top ] [ [382]Contents ] [ [383]Section Contents ] [ [384]Next ]
- Old Xenix versions... Did you know: Xenix 3.0 is *older* than Xenix
- 2.0?
- In Xenix 2.3.4 and probably other Xenix versions, momentarily dropping
- DTR to hang up a modem does not work. DTR goes down but does not come
- up again. Workaround: Use SET MODEM HANGUP-METHOD MODEM-COMMAND.
- Anybody who would like to fix this is welcome to take a look at
- tthang() in [385]ckutio.c. Also: modem signals can not be read in
- Xenix, and the maximum serial speed is 38400.
- There is all sorts of confusion among SCO versions, particularly when
- third- party communications boards and drivers are installed, regarding
- lockfile naming conventions, as well as basic functionality. As far as
- lockfiles go, all bets are off if you are using a third-party multiport
- board. At least you have the source code. Hopefully you also have a C
- compiler :-)
- Xenix 2.3.0 and later claim to support RTSFLOW and CTSFLOW, but this is
- not modern bidirectional hardware flow control; rather it implements
- the original RS-232 meanings of these signals for unidirectional
- half-duplex line access: If both RTSFLOW and CTSFLOW bits are set,
- Xenix asserts RTS when it wants to send data and waits for CTS
- assertion before it actually starts sending data (also, reportedly,
- even this is broken in Xenix 2.3.0 and 2.3.1).
- 3.6.2. SCO UNIX AND OSR5
- [ [386]Top ] [ [387]Contents ] [ [388]Section Contents ] [ [389]Next ]
- [ [390]Previous ]
- SCO systems tend to use different names (i.e. drivers) for the same
- device. Typically /dev/tty1a refers to a terminal device that has no
- modem control; open, read, write, and close operations do not depend on
- carrier. On the other hand, /dev/tty1A (same name, but with final
- letter upper case), is the same device with modem control, in which
- carrier is required (the SET LINE command does not complete until
- carrier appears, read/write operations fail if there is no carrier,
- etc).
- SCO OpenServer 5.0.5 and earlier do not support the reading of modem
- signals. Thus "show comm" does not list modem signals, and C-Kermit
- does not automatically pop back to its prompt when the modem hangs up
- the connection (drops CD). The ioctl() call for this is simply not
- implemented, at least not in the standard drivers. OSR5.0.6 attempts to
- deal with modem signals but fails; however OSR5.0.6a appears to
- function properly.
- Dialing is likely not to work well in SCO OpenServer 5.0.x because many
- of the serial-port APIs simply do not operate when using the standard
- drivers. For example, if DTR is dropped by the recommended method
- (setting speed to 0 for half a seconds, then restoring the speed), DTR
- and RTS go down but never come back up. When in doubt SET MODEM
- HANGUP-METHOD MODEM-COMMAND or SET DIAL HANGUP OFF.
- On the other hand, certain functions that might not (do not) work right
- or at all when using SCO drivers (e.g. high serial speeds, hardware
- flow control, and/or reading of modem signals) might work right when
- using third-party drivers. (Example: hardware flow control works,
- reportedly, only on uppercase device like tty1A -- not tty1a -- and
- only when CLOCAL is clear when using the SCO sio driver, but there are
- no such restrictions in, e.g., [391]Digiboard drivers).
- One user reports that he can't transfer large files with C-Kermit under
- SCO OSR5.0.0 and 5.0.4 -- after the first 5K, everything falls apart.
- Same thing without Kermit -- e.g. with ftp over a PPP connection.
- Later, he said that replacing SCO's SIO driver with FAS, an alternative
- communications driver, made the problem go away:
- [392]ftp://ftp.fu-berlin.de/pub/unix/driver/fas
- With regard to bidirectional serial ports on OpenServer 5.0.4, the
- following advice appeared on an SCO-related newsgroup:
- No amount of configuration information is going to help you on 5.0.4
- unless it includes the kludge for the primary problem. With almost
- every modem, the 5.0.4 getty will barf messages and may or may not
- connect. There are 2 solutions and only one works on 5.0.4. Get the
- atdialer binary from a 5.0.0 system and substitute it for the native
- 5.0.4 atdialer. The other solution is to upgrade to 5.0.5. And, most
- of all, on any OpenServer products, do NOT run the badly broken
- Modem Manager. Configure the modems in the time honored way that
- dates back to Xenix.
- Use SCO-provided utilities for switching the directionality of a modem
- line, such as "enable" and "disable" commands. For example, to dial out
- on tty1a, which is normally set up for logins:
- disable tty1a
- kermit -l /dev/tty1a
- enable tty1a
- If a tty device is listed as an ACU in /usr/lib/uucp/Devices and is
- enabled, getty resets the ownership and permissions to uucp.uucp and
- 640 every time the device is released. If you want to use the device
- only for dialout, and you want to specify other owners or permissions,
- you should disable it in /usr/lib/uucp/Devices; this will prevent getty
- from doing things to it. You should also changes the device's file
- modes in /etc/conf/node.d/sio by changing fields 5-7 for the desired
- device(s); this determines how the devices are set if you relink the
- kernel.
- One SCO user of C-Kermit 5A(190) reported that only one copy of Kermit
- can run at a time when a Stallion Technologies multiport boards are
- installed. Cause, cure, and present status unknown (see [393]Section 14
- for more info regarding Stallion).
- Prior to SCO OpenServer 5.0.4, the highest serial port speed supported
- by SCO was 38400. However, in some SCO versions (e.g. OSR5) it is
- possible to map rarely-used lower speeds (like 600 and 1800) to higher
- ones like 57600 and 115200. To find out how, go to
- [394]http://www.sco.com/ and search for "115200". In OSR5.0.4, serial
- speeds up to 921600 are supported through the POSIX interface; C-Kermit
- 6.1.193 or later, when built for OSR5.0.4 using /bin/cc (NOT the UDK,
- which hides the high-speed definitions from CPP), supports these
- speeds, but you might be able to run this binary on earlier releases to
- get the high serial speeds, depending on various factors, described by
- Bela Lubkin of SCO:
- Serial speeds under SCO Unix / Open Desktop / OpenServer
- ========================================================
- Third party drivers (intelligent serial boards) may provide any speeds
- they desire; most support up to 115.2Kbps.
- SCO's "sio" driver, which is used to drive standard serial ports with
- 8250/16450/16550 and similar UARTs, was limited to 38400bps in older
- releases. Support for rates through 115.2Kbps was added in the
- following releases:
- SCO OpenServer Release 5.0.0 (requires supplement "rs40b")
- SCO OpenServer Release 5.0.2 (requires supplement "rs40a" or "rs40b")
- SCO OpenServer Release 5.0.4 or later
- SCO Internet FastStart Release 1.0.0 or later
- SCO supplements are at [395]ftp://ftp.sco.com/; the "rs40" series are
- under directory /Supplements/internet
- Kermit includes the high serial speeds in all OSR5 builds, but that
- does not necessarily mean they work. For example, on our in-house 5.0.5
- system, SET SPEED 57600 or higher seems to succeed (no error occurs)
- but when we read the speed back the driver says it is 50. Similarly,
- 76800 becomes 75, and 115200 becomes 110. Testing shows the resulting
- speed is indeed the low one we read back, not the high one we asked
- for. Moral: Use speeds higher than 38400 with caution on SCO OSR5.
- Reportedly, if you have a script that makes a TCP/IP SET HOST (e.g.
- Telnet) connection to SCO 3.2v4.2 with TCP/IP 1.2.1, and then does the
- following:
- script $ exit
- hangup
- this causes a pseudoterminal (pty) to be consumed on the SCO system; if
- you do it enough times, it will run out of ptys. An "exit" command is
- being sent to the SCO shell, and a HANGUP command is executed locally,
- so the chances are good that both sides are trying to close the
- connection at once, perhaps inducing a race condition in which the
- remote pty is not released. It was speculated that this would be fixed
- by applying SLS net382e, but it did not. Meanwhile, the workaround is
- to insert a "pause" between the SCRIPT and HANGUP commands. (The
- situation with later SCO releases is not known.)
- SCO UNIX and OpenServer allow their console and/or terminal drivers to
- be configured to translate character sets for you. DON'T DO THIS WHEN
- USING KERMIT! First of all, you don't need it -- Kermit itself already
- does this for you. And second, it will (a) probably ruin the formatting
- of your screens (depending on which emulation you are using); and (b)
- interfere with all sorts of other things -- legibility of non-ASCII
- text on the terminal screen, file transfer, etc. Use:
- mapchan -n
- to turn off this feature.
- Note that there is a multitude of SCO entries in the makefile, many of
- them exhibiting an unusually large number of compiler options. Some
- people actually understand all of this. Reportedly, things are settling
- down with SCO OpenServer 5.x and Unixware 7 (and Open UNIX 8 and who
- knows what the next one will be -- Linux probably) -- the SCO UDK
- compiler is said to generate binaries that will run on either platform,
- by default, automatically. When using gcc or egcs, on the other hand,
- differences persist, plus issues regarding the type of binary that is
- generated (COFF, ELF, etc), and where and how it can run. All of this
- could stand further clarification by SCO experts.
- 3.6.3. Unixware
- [ [396]Top ] [ [397]Contents ] [ [398]Section Contents ] [ [399]Next ]
- [ [400]Previous ]
- Unixware changed hands several times before landing at SCO, and so has
- its [401]own section in this document. (Briefly: AT&T UNIX Systems
- Laboratories sold the rights to the UNIX name and to System V R4 (or
- R5?) to Novell; later Novell spun its UNIX division off into a new
- company called Univel, which eventually was bought by SCO, which later
- was bought by Caldera, which later sort of semi-spun-off SCO...)
- 3.6.4. Open UNIX 8
- [ [402]Top ] [ [403]Contents ] [ [404]Section Contents ] [
- [405]Previous ]
- SCO was bought by Caldera in 2000 or 2001 and evolved Unixware 7.1 into
- Caldera Open UNIX 8.00. It's just like Unixware 7.1 as far as Kermit is
- concerned (the Unixware 7.1 makefile target works for Open UNIX 8.00,
- and in fact a Unixware 7.1 Kermit binary built on Unixware 7.1 runs
- under OU8; a separate OU8 makefile target exists simply to generate an
- appropriate program startup herald). Open Unix is now defunct;
- subsequent releases are called UnixWare again (e.g. UnixWare 7.1.3).
- 3.7. C-KERMIT AND SOLARIS
- [ [406]Top ] [ [407]Contents ] [ [408]Section Contents ] [ [409]Next ]
- [ [410]Previous ]
- SECTION CONTENTS
- 3.7.1. [411]Serial Port Configuration
- 3.7.2. [412]Serial Port Problems
- 3.7.3. [413]SunLink X.25
- 3.7.4. [414]Sun Workstation Keyboard Mapping
- 3.7.5. [415]Solaris 2.4 and Earlier
- REFERENCES
- * The [416]comp.unix.solaris newsgroup
- * [417]http://access1.sun.com/
- * [418]http://docs.sun.com/
- * [419]http://www.sunhelp.com/
- * [420]http://www.wins.uva.nl/pub/solaris/solaris2/
- * [421]http://www.wins.uva.nl/cgi-bin/sfaq.cgi
- * [422]ftp://ftp.wins.uva.nl/pub/solaris
- * [423]http://www.science.uva.nl/pub/solaris/solaris2.html
- And about serial communications in particular, see "Celeste's Tutorial
- on Solaris 2.x Modems and Terminals":
- [424]http://www.stokely.com/
- In particular:
- [425]http://www.stokely.com/unix.sysadm.resources/faqs.sun.html
- For PC-based Solaris, also see general comments on PC-based Unixes in
- [426]Section 3.0. Don't expect Solaris or any other kind of Unix to
- work right on a PC until you resolve all interrupt conflicts. Don't
- expect to be able to use COM3 or COM4 (or even COM2) until you have
- configured their addresses and interrupts.
- 3.7.1. Serial Port Configuration
- [ [427]Top ] [ [428]Contents ] [ [429]Section Contents ] [ [430]Section
- Contents ] [ [431]Next ]
- Your serial port can't be used -- or at least won't work right -- until
- it is enabled in Solaris. For example, you get a message like "SERIAL:
- Operation would block" when attempting to dial. This probably indicates
- that the serial port has not been enabled for use with modems. You'll
- need to follow the instructions in your system setup or management
- manual, such as (e.g.) the Desktop SPARC Sun System & Network Manager's
- Guide, which should contain a section "Setting up Modem Software"; read
- it and follow the instructions. These might (or might not) include
- running a program called "eeprom", editing some system configuration
- file (such as, for example:
- /platform/i86pc/kernel/drv/asy.conf
- and then doing a configuration reboot, or running some other programs
- like drvconfig and devlinks. "man eeprom" for details.
- Also, on certain Sun models like IPC, the serial port hardware might
- need to have a jumper changed to make it an RS-232 port rather than
- RS-423.
- eeprom applies only to real serial ports, not to "Spiff" devices
- (serial port expander), in which case setup with Solaris' admintool is
- required.
- Another command you might need to use is pmadm, e.g.:
- pmadm -d -p zsmon -s tty3
- pmadm -e -p zsmon -s tty3
- You can use the following command to check if a process has the device
- open:
- fuser -f /dev/term/3
- In some cases, however (according to Sun support, May 2001) "It is
- still possible that a zombie process has hold of the port EVEN IF there
- is no lock file and the fuser command comes up empty. In that case, the
- only way to resolve the problem is by rebooting."
- If you can't establish communication through a serial port to a device
- that is not asserting CD (Carrier Detect), try setting the environment
- variable "ttya-ignore-cd" to "true" (replace "ttya" with the port
- name).
- 3.7.2. Serial Port Problems
- [ [432]Top ] [ [433]Contents ] [ [434]Section Contents ] [ [435]Next ]
- [ [436]Previous ]
- Current advice from Sun is to always the /dev/cua/x devices for dialing
- out, rather than the /dev/term/x. Nevertheless, if you have trouble
- dialing out with one, try the other.
- Reportedly, if you start C-Kermit and "set line" to a port that has a
- modem connected to it that is not turned on, and then "set flow
- rts/cts", there might be some (unspecified) difficulties closing the
- device because the CTS signal is not coming in from the modem.
- 3.7.3. SunLink X.25
- [ [437]Top ] [ [438]Contents ] [ [439]Section Contents ] [ [440]Next ]
- [ [441]Previous ]
- The built-in SunLink X.25 support for Solaris 2.3/2.4./25 and SunLink
- 8.01 or 9.00 works OK provided the X.25 system has been installed and
- initialized properly. Packet sizes might need to be reduced to 256,
- maybe even less, depending on the configuration of the X.25
- installation. On one connection where C-Kermit 6.0 was tested, very
- large packets and window sizes could be used in one direction, but only
- very small ones would work in the other.
- In any case, according to Sun, C-Kermit's X.25 support is superfluous
- with SunLink 8.x / Solaris 2.3. Quoting an anonymous Sun engineer:
- ... there is now no need to include any X.25 code within kermit. As
- of X.25 8.0.1 we support the use of kermit, uucp and similar
- protocols over devices of type /dev/xty. This facility was there in
- 8.0, and should also work on the 8.0 release if patch 101524 is
- applied, but I'm not 100% sure it will work in all cases, which is
- why we only claim support from 8.0.1 onwards.
- When configuring X.25, on the "Advanced Configuration->Parameters"
- screen of the x25tool you can select a number of XTY devices. If you
- set this to be > 1, press Apply, and reboot, you will get a number
- of /dev/xty entries created.
- Ignore /dev/xty0, it is a special case. All the others can be used
- exactly as if they were a serial line (e.g. /dev/tty) connected to a
- modem, except that instead of using Hayes-style commands, you use
- PAD commands.
- From kermit you can do a 'set line' command to, say, /dev/xty1, then
- set your dialing command to be "CALL 12345678", etc. All the usual
- PAD commands will work (SET, PAR, etc).
- I know of one customer in Australia who is successfully using this,
- with kermit scripts, to manage some X.25-connected switches. He used
- standard kermit, compiled for Solaris 2, with X.25 8.0 xty devices.
- 3.7.4. Sun Workstation Keyboard Mapping
- [ [442]Top ] [ [443]Contents ] [ [444]Section Contents ] [ [445]Next ]
- [ [446]Previous ]
- Hints for using a Sun workstation keyboard for VT emulation when
- accessing VMS, from the [447]comp.os.vms newsgroup:
- From: Jerry Leichter <leichter@smarts.com>
- Newsgroups: comp.os.vms
- Subject: Re: VT100 keyboard mapping to Sun X server
- Date: Mon, 19 Aug 1996 12:44:21 -0400
- > I am stuck right now using a Sun keyboard (type 5) on systems
- running SunOS
- > and Solaris. I would like to use EVE on an OpenVMS box with
- display back to
- > the Sun. Does anyone know of a keyboard mapping (or some other
- procedure)
- > which will allow the Sun keyboard to approximate a VT100/VT220?
- You can't get it exactly - because the keypad has one fewer key -
- but you can come pretty close. Here's a set of keydefs I use:
- keycode 101=KP_0
- keycode 119=KP_1
- keycode 120=KP_2
- keycode 121=KP_3
- keycode 98=KP_4
- keycode 99=KP_5
- keycode 100=KP_6
- keycode 75=KP_7
- keycode 76=KP_8
- keycode 77=KP_9
- keycode 52=KP_F1
- keycode 53=KP_F2
- keycode 54=KP_F3
- keycode 57=KP_Decimal
- keycode 28=Left
- keycode 29=Right
- keycode 30=KP_Separator
- keycode 105=KP_F4
- keycode 78=KP_Subtract
- keycode 8=Left
- keycode 10=Right
- keycode 32=Up
- keycode 33=Down
- keycode 97=KP_Enter
- Put this in a file - I use "keydefs" in my home directory and feed
- it into xmodmap:
- xmodmap - <$HOME/keydefs
- This takes care of the arrow keys and the "calculator" key cluster.
- The "+" key will play the role of the DEC "," key. The Sun "-" key
- will be like the DEC "-" key, though it's in a physically different
- position - where the DEC PF4 key is. The PF4 key is ... damn, I'm
- not sure where "key 105" is. I *think* it may be on the leftmost key
- of the group of four just above the "calculator" key cluster.
- I also execute the following (this is all in my xinitrc file):
- xmodmap -e 'keysym KP_Decimal = KP_Decimal'
- xmodmap -e 'keysym BackSpace = Delete BackSpace' \
- -e 'keysym Delete = BackSpace Delete'
- xmodmap -e 'keysym KP_Decimal = Delete Delete KP_Decimal'
- xmodmap -e 'add mod1 = Meta_R'
- xmodmap -e 'add mod1 = Meta_L'
- Beware of one thing about xmodmap: Keymap changes are applied to the
- *whole workstation*, not just to individual windows. There is, in
- fact, no way I know of to apply them to individual windows. These
- definitions *may* confuse some Unix programs (and/or some Unix
- users).
- If you're using Motif, you may also need to apply bindings at the
- Motif level. If just using xmodmap doesn't work, I can try and dig
- that stuff up for you.
- 3.7.5. Solaris PPP Connections
- [ [448]Top ] [ [449]Contents ] [ [450]Section Contents ] [ [451]Next ]
- [ [452]Previous ]
- The following is a report from a user of C-Kermit 8.0 on Solaris 8 and
- 9, who had complained that while Kermit file transfers worked perfectly
- on direct (non-PPP) dialout connections, they failed miserably on PPP
- connections. We suggested that the PPP dialer probably was not setting
- the port and/or modem up in the same way that Kermit did:
- I want to get back on this and tell you what the resolution was. You
- pointed me in the direction of flow control, which turned out to be
- the key.
- Some discussion on the comp.unix.solaris newsgroup led to some
- comments from Greg Andrews about the need to use the uucp driver to
- talk to the modem (/dev/cua/a). I had to remind Greg that no matter
- what the manpages for the zs and se drivers say, the ppp that Sun
- released with Solaris 8 7/01, and has in Solaris 9, is a setuid root
- program, and simply trying to make a pppd call from user space
- specifying /dev/cua/a would fail because of permissions. Greg
- finally put the question to the ppp people, who came back with
- information that is not laid out anywhere in the docs available for
- Solaris users. Namely, put /dev/cua/a in one of the privileged
- options files in the /etc/ppp directory. That, plus resetting the
- OBP ttya-ignore-cd flag (this is Sun hardware) to false, seems to
- have solved the problems.
- While I note that I had installed Kermit suid to uucp to use
- /dev/cua/a on this particular box, it seems to run fine through
- /dev/term/a. Not so with pppd.
- With this change in place, I seem to be able to upload and download
- through telnet run on Kermit with the maximum length packets. I note
- that the window allocation display does show STREAMING, using
- telnet. Running ssh on Kermit, I see the standard 1 of 30 windows
- display, and note that there appears to be a buffer length limit
- between 1000 and 2000 bytes. Run with 1000, and it's tick-tock,
- solid as a rock. With 2000 I see timeout errors and RTS/CTS action
- on the modem.
- Kermit's packet-length and other controls let you make adjustments like
- this to get around whatever obstacles might be thrown up -- in this
- case (running Kermit over ssh), the underling Solaris PTY driver.
- 3.7.6. Solaris 2.4 and Earlier
- [ [453]Top ] [ [454]Contents ] [ [455]Section Contents ] [
- [456]Previous ]
- C-Kermit can't be compiled successfully under Solaris 2.3 using
- SUNWspro cc 2.0.1 unless at least some of the following patches are
- applied to cc (it is not known which one(s), if any, fix the problem):
- * 100935-01 SparcCompiler C 2.0.1: bad code generated when addresses
- of two double arguments are involved
- * 100961-05 SPARCcompilers C 2.0.1: conditional expression with
- function returning structure gives wrong value
- * 100974-01 SparcWorks 2.0.1: dbx jumbo patch
- * 101424-01 SPARCworks 2.0.1 maketool SEGV's instantly on Solaris 2.3
- With unpatched cc 2.0.1, the symptom is that certain modules generate
- truncated object files, resulting in many unresolved references at link
- time.
- The rest of the problems in this section have to do with
- bidirectional terminal ports and the Solaris Port Monitor. A bug in
- C-Kermit 5A ticked a bug in Solaris. The C-Kermit bug was fixed in
- version 6.0, and the Solaris bug was fixed in 2.4 (I think, or maybe
- 2.5).
- Reportedly, "C-Kermit ... causes a SPARCstation running Solaris 2.3 to
- panic after the modem connects. I have tried compiling C-Kermit with
- Sun's unbundled C compiler, with GCC Versions 2.4.5 and 2.5.3, with
- make targets 'sunos51', 'sunos51tcp', 'sunos51gcc', and even 'sys5r4',
- and each time it compiles and starts up cleanly, but without fail, as
- soon as I dial the number and get a 'CONNECT' message from the modem, I
- get:
- BAD TRAP
- kermit: Data fault
- kernel read fault at addr=0x45c, pme=0x0
- Sync Error Reg 80 <INVALID>
- ...
- panic: Data Fault.
- ...
- Rebooting...
- The same modem works fine for UUCP/tip calling." Also (reportedly),
- this only happens if the dialout port is configured as in/out via
- admintool. If it is configured as out-only, no problem. This is the
- same dialing code that works on hundreds of other System-V based Unix
- OS's. Since it should be impossible for a user program to crash the
- operating system, this problem must be chalked up to a Solaris bug.
- Even if you SET CARRIER OFF, CONNECT, and dial manually by typing
- ATDTnnnnnnn, the system panics as soon as the modem issues its CONNECT
- message. (Clearly, when you are dialing manually, C-Kermit does not
- know a thing about the CONNECT message, and so the panic is almost
- certainly caused by the transition of the Carrier Detect (CD) line from
- off to on.) This problem was reported by many users, all of whom say
- that C-Kermit worked fine on Solaris 2.1 and 2.2. If the speculation
- about CD is true, then a possible workaround might be to configure the
- modem to leave CD on (or off) all the time. Perhaps by the time you
- read this, a patch will have been issued for Solaris 2.3.
- The following is from Karl S. Marsh, Systems & Networks Administrator,
- AMBIX Systems Corp, Rochester, NY:
- Environment: Solaris 2.3 Patch 101318-45 C-Kermit 5A(189) (and
- presumably this applies to 188 and 190 also). eeprom setting:
- ttya-rts-dtr-off=false
- ttya-ignore-cd=false
- ttya-mode=19200,8,n,8,-
- To use C-Kermit on a bidirectional port in this environment, do not
- use admintool to configure the port. Use admintool to delete any
- services running on the port and then quit admintool and issue the
- following command:
- pmadm -a -p zsmon -s ttyb -i root -fu -v 1 -m "`ttyadm -b -d /dev/term/b \
- -l conttyH -m ldterm,ttcompat -s /usr/bin/login -S n`"
- [NOTE: This was copied from a blurry fax, so please check it
- carefully] where:
- -a = Add service
- -p = pmtag (zsmon)
- -s = service tag (ttyb)
- -i = id to be associated with service tag (root)
- -fu = create utmp entry
- -v = version of ttyadm
- -m = port monitor-specific portion of the port monitor administrative file
- entry for the service
- -b = set up port for bidirectional use
- -d = full path name of device
- -l = which ttylabel in the /etc/ttydefs file to use
- -m = a list of pushable STREAMS modules
- -s = pathname of service to be invoked when connection request received
- -S = software carrier detect on or off (n = off)
- "This is exactly how I was able to get Kermit to work on a
- bi-directional port without crashing the system."
- On the Solaris problem, also see SunSolve Bug ID 1150457 ("Using
- C-Kermit, get Bad Trap on receiving prompt from remote system").
- Another user reported "So, I have communicated with the Sun tech
- support person that submitted this bug report [1150457]. Apparently,
- this bug was fixed under one of the jumbo kernel patches. It would seem
- that the fix did not live on into 101318-45, as this is EXACTLY the
- error that I see when I attempt to use kermit on my system."
- Later (Aug 94)... C-Kermit dialout successfully tested on a Sun4m with
- a heavily patched Solaris 2.3. The patches most likely to have been
- relevant:
- * 101318-50: SunOS 5.3: Jumbo patch for kernel (includes libc, lockd)
- * 101720-01: SunOS 5.3: ttymon - prompt not always visible on a modem
- connection
- * 101815-01: SunOS 5.3: Data fault in put() NULL queue passed from
- ttycommon_qfull()
- * 101328-01: SunOS 5.3: Automation script to properly setup tty ports
- prior to PCTS execution
- Still later (Nov 94): another user (Bo Kullmar in Sweden) reports that
- after using C-Kermit to dial out on a bidirectional port, the port
- might not answer subsequent incoming calls, and says "the problem is
- easy enough to fix with the Serial Port Manager; I just delete the
- service and install it again using the graphical interface, which
- underneath uses commands like sacadm and pmadm." Later Bo reports, "I
- have found that if I run Kermit with the following script then it
- works. This script is for /dev/cua/a, "-s a" is the last a in
- /dev/cua/a:
- #! /bin/sh
- kermit
- sleep 2
- surun pmadm -e -p zsmon -s a
- 3.8. C-KERMIT AND SUNOS
- [ [457]Top ] [ [458]Contents ] [ [459]Section Contents ] [ [460]Next ]
- [ [461]Previous ]
- For additional information, see "Celeste's Tutorial on SunOS 4.1.3+
- Modems and Terminals":
- [462]http://www.stokely.com/
- For FAQs, etc, from Sun, see:
- * [463]http://access1.sun.com/
- For history of Sun models and SunOS versions, see (should be all the
- same):
- * [464]http://www.ludd.luth.se/~bear/project/sun/sun.hardware.txt
- * [465]ftp://ftp.netcom.com/pub/ru/rubicon/sun.hdwr.ref
- * [466]ftp://ftp.intnet.net/pub/SUN/Sun-Hardware-Ref
- Sun SPARCstation users should read the section "Setting up Modem
- Software" in the Desktop SPARC Sun System & Network Manager's Guide. If
- you don't set up your serial ports correctly, Kermit (and other
- communications software) won't work right.
- Also, on certain Sun models like IPC, the serial port hardware might
- need to have a jumper changed to make it an RS-232 port rather than
- RS-423.
- Reportedly, C-Kermit does not work correctly on a Sun SPARCstation in
- an Open Windows window with scrolling enabled. Disable scrolling, or
- else invoke Kermit in a terminal emulation window (xterm, crttool,
- vttool) under SunView (this might be fixed in later SunOS releases).
- On the Sun with Open Windows, an additional symptom has been reported:
- outbound SunLink X.25 connections "magically" translate CR typed at the
- keyboard into LF before transmission to the remote host. This doesn't
- happen under SunView.
- SET CARRIER ON, when used on the SunOS 4.1 version of C-Kermit
- (compiled in the BSD universe), causes the program to hang
- uninterruptibly when SET LINE is issued for a device that is not
- asserting carrier. When Kermit is built in the Sys V universe on the
- same computer, there is no problem (it can be interrupted with Ctrl-C).
- This is apparently a limitation of the BSD-style tty driver.
- SunOS 4.1 C-Kermit has been observed to dump core when running a
- complicated script program under cron. The dump invariably occurs in
- ttoc(), while trying to output a character to a TCP/IP TELNET
- connection. ttoc() contains a write() call, and when the system or the
- network is very busy, the write() call can get stuck for long periods
- of time. To break out of deadlocks caused by stuck write() calls, there
- is an alarm around the write(). It is possible that the core dump
- occurs when this alarm signal is caught. (This one has not been
- observed recently -- possibly fixed in edit 190.)
- On Sun computers with SunOS 4.0 or 4.1, SET FLOW RTS/CTS works only if
- the carrier signal is present from the communication device at the time
- when C-Kermit enters packet mode or CONNECT mode. If carrier is not
- sensed (e.g. when dialing), C-Kermit does not attempt to turn on
- RTS/CTS flow control. This is because the SunOS serial device driver
- does not allow characters to be output if RTS/CTS is set (CRTSCTS) but
- carrier (and DSR) are not present. Workaround (maybe): SET CARRIER OFF
- before giving the SET LINE command, establish the connection, then SET
- FLOW RTS/CTS
- It has also been reported that RTS/CTS flow control under SunOS 4.1
- through 4.1.3 works only on INPUT, not on output, and that there is a
- patch from Sun to correct this problem: Patch-ID# T100513-04, 20 July
- 1993 (this patch might apply only to SunOS 4.1.3). It might also be
- necessary to configure the eeprom parameters of the serial port; e.g.
- do the following as root at the shell prompt:
- eeprom ttya-ignore-cd=false
- eeprom ttya-rts-dtr-off=true
- There have been reports of file transfer failures on Sun-3 systems when
- using long packets and/or large window sizes. One user says that when
- this happens, the console issues many copies of this message:
- chaos vmunix: zs1: ring buffer overflow
- This means that SunOS is not scheduling Kermit frequently enough to
- service interrupts from the zs serial device (Zilog 8350 SCC serial
- communication port) before its input silo overflows. Workaround: use
- smaller packets and/or a smaller window size, or use "nice" to increase
- Kermit's priority. Use hardware flow control if available, or remove
- other active processes before running Kermit.
- SunLink X.25 support in C-Kermit 5A(190) was built and tested
- successfully under SunOS 4.1.3b and SunLink X.25 7.00.
- 3.9. C-KERMIT AND ULTRIX
- [ [467]Top ] [ [468]Contents ] [ [469]Section Contents ] [ [470]Next ]
- [ [471]Previous ]
- See also: The [472]comp.unix.ultrix and [473]comp.sys.dec newsgroups.
- There is no hardware flow control in Ultrix. That's not a Kermit
- deficiency, but an Ultrix one.
- When sending files to C-Kermit on a Telnet connection to a remote
- Ultrix system, you must SET PREFIXING ALL (or at least prefix more
- control characters than are selected by SET PREFIXING CAUTIOUS).
- Reportedly, DEC ULTRIX 4.3 is immune to C-Kermit's disabling of
- SIGQUIT, which is the signal that is generated when the user types
- Ctrl-\, which kills the current process (i.e. C-Kermit) and dumps core.
- Diagnosis and cure unknown. Workaround: before starting C-Kermit -- or
- for that matter, when you first log in because this applies to all
- processes, not just Kermit -- give the following Unix command:
- stty quit undef
- Certain operations driven by RS-232 modem signal do not work on
- DECstations or other DEC platforms whose serial interfaces use MMP
- connectors (DEC version of RJ45 telephone jack with offset tab). These
- connectors convey only the DSR and DTR modem signals, but not carrier
- (CD), RTS, CTS, or RI. Use SET CARRIER OFF to enable communication, or
- "hotwire" DSR to CD.
- The maximum serial speed on the DECstation 5000 is normally 19200, but
- various tricks are available (outside Kermit) to enable higher rates.
- For example, on the 5000/200, 19200 can be remapped (somehow, something
- to do with "a bit in the SIR", whatever that is) to 38400, but in
- software you must still refer to this speed as 19200; you can't have
- 19200 and 38400 available at the same time.
- 19200, reportedly, is also the highest speed supported by Ultrix, but
- NetBSD reportedly supports speeds up to 57600 on the DECstation,
- although whether and how well this works is another question.
- In any case, given the lack of hardware flow control in Ultrix, high
- serial speeds are problematic at best.
- 3.10. C-KERMIT AND UNIXWARE
- [ [474]Top ] [ [475]Contents ] [ [476]Section Contents ] [ [477]Next ]
- [ [478]Previous ]
- See also:
- * The Freebird Project (Unixware software repository)
- [479]http://www.freebird.org/
- * The UnixWare FAQ: [480]http://www.freebird.org/faq/
- * The following newsgroups:
- + [481]comp.unix.unixware.misc
- + [482]comp.unix.sco.misc.
- Also see general comments on PC-based Unixes in [483]Section 3.0. By
- the way, this section is separate from the SCO (Caldera) section
- because at the time this section was started, Unixware was owned by a
- company called Univel. Later it was sold to Novell, and then to SCO.
- Still later, SCO was sold to Caldera.
- In Unixware 2.0 and later, the preferred serial device names (drivers)
- are /dev/term/00 (etc), rather than /dev/tty00 (etc). Note the
- following correspondence of device names and driver characteristics:
- New name Old name Description
- /dev/term/00 /dev/tty00 ???
- /dev/term/00h /dev/tty00h Modem signals and hardware flow control
- /dev/term/00m /dev/tty00m Modem signals(?)
- /dev/term/00s /dev/tty00s Modem signals and software flow control
- /dev/term/00t /dev/tty00t ???
- Lockfile names use device.major.minor numbers, e.g.:
- /var/spool/locks/LK.7679.003.005
- The minor number varies according to the device name suffix (none, h,
- m, s, or t). Only the device and major number are compared, and thus
- all of the different names for the same physical device (e.g. all of
- those shown in the table above) interlock effectively.
- Prior to UnixWare 7, serial speeds higher than 38400 are not supported.
- In UnixWare 7, we also support 57600 and 115200, plus some unexpected
- ones like 14400, 28800, and 76800, by virtue of a strange new
- interface, evidently peculiar to UnixWare 7, discovered while digging
- through the header files: tcsetspeed(). Access to this interface is
- allowed only in POSIX builds, and thus the UnixWare 7 version of
- C-Kermit is POSIX-based, unlike C-Kermit for Unixware 1.x and 2.x
- (since the earlier UnixWare versions did not support high serial
- speeds, period).
- HOWEVER, turning on POSIX features engages all of the "#if
- (!_POSIX_SOURCE)" clauses in the UnixWare header files, which in turn
- prevent us from having modem signals, access to the hardware flow
- control APIs, select(), etc -- in short, all the other things we need
- in communications software, especially when high speeds are used. Oh
- the irony. And so C-Kermit must be shamelessly butchered -- as it has
- been so many times before -- to allow us to have the needed features
- from the POSIX and non-POSIX worlds. See the UNIXWAREPOSIX sections of
- [484]ckutio.c.
- After the butchery, we wind up with Unixware 2.x having full
- modem-signal capability, but politically-correct Unixware 7.x lacking
- the ability to automatically detect a broken connection when carrier
- drops.
- Meanwhile the Unixware tcsetspeed() function allows any number at all
- (any long, 0 or positive) as an argument and succeeds if the number is
- a legal bit rate for the serial device, and fails otherwise. There is
- no list anywhere of legal speeds. Thus the SET SPEED keyword table
- ("set speed ?" to see it) is hardwired based on trial and error with
- all known serial speeds, the maximum being 115200. However, to allow
- for the possibility that other speeds might be allowed in the future
- (or with different port drivers), the SET SPEED command for UnixWare 7
- only allows you to specify any number at all; a warning is printed if
- the number is not in the list, but the number is accepted anyway; the
- command succeeds if tcsetspeed() accepts the number, and fails
- otherwise.
- In C-Kermit 8.0 testing, it was noticed that the POSIX method for
- hanging up the phone by dropping DTR (set speed 0, pause, restore
- speed) did not actually drop DTR. The APIs do not return any error
- indication, but nothing happens. I changed tthang() to skip the special
- case I had made for Unixware and instead follow the normal path: if
- TIOCSDTR is defined use that, otherwise blah blah... It turns out
- TIOCSDTR *is* defined, and it works.
- So in Unixware (at least in 2.1.3) we can read modem signals, hangup by
- toggling DTR, and so on, BUT... But once the remote hangs up and
- Carrier drops, the API for reading modem signals ceases to function;
- although the device is still open, the TIOCMGET ioctl always raises
- errno 6 = ENXIO, "No such device or address".
- Old business:
- Using C-Kermit 6.0 on the UnixWare 1.1 Application Server, one user
- reported a system panic when the following script program is executed:
- set line /dev/tty4
- set speed 9600
- output \13
- connect
- The panic does not happen if a PAUSE is inserted:
- set line /dev/tty4
- set speed 9600
- pause 1
- output \13
- connect
- This is using a Stallion EasyIO card installed as board 0 on IRQ 12 on
- a Gateway 386 with the Stallion-supplied driver. The problem was
- reported to Novell and Stallion and (reportedly) is now fixed.
- 3.11. C-KERMIT AND APOLLO SR10
- [ [485]Top ] [ [486]Contents ] [ [487]Section Contents ] [ [488]Next ]
- [ [489]Previous ]
- Reportedly, version 5A(190), when built under Apollo SR10 using "make
- sr10-bsd", compiles, links, and executes OK, but leaves the terminal
- unusable after it exits -- the "cs7" or "cs8" (character size)
- parameter has become cs5. The terminal must be reset from another
- terminal. Cause and cure unknown. Suggested workaround: Wrap Kermit in
- a shell script something like:
- kermit @*
- stty sane
- 3.12. C-KERMIT AND TANDY XENIX 3.0
- [ [490]Top ] [ [491]Contents ] [ [492]Section Contents ] [ [493]Next ]
- [ [494]Previous ]
- C-Kermit 7.0 was too big to be built on Tandy Xenix, even in a minimum
- configuration; version 6.0 is the last one that fits.
- Reportedly, in C-Kermit 6.0, if you type lots of Ctrl-C's during
- execution of the initialization file, ghost Kermit processes will be
- created, and will compete for the keyboard. They can only be removed
- via "kill -9" from another terminal, or by rebooting. Diagnosis --
- something strange happening with the SIGINT handler while the process
- is reading the directory (it seems to occur during the SET PROMPT
- [\v(dir)] ... sequence). Cure: unknown. Workaround: don't interrupt
- C-Kermit while it is executing its init file on the Tandy 16/6000.
- 3.13. C-KERMIT AND OSF/1 (DIGITAL UNIX) (TRU64 UNIX)
- [ [495]Top ] [ [496]Contents ] [ [497]Section Contents ] [ [498]Next ]
- [ [499]Previous ]
- While putting together and testing C-Kermit 8.0, it was discovered that
- binaries built for one version of Tru64 Unix (e.g. 4.0G) might exhibit
- very strange behavior if run on a different version of Tru64 Unix (e.g.
- 5.1A). The typical symptom was that a section of the initialization
- file would be skipped, notably locating the dialing and/or network
- directory as well as finding and executing the customization file,
- ~/.mykermrc. This problem also is reported to occur on Tru64 Unix 5.0
- (Rev 732) even when running a C-Kermit binary that was built there.
- However, the Tru64 5.1A binary works correctly on 5.0. Go figure.
- When making Telnet connections to a Digital Unix or Tru64 system, and
- your Telnet client forwards your user name, the Telnet server evidently
- stuffs the username into login's standard input, and you see:
- login: ivan
- Password:
- This is clearly going to play havoc with scripts that look for
- "login:". Workaround (when Kermit is your Telnet client): SET LOGIN
- USER to nothing, to prevent Kermit from sending your user ID.
- Before you can use a serial port on a new Digital Unix system, you must
- run uucpsetup to enable or configure the port. Evidently the /dev/tty00
- and 01 devices that appear in the configuration are not usable;
- uucpsetup turns them into /dev/ttyd00 and 01, which are. Note that
- uucpsetup and other uucp-family programs are quite primitive -- they
- only know about speeds up to 9600 bps and their selection of modems
- dates from the early 1980s. None of this affects Kermit, though -- with
- C-Kermit, you can use speeds up to 115200 bps (at least in DU4.0 and
- later) and modern modems with hardware flow control and all the rest.
- Reportedly, if a modem is set for &S0 (assert DSR at all times), the
- system resets or drops DTR every 30 seconds; reportedly DEC says to set
- &S1.
- Digital Unix 3.2 evidently wants to believe your terminal is one line
- longer than you say it is, e.g. when a "more" or "man" command is
- given. This is has nothing to do with C-Kermit, but tends to annoy
- those who use Kermit or other terminal emulators to access Digital Unix
- systems. Workaround: tell Unix to "stty rows 23" (or whatever).
- Reportedly, there is some bizarre behavior when trying to use a version
- of C-Kermit built on one Digital Unix 4.0 system on another one,
- possibly due to differing OS or library revision levels; for example,
- the inability to connect to certain TCP/IP hosts. Solution: rebuild
- C-Kermit from source code on the system where you will be using it.
- Digital Unix tgetstr() causes a segmentation fault. C-Kermit 7.0 added
- #ifdefs to avoid calling this routine in Digital Unix. As a result, the
- SCREEN commands always send ANSI escape sequences -- even though curses
- knows your actual terminal type.
- Reportedly the Tru64 Unix 4.0E 1091 Telnet server does not tolerate
- streaming transfers into itself, at least not when the sending Kermit
- is on the same local network. Solution: tell one Kermit or the other
- (or both) to "set streaming off". This might or might be the case with
- earlier and/or later Tru64, Digital Unix, and OSF/1 releases.
- 3.14. C-KERMIT AND SGI IRIX
- [ [500]Top ] [ [501]Contents ] [ [502]Section Contents ] [ [503]Next ]
- [ [504]Previous ]
- See also:
- * The [505]comp.sys.sgi.misc and [506]comp.sys.sgi.admin newsgroups.
- [507]The SGI website
- * The SGI FAQ:
- + [508]http://www-viz.tamu.edu/~sgi-faq/
- + [509]ftp://viz.tamu.edu/pub/sgi/faq/
- About IRIX version numbers: "uname -a" tells the "two-digit" version
- number, such as "5.3" or "6.5". The three-digit form can be seen with
- "uname -R". (this information is unavailable at the simple API level).
- Supposedly all three-digit versions within the same two-digit version
- (e.g. 6.5.2, 6.5.3) are binary compatible; i.e. a binary built on any
- one of them should run on all others. The "m" suffix denotes just
- patches; the "f" suffix indicates that features were added.
- An IRIX binary built on lower MIPS model (Instruction Set Architecture,
- ISA) can run on higher models, but not vice versa:
- MIPS1 R3000 and below
- MIPS2 R4000
- MIPS3 R4x00
- MIPS4 R5000 and above
- Furthermore, there are different Application Binary Interfaces (ABIs):
- COFF 32 bits, IRIX 5.3, 5.2, 5.1, 4.x and below
- o32 ELF 32 bits, IRIX 5.3, 6.0 - 6.5
- N32 ELF 32 bits, IRIX 6.2 - 6.5
- N64 ELF 64 bits, IRIX 6.2 - 6.5
- Thus a prebuilt IRIX binary works on a particular machine only if (a)
- the machine's IRIX version (to one decimal place) is equal to or
- greater than the version under which the binary was built; (b) the
- machine's MIPS level is greater or equal to that of the binary; and (c)
- the machine supports the ABI of the binary. If all three conditions are
- not satisfied, of course, you can build a binary yourself from source
- code since, unlike some other Unix vendors, SGI does supply a C
- compiler and libraries.
- SGI did not supply an API for hardware flow control prior to IRIX 5.2.
- C-Kermit 6.1 and higher for IRIX 5.2 and higher supports hardware flow
- control in the normal way, via "set flow rts/cts".
- For hardware flow control on earlier IRIX and/or C-Kermit versions, use
- the ttyf* (modem control AND hardware flow control) devices and not the
- ttyd* (direct) or ttym* (modem control but no hardware flow control)
- ones, and obtain the proper "hardware handshaking" cable from SGI,
- which is incompatible with the ones for the Macintosh and NeXT even
- though they look the same ("man serial" for further info) and tell
- Kermit to "set flow keep" and "set modem flow rts/cts".
- Serial speeds higher than 38400 are available in IRIX 6.2 and later, on
- O-class machines (e.g. Origin, Octane) only, and are supported by
- C-Kermit 7.0 and later. Commands such as "set speed 115200" may be
- given on other models (e.g. Iris, Indy, Indigo) but will fail because
- the OS reports an invalid speed for the device.
- Experimentation with both IRIX 5.3 and 6.2 shows that when logged in to
- IRIX via Telnet, that remote-mode C-Kermit can't send files if the
- packet length is greater than 4096; the Telnet server evidently has
- this restriction (or bug), since there is no problem sending long
- packets on serial or rlogin connections. However, it can receive files
- with no problem if the packet length is greater than 4096. As a
- workaround, the FAST macro for IRIX includes "set send packet-length
- 4000". IRIX 6.5.1 does not have this problem, so evidently it was fixed
- some time after IRIX 6.2. Tests show file-transfer speeds are better
- (not worse) with 8K packets than with 4K packets from IRIX 6.5.1.
- Reportedly some Indys have bad serial port hardware. IRIX 5.2, for
- example, needs patch 151 to work around this; or upgrade to a later
- release. Similarly, IRIX 5.2 has several problems with serial i/o, flow
- control, etc. Again, patch or upgrade.
- Reportedly on machines with IRIX 4.0, Kermit cannot be suspended by
- typing the suspend ("swtch") character if it was started from csh, even
- though other programs can be suspended this way, and even though the Z
- and SUSPEND commands still work correctly. This is evidently because
- IRIX's csh does not deliver the SIGTSTP signal to Kermit. The reason
- other programs can be suspended in the same environment is probably
- that they do not trap SIGTSTP themselves, so the shell is doing the
- suspending rather than the application.
- Also see notes about IRIX 3.x in the [510]C-Kermit for Unix
- Installation Instructions.
- If you have problems making TCP/IP connections in versions of IRIX
- built with GCC 2.95.2, see the bugs section of:
- [511]http://freeware.sgi.com/Installable/gcc-2.95.2.html.
- Reportedly, if you allow gcc to compile C-Kermit on Irix you should be
- aware that there might be problems with some of the network code. The
- specifics are at
- [512]http://freeware.sgi.com/Installable/gcc-2.95.2.html; scroll down
- to the "known bugs" section at the end of the document.
- 3.15. C-KERMIT AND THE BEBOX
- [ [513]Top ] [ [514]Contents ] [ [515]Section Contents ] [ [516]Next ]
- [ [517]Previous ]
- See also: The [518]comp.sys.be newsgroup.
- The BeBox has been discontinued and BeOS repositioned for PC platforms.
- The POSIX parts of BeOS are not finished, nor is the sockets library,
- therefore a fully functional version of C-Kermit is not possible. In
- version 6.0 of C-Kermit, written for BeOS DR7, it was possible to:
- * set line /dev/serial2 (and probably the other serial ports)
- * set speed 115200 (and at least some of the lower baud rates)
- * connect
- * set modem type hayes (and likely others, too)
- * dial phone-number
- * set send packet-length 2048 (other lengths for both send and
- receive)
- * set receive packet length 2048
- * set file type binary (text mode works, too) (with remote kermit
- session in server mode)
- * put bedrop.jpg
- * get bedrop.jpg
- * get bedrop.jpg bedrop.jpg2
- * finish, bye
- The following do not work:
- * kermit does not detect modem hangup
- * !/RUN/PUSH [commandline command]
- * Running kermit in remote mode
- * Using other protocols (x/y/zmodem)
- * TCP networking interface (Be's TCP/IP API has a ways to go, still)
- C-Kermit does not work on BeOS DR8 because of changes in the underlying
- APIs. Unfortunately not enough changes were made to allow the regular
- POSIX-based C-Kermit to work either. Note: the lack of a fork() service
- requires the select()-based CONNECT module, but there is no select().
- There is a select() in DR8, but it doesn't work.
- C-Kermit 7.0 was built for BeOS 4.5 and works in remote mode. It does
- not include networking support since the APIs are still not there. It
- is not known if dialing out works, but probably not. Be experts are
- welcome to lend a hand.
- 3.16. C-KERMIT AND DG/UX
- [ [519]Top ] [ [520]Contents ] [ [521]Section Contents ] [ [522]Next ]
- [ [523]Previous ]
- Somebody downloaded the C-Kermit 6.0 binary built under DG/UX 5.40 and
- ran it under DG/UX 5.4R3.10 -- it worked OK except that file dates for
- incoming files were all written as 1 Jan 1970. Cause and cure unknown.
- Workaround: SET ATTRIBUTE DATE OFF. Better: Use a version of C-Kermit
- built under and for DG/UX 5.4R3.10.
- 3.17. C-KERMIT AND SEQUENT DYNIX
- [ [524]Top ] [ [525]Contents ] [ [526]Section Contents ] [ [527]Next ]
- [ [528]Previous ]
- Reportedly, when coming into a Sequent Unix (DYNIX) system through an
- X.25 connection, Kermit doesn't work right because the Sequent's
- FIONREAD ioctl returns incorrect data. To work around, use the
- 1-character-at-a-time version of myread() in ckutio.c (i.e. undefine
- MYREAD in ckutio.c and rebuild the program). This is unsatisfying
- because two versions of the program would be needed -- one for use over
- X.25, and the other for serial and TCP/IP connections.
- 3.18. C-KERMIT AND FREEBSD, OPENBSD, and NETBSD
- [ [529]Top ] [ [530]Contents ] [ [531]Section Contents ] [ [532]Next ]
- [ [533]Previous ]
- Some NebBSD users have reported difficulty escaping back from CONNECT
- mode, usually when running NetBSD on non-PC hardware. Probably a
- keyboard issue.
- NetBSD users have also reported that C-Kermit doesn't pop back to the
- prompt if the modem drops carrier. This needs to be checked out & fixed
- if possible.
- (All the above seems to work properly in C-Kermit 7.0 and later.)
- 3.19. C-KERMIT AND MAC OS X
- [ [534]Top ] [ [535]Contents ] [ [536]Section Contents ] [ [537]Next ]
- [ [538]Previous ]
- Mac OS X is Apple's 4.4BSD Unix variety, closely related to FreeBSD,
- but different. "uname -a" is singularly uninformative, as in Linux,
- giving only the Darwin kernel version number. The way to find out the
- actual Mac OS X version is with
- /usr/bin/sw_vers -productName
- /usr/bin/sw_vers -productVersion
- or:
- fgrep -A 1 'ProductVersion'
- /System/Library/CoreServices/SystemVersion.plist
- Here are some points to be aware of:
- * A big gotcha for Kermit users is that Mac OS X does not support
- serial ports and, as far as I can tell, doesn't support its
- built-in modem either, for anything other than making Internet
- connections. Macintoshes capable of running Mac OS X, such as the
- G5 and later, come without serial ports and without any APIs to
- support them, and also without the UUCP family of programs
- (including cu), nor any standard for serial-port lockfile
- directory.
- * Early versions of Mac OS X came without Curses, Termlib, or
- Terminfo libraries. Later versions seem to have ncurses (it would
- seem that Mac OS X 10.3.9 was the first mature and complete version
- of Mac OS X). Kermit uses curses for its file-transfer display. See
- elsewhere about curses-vs-ncurses confusion.
- * In the HFS+ file system, filenames are case-folded. Thus "makefile"
- and "Makefile" are the same file. So, for example, suppose you are
- sending two distinct files, Foo and FOO, from (say) Linux to Mac OS
- X. This will produce a file collision that will be handled
- according to Mac OS X C-Kermit's FILE COLLISION setting, which by
- default is BACKUP, so the Mac will wind up with files called FOO
- and Foo.~1~.
- * HSF+ files that are composed of a resource fork and a data fork...
- I doubt that C-Kermit does anything useful with them. There is no
- code in C-Kermit for traditional two-forked Macintosh files, but it
- could be added if there is any demand (code for this existed in
- [539]Mac Kermit, the old pre-Mac-OS-X Macintosh version of
- C-Kermit).
- * In case you want to transfer a traditional Macintosh text file (or
- data fork of a file that is plain text), you can use these C-Kermit
- commands:
- set file eol cr
- set file character-set apple-quickdraw
- send /text filename
- * File or pathnames that include spaces must be enclosed in either
- doublequotes or curly braces in C-Kermit commands.
- * Mac OS X can use a third-party package manager called "fink".
- Various fink packages for C-Kermit are floating around that are not
- standard releases. For example, there's a C-Kermit 8.0.201 package
- in which C-Kermit was modified (at least) to use a UUCP lockfile
- directory that does not exist on vanilla Mac OS X systems.
- Mac OS X and Serial Ports
- Apple is in the forefront of companies that believe serial ports have
- no use in the modern world and so has simply eliminated all traces of
- them from its machines and OS. But of course serial ports are still
- needed to connect not only to external modems, but also to the control
- ports of hubs, routers, terminal servers, PBXs, and similar devices,
- not to mention barcode readers, POS systems and components, speaking
- devices, hand calculators such as the HP48, automated factory-floor
- equipment, and scientific, medical, and lab equipment (to name a few).
- Among workers in these areas, there is a need to add serial ports back
- onto this platform, which is being filled by third-party products such
- as the [540]Keyspan High Speed USB Serial Adapter USA-19HS, which has a
- DB-9 male connector. To use the Keyspan device, you must install the
- accompanying device drivers, which winds up giving you serial ports
- with names like /dev/cu.USA19H3b1P1.1, /dev/cu.KeySerial1,
- /dev/tty.KeySerial1.
- C-Kermit 9.0 works "out of the box" with third-party serial ports on
- Mac OS X, because it is built by default ("make macosx") without the
- "UUCP lockfile" feature. If you have C-Kermit 9.0 on a personal
- Macintosh, you can skip the next section.
- Mac OS X Serial Ports with C-Kermit 8.0 and earlier
- In earlier versions of C-Kermit, you'll need to either build a special
- -DNOUUCP version, or deal with the UUCP port contention sytem in
- [541]all its glory (this is usually an exercise in futility because any
- other applications on your Mac that use the serial port will not
- necessarily follow the same conventions):
- 1. su (or sudo -s)
- chgrp xxxx /var/spool/lock
- chmod g+w /var/spool/lock
- chgrp xxxx /dev/cu.*
- (where xxxx is the name of the group for users to whom serial-port
- access is to be granted). Use "admin" or other existing group, or
- create a new group if desired. NB:
- In the absence of official guidance from Apple or anyone else, we
- choose /var/spool/lock as the lockfile directory because this
- directory (a) already exists on vanilla Mac OS X installations, and
- (b) it is the directory used for serial-port lockfiles on many other
- platforms.
- 2. Put all users who need access to the serial port in the same group.
- 3. Make sure the serial device files that are to be used by C-Kermit
- have group read-write permission and (if you care) lack world
- read-write permission, e.g.:
- chmod g+rw,o-rw /dev/cu.*
- If you do the above, then there's no need to become root to use Kermit,
- or to make Kermit suid or sgid. Just do this:
- chmod 775 wermit
- mv wermit /usr/local/kermit
- (or whatever spot is more appropriate, e.g. /usr/bin/). For greater
- detail about installation, [542]CLICK HERE.
- Alternatively, to build a pre-9.0 version of C-Kermit without UUCP
- lockfile support, set the NOUUCP flag; e.g. (for Mac OS 10.4):
- make macosx10.4 KFLAGS=-DNOUUCP
- This circumvents the SET PORT failure "?Access to lockfile directory
- denied". But it also sacrifices Kermit's ability to ensure that only
- one copy of Kermit can have the device open at a time, since Mac OS X
- is the same as all other varieties of Unix in that exclusive access to
- serial ports is not enforced in any way. But if it's for your own
- desktop machine that nobody else uses, a -DNOUUCP version might be
- adequate and preferable to the alternatives.
- To build C-Kermit 9.0 with UUCP support, do:
- make macosx KFLAGS=-UNOUUCP
- (note: "-U", not "-D).
- RS-232 versus RS-422
- Meanwhile, back when Macs had serial ports, they were not RS-232 (the
- standard for connecting computers with nearby modems) but rather RS-422
- or -423 (a standard for connecting serial devices over longer
- distances). Macintosh serial ports do not support modems well because
- they do not have enough wires (or more properly in the case RS-422/423,
- wire pairs) to convey a useful subset of modem signals.
- Keyspan also sells a [543]USB Twin Serial Adapter that gives you two
- Mini-Din8 RS-422 ports, that are no better (or worse) for communicating
- with modems or serial devices than a real Mac Din-8 port was. In
- essence, you get Data In, Data Out, and two modem signals. It looks to
- me as if the signals chosen by Keyspan are RTS and CTS. This gives you
- hardware flow control, but at the expense of Carrier Detect. Thus to
- use C-Kermit with a Keyspan USB serial port, you must tell C-Kermit to:
- set modem type none ; (don't expect a modem)
- set carrier-watch off ; (ignore carrier signal)
- set port /dev/cu.USA19H3b1P1.1 ; (open the port)
- set flow rts/cts ; (this is the default)
- set speed 57600 ; (or whatever)
- connect ; (or DIAL or whatever)
- Use Ctrl-\C in the normal manner to escape back to the C-Kermit>
- prompt. Kermit can't pop back to its prompt automatically when Carrier
- drops because there is no Carrier signal in the physical interface.
- Here's a typical sequence for connecting to Cisco devices (using a
- mixture of command-line options and interactive commands at the
- prompt):
- $ ckermit -l /dev/cu.USA19H3b1P1.1 -b 9600
- C-Kermit> set carrier-watch off
- C-Kermit> connect
- Instructions for the built-in modem (if any) remain to be written due
- to lack of knowledge. If you can contribute instructions, hints, or
- tips, please [544]send them in.
- 3.20. C-KERMIT AND COHERENT
- [ [545]Top ] [ [546]Contents ] [ [547]Section Contents ] [
- [548]Previous ]
- Also see:
- [549]http://www.uni-giessen.de/faq/archiv/coherent-faq.general/msg000
- 00.html
- Mark Williams COHERENT was perhaps the first commercial Unix-based
- operating system for PCs, first appearing about 1983 or -84 for the
- PC/XT (?), and popular until about 1993, when Linux took over.
- C-Kermit, as of version 8.0, is still current for COHERENT 386 4.2
- (i.e. only for i386 and above). Curses is included, but lots of other
- features are omitted due to lack of the appropriate OS features, APIs,
- libraries, hardware, or just space: e.g. TCP/IP, floating-point
- arithmetic, learned scripts. Earlier versions of COHERENT ran on 8086
- and 80286, but these are to small to build or run C-Kermit, but
- G-Kermit should be OK (as might be ancient versions of C-Kermit).
- You can actually build a version with floating point support -- just
- take -DNOFLOAT out of CFLAGS and add -lm to LIBS; NOFLOAT is the
- default because COHERENT tends to run on old PCs that don't have
- floating-point hardware. You can also add "-f" to CFLAGS to have it
- link in the floating-point emulation library. Also I'm not sure why
- -DNOLEARN is included, since it depends on select(), which COHERENT
- has.
- 4. GENERAL UNIX-SPECIFIC HINTS, LIMITATIONS, AND BUGS
- [ [550]Top ] [ [551]Contents ] [ [552]Next ] [ [553]Previous ]
- 4.1. Modem Signals
- There seems to be an escalating demand for the ability to control "dumb
- serial devices" (such as "smartcard readers", barcode readers, etc) by
- explicitly manipulating modem signals, particularly RTS. This might
- have been easy to do in DOS, where there is no operating system
- standing between the application and the serial device, but it is
- problematic in Unix, where modem signals are controlled by the serial
- device driver. If the driver does not provide an API for doing this,
- then the application can't do it. If it does provide an API, expect it
- to be totally different on each Unix platform, since there is no
- standard for this.
- 4.2. NFS Troubles
- Beginning with C-Kermit 6.0, the default C-Kermit prompt includes your
- current (working) directory; for example:
- [/usr/olga] C-Kermit>
- (In C-Kermit 7.0 the square braces were replaced by round parentheses
- to avoid conflicts with ISO 646 national character sets.)
- If that directory is on an NFS-mounted disk, and NFS stops working or
- the disk becomes unavailable, C-Kermit will hang waiting for NFS and/or
- the disk to come back. Whether you can interrupt C-Kermit when it is
- hung this way depends on the specific OS. Kermit has called the
- operating systems's getcwd() function, and is waiting for it to return.
- Some versions of Unix (e.g. HP-UX 9.x) allow this function to be
- interrupted with SIGINT (Ctrl-C), others (such as HP-UX 8.x) do not. To
- avoid this effect, you can always use SET PROMPT to change your prompt
- to something that does not involve calling getcwd(), but if NFS is not
- responding, C-Kermit will still hang any time you give a command that
- refers to an NFS-mounted directory. Also note that in some cases, the
- uninterruptibility of NFS-dependent system or library calls is
- considered a bug, and sometimes there are patches. For HP-UX, for
- example:
- replaced by:
- HP-UX 10.20 libc PHCO_8764 PHCO_14891/PHCO_16723
- HP-UX 10.10 libc PHCO_8763 PHCO_14254/PHCO_16722
- HP-UX 9.x libc PHCO_7747 S700 PHCO_13095
- HP-UX 9.x libc PHCO_6779 S800 PHCO_11162
- 4.3. C-Kermit as Login Shell
- You might have reason to make C-Kermit the login shell for a specific
- user, by entering the pathname of Kermit (possibly with command-line
- switches, such as -x to put it in server mode) into the shell field of
- the /etc/passwd file. This works pretty well. In some cases, for
- "ultimate security", you might want to use a version built with
- -DNOPUSH (see the [554]Configurations Options document for this, but
- even if you don't, then PUSHing or shelling out from C-Kermit just
- brings up a new copy of C-Kermit (but warning: this does not prevent
- the user from explicitly running a shell; e.g. "run /bin/sh"; use
- NOPUSH to prevent this).
- 4.4. C-Kermit versus screen and splitvt
- C-Kermit file transfers will probably not work if attempted through the
- "splitvt" or GNU "screen" programs because the screen optimization (or
- at least, line wrapping, control-character absorption) done by this
- package interferes with Kermit's packets.
- The same can apply to any other environment in which the user's session
- is captured, monitored, recorded, or manipulated. Examples include the
- 'script' program (for making a typescript of a session), the
- Computronics PEEK package and pksh (at least versions of it prior to
- 1.9K), and so on.
- You might try the following -- what we call "doomsday Kermit" --
- settings to push packets through even the densest and most obstructive
- connections, such as "screen" and "splitvt" (and certain kinds of 3270
- protocol emulators): Give these commands to BOTH Kermit programs:
- SET FLOW NONE
- SET CONTROL PREFIX ALL
- SET RECEIVE PACKET-LENGTH 70
- SET RECEIVE START 62
- SET SEND START 62
- SET SEND PAUSE 100
- SET BLOCK B
- If it works, it will be slow.
- 4.5. C-Kermit versus DOS Emulators
- On Unix workstations equipped with DOS emulators like SoftPC, watch out
- for what these emulators do to the serial port drivers. After using a
- DOS emulator, particularly if you use it to run DOS communications
- software, you might have to reconfigure the serial ports for use by
- Unix.
- 4.6. C-Kermit versus Job Control
- Interruption by Ctrl-Z makes Unix C-Kermit try to suspend itself with
- kill(0,SIGTSTP), but only on platforms that support job control, as
- determined by whether the symbol SIGTSTP is defined (or on POSIX or
- SVR4 systems, if syconf(_SC_JOB_CONTROL) or _POSIX_JOB_CONTROL in
- addition to SIGTSTP). However, if Kermit is running under a login shell
- (such as the original Bourne shell) that does not support job control,
- the user's session hangs and must be logged out from another terminal,
- or hung up on. There is no way Kermit can defend itself against this.
- If you use a non-job control shell on a computer that supports job
- control, give a command like "stty susp undef" to fix it so the suspend
- signal is not attached to any particular key, or give the command SET
- SUSPEND OFF to C-Kermit, or build C-Kermit with -DNOJC.
- 4.7. Dates and Times
- Unix time conversion functions typically apply locale rules to return
- local time in terms of any seasonal time zone change in effect for the
- given date. The diffdate function assumes that the same timezone rules
- are in effect for both dates, but a date with timezone information will
- be converted to the local time zone in effect at the given time, e.g.,
- a GMT specification will produce either a Standard Time or Daylight
- Savings Time, depending on which applies at the given time. An example
- using the 2001 seasonal change from EDT (-0400) to EST (-0500):
- C-Kermit> DATE 20011028 05:01:02 GMT ; EDT
- 20011028 01:01:02
- C-Kermit> DATE 20011028 06:01:02 GMT ; EST
- 20011028 01:01:02
- C-Kermit>
- but the implicit change in timezone offset is not recognized:
- C-Kermit> echo \fdiffdate(20011028 05:01:02 GMT, 20011028 06:01:02 GMT)
- +0:00
- C-Kermit>
- Date/time arithmetic, offsets, delta times, and timezone support are
- new to C-Kermit 8.0, and might be expected to evolve and improve in
- subsequent releases.
- On some platforms, files downloaded with HTTP receive the current
- timestamp, rather than the HTTP "Last Modified" time (this can be fixed
- by including utime.h, e.g. in SunOS and Tru64...).
- 4.8. Pseudoterminals
- The SSH and PTY commands work by assigning a pseudoterminal and reading
- and writing from it. Performance varies according to the specific
- platform ranging from very fast to very flow.
- SSH and PTY commands can fail if (a) all pseudoterminals are in use; or
- (b) you do not have read/write access to the pseudoterminal that was
- assigned. An example of (b) was reported with the Zipslack Slackware
- Linux distribution, in which the pseudoterminals were created with
- crw-r--r-- permission, instead of crw-rw-rw-.
- 4.9. Miscellaneous
- * Reportedly, the Unix C-Kermit server, under some conditions, on
- certain particular systems, fails to log out its login session upon
- receipt of a BYE command. Before relying on the BYE command
- working, test it a few times to make sure it works on your system:
- there might be system configuration or security mechanisms to
- prevent an inferior process (like Kermit) from killing a superior
- one (like the login shell).
- * On AT&T 7300 (3B1) machines, you might have to "stty nl1" before
- starting C-Kermit. Do this if characters are lost during
- communications operations.
- * Under the bash shell (versions prior to 1.07 from CWRU), "pushing"
- to an inferior shell and then exiting back to Kermit leaves Kermit
- in the background such that it must be explicitly fg'd. This is
- reportedly fixed in version 1.07 of bash (and definitely in modern
- bash versions).
- 5. INITIALIZATION AND COMMAND FILES
- [ [555]Top ] [ [556]Contents ] [ [557]Next ] [ [558]Previous ]
- C-Kermit's initialization file for Unix is .kermrc (lowercase, starts
- with period) in your home directory, unless Kermit was built with the
- system-wide initialization-file option (see the [559]C-Kermit for Unix
- Installation Instructions).
- C-Kermit identifies your home directory based on the environment
- variable, HOME. Most Unix systems set this variable automatically when
- you log in. If C-Kermit can't find your initialization file, check your
- HOME variable:
- echo $HOME (at the Unix prompt)
- or:
- echo \$(HOME) (at the C-Kermit prompt)
- If HOME is not defined, or is defined incorrectly, add the appropriate
- definition to your Unix .profile or .login file, depending on your
- shell:
- setenv HOME full-pathname-of-your-home-directory (C-Shell, .login file)
- or:
- HOME=full-pathname-of-your-home-directory (sh, ksh, .profile file)
- export HOME
- NOTE: Various other operations depend on the correct definition of
- HOME. These include the "tilde-expansion" feature, which allows you to
- refer to your home directory as "~" in filenames used in C-Kermit
- commands, e.g.:
- send ~/.kermrc
- as well as the \v(home) variable.
- Prior to version 5A(190), C-Kermit would look for its initialization
- file in the current directory if it was not found in the home
- directory. This feature was removed from 5A(190) because it was a
- security risk. Some people, however, liked this behavior and had
- .kermrc files in all their directories that would set up things
- appropriately for the files therein. If you want this behavior, you can
- accomplish it in various ways, for example:
- * Create a shell alias, for example:
- alias kd="kermit -Y ./.kermrc"
- * Create a .kermrc file in your home directory, whose contents are:
- take ./.kermrc
- Suppose you need to pass a password from the Unix command line to a
- C-Kermit script program, in such a way that it does not show up in "ps"
- or "w" listings. Here is a method (not guaranteed to be 100% secure,
- but definitely more secure than the more obvious methods):
- echo mypassword | kermit myscript
- The "myscript" file contains all the commands that need to be executed
- during the Kermit session, up to and including EXIT, and also includes
- an ASK or ASKQ command to read the password from standard input, which
- has been piped in from the Unix 'echo' command, but it must not include
- a CONNECT command. Only "kermit myscript" shows up in the ps listing.
- 6. COMMUNICATION SPEED SELECTION
- [ [560]Top ] [ [561]Contents ] [ [562]Next ] [ [563]Previous ]
- Version-7 based Unix implementations, including 4.3 BSD and earlier and
- Unix systems based upon BSD, use a 4-bit field to record a serial
- device's terminal speed. This leaves room for 16 speeds, of which the
- first 14 are normally:
- 0, 50, 75, 110, 134.5, 150, 200, 300, 600, 1200, 1800, 2400, 4800,
- and 9600
- The remaining two are usually called EXTA and EXTB, and are defined by
- the particular Unix implementation. C-Kermit determines which speeds
- are available on your system based on whether symbols for them are
- defined in your terminal device header files. EXTA is generally assumed
- to be 19200 and EXTB 38400, but these assumptions might be wrong, or
- they might not apply to a particular device that does not support these
- speeds. Presumably, if you try to set a speed that is not legal on a
- particular device, the driver will return an error, but this can not be
- guaranteed.
- On these systems, it is usually not possible to select a speed of 14400
- bps for use with V.32bis modems. In that case, use 19200 or 38400 bps,
- configure your modem to lock its interface speed and to use RTS/CTS
- flow control, and tell C-Kermit to SET FLOW RTS/CTS and SET DIAL
- SPEED-MATCHING OFF.
- The situation is similar, but different, in System V. SVID Third
- Edition lists the same speeds, 0 through 38400.
- Some versions of Unix, and/or terminal device drivers that come with
- certain third-party add-in high-speed serial communication interfaces,
- use the low "baud rates" to stand for higher ones. For example, SET
- SPEED 50 gets you 57600 bps; SET SPEED 75 gets you 76800; SET SPEED 110
- gets 115200.
- SCO ODT 3.0 is an example where a "baud-rate-table patch" can be
- applied that can rotate the tty driver baud rate table such that
- 600=57600 and 1800=115k baud. Similarly for Digiboard
- multiport/portservers, which have a "fastbaud" setting that does this.
- Linux has a "setserial" command that can do it, etc.
- More modern Unixes support POSIX-based speed setting, in which the
- selection of speeds is not limited by a 4-bit field. C-Kermit 6.1
- incorporates a new mechanism for finding out (at compile time) which
- serial speeds are supported by the operating system that does not
- involve editing of source code by hand; on systems like Solaris 5.1,
- IRIX 6.2, and SCO OSR5.0.4, "set speed ?" will list speeds up to 460800
- or 921600. In C-Kermit 7.0 and later:
- 1. If a symbol for a particular speed (say B230400 for 230400 bps)
- appears in whatever header file defines acceptable serial speeds
- (e.g. <termbits.h> or <sys/termios.h> or <sys/ttydev.h>, etc), the
- corresponding speed will appear in C-Kermit's "set speed ?" list.
- 2. The fact that a given speed is listed in the header files and
- appears in C-Kermit's list does not mean the driver will accept it.
- For example, a computer might have some standard serial ports plus
- some add-on ones with different drivers that accept a different
- repertoire of speeds.
- 3. The fact that a given speed is accepted by the driver does not
- guarantee the underlying hardware can accept it.
- When Kermit is given a "set speed" command for a particular device, the
- underlying system service is called to set the speed; its return code
- is checked and the SET SPEED command fails if the return code indicates
- failure. Regardless of the system service return status, the device's
- speed is then read back and if it does not match the speed that was
- requested, an error message is printed and the command fails.
- Even when the command succeeds, this does not guarantee successful
- operation at a particular speed, especially a high one. That depends on
- electricity, information theory, etc. How long is the cable, what is
- its capacitance, how well is it shielded, etc, not to mention that
- every connection has two ends and its success depends on both of them.
- (With the obvious caveats about internal modems, is the cable really
- connected, interrupt conflicts, etc etc etc).
- Note, in particular, that there is a certain threshold above which
- modems can not "autobaud" -- i.e. detect the serial interface speed
- when you type AT (or whatever else the modem's recognition sequence
- might be). Such modems need to be engaged at a lower speed (say 2400 or
- 9600 or even 115200 -- any speed below their autobaud threshold) and
- then must be given a modem-specific command (which can be found in the
- modem manual) to change their interface speed to the desired higher
- speed, and then the software must also be told to change to the new,
- higher speed.
- For additional information, read [564]Section 9.5 of the Installation
- Instructions, plus any platform-specific notes in [565]Section 3 above.
- 7. COMMUNICATIONS AND DIALING
- [ [566]Top ] [ [567]Contents ] [ [568]Next ] [ [569]Previous ]
- 7.1. Serial Ports and Modems
- If you SET LINE to a serial port modem-control device that has nothing
- plugged in to it, or has a modem connected that is powered off, and you
- have not given a prior SET MODEM TYPE or SET CARRIER-WATCH OFF command,
- the SET LINE command is likely to hang. In most cases, you can Ctrl-C
- out. If not, you'll have to kill C-Kermit from another terminal.
- Similarly, if you give a SET MODEM TYPE HAYES (or USR, or any other
- modem type besides DIRECT, NONE, or UNKNOWN) and then SET LINE to an
- empty port, the subsequent close (implicit or explicit) is liable to
- hang or even crash (through no fault of Kermit's -- the hanging or
- crashing is inside a system call such as cfsetospeed() or close()).
- The SET CARRIER-WATCH command works as advertised only if the
- underlying operating system and device drivers support this feature; in
- particular only if a read() operation returns immediately with an error
- code if the carrier signal goes away or, failing that, if C-Kermit can
- obtain the modem signals from the device driver (you can tell by giving
- a "set line" command to a serial device, and then a "show
- communications" command -- if modem signals are not listed, C-Kermit
- won't be able to detect carrier loss, the WAIT command will not work,
- etc). Of course, the device itself (e.g. modem) must be configured
- appropriately and the cables convey the carrier and other needed
- signals, etc.
- If you dial out from Unix system, but then notice a lot of weird
- character strings being stuck into your session at random times
- (especially if they look like +++ATQ0H0 or login banners or prompts),
- that means that getty is also trying to control the same device. You'll
- need to dial out on a device that is not waiting for a login, or else
- disable getty on the device.
- As of version 7.0, C-Kermit makes explicit checks for the Carrier
- Detect signal, and so catches hung-up connections much better than 6.0
- and earlier. However, it still can not be guaranteed to catch every
- ever CD on-to-off transition. For example, when the HP-UX version of
- C-Kermit is in CONNECT mode on a dialed connection and CARRIER-WATCH ON
- or AUTO, and you turn off the modem, HP-UX is stuck in a read() that
- never returns. (C-Kermit does not pop back to its prompt automatically,
- but you can still escape back.)
- If, on the other hand, you log out from the remote system, and it hangs
- up, and CD drops on the local modem, C-Kermit detects this and pops
- back to the prompt as it should. (Evidently there can be a difference
- between CD and DSR turning off at the same time, versus CD turning off
- while DSR stays on; experimentation with &S0/&S1/&S2 on your modem
- might produce the desired results).
- When Unix C-Kermit exits, it closes (and must close) the communications
- device. If you were dialed out, this will most likely hang up the
- connection. If you want to get out of Kermit and still use Kermit's
- communication device, you have several choices:
- 1. Shell out from Kermit or suspend Kermit, and refer to the device
- literally (as in "term -blah -blah < /dev/cua > /dev/cua").
- 2. Shell out from Kermit and use the device's file descriptor which
- Kermit makes available to you in the \v(ttyfd) variable.
- 3. Use C-Kermit's REDIRECT command.
- 4. Use C-Kermit new EXEC /REDIRECT command.
- If you are having trouble dialing:
- 1. Make sure the dialout line is configured correctly. More about this
- below.
- 2. Make sure all necessary patches are installed for your operating
- system.
- 3. If you can't dial on a "bidirectional" line, then configure it for
- outbound-only (remove the getty) and try again. (The mechanisms --
- if any -- for grabbing bidirectional lines for dialout vary wildly
- among Unix implementations and releases, and C-Kermit -- which runs
- on well over 300 different Unix variations -- makes no effort to
- keep up with them; the recommended method for coping with this
- situation is to wrap C-Kermit in a shell script that takes the
- appropriate actions.)
- 4. Make sure C-Kermit's SET DIAL and SET MODEM parameters agree with
- the modem you are actually using -- pay particular attention to SET
- DIAL SPEED-MATCHING.
- 5. If MODEM HANGUP-METHOD is set to RS232-SIGNAL, change it to
- MODEM-COMMAND. Or vice-versa.
- 6. Try SET DIAL HANGUP OFF before the DIAL command. Also, SET DIAL
- DISPLAY ON to watch what's happening. See [570]Section 8 of the
- [571]Installation Instructions.
- 7. Read pages 50-67 of [572]Using C-Kermit.
- 8. As a last resort, don't use the DIAL command at all; SET CARRIER
- OFF and CONNECT to the modem and dial interactively, or write a
- script program to dial the modem.
- Make sure your dialout line is correctly configured for dialing out (as
- opposed to login). The method for doing this is different for each kind
- of Unix system. Consult your system documentation for configuring lines
- for dialing out (for example, Sun SparcStation IPC users should read
- the section "Setting up Modem Software" in the Desktop SPARC Sun System
- & Network Manager's Guide; HP-9000 workstation users should consult the
- manual Configuring HP-UX for Peripherals, etc).
- Symptom: DIAL works, but a subsequent CONNECT command does not.
- Diagnosis: the modem is not asserting Carrier Detect (CD) after the
- connection is made, or the cable does not convey the CD signal. Cure:
- Reconfigure the modem, replace the cable. Workaround: SET CARRIER OFF
- (at least in System-V based Unix versions).
- For Berkeley-Unix-based systems (4.3BSD and earlier), Kermit includes
- code to use LPASS8 mode when parity is none, which is supposed to allow
- 8-bit data and Xon/Xoff flow control at the same time. However, as of
- edit 174, this code is entirely disabled because it is unreliable: even
- though the host operating system might (or might not) support LPASS8
- mode correctly, the host access protocols (terminal servers, telnet,
- rlogin, etc) generally have no way of finding out about it and
- therefore render it ineffective, causing file transfer failures. So as
- of edit 174, Kermit once again uses rawmode for 8-bit data, and so
- there is no Xon/Xoff flow control during file transfer or terminal
- emulation in the Berkeley-based versions (4.3 and earlier, not 4.4).
- Also on Berkeley-based systems (4.3 and earlier), there is apparently
- no way to configure a dialout line for proper carrier handling, i.e.
- ignore carrier during dialing, require carrier thereafter, get a fatal
- error on any attempt to read from the device after carrier drops (this
- is handled nicely in System V by manipulation of the CLOCAL flag). The
- symptom is that carrier loss does not make C-Kermit pop back to the
- prompt automatically. This is evident on the NeXT, for example, but not
- on SunOS, which supports the CLOCAL flag. This is not a Kermit problem,
- but a limitation of the underlying operating system. For example, the
- cu program on the NeXT doesn't notice carrier loss either, whereas cu
- on the Sun does.
- On certain AT&T Unix systems equipped with AT&T modems, DIAL and HANGUP
- don't work right. Workarounds: (1) SET DIAL HANGUP OFF before
- attempting to dial; (2) If HANGUP doesn't work, SET LINE, and then SET
- LINE <device> to totally close and reopen the device. If all else
- fails, SET CARRIER OFF.
- C-Kermit does not contain any particular support for AT&T DataKit
- devices. You can use Kermit software to dial in to a DataKit line, but
- C-Kermit does not contain the specialized code required to dial out
- from a DataKit line. If the Unix system is connected to DataKit via
- serial ports, dialout should work normally (e.g. set line /dev/ttym1,
- set speed 19200, connect, and then see the DESTINATION: prompt, from
- which you can connect to another computer on the DataKit network or to
- an outgoing modem pool, etc). But if the Unix system is connected to
- the DataKit network through the special DataKit interface board, then
- SET LINE to a DataKit pseudodevice (such as /dev/dk031t) will not work
- (you must use the DataKit "dk" or "dkcu" program instead). In C-Kermit
- 7.0 and later, you can make Kermit connections "though" dk or dkcu
- using "set line /pty".
- In some BSD-based Unix C-Kermit versions, SET LINE to a port that has
- nothing plugged in to it with SET CARRIER ON will hang the program (as
- it should), but it can't be interrupted with Ctrl-C. The interrupt trap
- is correctly armed, but apparently the Unix open() call cannot be
- interrupted in this case. When SET CARRIER is OFF or AUTO, the SET LINE
- will eventually return, but then the program hangs (uninterruptibly)
- when the EXIT or QUIT command (or, presumably, another SET LINE
- command) is given. The latter is probably because of the attempt to
- hang up the modem. (In edit 169, a timeout alarm was placed around this
- operation.)
- With SET DIAL HANGUP OFF in effect, the DIAL command might work only
- once, but not again on the same device. In that case, give a CLOSE
- command to close the device, and then another SET LINE command to
- re-open the same device. Or rebuild your version of Kermit with the
- -DCLSOPN compile-time switch.
- The DIAL command says "To cancel: Type your interrupt character
- (normally Ctrl-C)." This is just one example of where program messages
- and documentation assume your interrupt character is Ctrl-C. But it
- might be something else. In most (but not necessarily all) cases, the
- character referred to is the one that generates the SIGINT signal. If
- Ctrl-C doesn't act as an interrupt character for you, type the Unix
- command "stty -a" or "stty all" or "stty everything" to see what your
- interrupt character is. (Kermit could be made to find out what the
- interrupt character is, but this would require a lot of
- platform-dependent coding and #ifdefs, and a new routine and interface
- between the platform-dependent and platform-independent parts of the
- program.)
- In general, the hangup operation on a serial communication device is
- prone to failure. C-Kermit tries to support many, many different kinds
- of computers, and there seems to be no portable method for hanging up a
- modem connection (i.e. turning off the RS-232 DTR signal and then
- turning it back on again). If HANGUP, DIAL, and/or Ctrl-\H do not work
- for you, and you are a programmer, look at the tthang() function in
- ckutio.c and see if you can add code to make it work correctly for your
- system, and send the code to the address above. (NOTE: This problem has
- been largely sidestepped as of edit 188, in which Kermit first attempts
- to hang up the modem by "escaping back" via +++ and then giving the
- modem's hangup command, e.g. ATH0, when DIAL MODEM-HANGUP is ON, which
- is the default setting.)
- Even when Kermit's modem-control software is configured correctly for
- your computer, it can only work right if your modem is also configured
- to assert the CD signal when it is connected to the remote modem and to
- hang up the connection when your computer drops the DTR signal. So
- before deciding Kermit doesn't work with your modem, check your modem
- configuration AND the cable (if any) connecting your modem to the
- computer -- it should be a straight-through [573]modem cable conducting
- the signals FG, SG, TD, RD, RTS, CTS, DSR, DTR, CD, and RI.
- Many Unix systems keep aliases for dialout devices; for example,
- /dev/acu might be an alias for /dev/tty00. But most of these Unix
- systems also use UUCP lockfile conventions that do not take this
- aliasing into account, so if one user assigns (e.g.) /dev/acu, then
- another user can still assign the same device by referring to its other
- name. This is not a Kermit problem -- Kermit must follow the lockfile
- conventions used by the vendor-supplied software (cu, tip, uucp).
- The SET FLOW-CONTROL KEEP option should be given *before* any
- communication (dialing, terminal emulation, file transfer,
- INPUT/OUTPUT/TRANSMIT, etc) is attempted, if you want C-Kermit to use
- all of the device's preexisting flow-control related settings. The
- default flow-control setting is XON/XOFF, and it will take effect when
- the first communication-related command is given, and a subsequent SET
- FLOW KEEP command will not necessarily know how to restore *all* of the
- device's original flow-control settings.
- 7.2. Network Connections
- C-Kermit tries to use the 8th bit for data when parity is NONE, and
- this generally works on real Unix terminal (tty) devices, but it often
- does not work when the Unix system is accessed over a network via
- telnet or rlogin protocols, including (in many cases) through terminal
- servers. For example, an Encore computer with Annex terminal servers
- only gives a 7-bit path if the rlogin protocol is selected in the
- terminal server but it gives the full 8 bits if the proprietary RDP
- protocol is used.
- If file transfer does not work through a host to which you have
- rlogin'd, use "rlogin -8" rather than "rlogin". If that doesn't work,
- tell both Kermit programs to "set parity space".
- The Encore TELNET server does not allow long bursts of input. When you
- have a TELNET connection to an Encore, tell C-Kermit on the Encore to
- SET RECEIVE PACKET-LENGTH 200 or thereabouts.
- 8. HARDWARE FLOW CONTROL
- [ [574]Top ] [ [575]Contents ] [ [576]Next ] [ [577]Previous ]
- SET FLOW RTS/CTS is available in Unix C-Kermit only when the underlying
- operating system provides an Application Program Interface (API) for
- turning this feature on and off under program control, which turns out
- to be a rather rare feature among Unix systems. To see if your Unix
- C-Kermit version supports hardware flow control, type "set flow ?" at
- the C-Kermit prompt, and look for "rts/cts" among the options. Other
- common situations include:
- 1. The API is available, so "set flow rts/cts" appears as a valid
- C-Kermit command, but it doesn't do anything because the device
- driver (part of the operating system) was never coded to do
- hardware flow control. This is common among System V R4
- implementations (details below).
- 2. The API is not available, so "set flow rts/cts" does NOT appear as
- a valid C-Kermit command, but you can still get RTS/CTS flow
- control by selecting a specially named device in your SET LINE
- command. Examples:
- + NeXTSTEP: /dev/cufa instead of /dev/cua, /dev/cufb instead of
- /dev/cub (68040 only; "man zs" for further info).
- + IRIX: /dev/ttyf2 instead of /dev/ttyd2 or /dev/ttym2 ("man 7
- serial").
- 3. The API is available, doesn't work, but a workaround as in (2) can
- be used.
- 4. The API is available, but Kermit doesn't know about it. In these
- cases, you can usually use an stty command to enable RTS/CTS on the
- device, e.g. "stty crtscts" or "stty ctsflow", "stty rtsflow",
- before starting Kermit, and then tell Kermit to SET FLOW KEEP.
- 5. No API and no special device drivers. Hardware flow control is
- completely unavailable.
- System V R4 based Unixes are supposed to supply a <termiox.h> file,
- which gives Kermit the necessary interface to command the terminal
- driver to enable/disable hardware flow control. Unfortunately, but
- predictably, many implementations of SVR4 whimsically place this file
- in /usr/include/sys rather than /usr/include (where SVID clearly
- specifies it should be; see SVID, Third Edition, V1, termiox(BA_DEV).
- Thus if you build C-Kermit with any of the makefile entries that
- contain -DTERMIOX or -DSTERMIOX (the latter to select <sys/termiox.h>),
- C-Kermit will have "set flow rts/cts" and possibly other hardware
- flow-control related commands. BUT... That does not necessarily mean
- that they will work. In some cases, the underlying functions are simply
- not coded into the operating system.
- WARNING: When hardware flow control is available, and you enable in
- Kermit on a device that is not receiving the CTS signal, Kermit can
- hang waiting for CTS to come up. This is most easily seen when the
- local serial port has nothing plugged in to it, or is connected to an
- external modem that is powered off.
- 9. TERMINAL CONNECTION AND KEY MAPPING
- [ [578]Top ] [ [579]Contents ] [ [580]Next ] [ [581]Previous ]
- C-Kermit is not a terminal emulator. Refer to page 147 of [582]Using
- C-Kermit, 2nd Edition: "Most versions of C-Kermit -- Unix, VMS, AOS/VS,
- VOS, etc -- provide terminal connection without emulation. These
- versions act as a 'semitransparent pipe' between the remote computer
- and your terminal, terminal emulator, console driver, or window, which
- in turn emulates (or is) a specific kind of terminal." The environment
- in which you run C-Kermit is up to you.
- If you are an X Windows user, you should be aware of an alternative to
- xterm that supports VT220 emulation, from Thomas E. Dickey:
- [583]http://dickey.his.com/xterm/xterm.html
- Unix C-Kermit's SET KEY command currently can not be used with keys
- that generate "wide" scan codes or multibyte sequences, such as
- workstation function or arrow keys, because Unix C-Kermit does not have
- direct access to the keyboard.
- However, many Unix workstations and/or console drivers provide their
- own key mapping feature. With xterm, for example, you can use 'xmodmap'
- ("man xmodmap" for details); here is an xterm mapping to map the Sun
- keyboard to DEC VT200 values for use with VT-terminal oriented
- applications like VMS EVE:
- keycode 101=KP_0
- keycode 119=KP_1
- keycode 120=KP_2
- keycode 121=KP_3
- keycode 98=KP_4
- keycode 99=KP_5
- keycode 100=KP_6
- keycode 75=KP_7
- keycode 76=KP_8
- keycode 77=KP_9
- keycode 52=KP_F1
- keycode 53=KP_F2
- keycode 54=KP_F3
- keycode 57=KP_Decimal
- keycode 28=Left
- keycode 29=Right
- keycode 30=KP_Separator
- keycode 105=KP_F4
- keycode 78=KP_Subtract
- keycode 8=Left
- keycode 10=Right
- keycode 32=Up
- keycode 33=Down
- keycode 97=KP_Enter
- Users of Linux consoles can use loadkeys ("man dumpkeys loadkeys
- keytables" for details. The format used by loadkeys is compatible with
- that used by Xmodmap, although it is not definitely certain that the
- keycodes are compatible for different keyboard types (e.g. Sun vs HP vs
- PC, etc).
- 10. FILE TRANSFER
- [ [584]Top ] [ [585]Contents ] [ [586]Next ] [ [587]Previous ]
- On most platforms, C-Kermit can not handle files longer than 2^31 or
- 2^32 bytes long, because it uses the traditional file i/o APIs that use
- 32-bit words to represent the file size. To accommodate longer files,
- we would have to switch to a new and different API. Unfortunately, each
- platform has a different one, a nightmare to handle in portable code.
- The C-Kermit file code was written in the days long before files longer
- than 2GB were supported or even contemplated in the operating systems
- where C-Kermit ran.
- If uploads (or downloads) fail immediately, give the CAUTIOUS command
- to Kermit and try again. If they still fail, then try SET PREFIXING
- ALL. If they still fail, try SET PARITY SPACE. If they still fail, try
- ROBUST.
- If reception (particularly of large files and/or binary files) begins
- successfully but then fail consistently after a certain amount of bytes
- have been sent, check:
- * Your ulimit ("ulimit -a")
- * The amount of available space on the target disk ("df ." or "df -k
- .")
- * Your personal disk quota (platform- and site-dependent)
- * The maximum file size on the receiver's file system (e.g. 2GB in
- old versions the Linux VFS file system, and/or in applications that
- have not been recoded to use new "large file" APIs).
- * If it's an NFS-mounted disk (if so, try uploading to a local disk)
- * Is there an "idle limit" on the receiving end?
- If none of these seem to explain it, then the problem is not size
- related, but reflects some clash between the file contents and the
- characteristics of the connection, in which case follow the
- instructions in the first paragraph of this section.
- Suppose two copies of Kermit are receiving files into the same
- directory, and the files have the same name, e.g. "foo.bar". Whichever
- one starts first opens an output file called "foo.bar". The second one
- sees there is already a foo.bar file, and so renames the existing
- foo.bar to foo.bar.~1~ (or whatever). When the first file has been
- received completely, Kermit goes to change its modification time and
- permissions to those given by the file sender in the Attribute packet.
- But in Unix, the APIs for doing this take a filename, not a file
- descriptor. Since the first Kermit's file has been renamed, and the
- second Kermit is using the original name, the first Kermit changes the
- modtime and permissions of the second Kermit's file, not its own.
- Although there might be a way to work around this in the code, e.g.
- using inode numbers to keep track of which file is which, this would be
- tricky and most likely not very portable. It's better to set up your
- application to prevent such things from happening, which is easy enough
- using the script language, filename templates, etc.
- Suppose you start C-Kermit with a command-line argument to send or
- receive a file (e.g. "kermit -r") and then type Ctrl-\c immediately
- afterwards to escape back and initiate the other end of the transfer,
- BUT your local Kermit's escape character is not Ctrl-\. In this case,
- the local Kermit passes the Ctrl-\ to the remote system, and if this is
- Unix, Ctrl-\ is likely to be its SIGQUIT character, which causes the
- current program to halt and dump core. Well, just about the first thing
- C-Kermit does when it starts is to disable the SIGQUIT signal. However,
- it is still possible for SIGQUIT to cause Kermit to quit and dump core
- if it is delivered while Kermit is being loaded or started, before the
- signal can be disabled. There's nothing Kermit itself can do about
- this, but you can prevent it from happening by disabling SIGQUIT in
- your Unix session. The command is usually something like:
- stty quit undef
- Unix C-Kermit does not reject incoming files on the basis of size.
- There appears to be no good (reliable, portable) way to determine in
- advance how much disk space is available, either on the device, or
- (when quotas or other limits are involved) to the user.
- Unix C-Kermit discards all carriage returns from incoming files when in
- text mode.
- If C-Kermit has problems creating files in writable directories when it
- is installed setuid or setgid on BSD-based versions of Unix such as
- NeXTSTEP 3.0, it probably needs to be rebuilt with the -DSW_ACC_ID
- compilation switch.
- If you SET FILE DISPLAY FULLSCREEN, and C-Kermit complains "Sorry,
- terminal type not supported", it means that the terminal library
- (termcap or termlib) that C-Kermit was built with does not know about a
- terminal whose name is the current value of your TERM environment
- variable. If this happens, but you want to have the fullscreen file
- transfer display, EXIT from C-Kermit and set a Unix terminal type from
- among the supported values that is also supported by your terminal
- emulator, or else have an entry for your terminal type added to the
- system termcap and/or terminfo database.
- If you attempt to suspend C-Kermit during local-mode file transfer and
- then continue it in the background (via bg), it will block for "tty
- output" if you are using the FULLSCREEN file transfer display. This is
- apparently a problem with curses. Moving a local-mode file transfer
- back and forth between foreground and background works correctly,
- however, with the SERIAL, CRT, BRIEF, or NONE file transfer displays.
- If C-Kermit's command parser no longer echoes, or otherwise acts
- strangely, after returning from a file transfer with the fullscreen
- (curses) display, and the curses library for your version of Unix
- includes the newterm() function, then try rebuilding your version of
- C-Kermit with -DCK_NEWTERM. Similarly if it echoes doubly, which might
- even happen during a subsequent CONNECT session. If rebuilding with
- -DCK_NEWTERM doesn't fix it, then there is something very strange about
- your system's curses library, and you should probably not use it. Tell
- C-Kermit to SET FILE DISPLAY CRT, BRIEF, or anything else other than
- FULLSCREEN, and/or rebuild without -DCK_CURSES, and without linking
- with (termlib and) curses. Note: This problem seemed to have escalated
- in C-Kermit 7.0, and -DCK_NEWTERM had to be added to many builds that
- previously worked without it: Linux, AIX 4.1, DG/UX, etc. In the Linux
- case, it is obviously because of changes in the (n)curses library; the
- cause in the other cases is not known.
- C-Kermit creates backup-file names (such as "oofa.txt.~1~") based on
- its knowledge of the maximum filename length on the platform where it
- is running, which is learned at compile time, based on MAXNAMLEN or
- equivalent symbols from the system header files. But suppose C-Kermit
- is receiving files on a Unix platform that supports long filenames, but
- the incoming files are being stored on an NFS-mounted file system that
- supports only short names. NFS maps the external system to the local
- APIs, so C-Kermit has no way of knowing that long names will be
- truncated. Or that C-Kermit is running on a version of Unix that
- supports both long-name and short-name file systems simultaneously
- (such as HP-UX 7.00). This can cause unexpected behavior when creating
- backup files, or worse. For example, you are sending a group of files
- whose names are differentiated only by characters past the point at
- which they would be truncated, each file will overwrite the previous
- one upon arrival.
- 11. EXTERNAL FILE TRANSFER PROTOCOLS
- [ [588]Top ] [ [589]Contents ] [ [590]Next ] [ [591]Previous ]
- SECTION CONTENTS
- 11.1. [592]C-Kermit as an External Protocol
- 11.2. [593]Invoking External Protocols from C-Kermit
- Unix C-Kermit can be used in conjunction with other communications
- software in various ways. C-Kermit can be invoked from another
- communications program as an "external protocol", and C-Kermit can also
- invoke other communication software to perform external protocols.
- This sort of operation makes sense only when you are dialing out from
- your Unix system (or making a network connection from it). If the Unix
- system is the one you have dialed in to, you don't need any of these
- tricks. Just run the desired software on your Unix system instead of
- Kermit. When dialing out from a Unix system, the difficulty is getting
- two programs to share the same communication device in spite of the
- Unix UUCP lockfile mechanism, which would normally prevent any sharing,
- and preventing the external protocol from closing (and therefore
- hanging up) the device when it exits back to the program that invoked
- it.
- 11.1. C-KERMIT AS AN EXTERNAL PROTOCOL
- [ [594]Top ] [ [595]Contents ] [ [596]Section Contents ] [ [597]Next ]
- (This section deleted; see [598]Using C-Kermit, 2nd Ed, Chapter 14.)
- "pcomm" is a general-purpose terminal program that provides file
- transfer capabilities itself (X- and YMODEM variations) and the ability
- to call on external programs to do file transfers (ZMODEM and Kermit,
- for example). You can tell pcomm the command to send or receive a file
- with an external protocol:
- Send Receive
- ZMODEM sz filename rz
- Kermit kermit -s filename kermit -r
- pcomm runs external programs for file transfer by making stdin and
- stdout point to the modem port, and then exec-ing "/bin/sh -c xxx"
- (where xxx is the appropriate command). However, C-Kermit does not
- treat stdin and stdout as the communication device unless you instruct
- it:
- Send Receive
- Kermit kermit -l 0 -s filename kermit -l 0 -r
- The "-l 0" option means to use file descriptor 0 for the communication
- device.
- In general, any program can pass any open file descriptor to C-Kermit
- for the communication device in the "-l" command-line option. When
- Kermit is given a number as the argument to the "-l" option, it simply
- uses it as a file descriptor, and it does not attempt to close it upon
- exit.
- Here's another example, for Seyon (a Linux communication program).
- First try the technique above. If that works, fine; otherwise... If
- Seyon does not give you a way to access and pass along the file
- descriptor, but it starts up the Kermit program with its standard i/o
- redirected to its (Seyon's) communications file descriptor, you can
- also experiment with the following method, which worked here in brief
- tests on SunOS. Instead of having Seyon use "kermit -r" or "kermit -s
- filename" as its Kermit protocol commands, use something like this
- (examples assume C-Kermit 6.0):
- For serial connections:
- kermit -YqQl 0 -r <-- to receive
- kermit -YqQl 0 -s filename(s) <-- to send one or more files
- For Telnet connections:
- kermit -YqQF 0 -r <-- to receive
- kermit -YqQF 0 -s filename(s) <-- to send one or more files
- Command line options:
- Y - skip executing the init file
- Q - use fast file transfer settings (default in 8.0)
- l 0 - transfer files using file descriptor 0 for a serial connection
- F 0 - transfer files using file descriptor 0 for a Telnet connection
- q - quiet - no messages
- r - receive
- s - send
- 11.2. INVOKING EXTERNAL PROTOCOLS FROM C-KERMIT
- [ [599]Top ] [ [600]Contents ] [ [601]Section Contents ] [
- [602]Previous ]
- (This section is obsolete, but not totally useless. See Chapter 14
- of [603]Using C-Kermit, 2nd Edition).
- After you have opened a communication link with C-Kermit's SET LINE
- (SET PORT) or SET HOST (TELNET) command, C-Kermit makes its file
- descriptor available to you in the \v(ttyfd) variable so you can pass
- it along to other programs that you RUN from C-Kermit. Here, for
- example, C-Kermit runs itself as an external protocol:
- C-Kermit>set modem type hayes
- C-Kermit>set line /dev/acu
- C-Kermit>set speed 2400
- C-Kermit>dial 7654321
- Call complete.
- C-Kermit>echo \v(ttyfd)
- 3
- C-Kermit>run kermit -l \v(ttyfd)
- Other programs that accept open file descriptors on the command line
- can be started in the same way.
- You can also use your shell's i/o redirection facilities to assign
- C-Kermit's open file descriptor (ttyfd) to stdin or stdout. For
- example, old versions of the Unix ZMODEM programs, sz and rz, when
- invoked as external protocols, expect to find the communication device
- assigned to stdin and stdout with no option for specifying any other
- file descriptor on the sz or rz command line. However, you can still
- invoke sz and rz as exterior protocols from C-Kermit if your current
- shell ($SHELL variable) is ksh (the Korn shell) or bash (the
- Bourne-Again shell), which allows assignment of arbitrary file
- descriptors to stdin and stdout:
- C-Kermit> run rz <&\v(ttyfd) >&\v(ttyfd)
- or:
- C-Kermit> run sz oofa.zip <&\v(ttyfd) >&\v(ttyfd)
- In version 5A(190) and later, you can use C-Kermit's REDIRECT command,
- if it is available in your version of C-Kermit, to accomplish the same
- thing without going through the shell:
- C-Kermit> redirect rz
- or:
- C-Kermit> redirect sz oofa.zip
- A complete set of rz,sz,rb,sb,rx,sx macros for Unix C-Kermit is defined
- in the file ckurzsz.ini. It automatically chooses the best redirection
- method (but is redundant since C-Kermit 6.0, which now has built-in
- support for external protocols via its SET PROTOCOL command).
- Note that external protocols can be used on C-Kermit SET LINE or SET
- HOST connections only if they operate through standard input and
- standard output. If they open their own connections, Kermit can't
- redirect them over its own connection.
- 12. SECURITY
- [ [604]Top ] [ [605]Contents ] [ [606]Next ] [ [607]Previous ]
- As of version 7.0, C-Kermit supports a wide range of security options
- for authentication and encryption: Kerberos 4, Kerberos 5 / GSSAPI,
- SSL/TLS, and SRP. See the separate [608]security document for details.
- 13. MISCELLANEOUS USER REPORTS
- [ [609]Top ] [ [610]Contents ] [ [611]Next ] [ [612]Previous ]
- Date: Thu, 12 Mar 92 1:59:25 MEZ
- From: Walter Mecky <walter@rent-a-guru.de>
- Subject: Help.Unix.sw
- To: svr4@pcsbst.pcs.com, source@usl.com
- PRODUCT: Unix
- RELEASE: Dell SVR4 V2.1 (is USL V3.0)
- MACHINE: AT-386
- PATHNAME: /usr/lib/libc.so.1
- /usr/ccs/lib/libc.a
- ABSTRACT: Function ttyname() does not close its file descriptor
- DESCRIPTION:
- ttyname(3C) opens /dev but never closes it. So if it is called
- often enough the open(2) in ttyname() fails. Because the broken
- ttyname() is in the shared lib too all programs using it can
- fail if they call it often enough. One important program is
- uucico which calls ttyname for every file it transfers.
- Here is a little test program if your system has the bug:
- #include <stdlib.h>
- #include <stdio.h>
- main() {
- int i = 0;
- while (ttyname(0) != NULL)
- i++;
- perror("ttyname");
- printf("i=%d\n", i);
- }
- If this program runs longer than some seconds you don't have the bug.
- WORKAROUND: None FIX: Very easy if you have source code.
- Another user reports some more explicit symptoms and recoveries:
- > What happens is when invoking ckermit we get one of the following
- > error messages:
- > You must set line
- > Not a tty
- > No more processes.
- > One of the following three actions clears the problem:
- > shutdown -y -g0 -i6
- > kill -9 the ttymon with the highest PID
- > Invoke sysadm and disable then enable the line you want to use.
- > Turning off respawn of sac -t 300 and going to getty's and uugetty's
- > does not help.
- >
- > Also C-Kermit reports "?timed out closing /dev/ttyxx".
- > If this happens all is well.
- ------------------------------
- (Note: the following problem also occurs on SGI and probably many other
- Unix systems):
- From: James Spath <spath@jhunix.hcf.jhu.edu>
- To: Info-Kermit-Request@cunixf.cc.columbia.edu
- Date: Wed, 9 Sep 1992 20:20:28 -0400
- Subject: C-Kermit vs uugetty (or init) on Sperry 5000
- We have successfully compiled the above release on a Unisys/Sperry
- 5000/95. We used the sys5r3 option, rather than sys5r2 since we have
- VR3 running on our system. In order to allow dialout access to
- non-superusers, we had to do "chmod 666 /dev/tty###, where it had been
- -rw--w--w- (owned by uucp), and to do "chmod +w /usr/spool/locks". We
- have done text and binary file transfers through local and remote
- connections.
- The problem concerning uucp ownership and permissions is worse than I
- thought at first. Apparently init or uugetty changes the file
- permissions after each session. So I wrote the following C program to
- open a set of requested tty lines. I run this for any required outgoing
- line prior to a Kermit session.
- ------ cut here -------
- /* opentty.c -- force allow read on tty lines for modem i/o */
- /* idea from: restrict.c -- System 5 Admin book Thomas/Farrow p. 605 */
- /* /jes jim spath {spath@jhunix.hcj.jhu.edu } */
- /* 08-Sep-92 NO COPYRIGHT. */
- /* this must be suid to open other tty lines */
- /* #define DEBUG */
- #define TTY "/dev/tty"
- #define LOK "/usr/spool/locks/LCK..tty"
- #include <stdio.h>
- /* allowable lines: */
- #define TOTAL_LINES 3
- static char allowable[TOTAL_LINES][4] = { "200", "201", "300" };
- static int total=TOTAL_LINES;
- int allow;
- /* states: */
- #define TTY_UNDEF 0
- #define TTY_LOCK 1
- #define TTY_OKAY 2
- main(argc, argv)
- int argc; char *argv[]; {
- char device[512];
- char lockdev[512];
- int i;
- if (argc == 1) {
- fprintf(stderr, "usage: open 200 [...]\n");
- }
- while (--argc > 0 && (*++argv) != NULL ) {
- #ifdef DEBUG
- fprintf(stderr, "TRYING: %s%s\n", TTY, *argv);
- #endif
- sprintf(device, "%s%s", TTY, *argv);
- sprintf(lockdev, "%s%s", LOK, *argv);
- allow = TTY_UNDEF; i = 0;
- while (i <= total) { /* look at all defined lines */
- #ifdef DEBUG
- fprintf(stderr, "LOCKFILE? %s?\n", lockdev);
- #endif
- if (access(lockdev, 00) == 0) {
- allow=TTY_LOCK;
- break;
- }
- #ifdef DEBUG
- fprintf(stderr, "DOES:%s==%s?\n", allowable[i], *argv);
- #endif
- if (strcmp(allowable[i], *argv) == 0)
- allow=TTY_OKAY;
- i++;
- }
- #ifdef DEBUG
- fprintf(stderr, "allow=%d\n", allow);
- #endif
- switch (allow) {
- case TTY_UNDEF:
- fprintf (stderr, "open: not allowed on %s\n", *argv);
- break;
- case TTY_LOCK:
- fprintf (stderr, "open: device locked: %s\n", lockdev);
- break;
- case TTY_OKAY:
- /* attempt to change mode on device */
- if (chmod (device, 00666) < 0)
- fprintf (stderr, "open: cannot chmod on %s\n", device);
- break;
- default:
- fprintf (stderr, "open: FAULT\n");
- }
- }
- exit (0);
- }
- 14. THIRD-PARTY DRIVERS
- [ [613]Top ] [ [614]Contents ] [ [615]Next ] [ [616]Previous ]
- Unix versions, especially those for PCs (SCO, Unixware, etc) might be
- augmented by third-party communication-board drivers from Digiboard,
- Stallion, etc. These can sometimes complicate matters for Kermit
- considerably since Kermit has no way of knowing that it is going
- through a possibly nonstandard driver. Various examples are listed in
- the earlier sections of this document; search for Stallion, Digiboard,
- etc. Additionally:
- * The Stallion Technologies EasyConnection serial board driver does
- not always report the state of DSR as low. From Stallion (October
- 1997): "Unfortunately, this is a bug in our driver. We have
- implemented all of the other TIOMC functions, eg DTR, DCD, RTS and
- CTS, but not DSR. Our driver should report the actual state of DSR
- on those of our cards that have a DSR signal. That the driver
- always reports DSR as not asserted (0), is a bug in the driver. The
- driver should be either reporting the state of DSR correctly on
- those cards that support DSR or as always asserted (1) on those
- cards that do not have a DSR signal. This will be fixed in a future
- version of our drivers; at this time I cannot say when this will
- be." And later, "As far as I can tell, we don't support the
- termios/termiox ioctls that relate specifically to DSR and RI; all
- the rest are supported. This will, as I mentioned earlier, be fixed
- in the next release of our ATA software."
- - World Wide Escalation Support, Stallion Technologies, Toowong
- QLD, [617]support@stallion.oz.au.
- Later (December 1997, from the same source):
- * We have now released a new version of the ATA software, version
- 5.4.0. This version fixes the problem with the states of the DSR
- and RI signals and how they were being reported by the driver. This
- is the problem that you reported in October. The DSR signal is
- reported correctly on those cards that support the DSR signal, such
- as the early revision of the EasyIO card and the EasyConnection 8D4
- panel, and as always asserted on those cards that do not support
- the DSR signal in the hardware. The new driver is available from
- our Web site, [618]www.stallion.com, in the /drivers/ata5/UnixWare
- directory.
- [ [619]Top ] [ [620]Contents ] [ [621]C-Kermit Home ] [ [622]C-Kermit
- 8.0 Overview ] [ [623]Kermit Home ]
- __________________________________________________________________
- C-Kermit 8.0 Unix Hints and Tips / [624]The Kermit Project /
- [625]Columbia University / [626]kermit@columbia.edu
|