From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: erik quanstrom Date: Mon, 24 Mar 2008 21:27:30 -0400 To: kokamoto@hera.eonet.ne.jp, 9fans@9fans.net MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Plan 9 system behind firewall Topicbox-Message-UUID: 808bced0-ead3-11e9-9d60-3106f5b1d025 > I have two sets of Plan 9 system within different IP domain, one of which > is sitting behind the firewall made by a brordband router and using fossil+venti+ > auth/cpu server and terminals(Plan 9-1). > Another is using Ken's fs, standalone auth server, cpu server, and terminals > (Plan 9-2). [...] > Lastly, I tried to login to the Plan 9-1 system behind the firewall from the above > Plan 9-2 system, and now I have problem. When I booted the Plan 9 kernel from > floppy drive (the kernel was read from the Plan 9-2 standalone auth server), > I had to wait 5 minutes until some response from the Plan 9-1 > auth server behind the firewall. It asked password, and I typed it, then, > I can reach the CPU server, not the Plan 9 system. I suppose this is same as > cpu command, and then, I have no display for rio. ---fact 4 are Plan9-1 and Plan9-2 in different authentication domains? if they are not, this could explain fact 4. you would have two auth servers serving the same authentication domain. this would explain how cpu could work when a direct login does not if you also have trouble contacting the remote authentication server but not the local one. this would allow plan 9 to know about the local auth server when drawterm may not. the long timeouts are sound like dns lookup problems to me. i generally double-check my ndb entries in cases like this, especially the auth, ip, and ipnet entries associated with the auth server. - erik