Re: [9fans] Plan 9 system behind firewall
I tryed Richard's suggestion, and got very good success. Thank you very much, Richard. Now I can drawterm from other IP domain than Plan 9-2 domain on Windows or Debian Linux. The last one, the long time delay of getting rio bootup remaines unsolved. However, it takes at doing /usr/okamoto/lib/profile, especially a line of mount -c /srv/boot /n/duniteother other, which is mounting 'other' file system to the main file system from the file server dunite withing Plan 9-2 system. I think I know why this happens, probably as John wrote yesterday. From outside the firewall, we have to target the fileserver as the fierewall machine, but after loged in we have to target dunite fileserver withing the domain... I'll try it next week. I don't know I can solve it cleanly or not, though. Kenji
Re: [9fans] Plan 9 system behind firewall
A long delay when connecting to a server behind a firewall may be an attempt to connect to the secstore port. Terminals booting with a remote fileserver, and some configurations of drawterm, will look for a secstore server, by default at address tcp!$auth!5356. If the auth machine isn't running auth/secstored, normally the client will immediately receive a tcp RST to show that the port is closed. But if a firewall is blocking the port by silently dropping packets, you'll get a long timeout instead. Can you configure the firewall to open tcp port 5356? If not, you can specify a different secstore address with argument '-s address' for drawterm, or by replying '[EMAIL PROTECTED]' instead of just 'okamoto' to the user: prompt when booting. If you don't have a secstore, just give an invalid dial string: user: [EMAIL PROTECTED] or drawterm -c cpuserver -a authserver -s !
Re: [9fans] Plan 9 system behind firewall
Thank you very much, Richard. A long delay when connecting to a server behind a firewall may be an attempt to connect to the secstore port. I'm not running secstore yet at the target (Plan 9-2) auth server. Can you configure the firewall to open tcp port 5356? Yes, I can. I'll try this soon. I'm now in a very tough time schedules, because of our comming new year, semester, here. Our situation is as this figure. Plan 9-1 and Plan 9-2 have local ip addresses, say 192.168.1.xx for Plan 9-1, 192.168.50.xx for Plan 9-2. Both firewall machines have global ip addresses. real wall ___ || other building |Plan 9-1 |==Linux box's =another firewall=| Plan 9-2 | | (Ken's fs, | firewall Univ LANBB router | venti+fossil+ | | auth server, | MZK-40g?? | cpu server, | | cpu server, | other Debian | terminals | |terminals)|machines |Debian, XP etc | | Windows XP| _ --- Now attempting to reach from Plan 9-1 domain terminal to Plan 9-2 system. One correction of my last mail: I can boot Plan 9 terminal in the Plan 9-1 domain using Plan 9-2 file/auth server. It was just too long time than I can wait.5.5 minutes from boot the kernel to a factotum responce of Plan 9-2 server, and 5 more minutes from it to get rio system (after type of password), total=10.5 minutes. Yes, then, I judged it failed to bootup. After the success of bootup, there is no problem, and I can use the Plan 9 teminal as usual way. I cannot solve this tommorow, Friday maybe. Kenji
Re: [9fans] Plan 9 system behind firewall
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
