Re: Two Netgear WGT624 models will not communicate

On Thu, 20 Jul 2006 05:29:48 GMT Jeff Liebermann <jeffl@xxxxxxxxxxxxxxxxxxxxxx> wrote:
| On 19 Jul 2006 19:55:11 GMT, phil-news-nospam@xxxxxxxx wrote:
|
|>| Were to access points to talk to each other, they would by necessity
|>| need to bridge more than one MAC address. That means a bridging
|>| protocol that tracks the interface location of all the wireless
|>| clients. That's missing in the typical access point.
|
|>Or alternatively, translate to level 3 and re-announce as IP addresses
|>in a routing protocol like RIP. But none of this is new; wire switches
|>do this all the time.
|
| Ok, you lost me. Translate what to the IP layer? What will that do
| to provide universal interoperability?

Basically, if a router sees another device and discovers its IP address,
it automatically adds it to the routing table and announces it in RIP
broadcasts, or whatever other routing protocol it's using. If you can't
get to it directly at layer 2, at least you can at layer 3 by IP address,
which for most needs, is sufficient.


| RIP on layer 3 is very similar to STP on layer 2. However, that would
| dramatically increase the leve of complexity of wireless. By leaving
| everything (except management and configuration) on layer 2, wireless
| bridges avoid the complications of the IP stack.

If they fully implement a mesh, then this works. I managed to get an
old 802.11b nameless bridge to work with the WGT624, but only by using
WEP for security. The printer won't talk to the bridge but it will
talk to the WGT624. So if I unplug the cat5 from the WGT624 and plug
in the bridge, I can't reach the printer. In this case the WGT624 is
the center of the star topology, but something prevents the it from
passing on the MAC addresses (cheap nameless bridge might have a limit
of one, for example).

I have not yet tested this, but I presume if I set up an IP layer
routing for it, I can still get to the printer. That's assuming the
WGT624 will route IP packets between 2 wireless devices (I cannot yet
rule out that it has some logic that blocks this since it is designed
as an internet/broadband router and might be limiting the routing to
just between the broadband side and the ethernet side, and won't send
a packet back out the same side it came in).

What I was saying about translating is that it would _also_ go ahead
and dynamically add the printer, when it is discovered, to to its
routing table and announce it on RIP (which I have enabled, but it's
not making any such announcement, probably because I have not added
the printer IP to the static route table). If it did announce it, I
could turn on a RIP client or do a static route in my Linux host to
finish the reach to the printer.


|>Would not the encryption of the packets themselves be sufficient
|>security?
|
| Maybe. Dunno for sure. Security in a WDS network is marginal. The
| first problem is that many routers ran out of sufficient flash ram to
| impliment both WPA encryption and WDS at the same time. The result is
| that these are now mutually exclusive and only WEP is supported in WDS
| mode. This has been fixed on some routers. I don't have the list of
| winners and losers. I don't consider WEP to be adequate security.

I'm curious just how much flash ram is involved. Embedded programming
practices I used to see would put strong emphasis on making small code.
Lately, it seems that this kind of programming skill has been lost.
Or maybe it's because the programmers are relying too much on general
purpose reusable code libraries that are not really designed for this.


| Incidentally, the WAP54G wireless bridge has a similar problem. Bridge
| mode and WPA are mutually exclusive. Grrr....

If you can choose between one or the other by control panel, then BOTH
implementations must be present. Then the issue is not being able to
RUN at the same time, which instead of being a flash problem is more
of a dynamic ram buffer space problem.


| Even with WAP and WDS, there's a problem. There's only one WPA key
| for the entire system. Everything, including the clients, have to
| know this key. There are some routers that have multiple SSID's and
| encryption methods/keys, but not in WDS mode.

It sure would be nice to be able to configure in more than one "wireless
zone" (no idea what the correct term would be for the subset of segment
that would be identified by it's own SSID).


