Range of BEFW11S4 version 1 vs. version 4

Anyone know if there is any range difference between the original
version 1 of BEFW11S4 and the final version, version 4?

MY 4+ year old version 1 with power booster had become increasingly
unreliable, requiring resetting multiple times a day due to dropped
connections. Just got a replacement, a version 4. Why not a G model,
you might ask? The replacement was $4.99 so the price was right. Also
I have the power output booster if necessary.

Initially set it up with out the old power booster and it seems to
provide similar readings on my wife's laptop two rooms and 3 walls away.

Bob

"Bob Alston" <(E-Mail Removed)> wrote in message
news:Jvume.8828$7p.8025@fed1read06...
> Anyone know if there is any range difference between the original version
> 1 of BEFW11S4 and the final version, version 4?
>
> MY 4+ year old version 1 with power booster had become increasingly
> unreliable, requiring resetting multiple times a day due to dropped
> connections. Just got a replacement, a version 4. Why not a G model, you
> might ask? The replacement was $4.99 so the price was right. Also I have
> the power output booster if necessary.
>
> Initially set it up with out the old power booster and it seems to provide
> similar readings on my wife's laptop two rooms and 3 walls away.

Wait a minute, you mean to tell me that I could have gotten a replacement
for the 11S4 v1 router that I tossed in the trash?

Duane

On Sun, 29 May 2005 21:03:32 -0500, Bob Alston
<(E-Mail Removed)> wrote:

>Anyone know if there is any range difference between the original
>version 1 of BEFW11S4 and the final version, version 4?

Dunno. The chipsets are radically difference. Punch in the FCCID
numbers into the FCCID web site and see what's inside:
https://gullfoss2.fcc.gov/prod/oet/c...ericSearch.cfm
V4 version:
| https://gullfoss2.fcc.gov/prod/oet/cf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout =500&calledFromFrame=N&application_id=524657&fcc_i d='PKW-BEFW11S4V4'
I couldn't find the V1 version.

I vaguely recall reading one complaint in this newsgroup about a
version 1 unit that just quit for no obvious reason.

>MY 4+ year old version 1 with power booster had become increasingly
>unreliable, requiring resetting multiple times a day due to dropped
>connections. Just got a replacement, a version 4. Why not a G model,
>you might ask? The replacement was $4.99 so the price was right.

I have a BEFW11S4v4. $5 is a great price. Try running the router
exploits test at:
http://www.pcflank.com/exploits.htm
Mine hangs on 2 of the tests. I forgot which ones.

>Also
>I have the power output booster if necessary.
>
>Initially set it up with out the old power booster and it seems to
>provide similar readings on my wife's laptop two rooms and 3 walls away.

I suggest you lose the power booster. The problem is that you've
built an alligator. That's an access point with a big mouth and small
ears. The whole neighborhood will hear your transmit signal, while
your receiver remains essentially unchanged and cannot hear low power
client radios at the same distances. If you're going to use a power
amp, you really should have equal power output at both ends of a link
to insure symmetrical ranges. Otherwise, your power boosted signal is
just another source of interference.

Also, going through 3 walls is somewhat of a crap shoot. You will
probably get a connection, but it probably won't stay reliably
connected. Perhaps you would be better off with a 2nd access point at
the other end of the house (with a CAT5 cable in between).


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558

On Sun, 29 May 2005 20:22:11 -0700, in alt.internet.wireless , Jeff
Liebermann <(E-Mail Removed)> wrote:

>Try running the router exploits test at:
> http://www.pcflank.com/exploits.htm

Whoever wrote these tests has some problems with correctly identifying
IPs. They're using http which is famous for being a poor method, as it
won't work if your ISP uses a web proxy or cache.

>Mine hangs on 2 of the tests. I forgot which ones.

Mine can't even be tested, due to the above flaw in the design of the
tests.


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

On Mon, 30 May 2005 11:59:12 +0100, Mark McIntyre
<(E-Mail Removed)> wrote:

