Jim,

Jim Showalter wrote:

I just installed the 2.02 version, but I still have the IP disabled problem. I have "Configure automatically using DHCP". Was this fixed in 2.02? (IBMPRISM driver.)

Let me put it this way: definitely one reason for this problem was fixed. It is very likely that there exists another reason on your system for that symptom. In the next week a user will show up with his notebook at my place that is using the same driver (I don't have such a card, so I can't test it alone). On WarpstockEurope in Desden last weekend we tested it with V1.20 and it worked just fine (is that true for your system as well?), but with V2.00 it didn't. (Just would like to mention: as V2.xx does not bring any imporvement for users of GenPrism style drivers - such as IBMPRISM - you can safely revert to XWLAN V1.20 until the current problem is solved).

As we unfortunately had no CVS access to netlabs.org (only http and https available), I could not create a debug build of the old version over there, so I could only debug V2.00, and still have no clue why V2.00 would fail and V1.20 would work. From my debug session with this hardware I can only say that the few values being passed to the driver and received from it make absolutely sense and are identical to those being sent from XWLAN to the GenPrism driver for my Artem card - and this one works perfectly. Hopefully the next debug session will be more successful.

Then the commands are executed automatically when wifi is connected or disconnected. In every case I see no reason to clear setup.cmd, instead only all config for the wifi interface should be left out of it (anyway) and then setup.cmd could be called on Wifi disconnect event to reset to the "cabled configuration". The config commands would be included into the XWLAN script within the connect event.

So you would switch between cabled and wireless just by changing between a dummy profile "cabled" which would connect to a nonexistant access point and fail with it, forcing the disconnect event (try any nonsense as SSID so that XWLAN will never connect) and a profile matching your access point, focing the connect event. IMHO this is a much more straight forward concept to change between cabled and wifi interface - much more simple and easier to use - instead of chasing icons.

Are the scripts required to be able to switch between wired and wifi, or to select one at startup?

Yes and no. First of all, for switching between cabled and wireless, the only case making real trouble is if you want access the same LAN by either method and be able to switch between them as you like - this is a topic for advanced users concerning TCP/IP, as there is a problem with TCP/IP address conflicts. You may have only one network adapter per system in the same TCP/IP address range, otherwise you easily may end up in a dead TCP/IP communication. XWLAN at least automatically detects an address conflict and offers you to deactivate either interface (wired or cabled).

If you access separate LANs with cabled or wireless (and you don't have to set a default route for the cabled network), you just use the widget and will be fine, no matter if a cable is plugged or not.

Now for switching between cabled and wireless access to the _same_ LAN (using the same TCP/IP address range), you definitely need either one script (for XWLAN) or multiple (for a solution with creating own icons on your desktop you would click instead), otherwise the cabled interface will never be reconfigured when switching back from wireless to cabled.. The XWLAN script (only one, handling both connect and disconnect event) are just a smart way to do this, as it is automatically executed when (dis)connecting from/to an access point. One may nevertheless prefer clicking on icons though, I would say it is just a question of taste. In every case I would say that using the XWLAN method is easier for novices to setup as they don't need to know TCP/IP commands - the only thing the XWLAN script would do in that case is to call setup.cmd on disconnect event (as stated in my quoted posting already).

I will think about how some information about this switching issue could be included in the INF of the next version.

I must confess that I have no clue as to how to set up wlan, even after reading the help.

The help clearly says that the interface bound to the WLAN device should be configured by XWLAN only, not by setup.cmd or any other script - see section "Installation", but I now see that this may be insufficient. In addition to the existing information another page in the installation section would make sense that could briefly explain the general steps for the following scenarios with links to the corresponding pages:

- how to connect to a public hotspot => see section "Usage" - "Detecting Public Wireless LANs"
- how to setup a connection profile => see section "Usage" - "Profile Properties" and its subpages. What needed to be added in the linking section is that you would add/edit a profile with the submenu "Add/Edit profile"

In general the INF contains already a big load of information, and it may certainly not match everybody's needs to understand it. Every suggestion to make anything clearer or every attempt to show existing problems will help to improve the docs. So thanx for the hint - you definitely found a thing missing or not well structured that was not as obvious to me (as it may look from outside that it should have been).

Thanx, Christian

-------------------------------------------------

Christian Langanke
COS2E & CWSE
Team OS/2 Ruhr e.V.
cla@clanganke.de