Thanks to John, Jeff, Lutful and others who've attempted to assist my
very unsuccessful attempts to remedy what seemed an intractible problem
in achieving a wireless solution.
As this is not a problem any more, and therefore of little interest,
I'll attempt brevity:
My network engineer son and I spend 5 hours in his office with
everything connected over ethernet, including my computer, his
computer, on which he monitored traffic, and the AP and Bridge units.
The problem was in the bridge which, when it was in "any" (no specified
SSID) mode would see the AP in the same class (had to be or could not
configure the bridge wirelessly through the AP), and immediately clash
with it. If one wired the bridge, configured to a specified SSID other
than the AP it connected to when put back, there was no conflict.
It required a router in between to allow them on different classes to
talk to each other. That the router just happened to be my (very
limited router) Vonage phone unit was a bonus: I am also on the phone
as though it were home.
The b vs g discussion is presumed to be the reason I could not reach
the station I'd been associating with the Hawking USB adapter; a newer
bridge might do better for me, though I rather like the 200mw this one
has. Perhaps there's a web interface configurable bridge with b/g and
200 or more mw someone would like to recommend? Actually, of course,
I'd prefer being able to point and click as I can with either the
windows zero or Hawking configuration tools I have, but as I will
always need to associate with my AP ("boatAP"), that probably won't
happen.
So, while I have to keep the Vonage unit aboard (vs up the mast) in
order to run my phone line more effectively, and the Senao unit still
requires NIC interface (unplug from the Vonage router) in order to
configure in a new port, this is a workable solution. I'll be
exploring POE next.
All the prior thrashing around was a product of the b vs g for the
local station difficulties, and the 'any' ssid configuration being
overwhelmed with my ap connected to it for the IP conflict.
Again, thanks to all who have attempted assistance in my travails.
L8R
Skip and Lydia, aboard, packing, almost ready to splash
On 8 Aug 2006 10:58:03 -0700, "Skip - Working on the boat"
<SkipGundlach@gmail.com> wrote in
<1155059883.485683.125200@m79g2000cwm.googlegroups .com>:
>Thanks to John, Jeff, Lutful and others who've attempted to assist my
>very unsuccessful attempts to remedy what seemed an intractible problem
>in achieving a wireless solution.
>
>As this is not a problem any more, and therefore of little interest,
>I'll attempt brevity:
>
>My network engineer son and I spend 5 hours in his office with
>everything connected over ethernet, including my computer, his
>computer, on which he monitored traffic, and the AP and Bridge units.
>
>The problem was in the bridge which, when it was in "any" (no specified
>SSID) mode would see the AP in the same class (had to be or could not
>configure the bridge wirelessly through the AP), and immediately clash
>with it. If one wired the bridge, configured to a specified SSID other
>than the AP it connected to when put back, there was no conflict.
>
>It required a router in between to allow them on different classes to
>talk to each other. That the router just happened to be my (very
>limited router) Vonage phone unit was a bonus: I am also on the phone
>as though it were home.
>
>The b vs g discussion is presumed to be the reason I could not reach
>the station I'd been associating with the Hawking USB adapter; a newer
>bridge might do better for me, though I rather like the 200mw this one
>has. Perhaps there's a web interface configurable bridge with b/g and
>200 or more mw someone would like to recommend? Actually, of course,
>I'd prefer being able to point and click as I can with either the
>windows zero or Hawking configuration tools I have, but as I will
>always need to associate with my AP ("boatAP"), that probably won't
>happen.
>
>So, while I have to keep the Vonage unit aboard (vs up the mast) in
>order to run my phone line more effectively, and the Senao unit still
>requires NIC interface (unplug from the Vonage router) in order to
>configure in a new port, this is a workable solution. I'll be
>exploring POE next.
>
>All the prior thrashing around was a product of the b vs g for the
>local station difficulties, and the 'any' ssid configuration being
>overwhelmed with my ap connected to it for the IP conflict.
>
>Again, thanks to all who have attempted assistance in my travails.
The IP conflict should be avoidable.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
On 8 Aug 2006 10:58:03 -0700, "Skip - Working on the boat"
<SkipGundlach@gmail.com> wrote:
>The problem was in the bridge which, when it was in "any" (no specified
>SSID) mode would see the AP in the same class (had to be or could not
>configure the bridge wirelessly through the AP), and immediately clash
>with it.
(...)
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.
>Skip and Lydia, aboard, packing, almost ready to splash
Good luck, have fun, and forget about using SSID=ANY.
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é 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.
"Skip - Working on the boat" <SkipGundlach@gmail.com> hath wroth:
>On the other, we have Jeff's somewhat more erudite
>reasoning/explanation of why I got clashes.
No. It's an explanation as to why you couldn't reliably connect and
stay connected. No IP's involved.
>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?
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.
>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?
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.
>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)?
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.
> 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)?
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).
> I'm (reasonably) sure having an 'a' unit is of little to no value,
....
> but we've had direct illustration of why a g is valuable.
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.
> 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.
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.
> 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.
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.
--
derek
On 9 Aug 2006 04:52:14 -0700, "Skip - Working on the boat"
<SkipGundlach@gmail.com> wrote in
<1155124334.440405.73680@75g2000cwc.googlegroups.c om>:
>Hi, Guys,
>
>Well, between you, there seems to be direct disagreement.
There really isn't -- Jeff and I disagree from time to time on fine
details and perspectives, but not on basic facts.
>On the one hand, "there shouldn't be any IP conflict" -- yet, that's
>what killed all attempts to merely communicate, before.
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.
>On the other, we have Jeff's somewhat more erudite
>reasoning/explanation of why I got clashes.
Jeff commented on SSID issues, not IP address issues.
>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?
Windows reports of IP address clashes are real conflicts detected at the
network level, not something else.
>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?
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.)
>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)?
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.
>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.
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.
>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...
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'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,
I agree that "a" is of little or no value. "g" is as fast as or faster
than "a".
>but we've had direct illustration of why a g is valuable.
A painful and expensive lesson.
>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.
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.
>I have the
>appropriate length crossover and standard cables.
Way down the priority list.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
On Wed, 09 Aug 2006 06:59:22 -0700, Jeff Liebermann
<jeffl@comix.santa-cruz.ca.us> wrote in
<7npjd290e64bo0ke3vr804gsmmrfsf6m10@4ax.com>:
>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.
Amen!
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
On Wed, 9 Aug 2006 10:23:27 -0400, "Bill Kearney"
<wkearney99@hotmail.com> wrote in
<AsKdnab5YvN9ckTZnZ2dnUVZ_sOdnZ2d@speakeasy.net> :
>> 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.
>
>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.
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.
>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.
I agree.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
On Wed, 09 Aug 2006 11:40:22 -0300, Derek Broughton
<news@pointerstop.ca> wrote in <mn8pq3-1qp.ln1@news.pointerstop.ca>:
>Bill Kearney wrote:
>
>> 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.
>
>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.
Likewise Windows XP. But neither will work with a client bridge, as is
the case here.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
> 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.
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"
<wkearney99@hotmail.com> wrote in
<6J-dnYEd2YcvnkHZnZ2dnUVZ_v6dnZ2d@speakeasy.net>:
>> 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.
>
>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.
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.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
> 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.
> 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.
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.
On Wed, 16 Aug 2006 08:42:41 -0400, "Bill Kearney"
<wkearney99@hotmail.com> wrote in
<QeKdnZhggLFfj37ZnZ2dnUVZ_u2dnZ2d@speakeasy.net> :
>> 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.
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.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
Senao sailboat use challenges update 
Linear Mode
