So I got my TigerDirect (were these refurbs or something?)
unit.

Can't get it to respond to the remote at all.

When plugged into my switch its up on 10mb and the server
manager under win98 can see it, but I can't figure out
how the heck to get it to set a real IP. Tried configuring the
ip setup and setting up DHCP on my switch. Neither works.

My switch (cisco 3500XL) can see it and does assign it
to 10mb. I can name it in the manager. The link light
does come on, on the receiver.

The only clue I have is that the activity light is on solid.

I have no machines with extra pci slots to test the hpna.

Tried forcing 10mb on the switch, differing cables and
ports, etc. The manager never goes blue even though it
can find the unit. The unit keeps assigning itself
completely bogus ips in the 169.254.x.x range.

None of the front panel buttons do anything except the power
button.

Hints?

Ed

Hmm okay looks like I need to find out more about how this
darn thing boots. I have found that it is related to attempting
to cross intelligent switches. I found a cisco, an AT&T and
a cabletron that it will not work across.

what kind of boot request is being made? DHCP? (doubtful)
or perhaps rarp? Obviously something I normally configure
down. I plan to test defaults on each and find it, but after spending 30 min with the cisco, I've gotten nowhere and
its very frustrating. The manual is less than adequate for a
network attached device.

Ed

P.S. the remote ONLY works if actively connected to a server?
That seems rather silly.

It does use DHCP to attempt to gain it's own IP address. If that fails it falls back and chooses a random IP address in the range that you spotted (this process is part of the standard uPNP spec I believe).

If you can't get your Receiver to get it's IP address via DHCP at the moment then you can get up and running in the meantime by assigning the network adapter on your server an extra IP address in the 169.254.x.x range. So add an IP address of 169.254.0.1 with a network mask of 255.255.0.0 to the adapter on the server.

The details of what it does over the network during boot can be found at http://www.mock.com/receiver/server/ in the "Network snooping" section.

General ethernet troubleshooting tips are here (for the Rio Car, they almost all apply here).

Details on how the thing boots and downloads its software are here.

At least not like the Empeg does DHCP anyway.

I'll browse the snoop sections. It doesn't seem to want to
pull DHCP off:

-local win2k pro machine
-cabletron switch
-cheap cable modem router from linksys
-cisco switch

So far tested this. It appears to not work with managed
switches. unmanaged ciscos work fine, but I don't
have one of those at home (grumble)

Ed

It appears to not work with managed switches. unmanaged ciscos work fine, but I don't have one of those at home

