Thanks for your pointers Al .. and to Will Honea for his assurance on reset
techniques!
Al, your post started me down the trail to fix all this. I have found the
errors, been able to do the entire complete resetup and configuration, totally
with OS/2 on my R40 ThinkPad, eSeamonkey latest and Unzip to handle one
firmware refresh file from the Linksys site.
You said:
>For what it is worth, I'd check to make sure that the local IP address
>assigned to your thinkpad(s) is in the subnet compatible with the local
>bridge address. i.e. It would be possible for the bridge to be passing
>the DCHP address requests up the line and your thinkpad getting back an
>address like 192.168.37.123 subnet 255.255.255.0 (or even a 172.x.x.x or
>10.... and an appropriate subnet mask) and thus the direct addressing to
>the standalone wireless bridge at 192.168.1.x subnet would be incompatible.
>In which case, you could hard code your IP address back to the 192.168.1.x
>255.255.255.0 subnet to allow you to connect locally to the bridge and
>change its settings ... such as putting it onto the subnet the DHCP server
>is providing, changing encryption keys, etc... then resetting your IP
>address back to getting a DHCP address and thus both your thinkpad(s) and
>the bridge are on the same subnet and can be accessed at the same time.
That pointed me to the research to fix this. Here are the facts. When the
older IP provider COX sold out to Suddenlink, I had all the fixed IP address
and my ZyXel 334 router tied to the cable modem all fixed for whatever. But I
also have several DHCP cable modem connection ports as well for whatever. One
of them was originally set up with the Linksys WRT54GL wireless router as a
WEP encrypted WiFi system here that worked fine. It connected to the research
WiFi user interface through a Linksys WET54G wireless bridge just fine. I
originally chose, installed and used the WET secured protocol.
I could either use the Linksys WET54G bridge solo to one computer over the
standard OS/2 LAN port or could use it for multiple computers by passing the
Internet output through an appropriately wire configured cable to a Linksys
SD205 10/100 dumb switch. But after my IP switch was made, suddenly, although
I could connect to my private WiFi setup which seemed fine, I could not obtain
any sort of stable DNS service with any Browser. I could, however, handle my
private IP based FTP server connections, as well as all my ZOC enabled TelNet
connections just fine! With no evidence of anything 'wrong' from any
Adminstrative help or trace operation, and a complete OS/2 Ping capability
showing solid connections to everything needed for any number of DNS servers,
either the one's wanted for Suddenlink or external. What to do?
Curious, I reset the WET54G bridge to one of the numerous 'public' unsecured
WiFi installations around me. This is Aggieland at Texas A&M and, sadly, as
expected, there are TONS of totally unsecured 'Linksys' WRT54G whatever
wireless routers everywhere. I then asked for and got a firm DHCP reset
assignment, POOF! total success for the DNS resolution as well as whatever!
That pointed squarely toward what you broadly outlined above.
Answer: Total reset of the entire WRT54GL router, connections to the cable
system, and most importantly .. you *MUST* reset the MAC address portion of
the setup process in the WRT54GL router. As well, from connections to the
Linksys support site, I was able to download and install the two firmware
updates for both my units. In the case of the WET54G wireless bridge, the
Linksys firmware update file is in a .ZIP package. I had to use Unzip to get
the file. Opening the WET54G setup program with Seamonkey via the default
192.168.1.226 address and starting the 'firmware' update with the browsed
location for that file produced at good update for the bridge. In the case
of the WRT54GL router and WiFi generator, the firmware update file is discrete
and you can simply use the firmware update tabs created from the 'standard'
192.168.1.1 router administrative address with Seamonkey, use the browsed
location on the OS/2 system file area, for the update. Perfect update.
Setting up all this with OS/2 and no form of Windows operations, with nothing
other than Seamonkey and private network URL's does work fine with the Linksys
units. However, here is the tricky part some people will either have to
discover the hard way or need to note! Experienced OS/2 networking folk
realize the OS/2 networking has to be present and the LAN operation must be
running in order to use Seamonkey, whatever, to communicate with the
192.168.1.1 router or 192,168.1.226 Linksys setup interfaces. But what isn't
often realized, for folks who are using startup DCHP addressing for the LAN,
is that you have to be connected to SOMETHING which will give you a discrete
private address for the LAN you want to use with Seamonkey BEFORE you can
connect to the router or the bridge! Yes,, this is boring to some folks here
I'm sure.
Thus, the only way, as far as I know, with OS/2 and PEER networking and DCHP
to do the setup, is that you must use the Linksys ROUTER to get started with
DCHP first! It will do that genericly. Once you have been assigned a private
address by the router, then comes the tricky part! You then, with the router
plugged into the LAN port on your computer, get to see the 192.168.1.1 address
of the Linksys router to do the adminstrative part of the setup. Whatever you
need. Note, if you are using cable modem technology, it seems you will almost
surely have to use the MAC addressing enablement to get DNS operations cleared
from your cable IP through your cable modem connection!
Now comes the interesting part of the project! At that point, with your
private WiFi operation working from the WRT54GL product, you yank out the LAN
cable from it to the LAN port on your ThinkPad or whatever!
You then power up your WET54G wireless bridge. You hold down the reset putton
in the back until the lights stabilize some 10 plus seconds after it totally
resets. Thanks Will Honea ..
Then, you jam the connection cable from the WET54G wireless bridge into the
LAN port you just vacated on your Thinkpad or whatever. You do *NOT* mess
with DCHP and trying to fuss with your 'connection' to your LAN. Despite the
fact that your DCHP connection is broken by this act, you then simply open up
Seamonkey. You enter the 192.168.1.226 address for the setup port to the
WET54G wireless bridge. In that your LAN connection is 'still there' for the
OS/2 unit and 'working', you will get to see the adminstrative setup program
for the wireless bridge.
At that point, you enter the required names for whatever is needed. You then
run the SEARCH function for the wireless bridge. You pick your WiFi
connection needed, as well as setting up whatever is needed for an encrypted
secured connection you may have chosen in the router-transmitter unit. You
accept the settings for the bridge, It will connect ot your Wifi. But wait!
don't forget!
At this point, what you have still in use, the 'not-connected DHCP address for
the old hard wired router LAN connect', is *NOT* acceptable for use with the
wireless bridge use! You will then have to use the DHCP monitor out of the
OS/2 Setup folder to release the old connection, which it will tell you isn't
there. You then use the DHCP monitor object to reconnect to your 'network'
while connected to the wireless bridge. If you haven't made any errors, you
will be assigned a new connection via the bridge to the router-transmitter.
For someone routinely using a wireless bridge to mess with WiFi sites, I'd
think it is obvious you'd want a shadow of the DHCP monitor object up there on
your WPS bar. I do.
And, you'll be connected to the internet via your new WiFi operation. Which
will be able to handle all the DNS operations that .. earlier .. you might
have seen and even pinged, but couldn't use! Except for some curious sites
which might work, yet most don't.
Just remember. The trick to all this with OS/2 and just a browser, is to make
sure you have a LAN operation going fine from SOME source of a private address
on the box you are using for configuration. Then using that 'ghost' yet no
longer connected hard cable established LAN session, use it to get to the
wireless bridge to configure it. After which you must reset your DCHP
assignment, or reboot the box to connect through the bridge to get to see and
actually USE the DNS operations. Including the entire Privoxy latest 3.5
proxy operations for OS/2 and Seamonkey. This all works just fine over these
Linksys tools. Yes, there are other ways to do this with 'hard addressing'
for your TCP/IP local setup operations. But if you are moving around from one
location for another and constantly using DHCP assigned private addresses,
this is the easy (?) way to do the configuration setup. Which will work even
for hot spot whatevers, should you be so inclined to spill coffee into your
keybaord, grin. Without a wireless chip set in your OS/2 whatever box(let).
I have no idea at all if the non-Linux Linksys units will work this way or
not. As well, I have no idea if any of this will work on something like the
USB ZyXel pen plug in WiFi finder gadget. I've got one but haven't tried to
set it up genericly yet to test whatever. Your call! All I'm trying to do
here is help people.
Mike Luther
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This message is sent to you because you are subscribed to
the mailing list <os2-wireless_users@2rosenthals.com>.
To unsubscribe, E-mail to: <os2-wireless_users-off@2rosenthals.com>
To switch to the DIGEST mode, E-mail to <os2-wireless_users-digest@2rosenthals.com>
To switch to the INDEX mode, E-mail to <os2-wireless_users-index@2rosenthals.com>
Send administrative queries to <os2-wireless_users-request@2rosenthals.com>
To subscribe (new addresses), E-mail to: <os2-wireless_users-on@2rosenthals.com> and reply to the confirmation email.
Web archives are publicly available at: http://lists.2rosenthals.com
This list is hosted by Rosenthal & Rosenthal, LLC
P.O. Box 281, Deer Park, NY 11729-0281. Non-
electronic communications related to content
contained in these messages should be directed
to the above address. (CAN-SPAM Act of 2003)
retour à la liste