Netgear WGPS606 <-> Netgear WGT624

| A reflector mounted to the existing antenna can be remarkably effective | -- see .

Good idea. And small at 2.4 Ghz.

On Sat, 22 Jul 2006 03:36:30 GMT John Navas wrote: | On 22 Jul 2006 02:53:51 GMT, snipped-for-privacy@ipal.net wrote in | : | |>On Sat, 22 Jul 2006 00:20:12 GMT John Navas wrote: |>| On 21 Jul 2006 21:31:29 GMT, snipped-for-privacy@ipal.net wrote in |>| : |>

|>| A key principle of networking is to carefully plan the network first, |>| then implement it. Rushing ahead is a bad idea. |>

|>That's what I did. But it was based on the _assumption_ | | That's _not_ careful planning. ;)

You are correct, it's not ... in the context of the information I should have known, but didn't. It would have been just right had wireless interfaces connected to the air in the same way that they would connect to a common bus. My mistake was assuming a wireless technology that was made the way I would have made it.

|>that wireless |>would not have limitations intentionally built in that it does have. | | It doesn't. It simply has different products just like wired | networking. You can't use a wired bridge as a wired router, just as you | can't use a wireless client bridge as a wireless router. You can't hook | one wired port to more than one other wired port, just as a wireless | client can be hooked up to more than one access point.

Sure you can hook one wired port to more than one other wired port. I've set up numerous networks that way, with hundreds of computers. It is called bus technology. It's how ethernet used to be before physical point to point CAT5 style became the new way. Almost all the networks I installed that way were 10 mbps over RG-58 grade coax with BNC T-connectors for taps.

That bus technology is very much like radio in a lot of ways. When any station sends a signal, all other stations get it. They might reject it if the checksum doesn't match, or the MAC header indicates it's not for them. But those are decisions made above the media layer.

Radios is, of course, different. Problems can be very exaggerated. Some nodes can't hear certain other nodes and some help is needed. An access point could certainly act as a repeater for this. Still, the radio channel is still effectively equivalent to a bus. Let any device accept frames from any other device on the same bus, as long as appropriate SSID and key match, and then let the layer above check it for correct MAC, etc.

|>Ironically, now that I know such limitations do exist, I was expecting |>to find lots of resources that I didn't look for before that would tell |>me this. I've looked around and found a lot of resourses, none of which |>tell me what I needed to know to do a correct plan. | | Yet lots of them do exist, including the wikis below and the wealth of | links they contain.

I could not find one that says an access point cannot talk to another access point. Nor could I find one that says a client cannot talk to another client.

|>| Gack! Each WLAN should have a really unique SSID, at least for |>| starters. The only time you want the same SSID is when you want |>| wireless clients to roam between them, which is probably not what you |>| want even later. |>

|>Except for my sister-in-law's laptop, no roaming is needed. |>

|>My original thinking of this was at the very least everything in my house |>would all be on one WLAN. | | Read what I wrote more carefully. You've already run into a common | problem caused by non-unique SSIDs.

If I was wiring my house with coaxial ethernet, it would all be in one broadcaste segment. There might be reasons for wanting to split it up. But if I chose not to, the attached devices would not be choosing to refuse a frame just because of what kind of device the sender is. I could attach computers, switches, routers, etc, to this coaxial bus. They might refuse certain frames or packets because of the nature of how that's supposed to be done in layer 2 or layer 3 (for example, "no route to host").

If a router gets a frame addressed to it (destination MAC equals its own), it's going to pass it up to the next layer in the stack, which looks at the IP address to see what to do net. It's never going to refuse to do that just because the frame came from a device that is a router. It won't care, or even know.

|>This little old bridge I do have will not talk _directly_ to the |>printer. I would need to have something running that WILL talk to the |>printer. The WGT624 does. | | That's because the printer is a client that needs an access point | (WGT624), not another client (little old bridge). Read the resources | and all the material I've now posted here.

What is the terminology for a device that takes a frame it gets from the radio (only if SSID and key/phrase match) and passes it on to layer