>On Sun, 29 May 2005 20:22:11 -0700, in alt.internet.wireless , Jeff
>Liebermann <(E-Mail Removed)> wrote:
>
>>Try running the router exploits test at:
>> http://www.pcflank.com/exploits.htm
>
>Whoever wrote these tests has some problems with correctly identifying
>IPs. They're using http which is famous for being a poor method, as it
>won't work if your ISP uses a web proxy or cache.
>
>>Mine hangs on 2 of the tests. I forgot which ones.
>
>Mine can't even be tested, due to the above flaw in the design of the
>tests.

There's no fix. The way a (SOCKS) proxy server works is that it
regenerates the connection. That makes everything on the internet
side appear as if it's coming from the proxy server instead of from
your home router. Same with web accelerator cache servers and
anonymizers.
http://www.web-caching.com/proxy-caches.html
The problem is similar to what happens if you install 2 or more NAT
routers in series. The test server on the internet will only see the
last router. Incidentally, this is common with WISP (wireless ISP)
service where the ISP doesn't want to deliver routeable IP's to the
clients and uses RFC-1918 non-routeable IP's instead. Running the
test only tests the ISP's firewall, not the clients.

Incidentally, one the early online web accelerator cache services and
ran into a problem. When one of their customers abused some other
system, and ended up on a blacklist, the IP address listed on the
blacklist was that of the web accelerator proxy server, and not that
of the customer. Suddenly, everyone using the system found themselves
banned from that system.


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558

On Mon, 30 May 2005 09:22:52 -0700, in alt.internet.wireless , Jeff
Liebermann <(E-Mail Removed)> wrote:

>On Mon, 30 May 2005 11:59:12 +0100, Mark McIntyre
><(E-Mail Removed)> wrote:
>
>>Whoever wrote these tests has some problems with correctly identifying
>>IPs. They're using http which is famous for being a poor method, as it
>>won't work if your ISP uses a web proxy or cache.
>
>There's no fix.

You're incorrect. Many sites can correctly identify my IP, by not
using http packets as the detection protocol. What you're missing is
that web caching / proxying is generally limited to only the web
ports.


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

On Mon, 30 May 2005 23:44:02 +0100, Mark McIntyre
<(E-Mail Removed)> wrote:

>On Mon, 30 May 2005 09:22:52 -0700, in alt.internet.wireless , Jeff
>Liebermann <(E-Mail Removed)> wrote:
>
>>On Mon, 30 May 2005 11:59:12 +0100, Mark McIntyre
>><(E-Mail Removed)> wrote:
>>
>>>Whoever wrote these tests has some problems with correctly identifying
>>>IPs. They're using http which is famous for being a poor method, as it
>>>won't work if your ISP uses a web proxy or cache.
>>
>>There's no fix.

>You're incorrect.

Naw, I never make mistakes (that I can't cover up).

>Many sites can correctly identify my IP, by not
>using http packets as the detection protocol. What you're missing is
>that web caching / proxying is generally limited to only the web
>ports.

Well, the usual method is using the CGI environment variables on the
web server to disclose the IP address the client. I scribbled some
scripts 10 years ago to do this while I was engaged in a heroic and
futile effort to learn web design and programming:
http://www.LearnByDestroying.com/crud/test.htm

Y'er right that internet web caches and proxy accelerators are usually
limited to port 80. However, proxy servers come in all shapes and
configurations which are normally configured for a set of "allowed"
ports. These are common in a corporate environment. I've configured
a few of these and have to install a configuration record for every
possible outgoing port number that is allowed.

I can see how one could obtain the IP at the user end using an ActiveX
control or some program that spys on the local system and returns the
necessary information. I wasn't aware that it could be done from a
simple internet web server. Is there some trick I'm missing? Do you
know a web page that does report the IP address of a client behind a
proxy server that I can try (and disect)? I'm curious to see how it's
done. This became an issue many years ago when some of the cable
companies were sniffing traffic trying to determine how many client
computahs were hidden behind an NAT firewall or proxy server so they
could charge for the "extra" clients.


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558