Network connection problem - 5040

[dainbramage]

Hi all.

Just got a refurb 5040 from Digital Networks. Trying to get it connected. I have a Buffalo WBR2-G54 router as my gateway. It connects on the WAN side to a DSL bridge (I have 5 static IPs, so I don't use DHCP).

When I connect the RTV to the DSL bridge, it connects fine and downloads all its needed info. However, when I connect it to the G54, it can't verify the network.

I'm trying to give it the following static data:

IP - 192.168.81.4
Mask - 255.255.255.0
GW - 192.168.81.1 (the G54 LAN address)
DNS1 - 151.164.1.8
DNS2 - 151.164.11.201

When configured to my DSL bridge, I use the following successfully:

IP - 66.136.30.187
Mask - 255.255.255.254
GW - 66.136.30.190
DNS1 - 151.164.1.8
DNS2 - 151.164.11.201

Note that my Windows boxen can connect to the internet find using the G54 as their gateway.

I don't know why this is so hard. Any clues?

Thanks for helping a newbie...

PS. I've searched here, at archive2, at planetreplay and on Google. I've used 64.124.73.106 as my primary DNS and I've used 12.127.16.67 (17.72) as DNS entries with no luck.

I went through the G54 configuration and didn't see anything that looked like it might be blocking anything. I'm using version 2.21 of the firmware.

[Creech]

Can you ping ReplayTV from your Windows box?
If not, is the activity light on on the Replay's nic? On the router?
Can your computer connect from the same ethernet run as the ReplayTV?
Are you connecting hard wired or wireless? If you are trying to connect wirelessly, have you tried hard wiring?

[dainbramage]

> Can you ping ReplayTV from your Windows box?

Can ping when connected to DSL bridge.
Can not ping when connected to G54 (with 192 address). It tries to verify the network, fails. At that poing I can not ping it.


> If not, is the activity light on on the Replay's nic? On the router?

Activity lights are on.

> Can your computer connect from the same ethernet run as the ReplayTV?

Not sure what you mean by "same ethernet run." I use the same cable to connect to the DSL bridge. That works.

>Are you connecting hard wired or wireless? If you are trying to connect wirelessly, have you tried hard wiring?


I'm connecting hard wired. Will try wireless when I can verify this works.

Thanks for the quick reply.

I had tried letting the Buffalo serve DHCP addresses. From its web config page I can verify that the RTV gets an address. The lease is really short, though.

This tells me the RTV and Buffalo are communicating.

[dainbramage]

For completeness sake:

When the RTV grabs the DHCP address, it still can not verify the network. That's when I connected it to the DSL bridge, gave it the 66 address. After that worked and it downloaded all of the guide data, I tried manually configuring it to use the 192 address. (And I did move the connection. :) )

[bkushner]

I thought the buffalos used a 192.168.11.1 address?

[dainbramage]

The LAN configuration page let's me change it. And all my other boxes can access the Buffalo using the 81.1 address.

However, I'll try anything at this point. When I get time (hopefully tonight) I'll try using the 11.1 address.

Any other suggestions, anyone? Thanks for your help, BTW.

[dainbramage]

bump....

Still having difficulty. Any more suggestions?

I understand that the WBR2-G54 is commonly used by folks in this forum as their router. Anyone willing to share their config (minus security, of course)?

Thanks.

[dainbramage]

Trying something new.

I have a Belkin wireless 54g router. Swapped it in place of the Buffalo. Same result.

The RTV 5040 returns the following Details screen:

Your ReplayTV could not contact your router (sometimes this message is: Your ReplayTV received an invalid response from your name server).

IP 192.168.81.4
Mask 255.255.255.0
GW 192.168.81.2 (the Belkin) not reachable
DNS 151.164.1.8 not reachable
DNS 151.164.11.201 not reachable

I can't understand why the GW would be unreachable. I have the cable connected directly from the Replay to the Belkin (or Buffalo). I even disconnected the cable from the Replay and plugged it into my Windows box. The Windows box still communicates with the outside world.

Any other thoughts/suggestions?

I don't really want to send this back, but I'll have to if I can't get it to work behind my router.

Thanks for any help.

[rm -rf *.*]

Reboot your ReplayTV.

[dainbramage]

I've rebooted several times, but I will do so once again when I get home from work. Here's what's happened in the past:

Because it was able to connect when using the 66. address, those settings are still in the system. The settings are:

IP 66.136.30.187
Mask 255.255.255.248
GW 66.136.30.190
DNS 151.164.1.8
DNS 151.164.11.201

When it boots up, it comes up and works fine. However, I want to change the Network Settings so that it is behind the my Buffalo router.

So, I make sure the cable is plugged into the router. Then I go to change the Network Settings. I enter :

IP 192.168.81.4
Mask 255.255.255.0
GW 192.168.81.1

and I've tried the following combinations for DNS:

--------------------
192.168.81.1
Empty
--------------------

--------------------
192.168.81.1
192.168.81.1
--------------------

--------------------
151.164.1.8
151.164.11.201
--------------------

Thanks for your help.

BTW, I've even tried doing a factory reset. I haven't tried connected via modem then switching back to network. Think that might jog it out of this funky state?

[rm -rf *.*]

dainbramage-

Don't sweat it. I was actually in the middle of reading this thread at the exact moment when your post (http://www.avsforum.com/avs-vb/showthread.php?postid=4383894#post4383894) popped up on the screen and since I wasn't sure if you had been rebooting after making the IP changes or not, the rapid-fire resposne was sent in the hopes of catching you at the keyboard before you went back to the replaytv (or whatever). Immediatey after hitting submit, I backgrouned that window just like any other time and went over any one of the other dozen or so I had open - judging by the time stamps, I'd say something hung up in the browser and I never noticed it.

[dainbramage]

No problem, rm.

I'm not sure what you mean by "if you had been rebooting after making the IP changes."

As soon as I make the IP changes, it wants to try to "verify the network." It then fails. If I reboot, I get the 66.136.30.187 settings again.

I should be in front of the unit again tonight (6pm CST or so) if you have any words of wisdom to offer.

Thanks.

[rm -rf *.*]

Part of that is how I read/interpert your post...

The other part of that is, as you are now rapidly discovering, that ReplayTV's tend to have personalities when it comes to their networking...

[dainbramage]

"Personalities." That'd be funny if it was someone else struggling with it. :)

I've been a programmer for a long time and I like my software to have character, but not personality.

So, any suggestions on how to get this thing to act right from behind a router?

[ClearToLand]

Originally posted by dainbramage: ...So, any suggestions on how to get this thing to act right from behind a router?


Remove the Buffalo Router (to leave your settings as they are)
Install the Belkin Router[list=1] WAN IP should be 66.136.30.187
LAN IP should be 192.168.81.254
DNS1 should be 151.164.1.8
DNS2 should be 151.164.11.201[/list=1]
Enable the DHCP Server[list=1] Allow the Server to give out *ONLY* 1 IP - 192.168.81.1
Connect your PC to the Belkin via a wired connection
From a DOS/Command Prompt run IPCONFIG /ALL
Verify that all the settings took and that you can access the Internet
Replace the PC with the ReplayTV on Automatic via a wired connection
What happened? [Try both rebooting via the "Power" Button *AND* unplugging/disconnecting all wires yada, yada, yada per JeffD][/list=1]

[dainbramage]

Thanks Tinkerer.

Here's the tale:

Disconnected and powered down the Buffalo WBR2-G54.
Brought up the Belkin F5D7230-4.

Cabled an empty port on my DSL router (which is in Bridge mode - see above) to the WAN port on the Belkin.

Cabled my Win2000 box to the first slot on the Belkin's LAN ports.

Brought up Firefox and configured the Belkin just as you suggested.

Configured the Win2000 box to use DHCP. Ran ipconfig /renew. Ran ping www.yahoo.com - success! Ran ipconfig /all to verify settings. They look correct.

I then checked the DHCP leases on the Belkin and it showed the Win box using 192.168.81.1. Great!

The Replay had been unplugged all night, so I plugged it in. While it was coming up (with nothing in the ethernet port), I rebooted the Belkin for good measure.

After the replay booted, I disconnected the cat 5 cable from the Windows box and connected it to the Replay's ethernet jack.

Went to Menu->....->Change from Manual to Automatic.

It came back pretty quickly saying it couldn't find the network information and wanted me to type in the stuff manually.

At this point, I tried using manual settings as in the first post above except the GW was .254. No luck. Can't contact router.

I then rebooted the Replay using the power button on the front. While it was booting up, I reconfigured my Windows box to use manual settings and connected it to the Belkin so I could watch the DHCP leases.

While the Replay is booting up, I see address 192.168.81.1 assigned to hostname (null) and MAC address 00:0a:97:02:65:88 (the Replay).

At some point during the Replay boot process, the lease goes away. The Belkin now shows "No leases."

Went through the whole Manual to Automatic setup again. This time it tried for 2 minutes to get network information. Went back and monitored the DHCP lease info on the Belkin. Hey, it's there! 192.168.81.1 is assigned to the Replay's MAC address.

Unforuntately, the Replay says it can't contact the router. The Belkin's DHCP list again shows "No leases." Bummer!

So, that's where I'm at. Any other suggestions?

[rm -rf *.*]

Good morning drainbrammage-

Trust us on this - do you're self a favor now and just forget about DHCP entirely. Take a look:

http://www.avsforum.com/avs-vb/showthread.php?postid=3614577#post3614577

Now you ought to REALLY get the "personalities" joke.... ;)

