I just installed NAS on this HP 712, so that I could receive the sound i/o from a remote KDE session (KDE offers native NAS support). KDE complains that it gets a connection refused, while using 'auinfo' replies with "unable to connect to server". The AUDIOSERVER variable is exported manualy on the commandline, prior to running 'auinfo' but does not help. Netstat confirms that there is something running on port 8000 on the 712, open to all incoming, but KDE still complains that it cannot connect to it. Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:8000 *:* LISTEN Is this problem specific to the hppa port, or have I just forgotten to configure something, either on the remote KDE (currently set to use NAS) or locally in X or elsewhere? FYI, I'm initiating the remote session using the 712's GDM Chooser (Gnome login panel).
Can you connect to port 8000 on the HP machine locally?
X8-----
<root@zarya:/root># auinfo -audio tcp/localhost:8000
Audio Server: ?localhost:8000
Version Number: 2.2
Vendor: Network Audio System Release 1.6 - VoxWare
Vendor Release: 1
Min Sample Rate: 8000
Max Sample Rate: 44100
Max Tracks: 32
Number of Formats: 7
Formats: ULAW8 LinearUnsigned8 LinearSigned8
LinearSigned16MSB LinearUnsigned16MSB
LinearSigned16LSB LinearUnsigned16LSB
Number of Elem Types: 12
Element Types: ImportClient ImportDevice ImportBucket
ImportWaveForm Bundle MultiplyConstant AddConstant
Sum ExportClient ExportDevice ExportBucket
ExportMonitor
Number of Wave Forms: 2
Wave Forms: Square Sine
Number of Actions: 3
Actions: ChangeState SendNotify Noop
Number of Devices: 3
Device 0:
Changable: Gain LineMode
ID: 0x23
Kind: PhysicalInput
Use: Import
Format: LinearUnsigned8
Num Tracks: 2
Access: Import List
Description: "Stereo Channel Input"
Min Rate: 8000
Max Rate: 44100
Location: Left Right External
Gain Percent: 50
Num Children: 0
Device 1:
Changable: Gain
ID: 0x22
Kind: PhysicalOutput
Use: Export
Format: LinearUnsigned8
Num Tracks: 2
Access: Export List
Description: "Stereo Channel Output"
Min Rate: 8000
Max Rate: 44100
Location: Center Internal
Gain Percent: 50
Num Children: 1
Children: 0x21
Device 2:
Changable: Gain
ID: 0x21
Kind: PhysicalOutput
Use: Export
Format: LinearUnsigned8
Num Tracks: 1
Access: Export List
Description: "Mono Channel Output"
Min Rate: 8000
Max Rate: 44100
Location: Center Internal
Gain Percent: 50
Num Children: 0
Number of Buckets: 0
<root@zarya:/root>#
X8-----
<snip> OK. Are you running a firewall on either machine that might be blocking the connection?
Nope. Both machines are wide open, though inside a firewall-proteced LAN.
Looking at the man page, I found this: "-aa Allows any client to connect. By default, access is allowed only to authenticated clients." My immediate reaction to that is, what's the means of authentication? tcpd? Must connection from a specific subnet be explicitely allowed in some file or is that deducted from the NIC's netmask?
Hmmm. Can you telnet to that port remotely?
Ah, that's probably it. You'll probably need to do X-style authentication.
X8----- <root@share:/root># telnet zarya 8000 Trying 172.16.1.13... Connected to zarya.intranet. Escape character is '^]'. X8-----
Since this is not specified in any of the documentation (at least, the man pages don't say anything), good luck in users figuring out that one (this comment should be passed on to upstream): This is a network service; generally speaking, means of control can include: tcpwrap, xauth, s\key, SSL certificate, ssh DSA or RSA key, etc. etc. As such, the assumption that, since they designed NAS as the audio equivalent of X, then authentication obviously follows xauth methods, is a rather dubvious one, especially at an era when people hardly use xauth, because SSH takes care of session authentication transparently for them or, otherwise, some display manager (GDM, XDM, KDM, etc.) handles it. So... Even at the risk of repeating data otherwise found elsewhere e.g. X man page, the authors should add a quick HOWTO for people that never had to deal with xauth style of authentication... assuming that this is how NAS works, in the first place. If the authentication method is not xauth, they better start typing some explanations. *grin*
OK, I guess I'll fiddle with xauth. *grin* At this point, I don't have anything to add to this bug report but, with your permission, would like to keep it open until upstream has released documentation about their authentication methods, which would then close the bug. :) Anyhow, thanks for your help in hunting down the cause for this! :)
Yes. Sorry - I've never tried to do this myself to know one way or
another.
Agreed. I'll forward it upstream.
I'm checking it out now. Yes, it's definitely xauth based:
trabant:~$ strace auinfo -audio tcp/leo:8000
...
access("/vsoft/home/steve/.Xauthority", R_OK) = 0
brk(0x8053000) = 0x8053000
open("/vsoft/home/steve/.Xauthority", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0600, st_size=1234, ...}) = 0
old_mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x402c4000
read(4, "\0\0\0\4\n\4\2\20\0\0010\0\22MIT-MAGIC-COOKIE-1\0"..., 32768)
= 1234
read(4, "", 32768) = 0
close(4) = 0
munmap(0x402c4000, 32768) = 0
writev(3, [{"l\373\2\0\2\0\0\0\0\0\377\277", 12}], 1) = 12
fcntl64(3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
read(3, 0xbffffa80, 8) = -1 EAGAIN (Resource
temporarily unavailable)
select(4, [3], NULL, NULL, NULL) = 1 (in [3])
read(3, "\0-\2\0\2\0\f\0", 8) = 8
read(3, "Client is not authorized to conn"..., 48) = 48
close(3) = 0
write(2, "auinfo: unable to connect to au"..., 43auinfo: unable to
connect to audio server
) = 43
_exit(1) = ?
If you set up your X authority stuff correctly, this should work fine
for you for now. And I'll complain at upstream and ask for
documentation on the authentication area. Sorry for the hassle...
:-) Exactly. I've marked the bug as forwarded upstream, so it will stay open until that's done. Hey, it's my job. Ish. :-) Glad to help.
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)? 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. KISS is the word (the accronym, not the band :).
[Added cc: to the nas mailing list] I don't _think_ so - I believe it's all meant to be big endian to match normal network traffic. 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?
Did you manage to get anywhere with xauth in the end? I've spoken to upstream, and they're going to add some more docs for the next release. Of course, they'd love some help with it and working examples would help a lot. :-)
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). ;-) 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...
Good to hear. What sort of tests do you suggest that I do, on localhost? ;-) Alsaplayer is a sample player. Depending upon the compilation options, it is possible to enable built-in support to output to arts, esound, NAS, etc. Noted. TBH, I'd much rather see NAS daemon use libtcpwrap than that bloated xauth. At any rate, I have always found xauth to be really cumbersome; thanks goodness SSH handles thta transparently, nowadays! The same goes for XDMCP (i.e.GDM,KDM,XDM), but that's a different issue. :)
[...] Trying out the nas clients, something like 'auinfo', 'auplay <some .wav file>', etc... In other words, just see if the server is even working properly with it's own clients... Ahh, right, I think Erik did the alsaplayer plugin... Erik? :) Does it work??? ;-) I accept patches ;-)