I've got the Mock replacement server up and running, but my Rio doesn't like it. I've done a network snoop, and here's what I see:

• The RR does a DHCP Discover
• The RR does an ARP request for one of those Microsoft IP addresses
• My DHCP server sends a DHCP Offer to the RR
• The RR makes a DHCP request to the DHCP server
• The RR broadcasts what seems to be an SSDP request with its new IP address (even though DHCP negotiations haven't finished)
• The DHCP server makes an ARP request for the RR's IP address
• The DHCP server ACKs the DHCP Request
• The RR responds to the DHCP server's ARP request
• The mock server responds to the SSDP request
• The RR makes an ARP request for the DHCP server/mock server
• Server responds to ARP request
• NFS ensues for about 2.5 seconds worth of traffic
• There's a pause of about 3.5 seconds
• RR makes ARP request for server
• Server responds to ARP request
• NFS ensues for about 5 seconds
• There's a pause of about 6 seconds
• This procedure starts over

During this, at the front panel of the Receiver, it shows ``Searching for music server'' for about 5 seconds, then ``Found music server'' for about another 5 seconds, then it's blank for about 4 seconds, then it starts over.

None of the traffic looks bad, and it never gets to doing anything beyond DHCP, ARP, SSDP, and NFS.

The server is the DHCP, SSDP, and NFS server. It's an OpenBSD machine. It serves NFS shares, including the Receiver share, just fine to other machines.

Any ideas? Should I crack the unit open and see if I can get a serial console?

Should I crack the unit open and see if I can get a serial console?

You'll need a little inverter board to do this, which plugs into a 4-pin header on the main board. Hugo might be able to help you out with the circuit diagram.

We've never tried it with an OpenBSD NFS server, so there could be something wrong there. ISTR that we had problems with the read packet size causing really slow bootups on other NFS servers (particularly ours).

However, if it's doing some NFS and then starting again, it sounds like it's crashing and rebooting. A serial port is probably the only thing to try here.

Generally, if the service locator request (for the HTTP server) is unsuccessful, you're left at the bootup screen with a (cryptic) failure message.

What does the screen say (exactly) -- the second kernel displays a different screen, so we can tell if it's successfully loading that.

Oh, something else occurs. Do you have the necessary layout files installed? I think it reboots if it can't find one.

You'll need a little inverter board to do this, which plugs into a 4-pin header on the main board. Hugo might be able to help you out with the circuit diagram.

That would be super.

if it's doing some NFS and then starting again, it sounds like it's crashing and rebooting.

That was my layman's guess, too.

service locator request

Is that the SSDP upnp UDP broadcast thingy?

What does the screen say (exactly) -- the second kernel displays a different screen, so we can tell if it's successfully loading that.

Rio (graphic)
Please wait
Searching for music server

then

Rio (graphic)
Please wait
Found music server

then

(blank)

then it restarts. I think I can see the LCD reset here, too.

When I get it running w/ the Windows software, it does the same thing except the blank screen doesn't last very long and is followed by:

Audio (graphic)
Receiver (graphic)
Searching for music... (inside a single-pixel frame)

Do you have the necessary layout files installed?

Eh? Layout files? (Edit: You mean the /layout/* files that it gets from the web server? They're there, but remember that, as far as I can see, it never makes any web requests at all; NFS is as far as it gets.)

In playing around with it, I found this interesting tidbit:

If I start the player against the Windows Audio Receiver, then exit the Audio Receiver application and start the Mock SSDP server, then turn off the Receiver and turn it back on, it works. In this method, when I tuen the Reciever back on, It only shows the ``Audio Receiver'' graphic startup screen.

Is it caching the NFS root that it received from the Windows Audio Receiver software and then using the SSDP data from the Mock server?

Edit: I also get the same thing if I use a Solaris 7 NFS server instead. Surely it isn't relying on some quirk in Linux's NFS server.

That would be super.

Hugo says to look at http://www.mock.com/receiver/server/, under the "Console" heading, which details the pins on the serial header.

Is that the SSDP upnp UDP broadcast thingy?

Yeah, but it's not real UPnP/SSDP, so I've stopped calling it that.

Found music server

...means that it's booted the second kernel, and is now grabbing the player.

Searching for music... (inside a single-pixel frame)

...means that it's loaded the player software and is now looking for the HTTP server.

If I start the player against the Windows Audio Receiver...

If you turn it off with the button, it's only soft-off. It's not actually exited the player, so it doesn't need to make any more service locator requests, and will continue using the old NFS server.

Surely it isn't relying on some quirk in Linux's NFS server.

No.

Can you get debug output from your NFS daemon (or a network trace). It'd be interesting to see what files it's looking for (and whether it finds them) once the second kernel starts up.

I think I may have found the problem. It looks like it's getting permission denied when trying to read the fonts files because the arf/tar file has the permissions on those files 0600. (Unfortunately, I can't verify that that's the problem, as I'm not at home right now.)

Is there any reason they need to be set that way? The whole share is ro anyway. And there aren't really any users on the Receiver OS, anyway, are there?

BTW, a couple of finds produce these outputs:

% find . \! -perm -0040
./empeg/lib/fonts/graphics.bf
./empeg/lib/fonts/large.bf
./empeg/lib/fonts/medium.bf
./empeg/lib/fonts/small.bf
./empeg/lib/fonts/wait.bf
./empeg/lib/fonts/timecode.bf

% find . \! -perm -0004
./dev/mem
./dev/kmem
./dev/ttyS0
./dev/ttyS1
./empeg/lib/fonts/graphics.bf
./empeg/lib/fonts/large.bf
./empeg/lib/fonts/medium.bf
./empeg/lib/fonts/small.bf
./empeg/lib/fonts/wait.bf
./empeg/lib/fonts/timecode.bf

(fx: lightbulb)

Ah, if you've got root_squash turned on, then the NFS client (the player) will be unable to open those files from the .arf file that are owned by root, but not group/world readable. I think.

So, try either using no_root_squash, or do as you suggest and make the files/device entries world readable.

That was it. I didn't seem to need to change the perms on the devices, just the font files.