Re: Two Netgear WGT624 models will not communicate
- From: Jeff Liebermann <jeffl@xxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 20 Jul 2006 10:39:21 -0700
phil-news-nospam@xxxxxxxx hath wroth:
(continuing from where I left off...)
It looks like the WGPS606 might actually do this. It shows in one of
the diagrams as communicating with a WGR614 router.
http://netgear.com/pdf_docs/WGPS606_ds_r1_3.pdf
http://www.netgear.com/products/details/WGPS606.php
That's a print server. Under the plastic box is a wireless client and
either an LPR/LPD print server, or more commonly a NETBIOS based
Windoze printer. The print server connects via 802.11 to the wireless
access point. The catch is that the other box (i.e. WGR614) has to be
either an access point or wireless router running in infrastructure
mode, or WDS mode. It won't work if the other box is running in
wireless bridge mode because wireless bridges only talk to other
wireless bridges.
The wireless printer does. I think that will be a client need. Also,
my sister-in-law might need net access here when she brings her laptop
over (unless we can be sure it will communicate on its own back to her
house).
Fine. That means you need "something" at each end running in
infrastructure mode (AP or wireless router).
If the transparent bridge will talk wirelessly to the router (WGT624)
then the router serving as the internet gateway can serve clients, IFF
it can be told to _route_ (it has RIPv2 so there is hope) over to my
LAN of computers.
It cannot do that (for the 3rd time). That's how we started this
discussion. You bought two wireless routers that will NOT talk to
each other. There are ways you can do this (i.e. WDS). A transparent
bridge will only talk to another transparent bridge unless it has some
goofy protocol that allows it to also service clients. I've seen
these appear ocassionally, but have no experience with them. A client
bridge will talk to an access point or wireless router, but you have
to be careful with how many MAC addresses are passed.
I think the problem may be terminology. I once tried to organize the
chronic misuse of the term "bridge" at:
http://wireless.wikia.com/wiki/Wi-Fi#Wireless_Bridge
It's not perfect and needs a bit of work, but it might help untangle
the buzzwords.
As for RIPv2, it's only useful if you have more than one path to the
interknot. It's intended mostly to change the routing on the fly
between two routers when one of the links drops. Check if the device
does static routes, which I think might be more useful.
IFF cannot be told to route if the entire wireless network is based on
bridging. Assigning a static route through the maze of IP's does no
good if the underlying destination MAC addresses cannot be seen.
And one end or the other needs to connect to a DSL modem.
That's sorta assumed here. Suggestion: Try to assemble a topological
map of the system using seperate boxes for seperate functions. For
example, a wireless router would be 3 seperate boxes, an ethernet
router, an ethernet switch, and a wireless access point. They can be
recombined into a single unit later. That might clean things up a
bit.
Where I will be placing the router that connects to the DSL mode, its
antenna can see the window where the wireless would be in the other house.
Perfect. If you the antennas can see each other, you have line of
sight. Make sure there's no window screens or aluminized mylar on the
windows.
The other house is lower in elevation but its wireless will be on the
2nd floor. They have tiny 4 watt lights in each window and I can most
or all of them. A couple trees are along the path, but not completely
blocking things, even with leaves.
At the distances you're working with, the trees should not be a huge
problem. If they grow into a problem, external directional gain
antennas will probably be needed. However, if you do add a
directional antenna, you will create a new problem. With the stock
omni antennas, you'll have coverage of both the inside of the house
and across the road. However, if you redirect the bulk of the RF
across the road, there's not much left to cover the inside of the
house. You may need to do something weird with the antennas or
possibly use seperate radios for the inside coverage and the outside
link across the road.
I'm not trying to pass cable modem (over there) traffic back to here.
I'm getting DSL here soon. But the cable seems to be as fast as I
might expect over there.
Oh, that wasn't obvious. With two connections to the internet, you'll
probably need to nail the default route to the router on each side of
the road. That should keep the traffic seperated. If one goes down,
just point the default route to the router on the other side of the
road, and you're back on.
The reason I asked about speed was to get a feel for what manner of
performance you were expecting from the wireless.
| Nope. Everything on one "frequency" or rather channel as 802.11
| spread spectrum occupies about 22Mhz of spectrum.
So for 2 boxes by themselves it would be equivalent to ping-pong.
Yep. That's the way it works. Some of the really high speed wireless
links (bridges) offer full duplex on the ethernet ports. However, the
radio is not full duplex. It just runs twice as fast as the ethernet
port with an intelligent direction switching scheme. At the ethernet
port, it just looks like full duplex.
There are also wireless bridges that are genuinely full duplex. For
example, Proxim Lynx radios use half the 2.4Ghz band in one direction,
and the other half the band in the other. On the back of the radios
is a big cavity duplexer to keep the frequencies seperate. You don't
wanna know the price.
See:
http://www.winncom.com
for some clues on the fancier radios.
I'm really asking for RF to be a media not unlike any other ethernet
media, besides the added "physical" security needs and management.
You're asking for a fundamental change in topology. That's being
addressed for *NEW* wireless technologies. Please don't expect the
existing technology to change this much. Attempts to graft mesh
technology on top of 802.11 have been generally successful, but not as
effective as starting over with a new protocol (e.g. WiMax).
Beyond that, things like topology should be an administrative issue
that can be handled by smarter implementations or smart enough people.
Actually, the trend is for the topology to be undefined. Modern mesh
systems are advertised as "self configuring", "self provisioning", and
"self healing". I try not to act too disgusted when I read these
claims. I like the concept of having the network organize itself but
am not very optimistic as to whether it's any better than having it
pre-defined.
Products could come with a default that works best for most and MAYBE
support other things. But the _standard_ should not rule out anything.
Ok, time for rant. The 802.11 standard does nothing of the sort.
There's not one mention of any Layer 3 technology in 802.11. You can
do anything you want on Layer 3 and you will not be violating anything
in 802.11 (or FCC Part 15). Now, if you want to do "anything" on
layer 2, you'll need to re-write the standard. Note that even in the
current revisions of 802.11a/b/g, there is very little mention of
repeaters, zero mention of print servers, mesh networks, wireless
video, etc. At this time, you literally can do anything you want, and
that's the problem. Many companies do exactly that and screw up. For
example, the industry still can't seem to translate an ASCII WEP key
into a Hex WEP key. There's nothing in 802.11 so everyone does it
their own way with predictable incompatibilities.
Later standards efforts were a bit smarter about implimentations. An
extreme example is Bluetooth. They define each application as a
profile. Wanna do multimedia stereo over Bluetooth? Fine... follow
the exact proceedure in the profile. It's about as micro managed as
possible and vendors still manage to find ways to create
incompatibilities. The right answer is somewhere between the fairly
loose 802.11 and the draconian Bluetooth. Yes, it would have been
nice to be able to do mesh, self configuring, fast AP switching,
multiiple SSID's, fast roaming, etc, but nobody thought of that in
1996.
As I suggested previously, please try and define the requirements for
wireless in the year 2015 based on what we know today. That's what
you're asking from the original IEEE 802.11 committee.
I can get around the goofy RX/TX pairing design of ethernet twistedpair
by simply using a crossover cable.
If you follow the wiring diagrams for most crossover cables, it only
crosses over the two data pairs. You need all 4 pairs crossed to do
gigabit ethernet.
Radio just isn't so easy, so that's
where I think the designers need to think it through, better. If it's
a case of everything alternates between RX and TX on one frequency
(which is good for assymetric loading, as much of web usage and file
transfers are to sometimes quite an extreme), then the one frequency
design is right.
At the time (about 1995) most datacomm standards were symmetrical
(dialup, ISDN, DS0, T1, etc). The first asymmetrical datacomm was DSL
which first appeared in roughly 1997. However, most wireless
implimentations are quite intelligent about when to turn around the RF
direction with lots of buffering, sliding windows, and adjustable
packet sizes. There was a problem initially where different protocols
(IP, Netbeui, IPX/SPX) would have different thruputs, but that was
apparently solved (somehow).
But it really should accept _any_ security authenticated
packet that comes in and pass it to the bridging/switching/routing layer
which should not have standards imitations on flexibility.
Security and consumer wireless has had a long history or problems. All
802.11 wireless works on the bridging/switching layer so you are
limited to implimenting your creative network on the routing layer.
You can authorize and authenticate on any layer you find useful
including the applications layer. However, it's considered good form
to authenticate at the lowest possible layer to prevent spoofing
attacks.
OTOH, I've seen some terribly shoddy instls of coax and crimpable BNC
connectors just jammed on (fell apart faster than F connectors).
Ditto. I deal with LOTS of RF connectos. BNC's are NOT easy
connectors to attach. I won't even look at connectors that are not
crimped. For F connectors, I use the piston insertion type, not the
barrel crimp. Lots of ways to turn a good connector into junk.
Done right, coax can get up to 2 GHz on BNC, 4 GHz on TNC, 10 GHz on N,
and 24 GHz on SMA. That's assuming good cable, too.
I think you're a bit optimistic for the BNC and TNC, but that's about
right.
But at least the length of the impedance bumps in RJ-45 is not too long
at 100 MHz.
You should see some of the weird RJ45 connectors proposed for CAT7. I
have some TDR photos (somewhere) of common CAT5 patch cables. It's a
miracle that they work at all.
But the whole mess with twisted pair just annoys me. Going cheap is
one thing. But then trying to be compatible with the twisted pair cables
the telcos already use is another.
If you've ever watched a standards committee in action, you'll soon
find that nobody really cares about the technical issues. Those are
usually obvious and based on existing product tests. For example, the
IETF won't even accept an RFC proposal unless there are already two
independent existing implimentations. Anyway, the standards emphasis
is on IP (intellectual property), patents, and existing product
protection. Everyone want the standard to follow their product
because changing anything in production will cost too much money. Much
of the 802.11 effort went the same way. Buried in the 802.11 spec is
Texas Instruments PBCC-22 22Mbits/sec modulation. It would never have
been in there had TI not been so adamant and effectively blocked the
vote unless it was included. EIA-568 was worse in some respected
because huge companies were playing the same games.
We ended up having to have crossover
cables, anyway. We should have made that THE standard cable which would
mean every jack would TX on one side and RX on the other side universally.
But I guess someone didn't like simplicity.
It was that way until someone needed to connect to hubs or switches
together. The crossover standard wiring was NOT in the spec because
nobody knew if the extra two wires also needed to be crossed. The
POTS voice people said no. The datacomm people said yes. The
committee said lets go on to something else.
Ever seen a GR-874 coaxial connector?
Sure. I have some old General Radio equipment with them. Big, ugly,
sex-less, expensive, and universal. Want to see two of them on your
wireless access point?
I could have had 12 twisted pairs plus a ground pin on a DB-25. With the
same crossing-over logic, even that could have been made to work well.
Even DB-9 would have worked well that way.
Yep. I have a really bad attitude about non-differential data links.
Invariably, the common ground causes problems with ground loops,
noise, noise margin, ground bounce, signal isolation, and electrical
safety. Differential rules.
Ooops.... late again.
--
Jeff Liebermann jeffl@xxxxxxxxxxxxxxxxxxxxxx
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
.
- Follow-Ups:
- Re: Two Netgear WGT624 models will not communicate
- From: phil-news-nospam
- Re: Two Netgear WGT624 models will not communicate
- References:
- Two Netgear WGT624 models will not communicate
- From: phil-news-nospam
- Re: Two Netgear WGT624 models will not communicate
- From: Jeff Liebermann
- Re: Two Netgear WGT624 models will not communicate
- From: phil-news-nospam
- Re: Two Netgear WGT624 models will not communicate
- From: Jeff Liebermann
- Re: Two Netgear WGT624 models will not communicate
- From: phil-news-nospam
- Re: Two Netgear WGT624 models will not communicate
- From: Jeff Liebermann
- Re: Two Netgear WGT624 models will not communicate
- From: phil-news-nospam
- Two Netgear WGT624 models will not communicate
- Prev by Date: Re: Two Netgear WGT624 models will not communicate
- Next by Date: Re: Pairing 2 sets of bridges on one LAN for increased bandwidth
- Previous by thread: Re: Two Netgear WGT624 models will not communicate
- Next by thread: Re: Two Netgear WGT624 models will not communicate
- Index(es):
Relevant Pages
|
Loading