[sfhub]

Originally posted by dainbramage
While the Replay is booting up, I see address 192.168.81.1 assigned to hostname (null) and MAC address 00:0a:97:02:65:88 (the Replay).

At some point during the Replay boot process, the lease goes away. The Belkin now shows "No leases."

Went through the whole Manual to Automatic setup again. This time it tried for 2 minutes to get network information. Went back and monitored the DHCP lease info on the Belkin. Hey, it's there! 192.168.81.1 is assigned to the Replay's MAC address.

Unforuntately, the Replay says it can't contact the router. The Belkin's DHCP list again shows "No leases." Bummer!

So, that's where I'm at. Any other suggestions?
I'm not sure why it is being suggested to put 192.168.81.1 in the DHCP
range. That is somewhat dangerous because it is easy to forget your
are doing this test and it happens to be the address of your G54 router
and is the default gateway address in many setups.

If you happen to assign replay 192.168.81.1 and also have the G54
connected you will have troubles.

[dainbramage]

Good morning rm.

I agree. Forget about DHCP.

I've tried going all static. In fact, all of my boxen use static IPs. I only introduced the DHCP server to accomodate my work laptop's wireless NIC. This was before getting the RTV.

I've made sure no DHCP server was running and tried to connect using the settings in my first post above. With no luck. That's why I tried to connect using one of my public static IPs - simply to verify that it _could_ connect. It did. But it won't when I put it behind my firewall.

