On Thu, 20 Jul 2006 10:39:21 -0700 Jeff Liebermann wrote: | snipped-for-privacy@ipal.net 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. |>
formatting link
| |
formatting link
| | 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.
But the WGT624's I have now apparently are running in access point mode.
|>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).
The WGPS606 on one end, WGT624 on the other.
|>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'm not restricted to the notion of having both ends be identical. Yes, I originally thought that would work. I didn't know they made self-incompatible devices.
| I think the problem may be terminology. I once tried to organize the | chronic misuse of the term "bridge" at: |
formatting link
| It's not perfect and needs a bit of work, but it might help untangle | the buzzwords.
Aside from things like the number of MAC addresses (or IP route table entries) a device could be programmed to hold, what specifically is it that limits a wireless device from talking to ANY other wireless device that properly authenticates with a common frequency, modulation speed, SSID, and shared key?
| 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.
It can be a workaround for reachability if the midpoint can do the routing. Or static route table entries could do it.
| 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.
If something that can see both can also do routing, it's an indirect path there.
|>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.
I'll work on that.
|>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.
Of course.
|>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 understand the RF limitations. The first phase of this was to test just how well it would work with the basic by having one unit in a window at one house, and the other in a window at the other house.
|>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.
Exactly.
Actually, the plan involved an HTTP proxy server on this end. The kids in the other house would figure out the default route change.
| The reason I asked about speed was to get a feel for what manner of | performance you were expecting from the wireless.
I'll use all I can get. If I layed in gigabit fiber, I could eventually make full use of it.
|>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).
My whole point is that topology is more about the logic inside the devices and how they handle things like mesh vs. star, and route the frames and packets around based on MAC or IP.
When one radio is transmitting a frame, all the other radios that can "see it" are receiving that frame. Then they have to decide what to do with it. If it has uncorrectable errors, throw it away. If it fails to authenticate, throw it away. But at this point you have something that can be used. Now where it goes should be a matter of MAC table or interface, or even layer 3 switching by skipping the MAC and look at the IP address alone. Obviously you don't want to send every packet around on every wired LAN that has a radio on it. But all of this is a part of existing networking topologies that apply to wireless or wired networks. The radio channel is just a bus (that has limitations you might need to work around, such as far end nodes that cannot see each other directly).
|>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.
I think it can be helpful to have self-organizing as a default mode, but certainly being a control freak type of personality that has done networking in the wired world for 20 years, I would certainly like to be able to specify exactly what it does. Even in many of my networks where I used OSPF routing, I still set up many alternate IP addresses that I left out of OSPF and put static routes in so if OSPF goofed up somewhere I could still reach the critical nodes to manually reboot or maybe fix a configuration error. Usually OSPF worked fantastic. But there were a few times when it was the target of 4 letter words, especially when dialing in from home and no way to even reach the router that was confused.
|>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.
Things like WEP keys are what I would expect to be in a wireless standard. Things like layer 2 topology I would expect to NOT be. But there could be advisory information going between layer 1 and layer 2 (such as the signal strength of that frame).
Suppose I have a bus ethernet network (e.g. either of the old coax ethernet technologies). I should be able to replace each ethernet tap with a wireless radio node and get exactly the same topology. That would mean each node can send and receive directly from any other without having to relay/repeat/bounce off of a central node (which would double the air time used). I believe using bridge mode wireless devices would do that.
The issue happens with routers. I could put a router on that coax bus and through that interface of the router, talk directly with any node on that bus, even if that node was another router. A wireless router SHOULD be able to do the same thing. If it sends out an ARP request on the bus onr the wireless channel, the other router should be able to take that ARP request and check its interfaces (and if so configured, even its routing table) to see if there is a match. And if there is, it would respond back to the MAC address of the first router, which can now see which MAC address has that IP and build its ARP table.
If the equipment designers decided not to put that capability in, that's one thing. But the standard should not have any limitation that prevents that from working.
| 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.
The _more_ it is micro managed, the _more_ exposure there is to let vendors screw it up. And the harder it is for standards compliance certification to test it.
| 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 think the problem is that wireless may be trying to travel up the network layer stack when it should not. That's like asking ethernet to start defining the applications like multimedia stereo. Those things should be left up to upper layer standards to do and not be a part of standards that define how bits turn into radio waves, or how a physically insecure "bus" can be secured, etc.
|>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.
Doable.
But I would have NOT done that 3-6 around 4-5 straddling that telcos do. Of all the things I hated most about going to twisted pair was that stupid wiring that came from the telco world. Now, they actually did it right FOR THEIR PURPOSES, which was to have a _single_ pair (which is working in both directions) mate with the _same_ pair, while allowing a
2nd pair to work similarly. But for split RX/TX that data was using, that was just wrong. And it doesn't matter if it is voice or data. If the data had been a ping-pong on a
_single_ twisted pair, doing it as the telcos did would have been right.
What we ended up with was a hybrid cable. The 4 wires in the middle would work fine as 2 separate single bi-direction paths. Then the 4 wires on the outside were made separate (e.g. 1-2 and 7-8).
But one day, someone was on drugs and decided to use 1-2 and 3-6 for data.
The way it SHOULD have been done was to have every port TX on 1-2 and RX on 7-8 for the full duplex stuff. Then the cables would ALL be wired such that 1-2 on one end went to 7-8 on the other end and visa versa. Then it would b, with respect to 1-2 and 7-8, equivalent to what we today call a crossover cable. But all device ports would be alike and everything could talk to everything over a single common cable type. Do the same with 3-4 and 5-6 and you'd have 2 such paths.
In the end, what will work is doing ping-pong over 4 parallel data paths paired 1-2, 3-6, 4-5, and 7-8. But that's makes a more expensive port.
The whole point I'm ranting about is to keep things flexible. They did somewhat badly with twisted pair eithernet. We survived because there was a workaround (crossover cables and upstream ports). Wireless seems to have done worse (but I'm not going to go buy 802.11 docs just to see every detail they did wrong since I can't go back and fix it for them).
If _every_ wireless bridge is supposed to be able to talk to _every_ wireless bridge, then why not put the router logic interface inside a bridge device, as one single unit? The "router" "box" would have its own internal interface to the bridged/switched segment.
|>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.
But I would not use existance of authenticating at lowest layers as an excuse to not authenticate at higher layers as well.
|>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.
When I've made BNCs for radio work, they get well constructed. But it also takes a lot of time. Businesses don't seem to like that. Back when I was doing coax networks, buying cable with connectors already attached was so much simpler, faster, and in the long run cheaper. Same even for CAT5, though finding the lengths you need in crossover tends to be a problem.
|>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.
They do work to that level and a bit beyond if manufacturered well. Cheap import connectors with poor dimensional tolerance that don't fit real tight are a different matter.
|>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.
I say go with a pair of SMA, SMB, or SMC microwave connectors.
|>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.
This is why standards committees should NEVER allow commercial representation.
I once designed my own modulation scheme. It was similar to QAM but it used a hexagonal lattice instead of quadrature. Then the points were chosen within a circle, not a square. The number of points was not a power of two, but that was used to an advantage to define an "out of band" method of idling and syncing. But I could never make an implementation in a chip. I had read somewhere something similar was tried once, but that the hexagonal lattice was too complicated for the engineers. I thought it was the simplest part. I did this back in the early 1980's with digital TV in mind. Maybe today it could be practical. But patent holders of other technologies would not let it get standardized.
|>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.
If you were going to have bi-directional on one pair, don't cross. That's what POTS did. But if you were going to do split direction over two pairs, such as T1, then you needed to cross. When looking at it as a T1 issue, it wouldn't be obvious because T1 wasn't the kind of thing you'd be wiring a zillion devices in a computer room with. But ethernet was.
And the fact that ethernet was using 3-6 really threw a wrench into the works because ethernet needed crossing side to side but POTS did not. Had ethernet been on 1-2 and 7-8 it would have been a bit simpler. But I'd rather have had separate cables for POTS from data.
|>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?
There was an attempt to make a tiny version of them. If it could have been done somewhere between TNC and SMA size, it would have its uses. But there are many cases where I'd rather screw something on or at least nut-lock it on (e.g. BNC). I once tried to work out a nut-lock version of GR-874. That was going to be a manufacturing problem, though.
|>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.
Differential even rules for power, too. See article 647 of the National Electrical Code. 120 volts achieved by +60 and -60 volts relative to ground (of course the + and - reversing 60 times a second). Much less ground loop noise for audio equipment, and such. Fortunately a lot of stuff actually works at 240 volts, so where "balanced power" is needed, it can often be had cheaper with a 240 volt circuit wired USA style (the Europeans usually have 230 volts line-to-ground, so they can't get this).
| Ooops.... late again.
That seems to happen a lot.