or Connect
AVS › AVS Forum › Gaming & Content Streaming › ReplayTV & Showstopper PVRs › Wireless 802.11g Streaming for Cheap!
New Posts  All Forums:Forum Nav:

Wireless 802.11g Streaming for Cheap! - Page 24  

post #691 of 703
Wanting to convert my Linksys system over to Buffalo. Anyone clarify which to buy? There are 3 versions out I believe.

WBR-G54
WBR2-G54
WBR2-G54S

and even the:

WHR3-G54

Which to buy and why?

I have 2 5504 replays. Does that mean I should buy 2 routers and bridge them together right?

THanks for any info.
post #692 of 703
I haev been using old 802.11b for three years now.

I just got two WBR2-G54 units for $20 apiece with the rebates, and one PCMCIA 802.11g Buffalo card for my PowerBook.

My ReplayTV and PCs will be wired into the WBR2-G54 units, which will bridge and one of which will serve 802.11G wireless as well.

I believe that the WBR2-G54S units are 108Mb/s. And I would guess that like 802.11G throttles back to 802.11B levels when a standard "b" device connects, the 108Mb units would just throttle back to G or B levels when a G of B device connects. SOmeone feel free to correct me if I am high.
post #693 of 703
Since this one is back on the front page, figured I'd put this here rather than start a new thread..

I have a 'remote' 5040 off a WBR2-G54 bridge, and another 5040 and a DVArchive box hard wired to the 'core' WBR2-G54.

For the most part, streaming across the WDS is fine, and upon the remote 5040 bootup, both DVA and the hard wired Replay can see it and access the guide data fine.

But after a few minutes, DVA starts spitting out error messages stating it's unable to grab the remote 5040's guide.

Some quick troubleshooting confirmed what I initially suspected to be the problem: Both the WBR2 and ReplayTV use the default httpd port of 80, and, as far as I can tell, there is no way to get either device to listen on an alternate port.

So basically, DVArchive winds up hitting the Buffalo's httpd, thinking it is actually the Replay, and of course complains when the Buffalo can't provide any guide information.

It seems as though unplugging and reseating the wired connection between the remote 5040 and the Buffalo causes remote http connections to be forwarded to the Replay (temporarily.) But after a minute or two, the Buffalo's httpd starts responding to the requests again.

At first I suspected this had something to do with the Buffalo's UPnP support (enabled by default), but disabling UPnP on the remote Buffalo did not seem to have any effect.