So where do I go from here?

BTW - right you are on the personalities dig!

[sfhub]

When you assign a static IP address in Replay it needs to do 2 things
1) contact DNS server to resolve production.replaytv.net
2) contact production.replaytv.net at port 80 to make sure you can
contact the mothership

One of those two is failing.

You should start at step 1 with a very simple setup and work up from there.
It is possible there is some strange config you entered but have since
forgotten about in the router (MAC filtering, conflicting DHCP range, etc.)
To eliminate any router problems as the culprit, I suggest you just to
a factory reset, then configure just the WAN info and LAN info.

I remember in WBR-G54 there was a bug where you needed to reboot the
router for IP info changes to take or the router would be in a weird state
where it couldn't be contacted. I don't know if they fixed that in your
firmware, but with Buffalo, whenever you make changes I suggest after
saving the settings, pull the power plug to reboot the router.

Now we know the NIC in the replay is working because of your test
when connected directly to the DSL bridge. However somehow replay
is not able to contact your GW (and thus can't contact the DNS servers
either)

If you have a hub lying around, capture the packets during the IP address
assignment in Replay and we can figure out exactly what is failing. If you
can't do the capture, then you'll just need to resort to trial and error to
isolate everything that can go wrong. Only make one change at a time
so it won't get confusing which change had what effect.

[dainbramage]

Thanks, sfhub.

I do have a hub. In fact, here's a "schematic" of my network.

SWBellDSL->66.136.30.190->[DSL Bridge] (4 ports)

1)->66.136.30.186->[Linux box]->192.168.81.3 -> [Hub]
2)->66.136.30.187->[Belkin]->192.168.81.1-> [Hub]
3)->not used
4)->not used

[Hub] (4 ports)
1)->192.168.81.3 (the linux box)
2)->192.168.81.1 (the Belkin)
3)->192.168.81.12 (my Win2K box)
4)->192.168.81.13 (wife's Win XP box)

I'm connecting the RTV directly to the LAN ports on the Belkin and using its routing capability.

I will see if I can get a packet sniffer running on either the Linux box or my Win 2K box and report back what I find. That'll probably be tonight.

Thanks again.

[sfhub]

Originally posted by dainbramage
I will see if I can get a packet sniffer running on either the Linux box or my Win 2K box and report back what I find. That'll probably be tonight.

Please just keep it simple and use www.ethereal.com which is what
many of us use. Also post the entire capture file rather than just
cut/paste what is on the screen. You seem to be aware already,
but in case you are not, hub and switches work differently in that
hubs will broadcast packets to all ports and are critical for packet
sniffing applications which would not work with switches.

[dainbramage]

Downloaded ethereal. Reconfigured my network so that the Belkin is 66.136.30.187 on the WAN and 192.168.81.1 on the LAN. DHCP is off.

3 things connected to the hub
1) - the LAN side of the Belkin
2) - my Win 2K box running ethereal
3) - the Replay TV.

I set the Replay TV up to use:

IP 192.168.81.4
Mask 255.255.255.0
GW 192.168.81.1
DNS 151.164.1.8
DNS 151.164.11.201

Attached is the packet file. I hope this gives some clues...

[dainbramage]

This time, I set the Replay up like this:

IP 192.168.81.4
Mask 255.255.255.0
GW 192.168.81.1
DNS 192.168.81.1
DNS empty