I don't think the managed/unmanaged bit has anything to do with it. It's probably some other feature of the managed switches, something that (since they're managed) might be configurable. So there's hope, just keep pounding on it.

Well, it ought to work with at least 2 of those -- we tested it with W2K (Server) and a Linksys cable router.

Some questions:

How far through the boot does it get before bailing? Do you get a link light?
Can you get a network trace of it failing to get an IP?

Is there any way to turn on debugging or logging in the server
software?

It does get a link light, and the switches do see and
configure it as a 10mb only device. However then it usually
defaults to some odd ip, even if booted without a network
cable?


I'm looking for my old SNMP trace software. Haven't had to
use it in 2 years. Not much here to debug on the Cray


The server software can see it, but it always get some weird-ass
IP somehow like it fails DHCP but suceeds the SSDP. However
then the routing for the bogus class B keeps it from streaming.

I'm flying out to Quebec to do some rallying Wed, but I'll see
if I can get some time today to moved switches around here
and my router and switches around at home.

Ed

Run "armgr /log:filename.log"

You don't need to use any SNMP trace software -- if you've got a Linux box handy, just snag a copy of Ethereal.

...and if you don't have a Linux box handy but do have a Windows box (which given that you are running the Receiver server software you must have) then just grab Ethereal, as it is available for Windows too.

Yes well good thing I don't have to rely on the log.
After powering on the receiver and getting the
bogus ip as usual, it shows up in the list of receivers on
the server software, but NO log entry is made.


18:19:32.210 AdapterName.....
18:19:32.210 Description..... PCI Bus Master Adapter
18:19:32.210 Index........... 16777218 (0x1000002)
18:19:32.210 << Found Adapter info
18:19:32.210 DiscoverAdapters result: 0
18:19:32.210 HTTP Server: Starting...
18:19:32.210 Using database 'C:\Program Files\Audio Receiver\DB\cur2\audiorcv.dat'
18:19:32.210 httpd: binding to 192.168.1.69
18:19:32.210 Binding to 192.168.1.69:12078
18:19:32.270 NFS Server: Starting...
18:19:32.270 Using image file: C:\Program Files\Audio Receiver\receiver.arf
18:19:32.270 bootp: binding to 192.168.1.69:67
18:19:32.270 Hostname : 192.168.1.69
18:19:32.270 IP : 192.168.1.69
18:19:32.270 Gateway IP : 192.168.1.69
18:19:32.270 Server IP : 192.168.1.69
18:19:32.270 Netmask : 255.255.255.0
18:22:52.250 HTTP Server: Stopping...
18:22:52.250 HTTP Server: Stopped.
18:22:53.240 NFS Server: Stoppin

Well I can make the unit work on a totally flat cable or on
a private hub or unmanaged switch, but not at home
on the managed switch or at work anywhere
Still trying to figure it out. DLed that little snooper
and will check that out.

Have you tried setting the ports on the switch to 10Mbit? I've noticed that the receivers are a bit fussy and I think are timing out before the switch has got to 10Mbits.

Have you tried setting the ports on the switch to 10Mbit?

Surely he must have tried that, since it's the second thing on the list of ethernet troubleshooting tips I linked at the top of the thread.

funny, but that was among the first things I tried before posting.
I did look the board over as well.

Well still no luck. Ethereal under windows wasn't of much use
except that learned that a machine here had the latest strain
of one of those supid windows virii. Trying to watch the DHCP
is useless, but I do later see the SSDP attempts.

It doesn't appear to be a port blocking problem,but I'm about
stumped.

Why does the unit default to 169.254.x.x with no cable?
(well the wpnq does anyway, but its the same as when
it gets no assignment on eth)

Sorry to say I'll be out of town for a while so this will stay
not working.

Ed

funny, but that was among the first things I tried before posting. I did look the board over as well.
Sorry, just a thought as this was the cause of the problems I had. Have you tried locking the port at half-duplex?

Why does the unit default to 169.254.x.x with no cable? (well the wpnq does anyway, but its the same as when it gets no assignment on eth)
I beleive this is the default IP if it can't find the DHCP server.

Why does the unit default to 169.254.x.x with no cable?
(well the wpnq does anyway, but its the same as when
it gets no assignment on eth)

It's part of the uPNP standard. Have you tried giving up on DHCP and just adding 169.254.0.1/255.255.0.0 to your network card on your Windows PC ?

Well I got it working at home. Used the clue about the "timing"
to read up on how the switch did things. Seems cisco has a
timing value for port forwarding. If you set this to off (even as a
micro speed) it works properly. However I've yet to solve it
on cabletron. no "port fast" setting I can find. I suspect the
Receiver just plain does not wait that extra 'millisecond' long enough to get the DHCP replies.

This does work on my EMPEGs with either setting.

Also the log file does NOT list when it detects a new receiver
that it cannot connect to (ie: saw the odd class c and couldn't
route there). Adding this might be usefull.

Thanks to all, even for the sarcasm.

Ed

P.S. On second thought, nah, keep your sarcasm!
heh

After some careful looking into, I perceive a pair of faults on the
software and hardware:

The unit sends a DHCP too fast for 8 of 9 managed hubs and
switches I tested this morning. Without a second try for
a DHCP the unit always defaults the IP and then once the
server is contacted is useless. Fix would be a slight delay
on the initial packet send or a repeat of the DHCP after a
timeout, before the SSDP attempt.

This is based on "default" prom loads on these products.
I was able to get the receiver working on 5 of them but
haven't got the other 4 figured out yet. Its not a question of
the timing "to 10mbs" as someone suggested, but just plain
in the forwarding timing of the ports themselves. Some
devices can attempt to make this "near instant" or "fast
forwarding".

Second, the log is not near elaborate enough about what the
server is actually doing. Perhaps this is by design and it
has various levels of timing and verbosity? If not, more
info on detecting and contacting units should be added.
It was a bit frustrating to always see it pop up on the server list
but never in the logs.

Once working its a nifty product, save for the tiny tiny
text.

Hopefully someone can condense this and add an FAQ entry
on managed switches/hubs to help out others in the future.

Ed

The unit sends a DHCP too fast for 8 of 9 managed hubs

To clarify: Do you mean that it sends the DHCPREQUEST too soon after link is brought up -- and thus the hub drops it? Or do you mean it times out too quickly for these hubs?

You seem to be saying the first of these, but I want to be clear.

Also, which hubs/switches had difficulty? It'll help us in testing stuff in future.

And, as for the log file, it's probably a difference between the debug and release builds. ISTR that the Rio Receiver Manager software isn't particularly loquacious in a release build, when compared to emplode (for the car player), for example.

Hmm, strange. I'm sure it sends at least 3 DHCP requests, with at least 5 seconds between them.

There are no other prom loads apart from the default - there's no facility for upgrading the actual firmware.

Hugo

Yes the former, not the latter. Not as far as my snoops have
shown, anyway.

The defaults are: Cabletron (3 different models), Cisco(2 models), AT&T, and SMC.

Cisco is fixed with "port fast" on. This skips a port forwarding
delay. Cabletron has a similar feature but I forget the name
off the top of my head. Haven't figured out the AT&T and the
SMC, but the net guys here at the Supercomputer center
tell me they too have similar settings. (oh, and stop hacking
the switches, LOL!)

If the unit sends out multiple dhcprequests, it should work properly, but thats not what my data here shows.

Now if only I owned a real stereo... HEH!

Ed