Considering many of you are likely to have a comparable hardware configuration, I'm wondering why I've seen no other mention of this issue? Am I missing an option on either the Buffalo or Replay to bind the HTTPD to an alternate port? (You can specify the WAN configuration port on the Buffalo, but it doesn't look like you can change the LAN config port?) Or is the 'expected' behavior of the Buffalo to forward on the HTTP request to the WDS client device rather than respond to it itself - and I just got a flaky unit?
post #694 of 703
Quote:
Originally posted by delusion602
Some quick troubleshooting confirmed what I initially suspected to be the problem: Both the WBR2 and ReplayTV use the default httpd port of 80, and, as far as I can tell, there is no way to get either device to listen on an alternate port.
Why is this relevant? Your Buffalo and Replay have different IP addresses
so they can be individually contacted. The SSDP broadcasts from Replay
tell DVA to contact the Replay IP address, not the Buffalo IP address.
post #695 of 703
Um, for WDS the Replay and the Buffalo use the same IP address. That's what makes it a "bridged" connection.. no IP routing is going on between the Buffalo and the Replay.

Anyone else?

Edit: The misinterpretation of this issue does bring to mind something else possibly relevant though... In the interest of simplicity I have disabled all routing functions including DHCP on the remote Buffalo unit, set it up as a dedicated 'dumb' WDS bridge, and statically addressed both the Replay and Buffalo.

Now I'm thinking a plausible workaround would be to leave routing functions enabled on the remote Buffalo unit, and use it as a 'border router' instead of a dedicated bridge. In this instance, the Replay and Buffalo would in fact utilize seperate IP addresses, and the trouble would be alleviated.

It should work fine in theory (and may be what I end up doing), but I was trying to keep things as simple as possible on the initial setup.
post #696 of 703
Quote:
Originally posted by delusion602
Um, for WDS the Replay and the Buffalo use the same IP address. That's what makes it a "bridged" connection.. no IP routing is going on between the Buffalo and the Replay.
That is correct, no IP routing is going on between Buffalo and Replay,
but that is still not relevant.

The Buffalo responds to its own IP address in WDS bridge mode. This IP
address is different from the Replay IP address.

It's a "bridge" not because every unit is using the same IP address. It
is a bridge because different medium are being treated as one logical
network.

The only reason Buffalo and Replay might share the same IP is if you
are contacting them through the WAN port. However, if this is what
you are doing, you have misconfigured your network as all the streaming
should be taking place over the LAN side.

A quick rule of thumb which may help in your debugging... If nobody
complains about a problem that would seemingly affect everyone, the
problem is likely particular to your own configuration or setup.

All I can say so far is that your theory as to why DVA can't contact your
replay doesn't make any sense.
post #697 of 703
Now you're really not making any sense.

You're telling me I can bind an address (let's say, 10.0.0.1 for example's sake) to the Buffalo in dedicated WDS mode, and then bind another arbitrary IP address to the ReplayTV which is hardwired to it (say, 10.0.0.2), and the Buffalo - in DEDICATED WDS MODE - will magically know what to do with that traffic?

I guess I'm not making myself clear, because surely that's not what you're trying to say (because it's very much incorrect.)
post #698 of 703
Quote:
Originally posted by delusion602
You're telling me I can bind an address (let's say, 10.0.0.1 for example's sake) to the Buffalo in dedicated WDS mode, and then bind another arbitrary IP address to the ReplayTV which is hardwired to it (say, 10.0.0.2), and the Buffalo - in DEDICATED WDS MODE - will magically know what to do with that traffic?

I guess I'm not making myself clear, because surely that's not what you're trying to say (because it's very much incorrect.)
That is exactly what I'm saying. I've been doing that for over 7 months,
as have many folks in this forum.

There's nothing magical about Buffalo knowing what to do with the
traffic. It is all done by standard ARP. In WDS bridging, you have
one logical network. There is no routing or directing of traffic going
on. The ARPs are broadcast across the entire logical network. Just
like there is no routing being performed for a LAN, there is no routing
(in the tcp/ip sense) being performed for a LAN which has a WDS bridge
segment.

The only time potentially traffic would need to be directed is if you
had a loop in your WDS bridge configuration, but since the Buffalo's
don't support Spanning Tree Protocol, they can't handle the loop,
so you'll just need to resolve the loops by hand.

For all intents and purposes, the Buffalo in WDS bridge mode acts just
like you had a switch which is hardwired to the other side to another
switch (except the Buffalo is an added device which is attached to the
bridge, has its own IP, and is individually addressable) The WDS bridge
is just replacing the need to run CAT5 between the 2 switches.
post #699 of 703
My media room WBR-G54 has an IP of 192.168.11.54 and the Replay attached to its LAN port has an IP of 192.168.11.101. My bedroom bridge has an IP of 192.168.11.55, the Replay attached to it 192.168.11.102. Both of those are in dedicated WDS mode. You cannot assign two devices the same IP number, or you will get problems...kinda like you're having now, probably.

I'd bet that's your problem.
post #700 of 703
Quote:
Originally posted by delusion602
Edit: The misinterpretation of this issue does bring to mind something else possibly relevant though... In the interest of simplicity I have disabled all routing functions including DHCP on the remote Buffalo unit, set it up as a dedicated 'dumb' WDS bridge, and statically addressed both the Replay and Buffalo.

Now I'm thinking a plausible workaround would be to leave routing functions enabled on the remote Buffalo unit, and use it as a 'border router' instead of a dedicated bridge. In this instance, the Replay and Buffalo would in fact utilize seperate IP addresses, and the trouble would be alleviated.

It should work fine in theory (and may be what I end up doing), but I was trying to keep things as simple as possible on the initial setup.
The first configuration described above (assuming your buffalo and replay
have the same IP like you describe) is broken. I do not understand why
you would insist on statically assigning both the buffalo and the replay
to the same IP address over some imaginary theoretical image of what
you feel a bridge should look like. Just assign a different LAN IP for the
buffalo and Replay and watch everything start working.