Interesting to note that 81.1 replies with the IP for production.replaytv.net, but the replay unit continues to issue the DNS request. It eventually requests for production.replaytv.net.replaytv.net. Weird!

[dainbramage]

bump...

[ClearToLand]

Originally posted by rm -rf *.*: ...do you're self a favor now and just forget about DHCP entirely. Take a look:

http://www.avsforum.com/avs-vb/showthread.php?postid=3614577#post3614577

Since his RTV was able to successfully get an IP address (and all the rest of the info) by connecting to the SWBell DHCP Server, I was curious why the same didn't happen via the Belkin (or Buffalo) DHCP Server.


Originally posted by sfhub: ...I'm not sure why it is being suggested to put 192.168.81.1 in the DHCP range...

I chose 81.1, with a limit of 1 available address, because of the known RTV / DHCP Server bug where it sometimes requests (and gets) 2 different IP addresses - 1 for the OS, and 1 for the RTV application. Limiting the DHCP Server to 1 available would possibly avert that happening (or generate an error). My next suggestion would have been to increase the availability to 2 available addresses and see what happens. Starting the numbering with 1 was just to make it easily visible / rememberable how many "served" IPs (or *which* "served" IP) was in use.

My "thought process" was: RTV was able to automatically get info from DSL DHCP Server
RTV was not able to use manually inputed info
*IF* RTV could be tricked into getting manually requested info automatically from Belkin DHCP Server, would it retain that info once switched back to manual (since it was retaining the automatically obtained info from the DSL DHCP Server).

Originally posted by sfhub: ...Please just keep it simple and use www.ethereal.com which is what many of us use. Also post the entire capture file rather than just cut/paste what is on the screen.

I'm looking forward to reading how to interpret the contents of the log files. Except for a group of non-ascii characters before the DATE: variable in each grouping, PACKETS.TXT is readable via Notepad. PACKETS3.TXT is not readable via Notepad or Wordpad.


Originally posted by dainbramage: ...I do have a hub. In fact, here's a "schematic" of my network.

SWBellDSL->66.136.30.190->[DSL Bridge] (4 ports)

1)->66.136.30.186->[Linux box]->192.168.81.3 -> [Hub]
2)->66.136.30.187->[Belkin]->192.168.81.1-> [Hub]
3)->not used
4)->not used

[Hub] (4 ports)
1)->192.168.81.3 (the linux box)
2)->192.168.81.1 (the Belkin)
3)->192.168.81.12 (my Win2K box)
4)->192.168.81.13 (wife's Win XP box)

I'm connecting the RTV directly to the LAN ports on the Belkin and using its routing capability.

I don't understand Items #1 and #2 in the first group - Does the Linux box have 2 NIC cards? Why does it have 2 IP addresses?
Is the Belkin WAN or LAN port connected to the DSL Bridge?
Since the IP addresses of devices connected to the DSL Bridge are public (66.136.x.y) vs private (192.168.x.y), what functions does the DSL Bridge provide over hub/switch capability. Is there a firewall? (What is the make and model of the DSL Bridge so I can look it up via Google and understand the differences between it and a Router?)
What would happen if the Belkin was plugged directly into the DSL Modem and the DSL Bridge was completely removed from the network?

[sfhub]

Originally posted by dainbramage
Interesting to note that 81.1 replies with the IP for production.replaytv.net, but the replay unit continues to issue the DNS request. It eventually requests for production.replaytv.net.replaytv.net. Weird!
I looked over this packet dump. The way I would interpret this behavior
is the request is getting through to Belkin, thre response is being sent
by Belkin, but the response is not being received by replay. I have not
been able to come up with a reason why it is not being received by
Replay yet.

[sfhub]

Originally posted by dainbramage
3 things connected to the hub
1) - the LAN side of the Belkin
2) - my Win 2K box running ethereal
3) - the Replay TV.

I set the Replay TV up to use:

IP 192.168.81.4
Mask 255.255.255.0
GW 192.168.81.1
DNS 151.164.1.8
DNS 151.164.11.201

Attached is the packet file. I hope this gives some clues...
Are you sure about the net mask? Check the net mask in Replay as
well as the net mask configured into the DHCP server config on the Belkin.

You Replay should not be ARPing 151.164.1.8 since it is not on the same
subnet. Since that is your DNS server in this particular scenario, the ARP
will fall on deaf ears and it will be equivalent to the DNS server being
down.

This is very odd behavior and to me would indicate some type of network
config problem.

[dainbramage]

To ClearToLand:

The DSL Bridge _is_ the DSL Modem. I have DSL coming from the wall into the WAN port on the DSL Modem. However, the modem is configured in bridge mode. The 4 LAN ports will take public IP addresses.

The Linux box is configured with 2 NICs and serves routing/gateway functions.

