From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3297131e7597e7fdf78cf4e207cf2621@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] Authentication debugging help? In-Reply-To: <10048.1074626801@piper.nectar.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Tue, 20 Jan 2004 20:44:55 -0500 Topicbox-Message-UUID: bcc32df0-eacc-11e9-9e20-41e7f4b1d025 It's called snoopy. You can do a snoopy -f 'ip(a=)' and see of a dump of all the packets from/to that address. 'Connection refused' is what you get if you tried to connect via tcp and there was no server at the other end. 'Connection rejected' is the same thing if you tried to connect via il. I should probably go through the two protocols and try to consolidate the error messages. Clearly you've been trying different answers to 'root is from'. Sounds like one of: 1) never told your fossil server 'listen tcp!*!564' 2) it couldn't announce on the port for some other reason like perhaps a 'listen' process was already listening there. Make sure there are no /rc/bin/service*/tcp564 files lying around. 3) there isn't a listener for the auth server The stuff I gave you earlier should detect all or the above. If the file server is announced and running right with the file server, srv tcp! should work and create a file: /srv/tcp!ip address of file server> I the authentication stuff is working mount /srv/tcp! /tmp should work even if you aren't the host owner (hostid from a previous discussion). If you are the hostowner, you can do this even if there is no auth server since it'll be the same key on both sides and you don't need a third party with both shared keys. In fact, that's how we normally run our cpu servers; they have the same host owner and password as the file server so that they can come up even if the one booting is the auth server. Anyways, tell me how you do.