2 where the destination MAC address is used to look up the next path to send the frame to? Note that I am asking about one that makes no other judgements about it. In the wired world, this would be called a switch or bridge (a small case of a bridge). There seems to be no analogy for wireless because in wireless, other judgements are made, such as "if it came from a client, and I'm a client, I'll ignore it". So I would get there is no terminology for it in the wireless world.

|>| Are you trying to create a big network covering both houses, where |>| everything can talk to everything? If so, you're options include: |>

|>I was going to try that. Having it cover just my house alone would |>be an accomplishment, it seems. | | Actually pretty easy.

With an excess of components, sure. There's a router, and over there is a client. To communicate to each from one point requires TWO classes of devices (a bridge to talk to the router, and a router to talk to the client). Had that been done on a coax ethernet, exactly ONE interface would be needed to talk to the router AND the printer.

|>| 1. One WLAN covering both house. Wireless probably won't work, and a |>| bitch to use both broadbands. |>

|>I already have the cross-usage of broadbands figured out. My file server |>in my house has a running Squid proxy. That's a start to get HTTP access. |>If my proxy can reach my DSL, then any machine that can reach my proxy |>can at least do HTTP via my DSL. The file server going into my brother's |>house can have the same thing. |>

|>I don't need to use both broadbands by direct reach to the respective routers. | | As I wrote, forget all that cool stuff until you finish the network.

Many parts of this network won't come into place for a while. For example, the DSL is not here, yet. Maybe in two months it will be. the file server for my brother's house is yet to be built and the parts haven't even been selected (I'll be building one for my house at the same time, retiring the old file server, which might go to some other use, maybe bumping another machine that ends up being used my one of my brother's kids).

So basically, the network is a work-in-progress. I expected to buy ONE more wireless device even under my idealistic but misguided plan. What I bought now was to get at least something going, to be ready for the DSL, and to make the printer practical (because there was no place to put it where it could be wired directly). Had I not found a wireless printer, I'd have probably put off getting a printer for a while longer.

|>| Here you go -- add a wireless client bridge (WCB), and everything |>| connects to everything: |>

|>That's looks viable. Would a WCB be usable in place of the WGPS606 |>even with a WCB at my brother's how? | | The WGPS606 is a WCB (Wireless Client Bridge), plus a network switch and | network printer server.

It seems they can certainly combine stuff. I wish someone would combine a client bridge with an access point and maybe even a router.

|>I consider manual configuration not a hassle. And I can run DHCP on |>a Linux box just as easily. | | Running any sort of DHCP on separate bridged networks is asking for | trouble, as I explained.

Of course. DHCP would be just for sloppy convenience. If it was part of the same ethernet broadcast segment, then redundant DHCP servers would be configured to all give IP addresses within this one big subnet. All such addresses would work anywhere on it just like the 1200 node switched networks I've built wired.

|>Your diagram shows the WCB at my brother's house, wireless to the WGT624 |>in my house, and wired to the WGT624 in his house. Would it be possible |>to reverse that where it would be wired to the WGT624 in my house and |>reach the WGT624 at his house by wireless under his SSID? I'm asking |>that to both understand what this is doing ... AND to be sure the WGPS606 |>would not interfere with it. | | Yes, opposite configuration of the WCB link will work.

Great.

|>Can a WCB be used in lieu of the WGPS606? | | Again, the WGPS606 is a WCB (Wireless Client Bridge), plus a network | switch and network printer server.

I've found that it, too, has the same cheap flimsy permanent 2dbi antenna. I'll look around for a WCB with a removeable antenna with a standard RF connector. Then I can make or buy a gain antenna if I need one (which I have expected is a definite possibility).

The WGPS606 is priced a good bit more than the WGT624. If that cost went into a beter quality product, it would be worth it. I suspect it went into adding USB ports, printer server software, and associated licensing ... all wasted. I'll look for other WCB's. But knowing this one should work helps figure this out.