The DSL bridge is a Cayman. Unfortunately, I can't tell you the model numbe at the moment. It's about 3-4 years old, though.

One other thing, when the Replay is connected to the DSL bridge, it does not do DHCP. Since I use static IPs, I have the turned off for the public IPs. I manually configured the Replay to the 66 address.

Sorry for the confusion. The Cayman is a DSL router configured in bridge mode. It doesn't do routing.

[dainbramage]

sfhub,

Thanks for looking at the packet dumps. I will redo the experiment tonight from scratch and double check everything.

Edited: 12:56 pm CST

The Belkin's DHCP had been turned off during the experiment as per your suggestion. Again, I'll double check everything tonight.

[sfhub]

Next, could you do the packet dump from a fresh reboot of replay all the
way through the manual IP configuration.

[sfhub]

When you connect replay to the DSL bridge and when you connect to
Belkin, are you using the same ethernet cable?

The only way I can explain the 2nd packet dump is some sort of cable
problem or bent pins in the ethernet jack. The response packets are
obviously being sent and appear on the hub (thus appear on every
port) but the replay is acting as if it has never received the response
packets.

The only software problem I could think of that could explain this specific
scenario is if multiple devices were configured for the same IP.

You'll see that the Belkin needed to ARP the replay unit 6 times over 5.5
seconds before the Replay unit replied. Normally it should just take one
or 2 ARPs.

This leads me to believe the return packets are getting through but some
cable or hardware issue is causing the return packets to be received very
unreliably.

I don't think the replay ethernet port is broken because it works fine when
connected to your DSL bridge, so it has to be something else.

[dainbramage]

I apologize up front for any confusion.

My original config was to use the Buffalo. Somewhere along the line it was suggested I try the Belkin. The packet files I uploaded yesterday included the Belkin in the config. The file today includes the Buffalo, which is my desired configuration.

The cable I'm using has been used successfully in the following configurations:

1) ReplayTV to DSL Bridge (using static 66.136.30.187 address).
2) Win2K box to Buffalo LAN port.

I will change cables and post another packet file if unsuccessful. For now, here's the file from tonight's experiment. The procedure went like this:

1) Power down ReplayTV.
2) Disconnect everything from hub except ReplayTV, Buffalo LAN, Win2K box.
3) Turn DHCP off on Buffalo.
4) Reboot Buffalo.
5) Start Ethereal packet capture.
6) Connect Ethernet cable to ReplayTV and power up.
7) ReplayTV boots to screen prompting for Channel Guide, Replay Guide or Menu. It does not respond to remote buttons.
8) Stop packet capture and delete packet file.
9) Restart packet capture.
10) Reboot ReplayTV using front panel power button.
11) Boots as in (7) and does not respond to remote buttons.
12) Stop packet capture and delete file.
13) Unplug ethernet cable from ReplayTV ethernet jack.
14) Power down then up ReplayTV.
15) ReplayTV boots to same screen as (7) but responds to remote.
16) Plug ethernet cable back into ReplayTV.
17) Start packet capture.
18) Reboot ReplayTV using front panel power button.
19) ReplayTV boots and now it responds to remote buttons.
20) Change Network Config to:
IP 192.168.81.4
Mask 255.255.255.0
GW 192.168.81.1
DNS 151.164.1.8
DNS 151.164.11.201
21) Click [Continue]
22) After 1:30, Replay reports failure
23) Stop packet capture
24) Post this message with file upload.

I appreciate all of your help. This has been a real struggle.

- B

PS. Valid extensions for an upload are gif, jpg, png, txt, zip, bmp, pdf. I save the file as allpackets.bin change it to allpackets.txt and upload. I know it's not text, but the extension doesn't seem to matter much.

[dainbramage]

Here's the packet capture file using a different Cat5 cable from the Replay to the hub.

The procedure went like this:

1) Replace cable.
2) Start packet capture.
3) Reboot ReplayTV using front panel power button.
4) After boot up, change network config to:

IP 192.168.81.4
Mask 255.255.255.0
GW 192.168.81.1
DNS 151.164.1.8
DNS 151.164.11.201

5) Click [Continue]
6) Before the 1:30 had elapsed, I get a message saying that the ReplayTV received an invalid response from the name server.
7) Stop packet capture.
8) Upload allpackets2.txt.

- B

[dainbramage]

One more bit of info I promised earlier...

I'm using a Cayman 3220-H DSL Router.

- B

[sfhub]

A few things.

The reason the replay hangs on the swirl screen is because it is trying
to contact the RDDNS server and is unable to because of your network
troubles. If you disable IVS, it shouldn't hang anymore. Even if it does
hang waiting for network to timeout, it should clear up within 15 minutes
if you just let it sit.

The new packet dump is not much different than the old Belkin dump.
Your replay is still making a lot of ARP requests and seemingly ignoring
the replies.

