Mark: Well, echo sertainly isn;t the problem, since it's output that isn't appearing, not input (d'Oh), but it isn't MTU size either, since in fact the input is processed just fine, despite the lack of output.
Romney On Fri, 22 Nov 2002 19:56:56 -0500 Post, Mark K said: >Romney, > >I hate to argue with you, but the fact that they stop getting responses from >any commands would indicate it's something more than just local echo >problems. If they're not up to maintenance level, it's probably that, >assuming their MTU is really set to 1492 on the Linux/390 end in the MP3000. > >Mark Post > >-----Original Message----- >From: Romney White [mailto:[EMAIL PROTECTED]] >Sent: Friday, November 22, 2002 7:38 PM >To: [EMAIL PROTECTED] >Subject: Re: Missing telnet output (another stupid newbie question) > > >Steve: > >Sounds like you need to turn on local echo in your Telnet client. > >Romney > >On Fri, 22 Nov 2002 18:34:17 -0600 Steve Marak said: >>Adam, Mark, thanks for your quick responses both of which suggested MTU >>size as the culprit. I left it out of my previous post, but we are >>explicitly specifying MTU size of 1492 both in the VM TCP/IP config for >>that CTC link and when the Linux code boots. (No reason other than that's >>what the redbooks suggested.) >> >>Adam, you'd win the bet about TCPIP maint, however - the VM system has >>little maint above the base level. We found the list of recommended >>service for running Linux and have pulled it, but haven't yet put it on. >>(We didn't build this VM LPAR, and technically don't own it, so we can't >>act unilaterally.) >> >>Since you both immediately pointed to MTU size I need to look at that some >>more. (I'll check the Linux settings via ifconfig.) The MTU size for the >>link out the other side of VM's TCPIP is defaulted. Given that it will be >>a bit before we can apply ip maint, what would you consider the easiest >>circumvention? >> >>Thanks again for your quick replies. >> >>Steve >> >> >> >>On Fri, 22 Nov 2002, Post, Mark K wrote: >> >>> Steve, >>> >>> This sounds like an MTU mis-match between the Linux/390 guest and the VM >>> TCP/IP stack. Don't default the MTU size in the VM TCP/IP definitions >for >>> your guest. Define it explicitly. Make it match what the rest of your >>> network is expecting. Then, make sure your Linux/390 network definitions >>> include that value as well. You can check it with an "ifconfig" command. >>> >>> Mark Post >>> >>> -----Original Message----- >>> From: Steve Marak [mailto:[EMAIL PROTECTED]] >>> Sent: Friday, November 22, 2002 6:12 PM >>> To: [EMAIL PROTECTED] >>> Subject: Missing telnet output (another stupid newbie question) >>> >>... >>> But when we telnet into the Linux guest from elsewhere in the network >(not >>> on the same subnet as either the Linux guest or the VM system due to >>> network configuration) things get odd. We are prompted for and provide >>> userid and password. Having hit return after entering the password, we >>> then show as logged on (according to who or ps from the console). We can >>> enter commands and, based on various trials, they are executed just fine. >>> But we never see another character of output on the telnet session - no >>> shell prompts, no command responses, nothing. >>> >>> This happens no matter which of several telnet clients we use (including >>> putty), which of several terminal types we select (ANSI, VT100, etc.) or >>> whether the userid is root or another that we add on the fly (with >>> non-zero uid and gid). >>... >>> Config stuff: SuSE 7 ipl deck from the ISO CD images we downloaded (cat >>> /proc/version -> Linux version 2.2.16 ([EMAIL PROTECTED]) (gcc version >>> 2.95.2 19991024 (release)) #1 SMP Fri Nov 3 09:38:59 GMT 2000). Booting >>> under VM/ESA 2.4, using virtual CTCs for networking via the VM ip stack. >>> Network connectivity appears good by every test we've tried. MP3000 P30 >>> hardware. >> >> >>-- Steve Marak >>-- [EMAIL PROTECTED]