FYI, Netgear's tech support said there was NO Netgear product with an ethernet port that would talk to the WGT624, and that I needed to get a PC card to do so. I may call back and ask that again, and if they still say no, then pop the WGPS606 on them and ask if that one would work. The thing is, the very highly compressed voice line to India they are using really ruins the music on hold.

|>What vendor device models are WCBs to choose from? | | Lots, including the WGPS606. Sometimes called Wireless Gaming Adapters, | although beware of those that can only handle a few or even just one | device. But since you seem to fancy yourself a hacker, I've already | recommended running third-party firmware in wireless client bridge mode | on a suitable box (e.g., Linksys WRT54G, which you may be able to find | for cheap -- just be sure to get a good version). See the wikis for | more info.

I understand that the gaming adapters do work different by emulating the MAC address of the wired peer, rather than its own, on the wireless side. Apparently this is essential for certain gaming devices to communicate because they will refuse to communicate with devices not of the proper game type, probably as determined by the MAC prefix (OUI) and maybe more. Documents I see specifically mention XBOX as needing this.

On Sat, 22 Jul 2006 05:02:18 GMT John Navas wrote: | On 22 Jul 2006 02:53:51 GMT, snipped-for-privacy@ipal.net wrote in | : | |>[SNIP] | | p.s. In case it's not obvious, you already have enough wireless gear to | at least get started by: | | 1. Connecting the WGPS606 by wire to WGT624(1). | | 2. Using the WGPS606 to connect by wireless to WGT624(2).

I don't have the WGPS606. I'm going to look for an alternative instead.

| See

Unfortunately, that's a wired path from DSL to computers. No go on it for that reason. The intent of a wireless hop on that path was what started this whole adventure in the first place.

On 22 Jul 2006 09:46:24 GMT, snipped-for-privacy@ipal.net wrote in :

There are good reasons it wasn't done that way.

That wouldn't work with your topology even with wires.

Linksys WET54G

