From: "Steve Simon" <steve.simon@snellwilcox.com>
To: 9fans@cse.psu.edu
Subject: [9fans] protocol botch
Date: Sun, 18 Apr 2004 23:36:06 +0100 [thread overview]
Message-ID: <e0265f7c942c12d306acf78177b6a2c1@snellwilcox.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]
Hi,
Still struggling with authentication. I am trying to get a terminal to
network boot from a signge cpu/fossil/auth server.
this now fails with (from memory)
auth_proxy rcp write: write fd: file not found
Just to test the configuration I tried booting the terminal from its local
factotum and try to authenticate.
auth/debug is quite happy, its tests for my steve and bootes work fine.
but:
paris% cpu -h felix
cpu: can't authenticate: felix: auth_proxy rpc write: cpu: srvauth:: auth server protocol botch
also (this one is from memory)
paris% telnet felix
challange: 838323
response: 983Fe7302
!auth server protocol botch
I copied my factotum contents and ndb/local between the machines
(via secstore), so they are definitely in sync.
I turned on factotum's debug on paris (the terminal) but its
not clear to me what is going wrong.
I have tried authenticating between terminals (comp.os.plan9 passim)
and always found that when auth/debug is happy auth just works;
This one seems different.
I searched the archives and got pointers to the authdom being different on
the two machines, but I checked this very carefully, the /lib/ndb/local is
the same, and even trying xd /dev/sd00/nvram to double check.
I have spent many hours on this and cannot find the problem (sigh).
Sorry to be dumb,
-Steve
[-- Attachment #2: factotum --]
[-- Type: text/plain, Size: 63 bytes --]
key proto=p9sk1 dom=home.mydom.net user=steve !password=xxxxxxx
[-- Attachment #3.1: Type: text/plain, Size: 338 bytes --]
from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless. To avoid possible automatic
execution, we changed the content headers.
The original header was:
Content-Disposition: attachment; filename=factotum.debug
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
[-- Attachment #3.2: factotum.debug.suspect --]
[-- Type: application/octet-stream, Size: 1708 bytes --]
11: start proto=p9any role=client yields phase CNeedProtos: ok
11: read 4093 in phase CNeedProtos yields phase CNeedProtos: phase: protocol phase error: read in state CNeedProtos
11: write 0 in phase CNeedProtos yields phase CNeedProtos: toosmall 2048
11: start proto=p9sk1 role=client dom=home.mydom.net yields phase CHaveChal: ok
11: write 19 in phase CNeedProtos yields phase CHaveProto: ok
11: read 19 in phase CHaveProto yields phase CRelay: ok
11: read 8 in phase CHaveChal yields phase CNeedTreq: ok
11: read 8 in phase CRelay yields phase CRelay: ok
11: read 4093 in phase CNeedTreq yields phase CNeedTreq: phase: protocol phase error: read in state CNeedTreq
11: read 4093 in phase CRelay yields phase CRelay: phase: protocol phase error: read in state CNeedTreq
11: write 0 in phase CNeedTreq yields phase CNeedTreq: toosmall 141
11: write 0 in phase CRelay yields phase CRelay: toosmall 141
11: write 141 in phase CNeedTreq yields phase CHaveTicket: ok
11: write 141 in phase CRelay yields phase CRelay: ok
11: read 85 in phase CHaveTicket yields phase CNeedAuth: ok
11: read 85 in phase CRelay yields phase CRelay: ok
11: read 4093 in phase CNeedAuth yields phase CNeedAuth: phase: protocol phase error: read in state CNeedAuth
11: read 4093 in phase CRelay yields phase CRelay: phase: protocol phase error: read in state CNeedAuth
11: write 0 in phase CNeedAuth yields phase CNeedAuth: toosmall 13
11: write 0 in phase CRelay yields phase CRelay: toosmall 13
11: failure auth server protocol botch
11: write 13 in phase CNeedAuth yields phase CNeedAuth: failure auth server protocol botch
11: write 13 in phase CRelay yields phase CRelay: failure auth server protocol botch
[-- Attachment #4: local --]
[-- Type: text/plain, Size: 835 bytes --]
#
# network database
#
# to force this file to be re-read type
# !echo -n refresh >/net/cs
ip=127.0.0.1 sys=localhost dom=localhost
database=
file=/lib/ndb/local
file=/lib/ndb/common
# laptop
sys=paris ether=0020af8d6140
ip=192.168.0.3
authdom=home.mydom.net
dom=paris.mydom.net
bootf=/386/9pc.gz
# home server
sys=felix ether=00609765ed59
ip=192.168.0.5
authdom=home.mydom.net
dom=felix.mydom.net
# home, inside firewall
ipnet=home ip=192.168.0.0 ipmask=255.255.255.0
ipgw=192.168.0.1
# dns=194.168.4.100 dns=194.168.8.100
# dnsdomain=mydom.net
pop3=webmail.snellwilcox.com
smtp=smtp-uk.snellwilcox.com
authdom=home.mydom.net
nntp=news.ntlworld.com
ntp=gb.public.ntp.get-time.net
fs=192.168.0.5
cpu=192.168.0.5
auth=192.168.0.5
auth=felix
authdom=home.mydom.net
next reply other threads:[~2004-04-18 22:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-18 22:36 Steve Simon [this message]
2004-04-18 22:55 ` Russ Cox
2004-04-18 23:40 Steve Simon
2004-04-19 15:13 Steve Simon
2004-04-19 15:59 ` Russ Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e0265f7c942c12d306acf78177b6a2c1@snellwilcox.com \
--to=steve.simon@snellwilcox.com \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).