--

If possible could you enable the DHCP server in buffalo
Range 192.168.81.100-192.168.81.110
Mask 255.255.255.0
DNS 192.168.81.1

create a MAC to IP address mapping to assign
192.168.81.100 to MAC 00:0A:97:02:65:88

save config and reboot buffalo

--

When you capture packets next time, could you apply following capture
filter to remove packets from your win2k box?
!(ether src 00:d0:09:61:28:fe or ether dst 00:d0:09:61:28:fe)

Start fresh packet capture using above filter.

Now could you perform factory reset on Replay
382-zones factory reset
and proceed through quick configure.

I'd like to see the packets throughout the whole procedure.

When going through quick config configure to use DHCP.

[ClearToLand]

Originally posted by sfhub: ...You Replay should not be ARPing 151.164.1.8 since it is not on the same subnet. Since that is your DNS server in this particular scenario, the ARP will fall on deaf ears and it will be equivalent to the DNS server being down.

This is very odd behavior and to me would indicate some type of network config problem.


Originally posted by sfhub: ...If possible could you enable the DHCP server in buffalo
Range 192.168.81.100-192.168.81.110
Mask 255.255.255.0
DNS 192.168.81.1


I do not understand your problem/concern with dainbramage's DNS entry. All of my PCs (automatic) and all of my RTVs (manual) successfully use the LAN IP of my Router as their Gateway, and the 2 ISP DNS addresses (supplied in the status screen of my SMC 7004BR Router and provided automatically to all my PCs requesting dynamic DHCP service) as their DNSs.

Would you please explain your logic for chosing 192.168.81.1 (the Gateway) over DNS1 - 151.164.1.8 & DNS2 - 151.164.11.201?


Also, does properly reading dainbramage's ethereal logs require the installation of ethereal?

[sfhub]

I could care less which DNS he ultimately uses. This is for debugging
purposes.

The problem is the reply packets are either not reaching, are not being
processed properly by Replay, or are experiencing heavy packet loss.

Using a DNS server in the same subnet (ie Buffalo proxying the DNS
requests) allows the network configuration to get further than using
the DNS from the ISP. Using the DNS from ISP the network config
process is blocked at trying to reach the DNS server and cannot
progress further. This is due to the network problem we are trying
to diagnose. I would rather get more data than less data to aid in
diagnosing the problem.

When you research the purpose of ARP you will understand the first
statement you quoted. ARP is a protocol to resolve MAC address given
an IP address. If that IP address is in a different subnet and packets
needs to pass through a gateway, it makes no sense to ARP the IP and
indicates some misconfiguration somewhere.

[ClearToLand]

Originally posted by sfhub: ...When you research the purpose of ARP you will understand the first statement you quoted. ARP is a protocol to resolve MAC address given an IP address. If that IP address is in a different subnet and packets needs to pass through a gateway, it makes no sense to ARP the IP and indicates some misconfiguration somewhere.

Please be patient with me, as I'm trying to learn this. Are you saying that a Gateway can resolve DNS addresses without being a PROXY Server? I'm confused because *ALL* of my Windows PCs using "automatic" DHCP get assigned the two DNS addresses that I find in my Router's Status Screen.

Previously (months ago), in an experiment, I stacked a (Wireless) Router/DHCP Server behind a (Wired) Router/DHCP Server, creating a secondary Private Subnet (192.168.1.xxx behind 192.168.0.xxx). While (IIRC) the PCs on 1.xxx could not access the PCs on 0.xxx, they *COULD* still access the internet (for sure!).

The only time that I assigned a local (192.168.x.y) address to a DNS entry was after I installed AnalogX's FastCache on that PC:AnalogX FastCache is a caching DNS server that runs on your local machine and handles any DNS request that your computer makes, from Internet Explorer to your favorite FTP client. Once a query is made, FastCache will override the normal timeout for the item with one that you specify, so instead of saving a query for a couple of seconds, it can save it for a couple of days. Now every time you ask for it again while it's in the cache, it gives it to you instantly.
Thus, regarding your interpretation of dainbramage's posted logs, I repeat my previous question:

Originally posted by ClearToLand: ...Also, does properly reading dainbramage's ethereal logs require the installation of ethereal?

I wish to understand where you saw: "...it makes no sense to ARP the IP and indicates some misconfiguration..."

[sfhub]

Many but not all routers will forward DNS requests they receive to the
DNS server configured in their WAN configuration side. They do this for
convenience of configuration. If the DNS servers change, none of the
units on your subnet need reconfiguration (not even DHCP renew)
because they are configured to use the router as DNS server. With the
Buffalo and Belkin routers being discussed here, with everything properly
configured both the router IP and the actual ISP DNS server IPs can be
used and the clients will be able to resolve IP addresses.

