Senao sailboat use challenges update

On 8 Aug 2006 10:58:03 -0700, "Skip - Working on the boat" wrote in :

The IP conflict should be avoidable.

(...)

Oh-oh.

That which is most obviously correct, beyond any need of checking, is the problem.

This is the first time you mentioned that you were using an SSID=ANY on the client. This is a big problem with some client radios. What happens is that SSID=ANY seems to mean: Pick the first available connection. If the signal drops for any reason, go on to the next available connection. That's not the official explanation of how it is suppose to work, but that's what I found while tinkering with a WRT54G with DD-WRT in client mode. It just will NOT stay connected to a specific SSID when set to ANY.

Also, if you want to create some real havoc, set the SSID of a wireless access point to ANY. If you set the client connection SSID=ANY, the piece of junk connects and disconnects at about 10 second intervals. I think that was a BEFW11s4v4 and a WET11 that was doing that. Lots of fun watching it thrash.

Good luck, have fun, and forget about using SSID=ANY.

Hi, Guys,

Well, between you, there seems to be direct disagreement.

On the one hand, "there shouldn't be any IP conflict" -- yet, that's what killed all attempts to merely communicate, before.

On the other, we have Jeff's somewhat more erudite reasoning/explanation of why I got clashes.

Is it that Windoze is calling clashes IP conflicts when it's really not that problem, but they label it that way so as not to confuse the hoi polloi?

And, regardless of labeling (we already know I'm clueless, so I'll not apologize for not being able to come up with the right terminology, if that's what's at root of the differences between all of us), is it, in fact, possible to set an AP and a bridge on the same netclass, have the bridge scanning for open sites (and exclude, somehow, my AP right next to it or 60 feet away belowdecks, perhaps), and not have conflicts?

Much more importantly to me, is it possible for *any* setup to allow me to use a configuration tool to see, and select from, available APs without having to do the manual resetting/configuration of some unit, whether by wifi or ethernet cable, as is the case now (understanding that I'm so thrilled with the end result that doing so is now a minor inconvenience)?

And, finally, now that the concept has ultimately been proven after months of failures, even from (another forum) having someone who'd had multiple dual-2611 setups (in a different environment but electronically similar to mine) not be able to resolve the conflict issue - other than to, also, suggest the insertion of a router (I'm guessing he had his tied to a specific SSID, negating my problem) - I'm willing to go afield. What would you suggest for a replacement to the bridge which would both be a better piece of kit, as well as not have the b-g issue? Having a bit of voice training would be nice (not an opera singer, just a good vocalist - say, 200mw) to help get to shore; the antenna seems to be adequate already...

I'm (reasonably) sure having an 'a' unit is of little to no value, as there's no time I'll need that kind of throughput, and any organization/gamer who needed it likely would have it encrypted, anyway, but we've had direct illustration of why a g is valuable. Given that the Vonage unit has to plug its ethernet into *something* I'll likely have to have it between whatever bridge and the ap, anyway, and likely have it downstairs, so that's not an issue. I have the appropriate length crossover and standard cables.

Thanks again for bearing with my naivet=E9 in all these areas. It's been quite a ride, but I can tell you for sure, after having been on a donkey for all this time, it's great to be on a gaited thoroughbread.

L8R

Skip, off for varnishing supplies

"Skip - Working on the boat" hath wroth:

No. It's an explanation as to why you couldn't reliably connect and stay connected. No IP's involved.

No. Please print out the following in 72 point type and plaster it on the wall before your computer: "ALL WIRELESS IS BRIDGING, NOT ROUTING" What this means is that at the bridging level, there are no IP addresses involved. In your case, if you can't get reliable bridging, then the IP addresses that sit on top of the bridging layer aren't going to work reliably. I don't wanna hear about anything on the IP layer until you have the bridging layer (MAC layer) stabilized.

That's a judgment call so I'll suggest that it is not possible when using SSID=ANY. Your wireless client will opportunistically hop from access point to access point at the slightest provocation and will not remain connected to any specific access point because you didn't specify a specific access point when you use SSID=ANY.

I read this to ask: "Can I connect to a specific access point without first manually specifying what to connect to?" Maybe, if you can find a wireless client bridge that allows connection by MAC address instead of SSID. You would need to supply it with a pre-approved list of acceptable MAC addresses for all the harbors you visit. I don't know of any such magic devices offhand. Using the limitations of existing hardware, the answer is "no", you can't.

