9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] protocol botch
@ 2004-04-19 15:13 Steve Simon
  2004-04-19 15:59 ` Russ Cox
  0 siblings, 1 reply; 5+ messages in thread
From: Steve Simon @ 2004-04-19 15:13 UTC (permalink / raw)
  To: 9fans

Hi,

I feel really bad asking again but I am stumped.

I checked my cpurc (I posted it this morning but
forgot to add a subject in my rush).

The only way forward I can see is to:

1/ understand the internals of factotum (which I really don't
have time to do at the moment) so I can understand its debug
messages.

2/ format my disks and reinstall from scratch in the hope I
type somthing differently.

3/ store my data on paper :-^

- auth/debug works
- cpu(1) doesn't
- telnet doesn't
- booting from the network doesn't

all authentication problems.

I'al pay in beer at the 9con...

Anyone ?

-Steve


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] protocol botch
  2004-04-19 15:13 [9fans] protocol botch Steve Simon
@ 2004-04-19 15:59 ` Russ Cox
  0 siblings, 0 replies; 5+ messages in thread
From: Russ Cox @ 2004-04-19 15:59 UTC (permalink / raw)
  To: 9fans

Your auth server is unhappy.  Auth/debug mainly debugs
network and auth server setup problems.  it doesn't
debug the factotums themselves.  It seems likely that
either your server or client factotum (or since they're in
sync, both!) don't have the password that you've
been typing into auth/debug and used in the auth
server changeuser setup.

I'd reread your secstore file very carefully to make sure
it's got the password you think it has.

Russ


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] protocol botch
@ 2004-04-18 23:40 Steve Simon
  0 siblings, 0 replies; 5+ messages in thread
From: Steve Simon @ 2004-04-18 23:40 UTC (permalink / raw)
  To: 9fans

Hi,

Russ, as I couldn't get the terminal (paris) to network boot
I loaded the distribution onto it and booted it as a standalone
terminal. Thus I could run auth/debug on the paris against the
fileserver (felix).

Felix is a PIII 650 with scsi disks, paris is my venerable NEC
Versa SX.

Andrey, I saw your previous posts about "protocol botch" but as
the authdom specified in the nvram is definitely the sam as the one
in /lib/ndb/local, bowth machines have their authdom set explicitly
(in the sys= line in /lib/ndb/local), and the /lib/ndb/local on the
two machines is a copy of the same file, I think I have covered that;
unless you know different?

Sorry, still stumpped. I shall check I start listen after keyfs
(and post a copy of my cpurc) tomorrow.

-Steve


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [9fans] protocol botch
  2004-04-18 22:36 Steve Simon
@ 2004-04-18 22:55 ` Russ Cox
  0 siblings, 0 replies; 5+ messages in thread
From: Russ Cox @ 2004-04-18 22:55 UTC (permalink / raw)
  To: 9fans

Have you run auth/debug on both machines?
What are paris and felix?  Assuming one is the 
terminal, how is it that you have a prompt
if you cannot boot the terminal?

Russ


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [9fans] protocol botch
@ 2004-04-18 22:36 Steve Simon
  2004-04-18 22:55 ` Russ Cox
  0 siblings, 1 reply; 5+ messages in thread
From: Steve Simon @ 2004-04-18 22:36 UTC (permalink / raw)
  To: 9fans

[-- 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2004-04-19 15:59 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-04-19 15:13 [9fans] protocol botch Steve Simon
2004-04-19 15:59 ` Russ Cox
  -- strict thread matches above, loose matches on Subject: below --
2004-04-18 23:40 Steve Simon
2004-04-18 22:36 Steve Simon
2004-04-18 22:55 ` Russ Cox

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).