Connecting to Win 2K... HELP!!!

I am having a really hard time with the Rio Sonic Blue MP3 Receiver. I have a Win2K box with plenty of speed,memory, etc. I am using a Linksys Router/Switch with wireless AP. I am also running Zone Alarm firewall. The Win2K PC is the only PC on my network.

I started the Receiver manager on my PC. I then plugged the reciever into an open port on the router. When I start the receiver it tries to connect and never does. When Zone Alarm is running, the receiver manager sees the receiver, but the receiver eventually timesout. The zone alarm logs show that it has blocked UDP access even if I add it to my trusted zone and set the security to Low. If I disable zone alarm the receiver manager does not even recognize the receiver. I have tried several different network settings with no luck. I unplug the receiver (power) after every change. The only thing that I have left to try is converting my FAT 32 file system to NTFS.

I know the receiver works because I tried it on a friends laptop where both the receiver and laptop were connected to a switch.

Any ideas? Any help will be greatly appreciated.

Thanks,
Drew

I started using a sniffer. It is able to get an IP from the router, but I get a "Destination unreacheable" IMCP error. It is when the receiver is trying to access UDP port 18678 on my PC. I ran netstat and that port is active for IP 0.0.0.0. Any ideas?

You sound like you probably know what you are doing, but do you think we could see the output from ipconfig /all just to make sure there is nothing screwy in your network card setup ?

Windows 2000 IP Configuration

Host Name . . . . . . . . . . . . : drewbitt
Primary DNS Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : Yes
WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : NETGEAR FA311/FA312 PCI Adapter
Physical Address. . . . . . . . . : 00-09-5B-05-86-06
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.1.100
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 151.197.0.38
151.197.0.39
Lease Obtained. . . . . . . . . . : Sunday, January 12, 2003 11:10:15 AM
Lease Expires . . . . . . . . . . : Monday, January 13, 2003 11:10:15 AM

Ok, well the first thing that it obvious is that your PC is getting it's IP addresses via DHCP.

Have you tried puttting the PC onto a fixed IP address, turning off the DHCP server (which is presumably on your router) and letting the Rio software act as the DHCP server for the Receiver. I'm not necessarily suggesting this as a long term fix, just as something to investigate if it makes any difference.

yep, tried that as well. I just continue to get a destination unreacheable ICMP error.

Very odd.

All I can suggest is you capture the whole thing from the Receiver power on using Ethereal http://www.ethereal.com/ and post the raw capture data here for people to pick over. At least then we compare it to a working setup and see where it is going wrong. If you do this then do it with the Receiver plugged straight into the router and turn Zone Alarm off.

Of course you probably want to make sure there is nothing private in the Ethereal trace...

The other thing is to go through the steps to make sure that the Receiver software is running properly that Roger listed here:

http://rioreceiver.comms.net/php/showflat.php?Cat=&Board=general&Number=2780&page=0&view=collapsed&sb=5&o=365&fpart=

Thought I'd better check back with the original question and make sure I asked you the right questions, it appears I didn't.

When I start the receiver it tries to connect and never does.

What does the Receiver display on it's screen in this case ?

If I disable zone alarm the receiver manager does not even recognize the receiver.

And what does it display in this case ?

I get a "Destination unreacheable" IMCP error. It is when the receiver is trying to access UDP port 18678 on my PC.

It isn't actually the Receiver trying to access the PC, it is the Audio Receiver Manager software on the PC trying to access the Receiver. It polls the Receiver on UDP port 18678 every few seconds to see what track it is playing.

You are probably seeing "Destination unreacheable" returned from the Receiver because the boot process has failed for whatever reason and it is therefore not running the player software which is what responds to the 18678 poll.

Either your intial DHCP transaction is failing to set the right data for the Receiver (so it can't find the PC) or something on your PC is stopping the Receiver from loading it's software over the network.

------------------------------
When I start the receiver it tries to connect and never does.

What does the Receiver display on it's screen in this case ?
------------------------------

It displays info on the receiver IP, the mask and the gateway

------------------------------
If I disable zone alarm the receiver manager does not even recognize the receiver.

And what does it display in this case ?
------------------------------

It displays the same as above, the IP info, etc

What IP does it show ? Does it show at 192.168.x.x one or a 169.254.x.x one ?

192.168.x.x

192.168.x.x

Well, at least it is finding a DHCP server then.

I know you said that you had tried turning the DHCP server on the router off...

...but I think the most likely cause of problems at this moment is that the Receiver is finding the router's DHCP server rather than the one in the ARM software. If the Receiver gets it's DHCP lease from the router it won't have the data it needs to then find the ARM software on the PC (the DHCP response that the ARM software sends tells it where to find it's firmware image to boot from).

