After building a Rio linux kernel so I could put some debugging in, it turns out that the wierd behaviour I was observing (ENETUNREACH) is caused by a complicated chain of events:

Unfortunately, my Rio *has* to get its IP address from my firewall since there is no way to prevent the firewall from replying to individual machines. :-(

Unlike every other machine on my LAN, the DHCP request from the Rio does not contain a 'Parameter Request List' option (option 55) asking for its gateway (parameter 3)!

Instead, it contains an empty gateway option (option 3) ... which is ignored by the DHCP server.

This has never caused a problem in the past since the Rio then uses broadcast SSDP to find it's NFS server (armgr.exe) and boots normally.

The reason that rioplay has problems is that the Rio boot loader explicitly passes a 'command line' argument to the new linux kernel containing the bogus IP configuration, and explicitly *disabling* further DHCP and SSDP!

The argument looks something like this:

ip=192.168.168.19:192.168.168.129:21075::255.255.255.0:::off

This is parsed in net/ipv4/ipconfig.c as:

myaddr:servaddr:pmapport:gateway:netmask:hostname:devname:flags

The gateway is therefore left unset, and the 'off' flag prevents dynamic configuration!

The "fix" is to make the function ip_auto_config_enable() return immediately at line 1961 without parsing the bogus config string, and to put the appropriate option into the dhcp request.

i.e. add the following 3 lines to ic_dhcp_init_ext() just after line 843

if (type==DHCPDISCOVER || type==DHCPREQUEST) {

> *e++ = 55; // PRB: Parameter Request List option
> *e++ = 1; // length of option
> *e++ = 3; // gateway address parameter

...


Anyhow... with these small fixes, I now have my Rio getting a sensible network configuration and rioplay can both talk to the rio server and route out of the local subnet to fetch shoutcast streams.

Paul