Put differently, what you're asking for the wireless client to do is sail into a random and unknown harbor, and somehow be able to guess which SSID you want to connect. Sorry, but without artificial intelligence or a Ouija Board, it's not going to happen. You have to somehow tell it which SSID to connect with. Perhaps if all the harbor access points had the same SSID, but not when they're almost random.

No and you generally do not want to do this. You should not just assume you can connect to any random open SSID you might happen to run across. Yes, it's often considered reasonable to "trespass lightly" on someone else's wifi connection. But there are a growing number of situations where folks have gotten themselves into trouble doing this. Granted, most of those cases seem to have other circumstances involved, but it's something to consider.

Let's say you run into two available SSIDs, both at the "same" signal/noise strength. One's clearly labelled as the SSID for the nearby municipal or other 'free' hotspot. The other's a network within a private company/residence, one hellbent on prosecuting people it catches stealing it's bandwidth. Wouldn't you rather avoid the trouble and use the one that's reasonably likely to be free from trouble? Letting the device make the choice isn't going to be as intelligent. Granted, the label shown in the SSID might be completely unrelated to the source, or even deliberately mislabelled as such. Some hacker could configure their device with the same label and then deliberately scan the packets, stealing usernames, passwords and the like.

Not to mention the hassles of hopping from one to another as the boat swings about. While it'd sure be convenient if the devices could be smart enough to do this "automagically" I've not come across any I'd trust to do this (yet).

In some of my testing I'm leaning toward building a GPS lat/long database of SSID's I've seen and correlating them as to which are suitable or not. That way if I'm back in a given area the device might be able to make an automagic connection based on previous knowledge. This isn't without it's hassles though. Shore connection labels or MAC addresses might change so I'd still be back to doing it manually. As it stands now it's not all that hard to fire up my browser and select a bookmark for the 'Site Survey' web page on the router. As things move forward I'm considering making a PC client program to use from the system tray. But it'd be tied to a specific type of router (in my case, WRT54's using dd-wrt).

Yes, b/g is great. Having 802.11a seems like a waste given it's rather poor market penetration. One might also consider 802.11n devices but they've not yet reached final standard yet. I'm guessing 802.11g will be more than sufficient most of the time.

Yes, shore-link wifi to the vonage unit and through that to the on-boat device(s). You generally should always have a VoIP device on the first connection to the uplink. This to allow the VoIP device to manage the limited bandwidth for calls. You "could" bring the shore-link device's wired connection to a multiport switch and plug everything else into that. But by doing so you're not letting the VoIP device grab as much bandwidth as it needs to maintain a good quality connection.

Frankly a VoIP device on the boat is unlikely to work reliably. For several reasons. One being that you'd be connected behind the shore's router. Most VoIP services need a direct IP address, not one behind a router. Since you have no control over the shore devices the VoIP device won't have a direct address.

Skype isn't VoIP and doesn't share the same issues as the client makes it's own outbound connections. VoIP devices do not, they sit waiting for an inbound connection and since the onshore router isn't configured to pass such things it won't work. It might work for outbound calls but very unlikely for anything inbound. Use Skype with SkypeOut minutes instead, the call quality's likely to be better anyway.

-Bill Kearney

NetworkManager (linux) uses a simpler method. If you've ever manually connected to a network, when it finds that network again it will try to use it.

On 9 Aug 2006 04:52:14 -0700, "Skip - Working on the boat" wrote in :

There really isn't -- Jeff and I disagree from time to time on fine details and perspectives, but not on basic facts.

What I actually wrote was quite different:

"The IP conflict should be avoidable."

What was implied: "If the hardware is configured properly."

I've frankly had a great deal of difficulty following all your attempts (and have been frustrated by your not following suggestions), but I've nonetheless seen some obvious problems.

Jeff commented on SSID issues, not IP address issues.

Windows reports of IP address clashes are real conflicts detected at the network level, not something else.

As I wrote, IP conflict should be avoidable. I say that with confidence because I've set this kind of thing up successfully many times. Unfortunately, you haven't provided the kind of sufficiently detailed and accurate information that I need to figure out what's wrong in your case. (As a result, I've spent far more time and effort getting nowhere than it would normally take to fix the problem, which is frustrating.)