When running Ethereal, I can see the receiver making a broadcast looking for my PC. The message says something like, "Who is <PC's IP>? Tell <Receiver's MAC>". Then I see the the PC sending a broadcast, "Who is <Recevier's IP>? Tell <Ethernet cards MAC>". The order may be reversed, but that does occur. Then I see UDP messages coming from my PC on port 18678 to the receiver's port 18678. Then I get the destination unreacheable (code 3 - invalid port) where the source is the receiver 18678 and the destination is the PC 18678.

When running Ethereal, I can see the receiver making a broadcast looking for my PC. The message says something like, "Who is <PC's IP>? Tell <Receiver's MAC>". Then I see the the PC sending a broadcast, "Who is <Recevier's IP>? Tell <Ethernet cards MAC>". The order may be reversed, but that does occur.

That does imply that the Receiver got the DHCP data from the PC, otherwise it wouldn't be doing an ARP request on the PC's IP address.

Then I see UDP messages coming from my PC on port 18678 to the receiver's port 18678. Then I get the destination unreacheable (code 3 - invalid port) where the source is the receiver 18678 and the destination is the PC 18678.

That is entirely expected. Until the Receiver has found it's firmware on the PC, downloaded it across the network and booted from it there is nothing listening on port 18678.

If you don't want to post your Ethereal trace here then send it to me at [email protected] and I'll see if I can spot what it happening.

the DHCP response that the ARM software sends tells it where to find it's firmware image to boot from

No it doesn't. The Receiver uses a second UDP broadcast to find its firmware image. It works fine with other DHCP servers, and was in fact designed to.

Fair enough. I was confused by the fact that the ARM DHCP server sends the details of where to find the kernel. I guess this data isn't actually used by the Receiver ?

I guess this data isn't actually used by the Receiver ?

No, it's not. It did this during development, when we were (IIRC) using DHCP/TFTP to boot the development boards.

I wish it was still using TFTP...

...I was going to use developing a complete replacement for ARM as a nice big .NET project to properly cut my .NET teeth. Everytime I look at it having to implement my own NFS server puts me off the idea.

You'd still need an NFS server to boot the player software. TFTP would only get you as far as the second kernel.

Besides, an NFS server is only (runs off to the source code) about 1000 lines of C/C++. It should be about half that with the .NET libraries.

Attached is the output from ethereal.

Thanks

Here is more info from the same ehtereal session

Hmmm

Well looking at the trace it is clear that the Receiver never attempts to contact the PC to download the second kernel (firmware).

Also, it looks to me as if the DHCP exchange isn't completing sucessfully. It definitely doesn't go through the same stages as on my network using the Rio DHCP server. Without digging out of the details of DHCP/BOOTP I can't be sure if it is failing DHCP, or just falling back to BOOTP.

Can we see a trace relying on the built in DHCP server in the Rio software, with the one on the router disabled ?

Also, if you post more traces can you save them in one of the formats that Ethereal can read them in again ? (that would make it easier to analyse them)

It isn't .net, but if you need an nfs server to boot your rio, take a look at RioBoot here http://groups.yahoo.com/group/jreceiver_user/files/.

I tried running that before. I get no response. The portmapper window displays nothing and the nfs server window displays "Starting NFS SERVER Starting MOUNT SERVER" and that is all.

It wasn't being suggested as a solution to your problems, the thread wandered a bit there. I wouldn't help you anyway, your Receiver isn't getting as far as making any port mapper or nfs requests.

Here are some sniffer outputs. One with the router's dhcp on and one with the router's dhcp off. 192.168.1.101 is the IP of the receiver. 192.168.1.100 is my PC's IP. The Receiver Manager software's dhcp was on for the 2nd test with a IP range of 192.1681.101 to 192.1681.116.

Thanks for your help

I guess I have to post this twice for the second file...

Router DHCP off attached...

I'm stumped. It is clear from those traces that the DHCP transaction is working fine. The Receiver gets it's correct IP address and netmask.

For some reason that I can't fathom the Receiver never does the UDP broadcast to find the server.

The only other thing I can suggest trying is to turn off both DHCP servers, add an extra IP address to the PC in the 169.254.x.x range and let the Receiver fallback to pnp to set it's IP address. I doubt this is likely tom make any difference though.

Hopefully Roger can suggest something more useful. It's hard to imagine how this could be a hardware problem given that the Receiver is clearly functioning and talking to the network.