The second configuration is what the majority (if not all of us) are using.

I don't understand your distinction between the first configuration (dumb
dedicated WDS bridge) and the second configuration (border router), other
than the 1st might have the LAN IP of the buffalo misconfigured to be the
same as Replay.

The only other explanation for how we can be totally at odds in this
discussion is that your WBR2-G54 has some new mode of operation
not available in the WBR-G54 firmware most of us are using.
post #701 of 703
MaxH:

When you traceroute to 192.168.11.102 from a PC on your LAN, what does the traceroute look like? That is, do you see it's uplink Buffalo at 192.168.11.55 as an intermediary hop? Or does the traceroute go directly to .102, with the Buffalo transparent at the IP layer?

sfhub:

So we have a Buffalo unit at IP address "A", taking packets from a downlinked ReplayTV at IP address "B", and passing them along to uplink router at IP "C".

Do you still maintain that the Buffalo is acting as a dedicated bridge, and is not doing any IP layer routing? If so, you may want to refrain from taking the CCIE exam just yet.
post #702 of 703
Quote:
Originally posted by delusion602
sfhub:

So we have a Buffalo unit at IP address "A", taking packets from a downlinked ReplayTV at IP address "B", and passing them along to uplink router at IP "C".

Do you still maintain that the Buffalo is acting as a dedicated bridge, and is not doing any IP layer routing? If so, you may want to refrain from taking the CCIE exam just yet.
You have a condescending attitude which is somewhat problematic but
they do not test for that in exams.

To prove to yourself that there is *no* IP layer3 routing in the configuration
I described (and which most of us are using) there is a simple test you can
do (everything is connected to the LAN ports of the Buffalo, WAN ports are
unused)

Laptop1
10.0.0.1
255.0.0.0
|
wired ethernet
|
Buffalo1
192.168.1.1
255.255.255.0
|
WDS
|
Buffalo2
192.168.1.2
255.255.255.0
|
wired ethernet
|
Laptop2
10.0.0.2
255.0.0.0

traceroute from Laptop1 to Laptop2. There will only be *1* line in the
traceroute. There can be *no* IP layer3 routing because Buffalo1 and
Buffalo2 have no clue how to get to 10.0.0.0/8 network. Further if there
was routing, there would be more than 1 line in the traceroute.

Just because Buffalo1 and Buffalo2 have IP addresses does not mean
they process the packets at IP layer3. Visually you just have the wrong
picture of how things are architected.

You should view the Buffalos as separate components internally connected
rather than one monolithic device.

So from a *logical* rather than physical perspective the Buffalo is actually:

4-port switch with WDS wireless uplink
|
wired ethernet (internal to device)
|
Buffalo router device

The Buffalo is essentially just another device hanging off the switch and
when you create a WDS wireless uplink, the Buffalo router device sub
module is not involved with the WDS uplink.

The device as a whole (in particular the switch and WDS uplink sub
modules) however is involved at layer2 with the MAC address tables
just like any switch would be. All direction of traffic across the WDS
wireless link are done using MAC address only.

There is a 4-tuple of MAC addresses in the wireless frame header
1) initial source
2) final destination
3) intermediate sender
4) intermediate receiver

WDS is a layer2 bridging technology and all the directing of packets is
based on MAC addresses described above. This is regardless of what
IP address you have the Buffalo LAN configured to.
post #703 of 703
Quote:
Originally posted by delusion602
MaxH:

When you traceroute to 192.168.11.102 from a PC on your LAN, what does the traceroute look like? That is, do you see it's uplink Buffalo at 192.168.11.55 as an intermediary hop? Or does the traceroute go directly to .102, with the Buffalo transparent at the IP layer?
It has a one line entry containing only 192.168.11.102.

There is no 192.168.11.55 in the traceroute and this is as expected.

How do you think we are bridging multiple devices behind a Buffalo
WDS bridge if they all share the same IP address?
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: ReplayTV & Showstopper PVRs
This thread is locked  
AVS › AVS Forum › Gaming & Content Streaming › ReplayTV & Showstopper PVRs › Wireless 802.11g Streaming for Cheap!