curious about how wireless to wired network bridges work

YES

the default ip address to this web

You can change the bridge's address to whatever you want once you are in the interface.

The address of the actual bridge is not the address the attached computer(s) will use, though it does have to be in the same subnet. If you don't give them static ip addresses, then they can get their addresses by DHCP from the central router that the bridge is connected to.

I don't know if you can actually run two computers through the bridge or not.

By the way, the cheaper way to do this is to use a router that can be set to serve as a client. The Buffalo WHR-G54S will do this and sells for under $50. Many others (Like the Linksys WRT54GL) can also do this if running aftermarket firmware like DD-WRT.

Items sold exclusively as client bridges cost more and do less.

Steve

"yawnmoth" hath wroth:

The absolute basics:

1. ALL wireless is bridging. Wireless knows nothing about IP addresses and routeing.
2. Basic wireless configuration consists SSID, encryption, and authentication. Everything else is set by the wireless access point. The bridge just follows.
3. A wireless client adapter is nothing but a marketing term for wireless bridge.
4. Bridges can be point to point or point to multipoint depending on configuration and topology.

Argh. You read the manual. I'll try to undo the damage.

The IP address for the WET54G is only used to configure the device. It has no real purpose in the operation of the bridge, which is all done on Layer 2 (MAC address layer) and not on Layer 3 (IP address layer).

Nothing happens. The IP addresses are handled by the corresponding wired or wireless router along with the IP stack in the connecting computah. The bridge does NOTHING with the IP addresses.

Again, the bridge does nothing. Other than the IP address required for configuration, the wireless bridge acts something like an ordinary CAT5 cable. It passes IP addresses unchanged. (Actually, that's not exactly true because a bridge only passes packets that have a destination MAC address on the other side of the bridge). However, at the IP address layer, a bridge looks like a cable.

No. The hub is just a repeater. It doesn't do NAT in any way. If you need a 2nd IP address on the LAN for a 2nd computah, it will need to be supplied by a router.

With NAT, the outside world sees exactly one IP address. That's you're routeable IP addresses and is the one that's reported by various internet sites the return your IP address:

One of many features inside your router is NAT (network address translation). If you happen to be reading Cisco literature, it's really PAT (port address translation). What NAT/PAT does it rewrite the IP header on the LAN (local area network) side by port number giving you multiple IP addresses on the LAN side. These addresses are assigned by another feature called DHCP (dynamic host confusion protocol).

Bottom line is that your questions about IP addresses are really handled by your router and that if you want multiple IP addresses, it cannot be done with just a wireless bridge or hub.

Reminder: Wireless is all bridging and does NOT involve IP addresses.

Hah! I love it ! Normaly, the reprimand is "RTFM" This is the alternate reprimand for those who actually did ! Between the two, all possible questioners are covered.

Cheers, Steve

"seaweedsteve" hath wroth:

Well, there's a bit of truth to my cynical attitude about manuals. I'll explain (whether you wanted it explained or not):

1. These daze, manuals are mostly legal disclaimers and wholesale repudiation of resposibility. They are also incomplete as the most important information is usually on a sticker plastered over the connectors or on a "read this first" loose document generally lost among the packing material.
2. Manuals only contain what to do, not how things work. If the user would take the time to understand how things work, they wouldn't need a manual as the proceedure would be fairly obvious. They also only cover the absolute basics, with many of the obscure settings remaining... well, obscure.
3. Manuals no longer contains a "Theory of Operation" section. This section is quite common in the better network device manuals, but is missing in consumer products.
4. The manual rarely follows the advances and feature additions in the firmware. It's often that the screenshot of a page does not resemble the actual page.
5. None of the manuals ever seem to mention that it's a good idea to check for firmware updates on the manufactory web pile. Those that do, don't bother to explain how to install the update. Those that explain how to install the update, don't bother to explain how to decode the revision numbers. Those that actually include all the aformentioned, don't bother to explain what to do when the firmware update goes wrong.
6. The troubleshooting section of most manuals are fairly crude and border on useless. None bother to suggest the ultimate troubleshooting proceedure, which it to punch the reset button and start over from scratch. They also never bother to suggest power cycleing the router if it seem to be hung or malfunctional.
7. The very simplicity of the manual implies that the device being configured is also quite simple. This is rarely the case. Ever notice that the devices with the fewest features have the biggest manuals?
8. Manuals rarely contain numbers such as the IP address of the router. This is intentional as the presentation of numbers, forumula, and RF theory, will cause the users brain to temporarily hang. It is the prime purpose of tech writers to remove all the numbers and useful information supplied by the engineers. However, if the manuals were written by engineers, nobody could understand them, so I guess this is a tolerable compromise.
9. The addition of foreign language translations has converted the English into something resembling a foreign language.
10. If there is a "help" section, there's often a question as to whom it was intended to help. I've suggested that manuals also include a "beyond help" section, but that has been consistantly vetoes by the tech writers as bad form and tactless.
11. There seems to be a presumption that if the product were any good, it wouldn't need a manual. This is largely true but has been misinterpreted by the manufacturers as the size of the manual determines the quality of the product, where smaller is better.
12. Manual writers are usually frustrated authors of fiction, who tend to be creative. This is not a good thing when dealing with technical terms designed to be specific. Every month, I see a new terms for common wireless devices.

I could go on and on, but it's Monday morning and the computah is ringing with yet another dull and inefficient VoIP conference call. (Hello? I can't hear you, can you hear me? Talk slower. What? Don't talk when I'm interrupting. Garble-garble. Turn off the video. Can you hear me now? Ad Nausium)