(Sorry, but I don't have time to debate the rest of your post.)

On 22 Jul 2006 09:57:23 GMT, snipped-for-privacy@ipal.net wrote in :

From my prior posts: Linksys WRT54G with third-party firmware Also: Linksys WET54G

I'm beginning to see why you couldn't find the necessary information on wireless networking in the beginning -- you're not taking the time to absorb the information you're reading. Go back and look at the start of my post, where I wrote: "at least get started". I didn't say it was a complete or permanent solution.

Oh, and by the way, you're welcome.

On Sat, 22 Jul 2006 13:57:00 GMT John Navas wrote: | On 22 Jul 2006 09:46:24 GMT, snipped-for-privacy@ipal.net wrote in | : | |>You are correct, it's not ... in the context of the information I should |>have known, but didn't. It would have been just right had wireless |>interfaces connected to the air in the same way that they would connect |>to a common bus. My mistake was assuming a wireless technology that |>was made the way I would have made it. | | There are good reasons it wasn't done that way.

I would like to see where those reasons are explained. I didn't see such a thing in your wiki.

Maybe I should start another thread strictly on the topic of how to make a better wireless technology, where those who wish to show that it can't be done would have the opportunity.

I might begin such a thread by explaining that with a central access point (and where each client won't talk to other clients) really means you're getting only half the usable speed. Whatever speed you end up with between a client and an access point, due to all the radio issues such as syncronizing, overhead, noise, reflections, etc., you have to then cut that speed in half just because every packet has to be sent first to the access point, then again to the other client. Obviously in cases where the two clients cannot reach each other, there is no choice but to bounce the data through some repeater, switch, router, or other mechanism. But this can be figured out dynamically so that for clients that can reach each other, no redundant relaying is even attempted.

|>| Running any sort of DHCP on separate bridged networks is asking for |>| trouble, as I explained. |>

|>Of course. DHCP would be just for sloppy convenience. If it was |>part of the same ethernet broadcast segment, then redundant DHCP |>servers would be configured to all give IP addresses within this |>one big subnet. All such addresses would work anywhere on it just |>like the 1200 node switched networks I've built wired. | | That wouldn't work with your topology even with wires.

Since I've done such things with wires, I would most certainly have to disagree.

|>| Again, the WGPS606 is a WCB (Wireless Client Bridge), plus a network |>| switch and network printer server. |>

|>I've found that it, too, has the same cheap flimsy permanent 2dbi antenna. |>I'll look around for a WCB with a removeable antenna with a standard RF |>connector. Then I can make or buy a gain antenna if I need one (which |>I have expected is a definite possibility). | | Linksys WET54G

Thanks.

| I'm beginning to see why you couldn't find the necessary information on | wireless networking in the beginning -- you're not taking the time to | absorb the information you're reading. Go back and look at the start of | my post, where I wrote: "at least get started". I didn't say it was a | complete or permanent solution.

In the beginning I really failed to do the research I should have done. I already understand wired ethernet technology well (I've build quite a number of networks, many with unusual topologies), some all switched, some with VLANs, and some heavily subnetted and routed. Most had some mix of things. Additionally, I understand radio modulation, analog and digital, and issues related to radio communication, such as interference, noise, signal loss, etc. I know that ethernet over wireless would not be as simple as ethernet over a single coax bus. But I also know that in basic form it really can be like that, with some intelligence used to overcome the radio limitations. I even understand the security it would need.

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.

Basically, I've held a vision for years, well over a decade, of exactly how to do this kind of technology, marrying radio and networking. What we have today isn't too far from it. I would have used OFDM right from the beginning, merely varying the signaling rate to vary data rate, for example. 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).

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. I've heard horror stories of multi-office buildings being overloaded on wireless, and now I can see why. 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. 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.

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).

| Read Wikipedia and the wikis below. Lots of helpful links. | | The problem is that you're trying to do something beyond normal consumer | networking, so it's inevitably going to get complicated if you're not | willing to pay (or beg) an expert to do it for you. | | You should decide whether you want to (a) debate terminology or (b) get | your network working. I'm happy to help with (b), but don't really have | the time for (a).

Here's how I think you can help, not me particularly (although had you done this before AND had I done my research and found it, this would have saved some confusion). Put SOMETHING on your wiki that explains that the Netgear WGT624 _will_ have the limitations of an access point. Maybe you could do this simply enough by explaining that the Netgear WGT624 _is_ an access point. The Netgear website DOES NOT. The PDF data sheet for the WGT624 DOES NOT. Those failures by Netgear are certainly not your fault. But I believe your wiki could be substantially more helpful to people if it explained specific models of products from specific vendors and what roles in a WLAN those models could or must operate. Maybe start a specific page for each wireless device model on the market. Then on that page all the features ... and misfeatures ... of that model can be made available. Then people can find out things they really want to know without having to sift the all the sales BS. I suppose I could start my own wiki. But you already have a very good start. And while your wiki is open to public update, I don't think it's my role to substantially update its structure.

I haven't really lost anything in all this due to not knowing what I have learned after the fact. I still need to have 2 wireless broadband routers. I know now NOT to buy a 3rd one, and instead, to get a WCB. For now, the no-model bridge I have gets minimal things working and I can put off buying a decent WCB.

However, having learned about a lot of limitations of the standarized technology and of the various models being made, I believe it would have been a better choice to have bought the Linksys WRT54G or WRT54GL. This would be so that I can hack my own firmware. I'm going to take the WGT624's back for refund, and get a pair of WRT54G's instead, maybe just one of them for now, and a WET54G (if I can find a place that sells them).

Is there any reason I should get a WRT54GL instead of a WRT54G?

| * WDS (Wireless Distribution System): | | WAP | /|\\ | / | \\ | WC WC WDS | /|\\ | / | \\ | WC WC WC

Would this work?

____WDS____ / | \\ / | \\ WAP WAP WAP /|\\ /|\\ /|\\ / | \\ / | \\ / | \\ WC WC WC WC WC WC WC WC WC

Or would it have to be more like this?

WDS-WDS-WDS / | \\ / | \\ WAP WAP WAP /|\\ /|\\ /|\\ / | \\ / | \\ / | \\ WC WC WC WC WC WC WC WC WC

| * Wireless Point-To-Point Bridge (to which WLANs can be connected) | | EthernetWPTPB----------WPTPBEthernet

Any known models of this that exist?

On 22 Jul 2006 22:52:43 GMT, snipped-for-privacy@ipal.net wrote in :

WDS is simply a WAP repeater for connections by wireless *clients* (WC), so it will only work in the kind of topology I described. Think of WDS as a kind of WAP.

Sure. Already posted some. The easy ways are:

EthernetWAP----------WCBEthernet

or

EthernetWCB----------WAPEthernet

On 22 Jul 2006 22:45:49 GMT, snipped-for-privacy@ipal.net wrote in :

It's not *my* wiki -- it's *our* wiki. I just started it and did most of the work on it thus far. The essence of a wiki is that *anyone* can contribute. Including you. ;)