The packet dumps are in tcpdump/libpcap format. You need a utility which
can interpret that format. Ethereal is one such utility. I'm sure there are
others.

[dainbramage]

Originally posted by sfhub
If possible could you enable the DHCP server in buffalo
Range 192.168.81.100-192.168.81.110
Mask 255.255.255.0
DNS 192.168.81.1


Attached is a screen shot of the DHCP config screen on the Buffalo WBR2-G54. I don't see a place to specify Subnet Mask. Hmmm... Is it automagically determined?

- B

[dainbramage]

Originally posted by sfhub

When you capture packets next time, could you apply following capture
filter to remove packets from your win2k box?
!(ether src 00:d0:09:61:28:fe or ether dst 00:d0:09:61:28:fe)


The actual filter I had to use is:
!(eth.dst == 00:d0:09:61:28:fe or eth.src == 00:d0:09:61:28:fe)

Capture file is attached. The procedure:

1) Configured Buffalo as requested.
2) Configured hub to have only the 3 devices in play.
3) Started capture.
4) Performed 382-Zones (showed Demo Mode as Disabled)
5) Performed factory reset and restart.
6) Went through quick connect - Ethernet.
7) It counted down the 2 minutes.

While it was counting down the 2 minutes, I checked the packet log and noticed nothing showing up.

8) At the end of the 2 minute countdown, the RTV asked me to input parameters manually. I left it there.
9) I then noticed that packets 87 - 100 showed up in the log.
10) At this point, I did a reboot on the RTV using the front panel button.
11) Went through quick connect - Ethernet again.
12) Again, a 2:00 countdown.
13) Stopped packet capture

Any clues? Thanks.

- B

[sfhub]

Originally posted by dainbramage
The actual filter I had to use is:
!(eth.dst == 00:d0:09:61:28:fe or eth.src == 00:d0:09:61:28:fe)

I'm looking over the capture now. I don't think you remembered to
select the capture filter when starting the capture as the win2k packets
are still there. No biggie it's easy to manually filter on display.

Don't know why you had to use alternate filter format. The one I posted
is what I'm using.

EDIT: I think the filters accepted for "capture filters" is less restrictive than
the filters for "display filters"

[dainbramage]

Good morning sfhub.

I'm not very skilled with ethereal. I copied the string you posted into the filter box on the main form. It turned red indicating a "syntax" error.

I then clicked on the button to the left of the filter box and tried to construct a filter.

I eventually ended up with the filter I posted on the main form. When I ran the test, I thought it might be filtering on display, but I had to leave for work so I let it run. I was more interested in getting a capture posted than fiddling with ethereal.

I just need to play with it more - and I will. Maybe you and I are running different versions?

- B

[sfhub]

I keep thinking you have a network cable or port problem.

I've never seen packet #s 91-98 "Bogus IP header length" in a working
network setup.

Is this a store bought cable or one your crimped yourself?

Did you play around with the full/half duplex settings for the ports on the
buffalo?

[dainbramage]

Originally posted by sfhub
I keep thinking you have a network cable or port problem.

I've never seen packet #s 91-98 "Bogus IP header length" in a working
network setup.


Could very well be.


Is this a store bought cable or one your crimped yourself?


I think both cables I tried are hand made (as opposed to store bought). Weird, though, that things work when connected directly to the Cayman router.

I have some store bought cables I will try tonight. I just have to move some hardware around. Should be no big deal. Anything in particular you want to see?

I'm also going to a friend's house tomorrow and he has two 5040's. We're going to try to hook my 5040 up to his network and see what happens.


Did you play around with the full/half duplex settings for the ports on the
buffalo?

No. Not sure what that really is and where I would fiddle with it. Should be the default settings. What would you like to see?


- B

[sfhub]

Originally posted by dainbramage
I think both cables I tried are hand made (as opposed to store bought). Weird, though, that things work when connected directly to the Cayman router.

I have some store bought cables I will try tonight. I just have to move some hardware around. Should be no big deal. Anything in particular you want to see?

My guess would be the cables. It doesn't mean much that they work
connected to the Cayman because the Buffalo and Belkin use
auto-MDI/MDIX and auto full/half duplex detection. These mechanisms
can interact differently (and poorly) with cables that are not built correct.

Where with the Cayman you might just get slight packet loss and not
notice it because you are not watching out for packet loss, with the
Belkin and Buffalo you could have major packet loss.

If you crimp your own cables, you really want to get a cable tester. It
is really easy to mix up just one of the wires or have a not so clean
crimp on one of the pins. Also many people do not realize there are
solid core and stranded cable as well as crimps for each specific type.
The reason the crimps is the pins are designed different to create solid
connections with the wires depending on whether they are solid or
stranded.

[MaxH]

