robin@itcatl.UUCP (Robin Cutshaw) (10/23/89)
I'm having a weird problem with inetd on AIX 1.1 for the PS/2. I can
make tcp connections out to anyone on my backbone with no problems. I
can also receive incoming calls such as ping and X-windows stuff with
no problems. However, when connections go through inetd they connect
with no problems but then hang. This effects everything in inetd.conf
including telnet, rlogin, etc.
Anyone seen this? IBM says "see your SE" or re-install the OS. They
say it's not a defect so sorry charlie. The guy I talked with said
he didn't know much about "TPC", I guess not.
Thanks.
robin
--
----------
Robin Cutshaw {gatech,rebel}!itcatl!robin
Disc Access, Atlanta, Ga. (404)261-1264 (formerly ITC)garnett@rpp386.cactus.org (John Garnett) (10/23/89)
In article <395@itcatl.UUCP> robin@itcatl.UUCP (Robin Cutshaw) writes: >I'm having a weird problem with inetd on AIX 1.1 for the PS/2. I can >make tcp connections out to anyone on my backbone with no problems. I >can also receive incoming calls such as ping and X-windows stuff with >no problems. However, when connections go through inetd they connect >with no problems but then hang. This effects everything in inetd.conf >including telnet, rlogin, etc. > >Anyone seen this? IBM says "see your SE" or re-install the OS. They >say it's not a defect so sorry charlie. The guy I talked with said >he didn't know much about "TPC", I guess not. > >Thanks. >robin Do the "hang" problems only occur when you try to telnet from an AIX PS/2 to an AIX/RT? If so, then you are experiencing a known problem that is described in the AIX PS/2 memo to users (stored in the root directory after updates have been applied). I believe the memo to users is also provided in printed form. The solution to the problem is to use "tn -e none hostname" and then set the TERM envariable to hft once having logged into the remote system. An alternate solution is to copy the AIX PS/2 /usr/lib/terminfo/ibm.ti file over to the AIX/RT system and use the tic command to recompile it. If this isn't the problem you are witnessing, please post a more complete description of the problem. Are you receiving any error messages when you use the commands that hang? Which commands used under what circumstances (from which system to which system?) hang? Do any error messages appear during the boot process (IPL)? Finally, you should try applying the AIX PS/2 Base Opsys update diskettes if you haven't done so. I believe that updates specific to AIX PS/2 TCP/IP are also available. -- +------------------------------------+-----------------------------------+ | John Garnett | Base 1.9 | | garnett@rpp386.cactus.org | | | {bigtex|texbell}!rpp386!garnett | "It's almost binary" |
robin@itcatl.UUCP (Robin Cutshaw) (10/24/89)
In article <395@itcatl.UUCP>, robin@itcatl.UUCP (Robin Cutshaw) (I) write(s): > I'm having a weird problem with inetd on AIX 1.1 for the PS/2. I can > make tcp connections out to anyone on my backbone with no problems. I > can also receive incoming calls such as ping and X-windows stuff with > no problems. However, when connections go through inetd they connect > with no problems but then hang. This effects everything in inetd.conf > including telnet, rlogin, etc. > After tinkering around a bit, I've found the problem! It seems that if your last line in /etc/inetd.conf includes a command that has multiple arguments, inetd will go into an infinite loop reading EOF. I had uncommented the last line in inetd.conf that included rpc and that's when it broke. All I had to do was enter a # on the next line and it worked fine. The fix: (after tinkering on a source machine) there is a call to ungetc (only one) in inetd.c. place the line "if (c != (char )EOF)" before this line and it will work just fine. Sloppy problem of ungetc'ing EOF. IBM, are you listening??? robin -- ---------- Robin Cutshaw {gatech,rebel}!itcatl!robin Disc Access, Atlanta, Ga. (404)261-1264 (formerly ITC)
oleg@gryphon.COM (Oleg Kiselev) (10/27/89)
In article <396@itcatl.UUCP> robin@itcatl.UUCP (Robin Cutshaw) writes: >After tinkering around a bit, I've found the problem! Indeed, that is the problem. >The fix: Good fix. >IBM, are you listening??? Not IBM's fault. The bug came from BSD TCP/IP code and is still in Tahoe system (I just looked). Thanks to you, this bug is fixed in AIX/370. Please file a formal bug report to get it fixed in AIX/PS2 (it's more logistically complicated to make fixes in a released product). Suggest your fix when you reprt the bug. -- "No regrets, no apologies" Ronald Reagan Oleg Kiselev ARPA: lcc.oleg@seas.ucla.edu, oleg@gryphon.COM (213)337-5230 UUCP: [world]!{ucla-se|gryphon}!lcc!oleg
jackv@turnkey.gryphon.COM (Jack F. Vogel) (10/27/89)
In article <396@itcatl.UUCP> robin@itcatl.UUCP (Robin Cutshaw) writes: [ original problem description deleted...] >After tinkering around a bit, I've found the problem! It seems that if >your last line in /etc/inetd.conf includes a command that has multiple >arguments, inetd will go into an infinite loop reading EOF. I had >uncommented the last line in inetd.conf that included rpc and that's >when it broke. All I had to do was enter a # on the next line and it >worked fine. > >The fix: (after tinkering on a source machine) > > there is a call to ungetc (only one) in inetd.c. > place the line "if (c != (char )EOF)" before this line > and it will work just fine. Sloppy problem of ungetc'ing EOF. > >IBM, are you listening??? Robin, The way in which changes get made or the way in which IBM "listens" to problems is a bit more formal than posting something to the net. What needs to happen is that a formal report of a bug is submitted, this is called an APAR. The APAR is evaluated by support and if needed is the basis of a programming change. In some cases all evaluation and changes will happen within IBM support, in difficult ones they will make their way back to us at Locus (the buck really stops here at this point :-}). In this particular case, however, a report will not be necessary since I believe the problem is already known. Also, I checked the 4.3tahoe source for inetd.c and it appears to be the same, so if the behavior does not occur there then I suspect the problem is in the library and not inetd itself. In any case it will be fixed. As you can see, we are listening :-}! Disclaimer: This is in no way an official statement of IBM or Locus. -- Jack F. Vogel jackv@seas.ucla.edu AIX Technical Support - or - Locus Computing Corp. jackv@ifs.umich.edu
oleg@gryphon.COM (Oleg Kiselev) (10/29/89)
In article <6387@turnkey.gryphon.COM> jackv@turnkey.gryphon.COM writes: > In this particular case, however, a report will not be necessary >since I believe the problem is already known. Not to anyone I talked to. And the fact that there hasn't been a Tahoe fix posted (not that I know of, anyway), seems to indicate that noone has noticed it yet. >Also, I checked the 4.3tahoe >source for inetd.c and it appears to be the same, so if the behavior >does not occur there then I suspect the problem is in the library and >not inetd itself. It does not happen because Tahoe's inetd.conf file ends in a bunch of "internal" services lines, none of which are "multi argument" commands. I think we had tried this on a 4.3 Tahoe and inetd failed just as badly as on AIX. >In any case it will be fixed. It is fixed in AIX/370. To get it fixed in AIX/PS2 someone has to file an APAR, but the severity of the problem is marginal -- there are clear and unobtrusive work arounds which in no way detract from functionality. -- "No regrets, no apologies" Ronald Reagan Oleg Kiselev ARPA: lcc.oleg@seas.ucla.edu, oleg@gryphon.COM (213)337-5230 UUCP: [world]!{ucla-se|gryphon}!lcc!oleg