There's no failure. The WGT624 is a wireless router, as Netgear clearly states, which is a combination of (a) a wired router and (b) a wireless access point.

Impractical in the general case, because there are simply too many products on the market. Worse, for many of these products there are many different versions that are really different products.

Again, it's not *my* wiki -- it's *our* wiki. I just started it and did most of the work on it thus far. The essence of a wiki is that *anyone* can contribute. Including you. ;)

A better WCB can be made with third-party firmware (e.g., DD-WRT) and an appropriate wireless broadband router, which may well be cheaper and better than a "decent WCB."

Good plan.

Compare them here: <

On 22 Jul 2006 19:26:19 GMT, snipped-for-privacy@ipal.net wrote in :

It's not intended to address esoteric issues like that. Search the Internet for background material on 802.11 and/or review the materials published by the working group.

Go for it. I'm not interested, but maybe Jeff or others will jump in.

OK. Learn the hard way.

On 22 Jul 2006 20:13:26 GMT, snipped-for-privacy@ipal.net wrote in :

Prohibited by the FCC in the beginning. Oops. ;)

No, that's not it. As I wrote, there are good reasons. Go look them up instead of just presuming you know better.

Go for it. Best wishes. Sincerely.

On Sun, 23 Jul 2006 03:48:18 GMT John Navas wrote: | On 22 Jul 2006 19:26:19 GMT, snipped-for-privacy@ipal.net wrote in | : | |>On Sat, 22 Jul 2006 13:57:00 GMT John Navas wrote: |>| On 22 Jul 2006 09:46:24 GMT, snipped-for-privacy@ipal.net wrote in |>| : |>| |>|>Of course. DHCP would be just for sloppy convenience. If it was |>|>part of the same ethernet broadcast segment, then redundant DHCP |>|>servers would be configured to all give IP addresses within this |>|>one big subnet. All such addresses would work anywhere on it just |>|>like the 1200 node switched networks I've built wired. |>| |>| That wouldn't work with your topology even with wires. |>

|>Since I've done such things with wires, I would most certainly have |>to disagree. | | OK. Learn the hard way.

It works fine with wires. I've already done the learning on that. If you think it doesn't work with wires, you may be missing out if you have such a situation to wire up some day.

On Sun, 23 Jul 2006 03:53:00 GMT John Navas wrote: | On 22 Jul 2006 20:13:26 GMT, snipped-for-privacy@ipal.net wrote in | : | |>Basically, I've held a vision for years, well over a decade, of exactly |>how to do this kind of technology, marrying radio and networking. What |>we have today isn't too far from it. I would have used OFDM right from |>the beginning, merely varying the signaling rate to vary data rate, for |>example. | | Prohibited by the FCC in the beginning. Oops. ;)

The FCC is not immutable. Have you ever made petitions to the FCC for rules changes *AND* gotten them approved to FR&O stage? I have.

|>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. I've heard horror stories of multi-office buildings being |>overloaded on wireless, and now I can see why. 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. ... | | No, that's not it. As I wrote, there are good reasons. Go look them up | instead of just presuming you know better.

What keywords? Was there a specific (public) discussion forum?

On Sun, 23 Jul 2006 03:37:18 GMT John Navas wrote: | On 22 Jul 2006 22:45:49 GMT, snipped-for-privacy@ipal.net wrote in | : | |>On Fri, 21 Jul 2006 22:55:06 GMT John Navas wrote: |>