That depends on the client bridge. If it can do that, then yes you can. What you need is a reliable way of communicating with the client bridge:

1. You don't want the client bridge being configured by DHCP, since the address might well change. You need to configure it manually at an address that won't conflict with anything else. A good choice for this purpose is an address in the special auto-configuration range (that Windows uses when DHCP fails): 169.254.0.0/16
2. To reliably connect to the client bridge, you need an IP address in the same netblock. If you follow my advice above, that won't happen with DHCP. Switching IP configurations is fast and easy with a connection manager (see wikis below). If you don't want to do that, then you'll need a second Ethernet adapter with a manual IP address in the same netblock, since Windows doesn't seem to be able to handle dual homing of a single adapter with DHCP as one of the two configurations.

No offense intended and with all due respect, I don't think there was ever any real question that it could be made to work had you followed proper procedures. That's something to bear in mind when going afield.

Senao Wireless Outdoor Multi-Client Bridge/AP/WDS-NOC-3220

More power probably won't help. As Jeff Liebermann puts it, "This is commonly known as an alligator, which is an animal with a big mouth and small ears. The xmit amplified [radio] can be heard over a much larger area than it can hear the replies from the [other radios]. Unless the [other] radios have a similar power amplifier, the system [becomes] asymmetrical, with more range in one direction than the other."

I agree that "a" is of little or no value. "g" is as fast as or faster than "a".

A painful and expensive lesson.

Arrgggthhhh! You *don't* want a router "between" the client bridge and the access point! Hang both the Vonage router and the access point off a small hub or (better) switch *if* the Vonage router will work through another NAT. I'm guessing the NAT could be a problem, and that you'd be better off with a simple Vonage adapter (e.g., D-Link VTA).

If you want my help, no offense intended and with all due respect, you'll have to resist the apparently strong urge to experiment wildly on your own, not follow suggestions, and argue with those trying to help you.

Way down the priority list.

On Wed, 09 Aug 2006 06:59:22 -0700, Jeff Liebermann wrote in :

Amen!

On Wed, 9 Aug 2006 10:23:27 -0400, "Bill Kearney" wrote in :

The problem with putting the Vonage router "between" the client bridge and the access point is that all wireless computers are probably then on double NAT, which is a bad idea.

I agree.

On Wed, 09 Aug 2006 11:40:22 -0300, Derek Broughton wrote in :

Likewise Windows XP. But neither will work with a client bridge, as is the case here.

Not really all that bad. I've tried it. Thus far nearly everything I'm likely to want to use on the boat works just fine behind double NAT routes. I'm pleasantly surprised.

Granted, anything that needs direct inbound packets isn't going to work. But they wouldn't work on a straight connection to the shore link either. So having them behind an on-boat NAT router doesn't really make much difference.

On Fri, 11 Aug 2006 00:12:33 -0400, "Bill Kearney" wrote in :

Double NAT (as the phrase is used by NETGEAR) means connecting one router directly behind another for the purpose of having multiple LANs. Double NAT may cause problems with VPN and visiting secure sites with SSL.

Which it does not. I can readily connect from a laptop on the boat, to the on-boat SSID and it's subnet from the client-mode link to the shore. VPNs using PPTP, L2TP and IPsec have worked fine. As have several HTTPS websites, ssh terminal sessions and secured IMAP, SMTP and POP.

Actual experience, not just theory or vendor claptrap, shows it's been working quite well.

Now, there is the off-chance that the on-shore link won't pass whatever's necessary for anything other than HTTP traffic. Or is specifically configured not to pass VPNs. With that being the case it wouldn't matter how many layers of routing were involved.

-Bill Kearney

And also consider that if equipment fails, or they bring new devices online, the MAC addresses will change. So even if you traveled to a given set of ports on a regular basis you still wouldn't be able to rely on either the MAC or SSID information being consistent. It'd be /nice/ if that were possible but as yet it's not.

When using something with the dd-wrt firmware it's really a simple matter of bringing up the 'Site Survey' webpage on the router and selecting the SSID. Make this part of your arrival procedure.

-Bill Kearney

On Wed, 16 Aug 2006 08:42:41 -0400, "Bill Kearney" wrote in :

For you in the cases you've tried. I seen real problems in other cases. It's great that it's working for you, but that doesn't mean problems can't be real, so dismissing them that way is a disservice to others.