I have a strange but related question. I'm getting a lot of IP spoofing attacks that I believe my Buffalo is blocking. It's identifying them and logging them in Intrusion Detection. But all it tells me is that the packets are to 255.255.255.255, which wouldn't work anyway, and they appear to be coming from a certain IP address, which is fake because when I try to filter packets from that address the filter doesn't acknowledge them but the Intrusion Detection still catches them. (Yes, I set the Intrustion Detection to allow for filtering first.)

So, is there any way to "sniff" the packets coming into my router without redirecting them to my computer, which I'm not sure I could or should do anyway? I was hoping I could tell Ethereal to read traffic on another device over the LAN, but it seems to only choose a physical interface on the device on which it's running. So right now I have no way of knowing anything more about these packets than their intended destination and their (forged) source IP.

Any ideas would be greatly appreciated.

[sfhub]

Originally posted by MaxH
So, is there any way to "sniff" the packets coming into my router
Connect your router WAN port, cable/dsl modem ethernet port, and PC
NIC port to hub and run ethereal. It will capture the packets. Doesn't
matter what you set the IP address to. You can turn of name resolution
in ethereal config if you like so ethereal doesn't try to resolve the
addresses it captures.

[dainbramage]

Originally posted by sfhub

My guess would be the cables. It doesn't mean much that they work
connected to the Cayman because the Buffalo and Belkin use
auto-MDI/MDIX and auto full/half duplex detection. These mechanisms
can interact differently (and poorly) with cables that are not built correct.



Should be easy enough to test. I'll do it when I get home.

Thanks.

- B

[MaxH]

Originally posted by sfhub
Connect your router WAN port, cable/dsl modem ethernet port, and PC
NIC port to hub and run ethereal. It will capture the packets. Doesn't
matter what you set the IP address to. You can turn of name resolution
in ethereal config if you like so ethereal doesn't try to resolve the
addresses it captures.

Excellent, thanks. Now I just have to pick up a cheap hub, which shouldn't be any problem.

[j.m.]

Originally posted by sfhub
Connect your router WAN port, cable/dsl modem ethernet port, and PC
NIC port to hub and run ethereal. It will capture the packets. Doesn't
matter what you set the IP address to. You can turn of name resolution
in ethereal config if you like so ethereal doesn't try to resolve the
addresses it captures.

I think I mentioned this before, though I'm not sure. I recently discovered that you can sniff packets on a network without using a hub by using "ARP poisoning." There are a few programs out there that support this. Some are standalone apps that can be used in conjunction with Ethereal etc. I believe Ettercap is a packet sniffer with ARP poisoning built in, though it does not have a very nice GUI so I prefer to use a standalone ARP Poisoning program with Ethereal.

ARP Poisoning is somewhat shady and probably isn't something you would want to do on networks that you don't completely own/control, as it would be frowned upon by sys admins. It does work though.

[sfhub]

One configuration issue is some cable modem systems are tied to specific
MAC addresses so you may need to reconfigure so the MAC address the
cable modem sees is your monitoring/proxy unit (either by rebooting
the cable modem or appropriate MAC cloning)

Other than that it works most of the time unless you are dealing with
debugging problems with very short timing windows where introducing
an intermediary can affect the timing enough to bypass the problem.

[dainbramage]

DANG!

The cable must've been the problem! Switched cables to a store bought cable and it's working now.

Thank you, sfhub.

Now to get the wireless bridge going. :)

- B

[sfhub]

Ding, Ding, another satisfied customer. Thank you for shopping at avs.

[Scallica]

Hi all,

I am having a problem with my 5504. It's been working fine for a year. Today, for no good reason, I cleared the Channel Guide (using 243 zones). The system rebooted. When I tried to reconnect to download a new guide, the system could not connect. I released and renewed the IP address....it could not verify the network. I looked at the details and my router was reachable, but my ISPs DNS servers were unreachable. I have restarted my router and unplugged my RTV. I have also entered a manual IP address....same thing happens. I am not sure what to do at this point. Any suggestions?

Thanks,
Scallica

[l8er]

Originally posted by Scallica
I am having a problem with my 5504. ... When I tried to reconnect to download a new guide, the system could not connect. ... I'm not positive, but I think there may be a problem with the ReplayTV servers. I was making some configuration changes myself, including clearing the guide on one of mine, and I can't connect for guide data currently either.

[Scallica]

Originally posted by l8er
I'm not positive, but I think there may be a problem with the ReplayTV servers. I was making some configuration changes myself, including clearing the guide on one of mine, and I can't connect for guide data currently either.

Oh great! I spent the last hour troubleshooting this by resetting my cable modem, router, and RTV ten times.

Do you use DHCP or Static on your RTV? I was wondering if you were able to verify your network configuration.

If the RTV servers are down, any idea why it says my ISPs DNS servers are unreachable?

-Scallica-