The receiver worked fine on a friends PC so I don't think it's the receiver. I think I am going to re-install Win2K and see if that helps.

Thank you all for your help.

I wouldn't reinstall Win2k if I were you. It looks very unlikely that the problem could be caused by anything at the PC end.

I'd give Roger a chance to read the thread again before resorting to anything like that.

When you tested the Receiver with the friends machine was it on your network ?

No, we used a switch that was only connected to his PC and the receiver. At home, he has a very similar setup though. He has the same router (possibly different firmware). I did not try my receiver on his home network. I may buy a Ethernet cross-over cable to try a direct connect to my PC. Do you think that is worth it?

I think I'd wait and see what Roger has to say. Then again, a cross over cable always comes in handy anyway...

I'd give Roger a chance to read the thread again before resorting to anything like that.

I'm already reading the thread.

For some reason that I can't fathom the Receiver never does the UDP broadcast to find the server.

It's just that I've come to more or less the same conclusion as you. The only thing that I can think of is that the Receiver is sending the packet, but it's being dropped by the router. However, this makes very little sense, since Ethereal (presumably running on the host Win2k box) is seeing the DHCP packets.

Could we recap the OP's network topology? Maybe there's something important that I'm missing.

Then again, a cross over cable always comes in handy anyway

Well, a cross-over cable would come in handy, but I'm not sure if Win2k's automatic link detection will play nice with the Receiver.

It's worth a try -- we need to take the router completely out of the equation.

Configure the 2k box for static IP, and try it with a cross-over cable. Alternatively, get hold of a 10Mbps hub from somewhere, and try with that.

I don't know of anyone with a Linksys router, otherwise I'd investigate the DHCP server on that.

I'm already reading the thread.

I know, you just hadn't had chance to read and respond to the latest details. I didn't want the OP reinstalling Win2k til you had had time to read the latest posts.

The only thing that I can think of is that the Receiver is sending the packet, but it's being dropped by the router. However, this makes very little sense, since Ethereal (presumably running on the host Win2k box) is seeing the DHCP packets.

Could we recap the OP's network topology? Maybe there's something important that I'm missing.

As I understand it things are real simple:

-1 receiver
-1 Win2k PC (with Zone Alarm, but turned off in these tests)
-1 LinkSys WiFi switch/router (but in these tests the PC and Receiver are both just plugged into the switch)

Router is using 192.168.1.0
PC using 192.168.1.100
Receiver given 192.168.1.101

Netmask on PC and Receiver 255.255.255.0, don't know about the router but I assume that is also 255.255.255.0

Not a setup that should really be causing a problems.

since Ethereal (presumably running on the host Win2k box) is seeing the DHCP packets

A worry is that Zone Alarm might be hiding packets from Ethereal, even when it is turned off. I don't know which hooks into the network stack at the lowest level.

I don't know of anyone with a Linksys router, otherwise I'd investigate the DHCP server on that.

I can't be the DHCP on the LinkSys at fault. The Ethereal traces have been run both using DHCP on the router and using ARM's DHCP. The failure has been the same in both cases.

I uninstalled Zone Alarm about a week ago. The router is using 192.168.1.1. The router is using the same netmask (255.255.255.0).

It can't be the DHCP on the LinkSys at fault.

No. Fair point. What I meant to suggest is that possibly the router is dropping the packets on the floor. I don't know why it would, but until it's taken completely out ot the equation -- either by using a cross-over cable or a hub, it can't be discounted.

Actually, thinking about it, Hugo uses a Linksys router on his cable. His Receiver works. I'll ask him if his network topology is particularly different from this one.

Actually, thinking about it, Hugo uses a Linksys router on his cable. His Receiver works. I'll ask him if his network topology is particularly different from this one.

Don't forget however that the underlying hardware/firmware of LinkSys routers varies as they are not all designed by the same manufacturer. You would need to know that they were similar models of router to compare them sensibly.

It's a BEFSR41 with the latest firmware, if that helps...

Hugo

I am using a BEFW11S4 v.2 with the latest firmware

OK, I'm not following this thread closely but wanted to let you know that:

I've got several linksys switches with Receivers (five currently) connect with no problems. I've got a linksys 5port, 8port, 16 port and a linksys cable/dsl router with no problems at all.

I'm at work so I can't give any real details of the model numbers but can if needed.

Good luck.

Well, a friend gave me an old Win98 PC to mess around with and it worked. Not sure what is wrong with my Win2K box, but I think it needs to be cleaned up. Thanks for all of your help.

I reinstalled Win2K this weekend and now it works perfectly. Thanks for all of your help.