Reading manuals causes temporary brain damage. Writing manuals seems to make it permanent.

I agree! I read the manuals just in case there IS some useful information. There are sometimes gems of actual functional info buried in the mountains of noise and repetition. But it's usually all in the "set-up guide" as you say, and often comes down to a sentence or two that tells me something I actually need to know.

Hey! I always thought it was the um, anyway, now I know. I was a tech writer in Silicon valley for a brief stint in the late 80s. I liked it, but they weren't consumer products I wrote about. I think that I got it right explained and organized all the loose knowledge about that Rolm mark 7600 confabulator into a cohesive document.

But, of course, most people are hacks, don't have enough interest in what they do...

Sounds like VOIP on landlines (vs Satellite) is problematic too. I had imagined that it would work for normal broadband...

Steve

"seaweedsteve" hath wroth:

Yep. I just skim the docs for the numbers, URL's, and startup incantations to get me started. The rest is usually obvious.

I once wrote a manual for a direction finder for the USCG. One full page on how to turn it on. Another full page on how to turn it off. However, the manual turned out quite well because I was being coached by an experienced tech writer from HP. Among the various lessons, I learned something that seems to be lacking in most consumer manuals. If the manual gives instructions for the user to do something, the manual should also show what the expected result should be. For example, if one is expected to type in a MAC address, the screen dump should show a real MAC address and what it should look like.

I won't hold that against you. Not the tech writing part, but the part where you claimed to have enjoyed it. You can always recognize the experts in any field. They're the ones that do the job perfectly, and hate every minute of it because they've done it so often and for so long. Anyone who is still enjoying themselves, just hasn't done it often enough or long enough to become terminally disgusted and cynical. Incidentally, that's roughly why I've had 3 professions in my life and am considering a 4th.

Argh. Telco manuals are written in a foreign language. It may resemble English, but telco policy is to never use any terms found elsewhere in the electronics industry. That dates back to the daze of the first AT&T breakup (there will be more breakups as soon as the Democrats get into power), where the various Baby Bells did not want to be accused of getting into the computah business. It may look, act, run, and smell like a computah, but to the telco crowd, it's called a switch. At the time, it was certain death to anyone that offered to publish a list of translations. Hopefully, you've recovered from the experience.

It varies. I have customers that watch over my shoulder, take notes, ask good questions, and learn from the experience. I'm a frustrated instructor, so I tend to give a running commentary on what I'm doing. I often suspect they are interested because they don't want to pay me to fix it after they screw it up again, but I prefer to give my customers the benefit of the doubt. However, for most people, you're correct. They just want to plug and play without the learning experience. "Why can't this stuff be easier?" is the most common exhibition of frustration. I have various stock answers, but I never shove it in their face by mentioning that they don't spend the time to learn anything about their computers. Many of my customers entire business operations are based on the functioning of their computers, yet they treat them like it was some manner of fashion accessory. I don't complain, because they pay me, but an adjustment of priorities might be in order.

You're assuming that this was with a dedicated broadband connection, and not an office corporate LAN. The problem is never the computer or even the ISP. It's the local constipation and bottleneck caused by what the user or his accomplices across the office are doing at the time he's trying to make a VoIP phone call. I have QoS setup to give priority to G.711 and G.729 traffic on my systems. Many routers do not. The result is that someone on the same WLAN connection watching YouTube videos at the same time as the VoIP call will trash the call. Even the VoIP users are clueless and will be doing something else that will slow their computer down. For example, one person was having nothing but trouble with the 9AM conference call, but would be fine at any other time. When I rescheduled her computahs virus scan for some other time, call quality dramatically improved.