[nas] Re: Bug#207659: hppa: cannot connect to host: connection refused

[Jon Trulson]

On Mon, 8 Sep 2003, Steve McIntyre wrote:

> From: Steve McIntyre <steve at einval.com>
> Date: Mon, 8 Sep 2003 15:02:41 +0100
> Subject: [nas] Re: Bug#207659: hppa: cannot connect to host: connection
>     refused
> To: Martin-?ric Racine <q-funk at pp.fishpool.fi>
> Cc: 207659 at bugs.debian.org, nas at radscan.com
> X-Spam-Status: No, hits=-42.7 required=5.0
> 	tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2,
> 	      RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES,
> 	      USER_AGENT_MUTT,X_AUTH_WARNING
> 	autolearn=ham version=2.53
> X-Spam-Level:
>
> [Added cc: to the nas mailing list]
>
> On Mon, Sep 08, 2003 at 04:58:37PM +0300, Martin-?ric Racine wrote:
> >
> >Nope.  Got nowhere.  I ended up modifying the wrapper script to start with the
> >"alcoholic anonymous" option on.  After that, I managed to get alsaplayer-nas to
> >send something to nasd, but it came out as very loud garbage whose amplitude
> >changed as I fiddled with the Alsaplayer sliders.
> >
> >Could that be caused by endian differences between i386 and hppa (the X session
> >was running on i386, while hppa acted as the terminal running nasd)?
>
> I don't _think_ so - I believe it's all meant to be big endian to
> match normal network traffic.
>

	NAS is endian clean... do the nas clients (auplay, et. al.) work
properly locally?  remotely?  I'd make sure that works before messing with
KDE/whatever you are trying to get working...

	I am not sure how ALSA plays into this...  I've heard that using
ALSA in OSS compat mode works, but I only use the OSS drivers here... I
have used clients on intel to talk to HPPA (hpux) without problems (other
than the buggyness of the HPUX sound driver).

> >Btw, those NAS developers should figure out a stategy to transparently handle
> >authentication e.g. when logging on by remote via GDM, KDM or XDM.  Given that
> >the DISPLAY environment variable is automatically exported when using such a
> >display manager in indirect mode, one would think that e.g. KDE would then
> >automagically know where to find its audio device, but in practice this fails.
> >
> >My suggestion is that the AUDIOSERVER variable should be abandoned and, instead,
> >the host identified by DISPLAY should be presumed as providing the NAS daemon,
> >at the DISPLAY+8000 port. Authentication should also be left to the X session
> >itself to handle, not to a separate authentication token just for NAS.
>
> I believe that's the way that it's _meant_ to work, actually. If you've
> made no progress at all then there's probably a real bug in there. Jon,
> any thoughts?
>

	;-) AUDIOSERVER is actually quite useful when your audio device is
across the room, but Steve is right - this is supposed to be working.  The
server to use is determined like so:

	$AUDIOSERVER
	$DISPLAY
	:0

	In that order...  This does require v1.6 though (there are various
bugs in previous versions)...  You can also run nasd with debugging - that
might show some useful info...

	As for the auth tokens... Yes, that does need some revisiting...
I played with it a year or so ago, and it just didn't work.  Not
surprising I guess, since that code hasn't been changed since 1994 or
so...

-- 
Jon Trulson    mailto:jon at radscan.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
You talk like a Ferengi.