| As I see it (probably wrong), the MAC address in the configuration is
| used to create the MAC to port mapping table (whatever it's called)
| and to add an additional layer of security by doing some light weight
| MAC address wireless filtering. Only those MAC addresses listed in
| the WDS config page can "join" the WDS network. See:
| http://www.linksysinfo.org/portal/forums/showthread.php?t=47118
| for a WRT54G sample configs. Oops. WEP again.

For incoming frames, a device could choose to accept a frame as being
addressed to it based on the destination MAC being in it's table of
"one or MACs I pretend to be" without regard to the port. And it could
fake the MAC for output frames. So I'm not sure if any MAC to port
mapping is even needed.

If there's no need to literally communicate with the device, it has
no need of a MAC (but, of course, we want to have an administrative
control panel, so it and an IP address are needed at minimum for that).
I can see how a wireless bridge could be made where the same MAC is
used for all ethernet ports and is the same as used over wireless.


|>Seems to me that once you get RF into a bit stream/packet
|>then you want to be sure it is authorized (security) before doing
|>any more with it (valid SSID, phrase, key, etc).
|
| It sure would be nice to have WDS authenticate with 802.1x using a
| RADIUS server. That would give each connection a temporary and unique
| encryption key with a secure method of key exchange. Not this week.
|
| However, I agree. If you consider WEP to be adequate security, then
| it's probably also adequate for WDS.

I'd feel better with WPA. But road hackers are probably unlikely to
be trying the remote rural road I live on.


|>For ethernet over wireless it's not much different than ethernet over
|>a coaxial cable, besides the greater noise, more lossage, and hackers
|>tapping in.
|
| Nope. 802.11 encapsulates 802.3 ethernet packets. Coax cable
| (whether DOCSIS RF or 10base2 baseband) is simply layer 1 of the ISO
| pile. The problem is that wireless tends to have more dropouts, more
| lost packets, more noise, lousier signal to noise, and other anomalies
| as compared to wired networks. The effects are the same with both
| media, but the degree of imparement is much worse with wireless. I
| can produce some S/N ratio comparisons for wired protocols versus
| wireless protocols if you really need them. (Say no, I'm busy).

I believe you. Wireless certainly needs more support than a plain
wired ethernet bus. But in a layered sense, it's still down at that
layer. Collision detection, for example, isn't as simple because
two far end TXers might not hear either other, which means they can
send at the same time, and the AP in the middle just gets junk. An
added means to control that is a plus (and I have no idea if that is
in the specs or not).

But as far as building a topology beyond where wireless can hear,
that should be at the next layer or two upwards. And if all you do
is IP, layer 3 (e.g. doing IP routing to get there) is adequate.
But it's not really that hard to do layer 2 mesh. OTOH, I have no
idea just how small these things are in terms of RAM.


|>Operationally, it seems like it should be the same. But
|>if there are separate RX and TX frequencies, a few things could get
|>more complicated.
|
| Actually, they get simpler with full duplex. Flow control would
| actually work. There would be no dead zones in the sliding window.
| Repeaters could be built that don't cut the thruput in half. Etc.

There would still need to be a RX on the TX freq just to avoid collisions.
And 2 devices far enough they cannot hear each other will still end up
butting heads anyway, as far as other RXers see it. So as I see it,
one common frequency should be fine. But it would be nice to have a
device that could talk 2 frequencies at once (even if it can't RX on
one and TX on the other at the same time), just to be able to split
things up so part of youe network is on one frequency and part on
another, and this device in the middle (the flower topology). If
all the meshing is done purely at layer 2 or above, then this could
at least be done with 2 wireless devices attached back to back on a
cat5.



|>That's what we have ethernet, IP, TCP, etc, for. Of course if two
|>strange machines want to talk to each other in Gibberish 2.0 then
|>why not.
|
| Wired TCP error control has no mechanism for dealing with repetative
| errors. The best it can do is a random backoff algorithm to vary the
| retransmission time to hopefully avoid the repetative interference.
| 802.11 wireless has multiple mechanisms, including flow control and
| fragmentation control, to deal with interference issues.

But ultimately it still needs to do this at layer 1, even if it peeks
into upper layers. E.g. once a frame has arrived, is error free, is
authenticated, it is handed to layer 2 and that layer can do a mesh if
the network admin decided it should (getting it implemented in 64k of
machine code might be another issue).


|>| No. Everything in 802.11 wireless is half duplex. A box can transmit
|>| or receive, one at a time. In a WDS systems, all radios are on the
|>| same channel.
|>
|>Then I can't see the reason for separate client mode at the media layer
|>other than to force the star topology. IMHO, star topology should not
|>be used in many cases.
|
| This is not a la carte networking. You don't chose your topology,
| protocols, and media from a menu as you need them. You get the whole
| mess packaged as Wi-Fi, blessed by the Wi-Fi Alliance, and certified
| by the FCC. There are plenty of places where a different topology
| would be more useful. Too bad they're a minor consideration compared
| to the huge number of situations where a star will work just fine. If
| you want creative toplogies, look into Zigbee and mesh networking.

Why not? I can see there being a default for what works best for most.
But why limit things?

The star topology actually uses twice the air time for communications
between 2 wireless devices. Getting them to go direct saves bandwidth.


|>A limit on MAC addresses is something I can get around.
|
| It's a table size limit. Bottom of the line router manufacturers are
| cheap. For example, Linksys was doing just fine with a WRT54G v3 that
| had 16MBytes of RAM and 4MBytes of flash. However, they're latest
| incantation has only half the RAM and flash. Never mind that it barfs
| when faced with a large number of simultaneous streams, apparently
| from running out of table space. Unless you can control the memory
| allocation, you're not going to increase the MAC address count much.

Hmmm. That's a lot _more_ RAM and flash than I thought. Now I suspect
poor programming. That's plenty of space to do so nice OSPF routing.
Even if 16k is set aside for a MAC table, it's still probably no more
than about 128 bytes per entry (48 for the MAC, the rest for destinations
and other states) which gives 128 MAC entries, a usable number.

I now see how it is some people are able to run Linux in some of these.
I first ran Linux in the 0.99 days on a PC with 4MB of RAM (a load image
of way less than 1MB).


| Incidentally, some manufacturers seem to think that the way to
| stratify the pricing for their bridges is by number of MAC addresses
| passed. A "workgroup bridge" will typically do 4-16 MAC addresses.
| The same model as a "transparent bridge" can do perhaps 2048.

Obviously not an engineering limitation.


|>I'll just split
|>up in subnets and route from one of the Linux boxes.
|
| Sure. No problem. Sorry, I forgot to mention that. You only need
| one MAC address passed to do routing. Put a router at both ends and
| it should work.

Right. But I'll now need to go structure my IP addresses into subnets
instead of the way I was doing before, which was taking the lower 16
bits of the MAC address and using 169.254 as the prefix (e.g. my printer
is 169.254.29.222). I'll probably shift over to the 172.16.0.0/12 space
for this.

Any idea when we'll see IPv6 in these things? Soon the US government
won't buy them without it. I guess they are gonna need 4x the RAM and
4x the flash to do that.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-07-20-0937@xxxxxxxx |
|------------------------------------/-------------------------------------|
.

Loading