phil-news-nospam@ipal.net hath wroth:

>In the beginning I really failed to do the research I should have done.

It's often helpful to understand the existing technology before
attempting to change it.

>What I rarely understand are the social engineering issues. Things like
>the squabbling that takes place in standards committees, and why it is
>they will go ahead and make choices towards less than optimal technology.
>Of course I do understand why some patent holders of some technology would
>lobby to have their technology chosen. But it makes no sense to me why
>the rest would accept that technology if it is not the actual and true
>best technology to choose.

Those are not social issues. They're political and financial.
Standards are invariably built upon the intellectual property and
patents of the participating companies. The results may not be
technically ideal dues to the necessary tradeoffs. If you want to
have something adopted, there has to be compromises. What you are
apparently assuming is that the committee will adopt the technically
superior combination of ingredients at the expense of IP and patents.
It's quite the opposite.

>I would have used OFDM right from
>the beginning,

Try again. In 1996, when 802.11 was being debated, OFDM wasn't a
viable technology because the expensive and elaborate processing power
necessary to implement OFDM wasn't there yet. OFDM only became
popular when sufficient CPU horsepower was available almost as an
accidental side effect of telco DMT (discrete multitone) DSL research.

>merely varying the signaling rate to vary data rate, for
>example.

Minor note. The faster 802.11g speeds are QAM. The two slowest
speeds are BPSK. Also, it's not the data rate that varies. It's the
coding rate.

>But for the infrastructure, I definitely would not have any
>device intentionally discard data frames from other devices unless there
>was a good reason to do so (uncorrectable errors, security authentication
>fails, not addressed to this or known reachable devices, known to have a
>better path elsewhere, etc).

Why not? All ethernet cards do exactly that. The PAD (packet
assembler/disassembler) in the front end of the ethernet card acts as
a filter. It asks "is this packet for me?". If not, it discards it
before decoding the packet. Saves quite a bit on processing power
(and current consumption). However, if you have surplus processing
horsepower, by all means, feel free to decode everything.

>If I were to make an access point device that actually would talk to
>another access point device, many problems would be solved that are today
>merely solved by having redundant equipment, often utilizing more channels
>than necessary.

Where were you in 1996 when such things were being discussed? The
original concept of a wireless access point was a central access
point, with directly connecting wireless clients. If there were
additional access points, they would be connected with ethernet. In a
corporate or business environment, that was all that was deemed
necessary. There were other grandiose topology schemes mentioned, but
all of them fell apart when it came time to weigh the added complexity
against the cost and necessity. Poorly defined repeater and WDS modes
were thrown in as a pacifier for those that wanted extensible wireless
networks.

>I've heard horror stories of multi-office buildings being
>overloaded on wireless, and now I can see why.

Yep. The surest sign of success is pollution. Wireless is certainly
successful.

>Perhaps some of these
>issues are perptrated by the vendors themselves in an effort to drive up
>more sales by making people have to buy even more devices just to make
>their network function.

Actually, quite the contrary. Most of the original participants were
academics, not greedy corporate exploiters. Note that the fastest
speed considered useful in 1996 was 2Mbits/sec.

>Given the existance of third part firmware, it
>sure suggests that the original vendors are either doing that, or are just
>not keeping up with what is technically possible to do, especially in the
>area of switching frames and routing packets.

Ummm... I'm not sure that alternative firmware has had much of an
impact on Linksys and others. For example, Linksys apparently shot
itself in the foot with the WRT54G v5, that originally could not
handle alternative firmware. Apparently they thought that the Linux
hacker market was so small as to not worth dealing with. Had the v5
mutation not been such a bug pile, they might have been correct.

>So perhaps I really should look at 3rd party firmware, but not so much
>for just loading something someone has written to do something better,
>but perhaps to actually get into doing this writing myself. OpenWRT
>sure seems like a good starting point. Assuming the limitations where
>a device refuses to talk to another instance of itself is not in the
>hardware, maybe I really can make an access point talk to another access
>point, and make a client bridge really talk to another client bridge,
>and do both of these things in the same one device. It's all in the
>programming (hopefully).

There's no hardware limitation that prevents the implementation of
code for getting two access points to talk to each other. Of course,
this has already been done with WDS, but I'm always interested in
improved implementations.

Reminder: Did you catch my comments about the antenna problem with
using a single box for both indoor and outdoor coverage? Having a
single box do everything *MIGHT* be a problem as the placement of the
box and antenna will be a compromise between indoor omni coverage, and
outdoor directional coverage. Sometimes, it's best to have two
separate wireless boxes.

--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558