|>| Read Wikipedia and the wikis below. Lots of helpful links. |>| |>| The problem is that you're trying to do something beyond normal consumer |>| networking, so it's inevitably going to get complicated if you're not |>| willing to pay (or beg) an expert to do it for you. |>| |>| You should decide whether you want to (a) debate terminology or (b) get |>| your network working. I'm happy to help with (b), but don't really have |>| the time for (a). |>

|>Here's how I think you can help, not me particularly (although had you done |>this before AND had I done my research and found it, this would have saved |>some confusion). Put SOMETHING on your wiki that explains that the Netgear |>WGT624 _will_ have the limitations of an access point. | | It's not *my* wiki -- it's *our* wiki. I just started it and did most | of the work on it thus far. The essence of a wiki is that *anyone* can | contribute. Including you. ;) | |>Maybe you could do |>this simply enough by explaining that the Netgear WGT624 _is_ an access |>point. The Netgear website DOES NOT. The PDF data sheet for the WGT624 |>DOES NOT. Those failures by Netgear are certainly not your fault. | | There's no failure. The WGT624 is a wireless router, as Netgear clearly | states, which is a combination of (a) a wired router and (b) a wireless | access point.

Neither "wireless" nor "router" alone implies an access point. Combining them does? No. Combining terms means the concepts are combined. But there is no implicit synergy that says it must be an access point. You could, for example, combine a router with a bridge. It would still have wireless functionality. It would have router functionality.

Indeed, Netgear never said the WGT624 was an access point.

|>But I |>believe your wiki could be substantially more helpful to people if it |>explained specific models of products from specific vendors and what roles |>in a WLAN those models could or must operate. Maybe start a specific page |>for each wireless device model on the market. Then on that page all the |>features ... and misfeatures ... of that model can be made available. Then |>people can find out things they really want to know without having to sift |>the all the sales BS. | | Impractical in the general case, because there are simply too many | products on the market. Worse, for many of these products there are | many different versions that are really different products.

The more products there are, the more reason to do so. A wiki is also just the right kind of means to do it, since it is a great tool for public input.

|>I suppose I could start my own wiki. But you |>already have a very good start. And while your wiki is open to public |>update, I don't think it's my role to substantially update its structure. | | Again, it's not *my* wiki -- it's *our* wiki. I just started it and did | most of the work on it thus far. The essence of a wiki is that *anyone* | can contribute. Including you. ;)

And if someone, maybe I, puts in pages for specific products, including an index page to those products?

On Sun, 23 Jul 2006 03:28:00 GMT John Navas wrote: | On 22 Jul 2006 22:52:43 GMT, snipped-for-privacy@ipal.net wrote in | : | |>On Fri, 21 Jul 2006 22:55:06 GMT John Navas wrote: |>

|>| * WDS (Wireless Distribution System): |>| |>| WAP |>| /|\\ |>| / | \\ |>| WC WC WDS |>| /|\\ |>| / | \\ |>| WC WC WC |>

|>Would this work? |>

|> ____WDS____ |> / | \\ |> / | \\ |> WAP WAP WAP |> /|\\ /|\\ /|\\ |> / | \\ / | \\ / | \\ |> WC WC WC WC WC WC WC WC WC |>

|>Or would it have to be more like this? |>

|> WDS-WDS-WDS |> / | \\ |> / | \\ |> WAP WAP WAP |> /|\\ /|\\ /|\\ |> / | \\ / | \\ / | \\ |> WC WC WC WC WC WC WC WC WC | | WDS is simply a WAP repeater for connections by wireless *clients* (WC), | so it will only work in the kind of topology I described. Think of WDS | as a kind of WAP.

I guess if I get a WRT54GL I get to make up my own concepts, as long as the _hardware_ part of the radio doesn't impose the "gender" concepts of wireless into the transmission or reception of a radio frame.

|>| * Wireless Point-To-Point Bridge (to which WLANs can be connected) |>| |>| EthernetWPTPB----------WPTPBEthernet |>

