From: SMTP%"@UKCC.UKY.EDU:list-mgr@WKUVX1.BITNET" 10-MAY-1993 08:43:41.92 To: EVERHART CC: Subj: Re: Help with name resolution problem... X-Listname: Message Exchange Discussion List Warnings-To: <> Errors-To: list-mgr%WKUVX1.BITNET@uu7.psi.com Sender: list-mgr%WKUVX1.BITNET@uu7.psi.com X-Newsgroups: vmsnet.networks.tcp-ip.cmu-tek,vmsnet.mail.mx From: millerh@CCVAX4.CCS.CSUS.EDU Subject: Re: Help with name resolution problem... Message-Id: <0096C465.C470FF5A@CCVAX4.CCS.CSUS.EDU> Reply-To: MX-List%WKUVX1.BITNET@uu7.psi.com, millerh@CCVAX4.CCS.CSUS.EDU Organization: CMU (no-TEK) Tech Support Date: Mon, 10 May 1993 11:46:27 GMT Lines: 44 To: MX-List@WKUVX1.BITNET X-Gateway-Source-Info: USENET In article <1sgooqINN3pi@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes: >In article <1993May7.133902.1562@dmc.com>, system@dmc.com writes: >=1. What is it trying to tell me? (134 = invalid media address). > >If I recall correctly, that status under CMU-TEK TCP/IP v6.4 meant that you >were unable to assign a channel to a net device. You'd typically have to >restart the TCP/IP package. > >=2. What do I have to provide you folks to help me debug this? (I'm a bit new >=to the TCP/IP world in general and the CMUIP world in particular). > >I'm not very familiar with the CMUIP v6.6, but you might want to have a look at >CMUIP_ROOT:[SYSMGR]TCP_ACTIVITY.LOG. >------------------------------------------------------------------------------- - >Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL > >Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My >understanding of astronomy is purely at the amateur level (or below). So >unless what I'm saying is directly related to VAX/VMS, don't hold me or my >organization responsible for it. If it IS related to VAX/VMS, you can try to >hold me responsible for it, but my organization had nothing to do with it. Carl, An error of this type could occur if IPACP crashed. But, as we all know, 6.6-5A is much less prone to crashing! Also, the IOSB changed a little between 6.4 and 6.5/6.6, as did the numbering of the error messages. But the 134 is a system message, not an IPACP message. I think your theory about not being able to assing a net device carries a lot of water - a site in Germany reports that TRACEROUTE fails to work after IPACP runs "for a long time", and I suspect that the IP device numbers may not be getting recycled properly. Thanks for adding some credence to my theory - I'll check it out this week, meteors, floods and earthquakes notwithstanding. -HWM ---------- Henry W. Miller Assistant Systems and Network Manager U.S. Bureau of Reclamation Mid Pacific Region 2800 Cottage Way MP1100