|>Any known models of this that exist? | | Sure. Already posted some. The easy ways are: | | EthernetWAP----------WCBEthernet | | or | | EthernetWCB----------WAPEthernet

But I am looking for a device that can peer with an identical copy of itself. Specifically, (I want to) build a network consisting of exactly ONE single model type, same firmware in that model, that can do all the things that could be done with 10base5, where the wireless device is in the equivalent role of the AUI or an AUI based media converter. Looks like the WRT54GL is the way to go to build it as the makers of firmware in most commercial devices are limited in what they can do (most likely limited by management/marketing edict than their own engineering skills).

snipped-for-privacy@ipal.net hath wroth:

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

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.

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.

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.

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.

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.

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

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.

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.

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.

On Sun, 23 Jul 2006 12:43:23 -0700 Jeff Liebermann wrote: | snipped-for-privacy@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.

Social is a broader category that includes 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.

If you had a committee intent on designing the best technology, then it could do so. If element A and element B cannot coexist unless one of them is less than optimal, then that's where technical tradeoffs might have to be made, or more research done to solve a problem.

Committees formed of manufacturers, however, tend to be more about promoting their technology to the others, rather than making something that works better.

I'd expect a little better of IEEE than what I have seen, although to a great degree they have done reasonably well.

The early TCP/IP standards were developed in quite different ways, and in many ways are quite superior to what you could get by a committee of manufacturers.

|>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.

The concept of the technology was known long before that. Driving the demand for a technology can create the ability to make it work sooner. Would you have simply never done OFDM had the DMT work never been done? That would be stupid. The CPU speed to do OFDM really was around even in 1996. It just wants _architectured_ in a way most suitable for it.

This is like a chicken and egg problem. They won't make the technology unless there is a demand for it. There won't be a demand for it if we decide to only use what already exists. Someone has to think ahead to get out of that vicious circle.

So basically, it sounds like the 802.11 group was stuck in a vicious circle and the telco group decided to get out of it.

|>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.

And some provide a means for more complex checking, such as multiple MACs. A device that needs to build the network, though, will have to do some kind of processing of most everything, unless that is delegated to a smarter co-processor or whatever might be on board.

|>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.

In 1996 I had no interest in doing wireless. I was doing other things.

But I do think it is not outside of reason to ask for _every_ wireless device in a home or small office to be able to communicate with _every_ other device there, when it has traffic specifically for it.

|>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.

I wouldn't necessarily use success. The term "popular" comes to mind as being more appropriate. Of course manufacturers would consider it to be successful if larger numebrs of units are sold, regardless whether the buyers find it usable or not. Of course non-usable can result in later sales going down. Ultimately I think people need to determine where they really need wireless and use it there and avoid it in other places.

|>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.

So why would they want to make each frame spedn air time TWICE?

|>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.

It's always hard for something like Linux to penetrate corporate culture. I still find people in _technical_ business that have never even heard of Linux at all. Most have, but they still think it's just some geek novelty. While it hasn't caught up with Windows for desktop usage (as long as you compare current Linux to current Windows ... today's Linux certainly beats Win98), Linux is widely used in a lot of embedded systems. Even Linksys did for a while in the early WRT54G. And somehow they did realize it would be good to have the WRTG54GL on the market. Maybe they figured Linux developers could find and open up new wireless uses.

|>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.

Agreed. But I would't make two different kinds of boxes _just_ to do that separation. Some people might just want coverage out to the deck in the back of the house, and one box doing everything might well be fine for that. if something really does need a 2nd box, then either of the boxes shoudl be able to perform that role. And it should be as simple as just putting it there if the firmware is smart enough.

That's not to say there isn't need for other kinds of boxes. Other kinds of connections in embedded system boxes might be nice to have, such as USB, Firewire, serial, eSATA, SCSI, PS/2, POTS, SDI, HDMI, and many more. Putting _everything_ that _anyone_ might need is just too impractical. But ethernet and wireless in one box is good enough to get quite a lot going.